[TLS] Pre_shared_key Extension Question
Hi all, the currently defined “pre_shared_key” extension allows clients to send a list of the identities. I was wondering in what use cases this is useful and what policy guides the server to pick the most appropriate psk identity. I couldn't find any discussion in the document about this aspect. Ciao Hannes signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS ExtensionType Registry
Hi Ekr, Hi all, reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I noticed the TLS ExtensionType Registry on page 77 & page 78. The "TLS 1.3" column has one of four values, namely - "Client", indicating that the server shall not send them. - "Clear", indicating that they shall be in the ServerHello. - "Encrypted", indicating that they shall be in the EncryptedExtensions block - "No" indicating that they are not used in TLS 1.3. The following values deserve a closer look: +---+---+---+ | Extension | Recommend | TLS 1.3 | | |ed | | +---+---+---+ | server_name [RFC6066] | Yes | Encrypted | | | | | | max_fragment_length [RFC6066] | Yes | Encrypted | | | | | | key_share [[this document]] | Yes | Clear | | | | | | pre_shared_key [[this | Yes | Clear | | document]]| | | | | | | | cookie [[this document]] | Yes | Encrypted/HelloRetryR | | | |equest | +---+---+---+ The server_name extension is sent in the initial ClientHello and will not be encrypted since it will be used to select the right server in a hosting environment. The max_fragment_length extension is sent in the initial ClientHello but is not as essential as the server_name extension. Still, in most cases there is no security context established at the time of sending the ClientHello (at least not in the full handshake when ECDHE is used). The key_share & the pre_shared_key extension is sent in clear in the ClientHello and in the ServerHello. The cookie is not sent encrypted in the HelloRetryRequest since the HelloRetryRequest is sent when the client has not provided a suitable "key_share" value. The DoS protection feature used in the HelloRetryRequest is most likely useful only in context of an unreliable transport protocol. If you want DoS protection then the server should not store per-session state, which establishing security context would require. I believe the definition of 'clear' should be changed to: "Clear", indicating that they shall be sent in clear in the ClientHello and in the ServerHello. I fear that the use of extension in the encrypted block may be dependent on where they can first be used and also in what handshake variant. It is also a question whether it makes sense to send an extension encrypted in the ServerHello when it first appeared in clear in the ClientHello. I wonder whether the "TLS 1.3" column in this table could actually be simplified to only provide information about extensions that can be used in TLS 1.3. Whether something is sent in clear, encrypted or only be the client is something that should be described in the protocol specification itself. Ciao Hannes signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS ExtensionType Registry
On Thu, Aug 11, 2016 at 08:56:25PM +0200, Hannes Tschofenig wrote: > Hi Ekr, Hi all, > > reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I > noticed the TLS ExtensionType Registry on page 77 & page 78. > > The "TLS 1.3" column has one of four values, namely > >- "Client", indicating that the server shall not send them. >- "Clear", indicating that they shall be in the ServerHello. >- "Encrypted", indicating that they shall be > in the EncryptedExtensions block >- "No" indicating that they are not used in TLS 1.3. > > The following values deserve a closer look: > >+---+---+---+ >| Extension | Recommend | TLS 1.3 | >| |ed | | >+---+---+---+ >| server_name [RFC6066] | Yes | Encrypted | >| | | | >| max_fragment_length [RFC6066] | Yes | Encrypted | >| | | | >| key_share [[this document]] | Yes | Clear | >| | | | >| pre_shared_key [[this | Yes | Clear | >| document]]| | | >| | | | >| cookie [[this document]] | Yes | Encrypted/HelloRetryR | >| | |equest | >+---+---+---+ > > The server_name extension is sent in the initial ClientHello and will > not be encrypted since it will be used to select the right server in a > hosting environment. Actually, the server_name could be made into 'client', since the only thing server sends about server_name is an ACK, meaning it has taken it into "consideration" (in some vague way). > The max_fragment_length extension is sent in the initial ClientHello but > is not as essential as the server_name extension. Still, in most cases > there is no security context established at the time of sending the > ClientHello (at least not in the full handshake when ECDHE is used). I think max_fragement_length should be made into 'clear', given what it is used for. > The cookie is not sent encrypted in the HelloRetryRequest since the > HelloRetryRequest is sent when the client has not provided a suitable > "key_share" value. The DoS protection feature used in the > HelloRetryRequest is most likely useful only in context of an unreliable > transport protocol. If you want DoS protection then the server should > not store per-session state, which establishing security context would > require. The "encrypted" seems to be leftover from time when there were inter- connection cookies (which were removed). > I fear that the use of extension in the encrypted block may be dependent > on where they can first be used and also in what handshake variant. It > is also a question whether it makes sense to send an extension encrypted > in the ServerHello when it first appeared in clear in the ClientHello. > I wonder whether the "TLS 1.3" column in this table could actually be > simplified to only provide information about extensions that can be used > in TLS 1.3. Whether something is sent in clear, encrypted or only be the > client is something that should be described in the protocol > specification itself. Actually, in that wide sense, all extensions can be used. TLS 1.3 just forbids negotiation of some extensions. But it does not forbid client sending any extension if downnegotiation is supported. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
Looking at those emails, I am prompted to wonder if anyone can justify the existence of a ciphersuite with a double-sized key and half-sized authentication tag. RFC 6655 doesn't really explain how that is a useful thing. On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos wrote: > On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: >> All, >> >> We've received a request for early IANA assignments for the 6 cipher >> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh >> e-psk-aead/. Please respond before August 23rd if you have concerns >> about early code point assignment for these cipher suites. > > I have previously raised an issue [0] on these ciphersuites. The same > requirement was noted also by Peter Dettman as something special in > [1]. However, there has been no reaction from the authors (now in CC). > > regards, > Nikos > > [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > [1]. https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > > ___ > 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] TLS ExtensionType Registry
On 12 August 2016 at 05:09, Ilari Liusvaara wrote: > Actually, the server_name could be made into 'client', since the only > thing server sends about server_name is an ACK, meaning it has taken it > into "consideration" (in some vague way). I disagree. If it can be encrypted, then it should be. (I don't believe that we ack this in NSS, so it's moot there.) >> The max_fragment_length extension is sent in the initial ClientHello but >> is not as essential as the server_name extension. Still, in most cases >> there is no security context established at the time of sending the >> ClientHello (at least not in the full handshake when ECDHE is used). > > I think max_fragement_length should be made into 'clear', given what > it is used for. I disagree. The client doesn't need to use this value until it has read all of the server's first flight, so it can be encrypted. The server can still act on the client's value until that time. (I know that you might make an argument that it could appear in HelloRetryRequest to force the client to cut its second ClientHello smaller, but that's really tricky to get right, and I think that servers should just be prepared to swallow an entire ClientHello.) >> The cookie is not sent encrypted in the HelloRetryRequest since the >> HelloRetryRequest is sent when the client has not provided a suitable >> "key_share" value. The DoS protection feature used in the >> HelloRetryRequest is most likely useful only in context of an unreliable >> transport protocol. If you want DoS protection then the server should >> not store per-session state, which establishing security context would >> require. > > The "encrypted" seems to be leftover from time when there were inter- > connection cookies (which were removed). Yep, this needs to be Client* with a note that it appears in the HelloRetryRequest (a category in which this is currently the only resident). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
