Contributing to TLS 1.3 - Where to start?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Contributing to TLS 1.3 - Where to start?

Thiago Arrais
I'm interested in contributing to TLS 1.3 support. I'm also a total newbie to openssl development. I'm trying to build/run the tests and working through CONTRIBUTING.

For TLS 1.3 specifically, I understand that support for draft-19 of the spec is mostly done. How do I get started working on draft-20 or some of the nice-to-haves that aren't done yet? Maybe some of the things that Matt enumerated on [his reply to openssl-users][1]? Maybe getting familiar with the spec?

Where should a beginner start?

Help!

;-)

-- Thiago Arrais


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

OpenSSL - Dev mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Thiago Arrais
Hmmm... The Getting Started page talks about writing test cases.

It seems like a good start. Is there any area that needs special attention?

On Tue, Apr 4, 2017 at 11:18 AM Salz, Rich via openssl-dev <[hidden email]> wrote:
Look at https://www.openssl.org/community/ and https://www.openssl.org/community/getting-started.html as useful starting points.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Matt Caswell-2


On 04/04/17 15:34, Thiago Arrais wrote:
> Hmmm... The Getting Started page talks about writing test cases.
>
> It seems like a good start. Is there any area that needs special attention?

Actually I have a suggestion for a fairly small self-contained piece of
work suitable for a starting project.

The spec has this requirement:

   As of TLS 1.3, servers are permitted to send the "supported_groups"
   extension to the client.  If the server has a group it prefers to the
   ones in the "key_share" extension but is still willing to accept the
   ClientHello, it SHOULD send "supported_groups" to update the client's
   view of its preferences; this extension SHOULD contain all groups the
   server supports, regardless of whether they are currently supported
   by the client.  Clients MUST NOT act upon any information found in
   "supported_groups" prior to successful completion of the handshake,
   but MAY use the information learned from a successfully completed
   handshake to change what groups they use in their "key_share"
   extension in subsequent connections.

At the moment we only ever send supported_groups client -> server. Never
server -> client. I wouldn't worry about the client acting on this
information at this stage. Just start with the server sending it if the
selected key_share is not for the most preferred group.

Hint: you will need to look at ssl/statem/extensions.c and you will also
need to add code to ssl/statem/extensions_srvr.c.

I strongly suggest you spend some time looking at some other github pull
requests to get a feel for how our submission and review process works,
and the kind of review comments that come up. You should also
familiarise yourself with our coding style:

https://www.openssl.org/policies/codingstyle.html

All submissions should include tests. Adding something to
test/recipes/70-test_tls13messages.t would probably be sufficient, i.e.
a test to demonstrate that sending a preferred key_share results in no
supported_groups extension in the EncryptedExtensions message, and then
a test to demonstrate that sending an acceptable but non-preferred
key_share results in the supported_groups extension being sent.

If you are not already familiar with the TLSv1.3 spec then you will need
to be. Make sure you read it through and gain a good understanding of it
before you start.

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Thiago Arrais
Thank you, Matt.

I actually am _not_ familiar with the spec. I was looking for some work on OpenSSL exactly because I want to know TLS better.

Your suggestion seems like a good start. It is pretty dense, but that was exactly what I was looking for.

Thank you again.

-- Arrais

On Tue, Apr 4, 2017 at 2:10 PM Matt Caswell <[hidden email]> wrote:


On 04/04/17 15:34, Thiago Arrais wrote:
> Hmmm... The Getting Started page talks about writing test cases.
>
> It seems like a good start. Is there any area that needs special attention?

Actually I have a suggestion for a fairly small self-contained piece of
work suitable for a starting project.

The spec has this requirement:

   As of TLS 1.3, servers are permitted to send the "supported_groups"
   extension to the client.  If the server has a group it prefers to the
   ones in the "key_share" extension but is still willing to accept the
   ClientHello, it SHOULD send "supported_groups" to update the client's
   view of its preferences; this extension SHOULD contain all groups the
   server supports, regardless of whether they are currently supported
   by the client.  Clients MUST NOT act upon any information found in
   "supported_groups" prior to successful completion of the handshake,
   but MAY use the information learned from a successfully completed
   handshake to change what groups they use in their "key_share"
   extension in subsequent connections.

At the moment we only ever send supported_groups client -> server. Never
server -> client. I wouldn't worry about the client acting on this
information at this stage. Just start with the server sending it if the
selected key_share is not for the most preferred group.

Hint: you will need to look at ssl/statem/extensions.c and you will also
need to add code to ssl/statem/extensions_srvr.c.

I strongly suggest you spend some time looking at some other github pull
requests to get a feel for how our submission and review process works,
and the kind of review comments that come up. You should also
familiarise yourself with our coding style:

https://www.openssl.org/policies/codingstyle.html

All submissions should include tests. Adding something to
test/recipes/70-test_tls13messages.t would probably be sufficient, i.e.
a test to demonstrate that sending a preferred key_share results in no
supported_groups extension in the EncryptedExtensions message, and then
a test to demonstrate that sending an acceptable but non-preferred
key_share results in the supported_groups extension being sent.

If you are not already familiar with the TLSv1.3 spec then you will need
to be. Make sure you read it through and gain a good understanding of it
before you start.

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Viktor Dukhovni
In reply to this post by Matt Caswell-2

> On Apr 4, 2017, at 1:09 PM, Matt Caswell <[hidden email]> wrote:
>
> Actually I have a suggestion for a fairly small self-contained piece of
> work suitable for a starting project.

My suggestion would be start with something simpler still, and get used
to the format of the documentation, which will be required for future
more ambitious work.

Specifically, update the documentation of SSL_CTX_set_verify_depth(3)
to correctly describe the semantics of the "verify depth" in OpenSSL
1.1.0 and later.  The documentation was updated in the CLI verify(1)
manpage, but some of the required changes did make it into the API
document.

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Thiago Arrais
Viktor,

This is related to this message on openssl-users, right?


As I understand this isn't directly related to TLS 1.3. But it can work as an intro to the codebase.

-- Arrais

On Tue, Apr 4, 2017 at 2:50 PM Viktor Dukhovni <[hidden email]> wrote:

> On Apr 4, 2017, at 1:09 PM, Matt Caswell <[hidden email]> wrote:
>
> Actually I have a suggestion for a fairly small self-contained piece of
> work suitable for a starting project.

My suggestion would be start with something simpler still, and get used
to the format of the documentation, which will be required for future
more ambitious work.

Specifically, update the documentation of SSL_CTX_set_verify_depth(3)
to correctly describe the semantics of the "verify depth" in OpenSSL
1.1.0 and later.  The documentation was updated in the CLI verify(1)
manpage, but some of the required changes did make it into the API
document.

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Contributing to TLS 1.3 - Where to start?

Viktor Dukhovni

> On Apr 4, 2017, at 3:28 PM, Thiago Arrais <[hidden email]> wrote:
>
> Viktor,
>
> This is related to this message on openssl-users, right?
>
> https://www.mail-archive.com/openssl-users@.../msg81251.html

Yes.

> As I understand this isn't directly related to TLS 1.3. But it can work
> as an intro to the codebase.

Yes, and we want all contributions to be documented, so the documentation
is a good place to start.  Perhaps then tests, and only after that new code.

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Loading...