Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Viktor Dukhovni]

> On Apr 4, 2017, at 3:28 PM, Thiago Arrais  wrote:
> 
> Viktor,
> 
> This is related to this message on openssl-users, right?
> 
> https://www.mail-archive.com/openssl-users@openssl.org/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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Thiago Arrais]

Viktor,

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

https://www.mail-archive.com/openssl-users@openssl.org/msg81251.html

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 
wrote:

>
> > On Apr 4, 2017, at 1:09 PM, Matt Caswell  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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Viktor Dukhovni]

> On Apr 4, 2017, at 1:09 PM, Matt Caswell  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

Re: [openssl-dev] 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  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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Matt Caswell]

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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Salz, Rich via openssl-dev]

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