Re: [TLS] New review through the TLS 1.3 Editor's Copy
I've updated the draft in response to a bunch of these comments and
scheduled some for update when I enter my own review comments which
are still in the "marked up document stage"
> > EncryptedExtensions.
> > : responses to any extensions that are not required to
> > determine the cryptographic parameters. [{{encrypted-extensions}}]
>
> Also, with Certificate extensions, the extensions here need to not
> be specific to a certificate or certificate chain.
Updated.
> > Finally, the client and server exchange Authentication messages. TLS
> > uses the same set of messages every time that authentication is needed.
> > Specifically:
> >
> > Certificate.
> > : the certificate of the endpoint. This message is omitted if the
> > server is not authenticating with a certificate. Note that if raw
> > public keys {{RFC7250}} or the cached information extension
> > {{?RFC7924}} are in use, then this message will not
> > contain a certificate but rather some other value corresponding to
> > the server's long-term key. [{{certificate}}]
>
> This is also omitted for client if CertificateRequest was not sent,
> right?
>
> > CertificateVerify.
> > : a signature over the entire handshake using the public key
> > in the Certificate message. This message is omitted if the
> > server is not authenticating via a certificate.
[{{certificate-verify}}]
>
> Same as above. And additionally, for client, doesn't sending an
> empty certificate omit this?
Updated both of these.
> > ## Zero-RTT Data
> >
> > With the Zero-RTT mode, clients can send data on their first flight
> > ("early data") whereby the client uses a PSK either obtained
> > out-of-band or as a ticket (i.e., one with the "early_data_info"
> > extension) from an earlier exchange to authenticate to the server.
> >
> > When clients use a PSK obtained out-of-band then the following
> > information MUST be provisioned to both parties:
> >
> > * The PSK identity
> > * The cipher suite for use with this PSK
> > * The key exchange and authentication modes this PSK is allowed to be
used with
> > * The Application-Layer Protocol Negotiation (ALPN) label(s)
> > * The Server Name Indication (SNI), if any is to be used
>
> The ALPN labels can't be plural. There must (nothing else will work) be
> a single ALP (possibly being the implicit default ALP) for any 0-RTT-
> capable PSK.
This was updated in PR#706.
> Also, AFAIK, the reason why ticket_age exists in PSK is to support
> 0-RTT anti-replay. Without 0-RTT data, there is no point in using
> anything that doesn't involve server-side contribution anyway (and
> thus would get superrior security properties).
I don't quite agree with this. I moved it from the 0-RTT messages to the
PSK messages so that the server had an opportunity to detect replay
of the ClientHello in case it was going to send 0.5 RTT data or other
side effects. This is an observation due to someone on the miTLS team
(can't remember who) that 0.5RTT (even without 0-RTT client data)
is like a client 0-RTT "I am here" message.
> > ## Decoding Errors
> >
> > TLS defines two generic alerts (see {{alert-protocol}}) to use upon
failure to parse
> > a message. Peers which receive a message which cannot be parsed
according to the syntax
> > (e.g., have a length extending beyond the message boundary or contain
an out-of-range
> > length) MUST terminate the connection with a "decoding_error" alert.
Peers which receive
> > a message which is syntactically correct but semantically invalid
(e.g., a DHE share of p - 1)
> > MUST terminate the connection with an "illegal_parameter" alert.
>
> What alert is used if some field is an non-extensible enumeration and
> the value transmitted is outside the legal values?
>
> E.g. An unknown max_fragment_length value.
>
> I have used illegal_parameter for errors like this.
Yeah, this seems like illegal_parameter.
I updated to make this clear.
> Also, isn't the alert name decode_error, not decoding_error?
Fixed.
> > ### Client Hello
> >
> > In the event that a client requests additional functionality using
> > extensions, and this functionality is not supplied by the server, the
> > client MAY abort the handshake. Note that TLS 1.3 ClientHello messages
> > MUST always contain extensions, and a TLS 1.3 server MUST respond to
> > any TLS 1.3 ClientHello without extensions or with data following
> > the extensions block with a "decode_error"
> > alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages
> > without extensions. If negotiating TLS 1.2, a server MUST check that
> > the message either contains no data after legacy_compression_methods
> > or that it contains a valid extensions block with no data following.
> > If not, then it MUST abort the handshake with a "decode_error" alert.
>
> Note that it is now impossible to receive a TLS 1.3 ClientHello without
> extensions (any such would be interpretted as TLS 1.2 ClientHello
> without extensions).
True. Updated.
> > ### Server Hello
> >
Re: [TLS] New review through the TLS 1.3 Editor's Copy
[I trimmed a couple things that already had sub-threads spun off;
leaving in others even where I don't have a comment right now]
On 10/17/2016 01:10 PM, Ilari Liusvaara wrote:
>
>> Finally, the client and server exchange Authentication messages. TLS
>> uses the same set of messages every time that authentication is needed.
>> Specifically:
>>
>> Certificate.
>> : the certificate of the endpoint. This message is omitted if the
>> server is not authenticating with a certificate. Note that if raw
>> public keys {{RFC7250}} or the cached information extension
>> {{?RFC7924}} are in use, then this message will not
>> contain a certificate but rather some other value corresponding to
>> the server's long-term key. [{{certificate}}]
> This is also omitted for client if CertificateRequest was not sent,
> right?
That as my understanding.
>> CertificateVerify.
>> : a signature over the entire handshake using the public key
>> in the Certificate message. This message is omitted if the
>> server is not authenticating via a certificate. [{{certificate-verify}}]
> Same as above. And additionally, for client, doesn't sending an
> empty certificate omit this?
For post-handshake, that is explicitly stated. It is also implicitly
stated for in-handshake ("Clients MUST send this message
[CertificateVerify] whenever authenticating via a Certificate (i.e.,
when the Certificate message is non-empty)."
>> ## Zero-RTT Data
>>
>> With the Zero-RTT mode, clients can send data on their first flight
>> ("early data") whereby the client uses a PSK either obtained
>> out-of-band or as a ticket (i.e., one with the "early_data_info"
>> extension) from an earlier exchange to authenticate to the server.
>>
>> When clients use a PSK obtained out-of-band then the following
>> information MUST be provisioned to both parties:
>>
>> * The PSK identity
>> * The cipher suite for use with this PSK
>> * The key exchange and authentication modes this PSK is allowed to be used
>> with
>> * The Application-Layer Protocol Negotiation (ALPN) label(s)
>> * The Server Name Indication (SNI), if any is to be used
> The ALPN labels can't be plural. There must (nothing else will work) be
> a single ALP (possibly being the implicit default ALP) for any 0-RTT-
> capable PSK.
I pointed this out on Kyle's declined pull request and he fixed it in a
later one that has already been merged.
> Also, AFAIK, the reason why ticket_age exists in PSK is to support
> 0-RTT anti-replay. Without 0-RTT data, there is no point in using
> anything that doesn't involve server-side contribution anyway (and
> thus would get superrior security properties).
>
I basically agree, and see only minimal reason why the ticket_age_add
needs to be mandatory. Sure, it can give the server some insight into
rejecting stale tickets, but there are other ways to do so.
>> 2. There are no guarantees of non-replay between connections.
>> Unless the server takes special measures outside those provided by TLS,
>> the server has no guarantee that the same
>> 0-RTT data was not transmitted on multiple 0-RTT connections
>> (See {{replay-time}} for more details).
>> This is especially relevant if the data is authenticated either
>> with TLS client authentication or inside the application layer
>> protocol. However, 0-RTT data cannot be duplicated within a connection
>> (i.e., the server
>> will not process the same data twice for the same connection) and
>> an attacker will not be able to make 0-RTT data appear to be
>> 1-RTT data (because it is protected with different keys.)
> Of course, if the server TLS library provodes the difference between
> 0-RTT and 1-RTT data is a different matter...
Yes, the library has to tell the application that 0-RTT data and 1-RTT
data are different, or bad things happen. Watson had some text to that
effect in PR 694, which was not accepted (some text in a
counter-proposal by Martin Thomson was accepted).
>> ### Server Hello
>>
>> version
>> : This field contains the version of TLS negotiated for this session.
>> Servers
>> MUST select the lower of the highest supported server version and the
>> version
>> offered by the client in the ClientHello. In particular, servers MUST
>> accept
>> ClientHello messages with versions higher than those supported and
>> negotiate
>> the highest mutually supported version. For this version of the
>> specification, the version is { 3, 4 }. (See {{backward-compatibility}}
>> for
>> details about backward compatibility.)
> Err, don't they have to select highest client indicated version that they
> support (now that version negotiation is with extensions)?
>
Basically. It is not clear to me whether there is consensus to say
"highest version" or just "server picks".
>> ## Hello Extensions
>>
>> An extension type MUST NOT appear in the ServerHello or HelloRetryRequest
>> unless the same extension type appeared in the corresponding ClientHello.
>> If a client receives an
Re: [TLS] New review through the TLS 1.3 Editor's Copy
On Monday, 17 October 2016 21:10:30 CEST Ilari Liusvaara wrote:
> > ## Decoding Errors
> >
> > TLS defines two generic alerts (see {{alert-protocol}}) to use upon
> > failure to parse a message. Peers which receive a message which cannot be
> > parsed according to the syntax (e.g., have a length extending beyond the
> > message boundary or contain an out-of-range length) MUST terminate the
> > connection with a "decoding_error" alert. Peers which receive a message
> > which is syntactically correct but semantically invalid (e.g., a DHE
> > share of p - 1) MUST terminate the connection with an "illegal_parameter"
> > alert.
>
> What alert is used if some field is an non-extensible enumeration and
> the value transmitted is outside the legal values?
>
> E.g. An unknown max_fragment_length value.
>
> I have used illegal_parameter for errors like this.
That would be my reading of the text too.
Anything that can be parsed given the requirements on structs should not
generate decode_error, if it needs to be rejected because of other
limitations, it should result in an illegal_parameter.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New review through the TLS 1.3 Editor's Copy
On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote:
> > %%% Authentication Messages
>
> > If sent by a server, the signature algorithm MUST be one offered in the
> > client's "signature_algorithms" extension unless no valid certificate chain
> > can be
> > produced without unsupported algorithms (see {{signature-algorithms}}).
>
> This is seemingly about server signatures. In that context, an
> unknown algorithm has absolutely no chance of working.
This came up in a discussion a while back and we decided to allow unsupported
algorithms as a last-ditch fall-back. Opportunistic encryption might not care
and there are systems that may trust certs as a whole, not caring about the
signatures. The end result is that the client should be tasked with making the
decision to accept or reject, not the server. Also can be helpful for debugging.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] New review through the TLS 1.3 Editor's Copy
Did a new review of the document, given that stuff from the older
review got addressed.
Consulted the older review when making this, but not the issue lists:
> EncryptedExtensions.
> : responses to any extensions that are not required to
> determine the cryptographic parameters. [{{encrypted-extensions}}]
Also, with Certificate extensions, the extensions here need to not
be specific to a certificate or certificate chain.
> Finally, the client and server exchange Authentication messages. TLS
> uses the same set of messages every time that authentication is needed.
> Specifically:
>
> Certificate.
> : the certificate of the endpoint. This message is omitted if the
> server is not authenticating with a certificate. Note that if raw
> public keys {{RFC7250}} or the cached information extension
> {{?RFC7924}} are in use, then this message will not
> contain a certificate but rather some other value corresponding to
> the server's long-term key. [{{certificate}}]
This is also omitted for client if CertificateRequest was not sent,
right?
> CertificateVerify.
> : a signature over the entire handshake using the public key
> in the Certificate message. This message is omitted if the
> server is not authenticating via a certificate. [{{certificate-verify}}]
Same as above. And additionally, for client, doesn't sending an
empty certificate omit this?
> ## Zero-RTT Data
>
> With the Zero-RTT mode, clients can send data on their first flight
> ("early data") whereby the client uses a PSK either obtained
> out-of-band or as a ticket (i.e., one with the "early_data_info"
> extension) from an earlier exchange to authenticate to the server.
>
> When clients use a PSK obtained out-of-band then the following
> information MUST be provisioned to both parties:
>
> * The PSK identity
> * The cipher suite for use with this PSK
> * The key exchange and authentication modes this PSK is allowed to be used
> with
> * The Application-Layer Protocol Negotiation (ALPN) label(s)
> * The Server Name Indication (SNI), if any is to be used
The ALPN labels can't be plural. There must (nothing else will work) be
a single ALP (possibly being the implicit default ALP) for any 0-RTT-
capable PSK.
Also, AFAIK, the reason why ticket_age exists in PSK is to support
0-RTT anti-replay. Without 0-RTT data, there is no point in using
anything that doesn't involve server-side contribution anyway (and
thus would get superrior security properties).
> 2. There are no guarantees of non-replay between connections.
> Unless the server takes special measures outside those provided by TLS,
> the server has no guarantee that the same
> 0-RTT data was not transmitted on multiple 0-RTT connections
> (See {{replay-time}} for more details).
> This is especially relevant if the data is authenticated either
> with TLS client authentication or inside the application layer
> protocol. However, 0-RTT data cannot be duplicated within a connection (i.e.,
> the server
> will not process the same data twice for the same connection) and
> an attacker will not be able to make 0-RTT data appear to be
> 1-RTT data (because it is protected with different keys.)
Of course, if the server TLS library provodes the difference between
0-RTT and 1-RTT data is a different matter...
> ## Decoding Errors
>
> TLS defines two generic alerts (see {{alert-protocol}}) to use upon failure
> to parse
> a message. Peers which receive a message which cannot be parsed according to
> the syntax
> (e.g., have a length extending beyond the message boundary or contain an
> out-of-range
> length) MUST terminate the connection with a "decoding_error" alert. Peers
> which receive
> a message which is syntactically correct but semantically invalid (e.g., a
> DHE share of p - 1)
> MUST terminate the connection with an "illegal_parameter" alert.
What alert is used if some field is an non-extensible enumeration and
the value transmitted is outside the legal values?
E.g. An unknown max_fragment_length value.
I have used illegal_parameter for errors like this.
Also, isn't the alert name decode_error, not decoding_error?
> ### Client Hello
>
> In the event that a client requests additional functionality using
> extensions, and this functionality is not supplied by the server, the
> client MAY abort the handshake. Note that TLS 1.3 ClientHello messages
> MUST always contain extensions, and a TLS 1.3 server MUST respond to
> any TLS 1.3 ClientHello without extensions or with data following
> the extensions block with a "decode_error"
> alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages
> without extensions. If negotiating TLS 1.2, a server MUST check that
> the message either contains no data after legacy_compression_methods
> or that it contains a valid extensions block with no data following.
> If not, then it MUST abort the handshake with a "decode_error" alert.
Note that it is now impossible to receive a TLS 1.3 ClientHello without
