Re: [TLS] ServerHello extensions

[R du Toit]

https://github.com/tlswg/tls13-spec/pull/1143

 

 

From: Eric Rescorla 
Date: Thursday, January 18, 2018 at 1:25 PM
To: R du Toit 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ServerHello extensions

 

Thanks. These are good points. I would welcome a PR.

 

On Thu, Jan 18, 2018 at 10:21 AM, R du Toit  wrote:

Issue#1: Section "4.1.3 Server Hello" currently states:

extensions   A list of extensions. The ServerHello MUST only include extensions 
which are required to establish the cryptographic context. Currently the only 
such extensions are “key_share” and “pre_shared_key”. All current TLS 1.3 
ServerHello messages will contain one of these two extensions, or both when 
using a PSK with (EC)DHE key establishment. The remaining extensions are sent 
separately in the EncryptedExtensions message.

 

"supported_versions" should be added to the list of required extensions for a 
session that negotiates TLS 1.3.

 

 

Issue#2: Section "4.1.4 Hello Retry Request" currently states:

Upon receiving the ServerHello, clients MUST check that the cipher suite 
supplied in the ServerHello is the same as that in the HelloRetryRequest and 
otherwise abort the handshake with an “illegal_parameter” alert.

 

There is no rule about checking that SH.supported_versions.selected_version 
matches HRR.supported_versions.selected_version.   I am currently adding draft 
23 support, and want to enforce that rule to make sure the protocol state 
machine does not have to jump back and forth between TLS 1.2 and TLS 1.3.

 

I can add a PR for both issues, if you agree.

 

--Roelof

 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ServerHello extensions

[Eric Rescorla]

Thanks. These are good points. I would welcome a PR.

On Thu, Jan 18, 2018 at 10:21 AM, R du Toit  wrote:

> Issue#1: Section "4.1.3 Server Hello" currently states:
>
> *extensions   A list of extensions. The ServerHello MUST only include
> extensions which are required to establish the cryptographic context.
> Currently the only such extensions are “key_share” and “pre_shared_key”.
> All current TLS 1.3 ServerHello messages will contain one of these two
> extensions, or both when using a PSK with (EC)DHE key establishment. The
> remaining extensions are sent separately in the EncryptedExtensions
> message.*
>
>
>
> "supported_versions" should be added to the list of required extensions
> for a session that negotiates TLS 1.3.
>
>
>
>
>
> Issue#2: Section "4.1.4 Hello Retry Request" currently states:
>
> *Upon receiving the ServerHello, clients MUST check that the cipher suite
> supplied in the ServerHello is the same as that in the HelloRetryRequest
> and otherwise abort the handshake with an “illegal_parameter” alert.*
>
>
>
> There is no rule about checking that
> *SH.supported_versions.selected_version* matches
> *HRR.supported_versions.selected_version*.   I am currently adding draft
> 23 support, and want to enforce that rule to make sure the protocol state
> machine does not have to jump back and forth between TLS 1.2 and TLS 1.3.
>
>
>
> I can add a PR for both issues, if you agree.
>
>
>
> --Roelof
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ServerHello extensions

[Benjamin Kaduk]

On 01/18/2018 12:21 PM, R du Toit wrote:
> I can add a PR for both issues, if you agree.

Please do.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ServerHello extensions

[R du Toit]

Issue#1: Section "4.1.3 Server Hello" currently states:

extensions   A list of extensions. The ServerHello MUST only include extensions 
which are required to establish the cryptographic context. Currently the only 
such extensions are “key_share” and “pre_shared_key”. All current TLS 1.3 
ServerHello messages will contain one of these two extensions, or both when 
using a PSK with (EC)DHE key establishment. The remaining extensions are sent 
separately in the EncryptedExtensions message.

 

"supported_versions" should be added to the list of required extensions for a 
session that negotiates TLS 1.3.

 

 

Issue#2: Section "4.1.4 Hello Retry Request" currently states:

Upon receiving the ServerHello, clients MUST check that the cipher suite 
supplied in the ServerHello is the same as that in the HelloRetryRequest and 
otherwise abort the handshake with an “illegal_parameter” alert.

 

There is no rule about checking that SH.supported_versions.selected_version 
matches HRR.supported_versions.selected_version.   I am currently adding draft 
23 support, and want to enforce that rule to make sure the protocol state 
machine does not have to jump back and forth between TLS 1.2 and TLS 1.3.

 

I can add a PR for both issues, if you agree.

 

--Roelof

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] signature_algorithms_cert extension

[Eric Rescorla]

On Thu, Jan 18, 2018 at 3:29 AM, Matt Caswell  wrote:

> The specification of the new signature_algorithms_cert seems somewhat
> lacking to me. There is very little description about how it should be
> interpreted. About the best I can get from the spec is this:
>
>The "signature_algorithms_cert" extension applies to signatures in
>certificates and the "signature_algorithms" extension, which
>originally appeared in TLS 1.2, applies to signatures in
>CertificateVerify messages.
>
> But in section 4.4.2.2 we see this:
>
>All certificates provided by the server MUST be signed by a signature
>algorithm that appears in the "signature_algorithms" extension
>provided by the client, if they are able to provide such a chain (see
>Section 4.2.3).  Certificates that are self-signed or certificates
>that are expected to be trust anchors are not validated as part of
>the chain and therefore MAY be signed with any algorithm.
>
>
> Is this an oversight? Should this reference "signature_algorithms_cert"
> as well/instead?
>

Yes, it's an oversight that it didn't get added here.


Some questions:
>
> - Is "signature_algorithms_cert" mandatory to implement for servers? It
> does not appear in 9.2 so I am assuming not. There is some text in 4.2.3
>  which says what to do if "signature_algorithms_cert" is not present -
> which seems to confirm that it is not mandatory for clients at least.
>

Both sides need to implement it for the purposes of filtering the
certificates
they send. Neither side need send it if it has a consistent policy for
CertVerify
and chain validation.


- Are we allowed to ignore "signature_algorithms_cert" if we can't build
> a chain and honour its contents?
>

Same rules as signature_algorithms.

I have filed https://github.com/tlswg/tls13-spec/pull/1142 to clarify these
points.

-Ekr



>
> Matt
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] signature_algorithms_cert extension

[Matt Caswell]

The specification of the new signature_algorithms_cert seems somewhat
lacking to me. There is very little description about how it should be
interpreted. About the best I can get from the spec is this:

   The "signature_algorithms_cert" extension applies to signatures in
   certificates and the "signature_algorithms" extension, which
   originally appeared in TLS 1.2, applies to signatures in
   CertificateVerify messages.

But in section 4.4.2.2 we see this:

   All certificates provided by the server MUST be signed by a signature
   algorithm that appears in the "signature_algorithms" extension
   provided by the client, if they are able to provide such a chain (see
   Section 4.2.3).  Certificates that are self-signed or certificates
   that are expected to be trust anchors are not validated as part of
   the chain and therefore MAY be signed with any algorithm.


Is this an oversight? Should this reference "signature_algorithms_cert"
as well/instead?

Some questions:

- Is "signature_algorithms_cert" mandatory to implement for servers? It
does not appear in 9.2 so I am assuming not. There is some text in 4.2.3
 which says what to do if "signature_algorithms_cert" is not present -
which seems to confirm that it is not mandatory for clients at least.

- Are we allowed to ignore "signature_algorithms_cert" if we can't build
a chain and honour its contents?


Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls