[TLS] certificate_request_context
Hi all, I am wondering why the certificate_request_context field found in the CertificateRequest and in the Certificate message is so long. It is supposed to be used to match a certificate request against incoming certificate. Does the field really need to be up to 256 bytes long? I think 8 bytes should be more than enough. I would also like to suggest to change the definition of certificate_request_context: Here is the current text since the last sentence feels misleading: " certificate_request_context An opaque string which identifies the certificate request and which will be echoed in the client’s Certificate message. The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client CertificateVerify messages). Within the handshake, this field MUST be empty. " " certificate_request_context An opaque string which identifies the certificate request and which will be echoed in the client’s Certificate message. The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client CertificateVerify messages). This field SHALL be zero length unless used for post-handshake authentication described in Section 4.5.2. " Ciao Hannes signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
On Fri, Oct 07, 2016 at 09:48:32AM +0200, Hannes Tschofenig wrote: > Hi all, > > I am wondering why the certificate_request_context field found in the > CertificateRequest and in the Certificate message is so long. It is > supposed to be used to match a certificate request against incoming > certificate. > > Does the field really need to be up to 256 bytes long? I think 8 bytes > should be more than enough. I presume 255, but whatever... If application supports any sort of multiplexing (e.g. HTTP/2), one presumably wants the context to be non-opaque and identify the stream that caused the request + some parameters about the request (to avoid duplicating those in application layer). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
On 7 October 2016 at 19:34, Ilari Liusvaara wrote: > If application supports any sort of multiplexing (e.g. HTTP/2), one > presumably wants the context to be non-opaque and identify the stream > that caused the request + some parameters about the request (to avoid > duplicating those in application layer). It's opaque to TLS. And 255 simply establishes the number of octets in the length (1), if you don't need that much context (few will even if they implement this), don't use the extra space. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] HMAC context of ClientFinished in TLS 1.3
Hi, Recently I have started writing a TLS 1.3 implementation. While working on it, I have noticed the following. In section 4.4.3, the hash value used for building the HMAC is defined as: Hash(Handshake Context + Certificate* + CertificateVerify*). For ServerFinished, this corresponds to the statement following the formula that states, quote: the HMAC input can generally be implemented by a running hash, i.e., just the handshake hash at this point. since Handshake Context for 1-RTT server is (as defined in section 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest. However, for ClientFinished, the two descriptions do not match, since Handshake Context for 1RTT client is: ClientHello … ServerFinished. If we follow the way it is defined in the formula, then Certificate and CertificateVerify needs to be applied to the hash after ServerFinished, which is in discordance with the statement that it could be implemented using a running hash. Is this an error in the draft? -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
Hi Martin, the problem is that with embedded implementations you need to be prepared to receive this amount of data when the specification says so. On 10/07/2016 10:59 AM, Martin Thomson wrote: > On 7 October 2016 at 19:34, Ilari Liusvaara wrote: >> If application supports any sort of multiplexing (e.g. HTTP/2), one >> presumably wants the context to be non-opaque and identify the stream >> that caused the request + some parameters about the request (to avoid >> duplicating those in application layer). > > > It's opaque to TLS. And 255 simply establishes the number of octets > in the length (1), if you don't need that much context (few will even > if they implement this), don't use the extra space. > signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
On 7 October 2016 at 20:45, Hannes Tschofenig wrote: > the problem is that with embedded implementations you need to be > prepared to receive this amount of data when the specification says so. How are you managing 65k session tickets, extensions, cipher suite lists, supported group lists, etc...? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HMAC context of ClientFinished in TLS 1.3
On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote: > Hi, > > Recently I have started writing a TLS 1.3 implementation. While > working on it, I have noticed the following. > > In section 4.4.3, the hash value used for building the HMAC is defined > as: Hash(Handshake Context + Certificate* + CertificateVerify*). > > For ServerFinished, this corresponds to the statement following the > formula that states, quote: > > the HMAC input can generally be implemented by a running hash, > i.e., just the handshake hash at this point. > > since Handshake Context for 1-RTT server is (as defined in section > 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest. > > However, for ClientFinished, the two descriptions do not match, since > Handshake Context for 1RTT client is: ClientHello … ServerFinished. > > If we follow the way it is defined in the formula, then Certificate > and CertificateVerify needs to be applied to the hash after > ServerFinished, which is in discordance with the statement that it > could be implemented using a running hash. Nope, it is a running hash: The server Finished includes the following messages, in this order: - ClientHello - HelloRetryRequest (if sent) - Clienthello (another, if HRR was sent) - ServerHello - EncryptedExtensions - CertificateRequest (if sent) - Certificate (server's) - CertificateVerify (server's) And this exactly corresponds to the send/receive order. The client finished includes, in this order: - ClientHello - HelloRetryRequest (if sent) - Clienthello (another, if HRR was sent) - ServerHello - EncryptedExtensions - CertificateRequest (if sent) - Certificate (server's) - CertificateVerify (server's) - Finished (server's) - Certificate (client's, if CR was sent). - CertificateVerify (client's, if non-empty client cert was sent) And this exactly corresponds to the send/receive order. One place to be careful of is client application keys: The hash used for those is taken immediately after ServerFinished, but the keys are only commissioned after ClientFinished (whereas server keys have the hash taken in the same time as those are commissioned in). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
Hi Martin, this may be an implementation specific issue but some of the parameters I have to keep in memory while others I "only" have to parse. In some cases the embedded implementation also has control over the number of parameters being included in a message (which is useful for bandwidth reasons as well). Ideally, I would prefer to have the length of a field somehow relate to the content. Going through all the parameters and re-evaluating whether the size is indeed appropriate might be a good idea. Ciao Hannes PS: For the reason that embedded devices don't have an endless amount of RAM the max_fragment_length extension was introduced and in https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 we suggest to also apply this concepts to lightweight TLS server implementations. On 10/07/2016 11:59 AM, Martin Thomson wrote: > On 7 October 2016 at 20:45, Hannes Tschofenig > wrote: >> the problem is that with embedded implementations you need to be >> prepared to receive this amount of data when the specification says so. > > How are you managing 65k session tickets, extensions, cipher suite > lists, supported group lists, etc...? > signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Milestones changed for tls WG
Changed milestone "Move ECC-based CS to Standards Track", set state to active from review, accepting new milestone. Changed milestone "DANE Record and DNSSEC Authentication Chain Extension for TLS to IESG", set state to active from review, accepting new milestone. Changed milestone "DTLS1.3 to IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tls/charter/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
I don't think it would be sensible to set an upper limit in this case (those lead to regrets in my experience), however, recommending that the value be kept as small as possible seems OK. It's probably redundant advice though. Since this is extremely transitory state, I sort-of assumed that it would be OK. And it's zero-length during the handshake. Were you planning on having super-constrained devices with post-handshake auth support? On 7 October 2016 at 21:30, Hannes Tschofenig wrote: > Hi Martin, > > this may be an implementation specific issue but some of the parameters > I have to keep in memory while others I "only" have to parse. In some > cases the embedded implementation also has control over the number of > parameters being included in a message (which is useful for bandwidth > reasons as well). > > Ideally, I would prefer to have the length of a field somehow relate to > the content. > > Going through all the parameters and re-evaluating whether the size is > indeed appropriate might be a good idea. > > Ciao > Hannes > > PS: For the reason that embedded devices don't have an endless amount of > RAM the max_fragment_length extension was introduced and in > https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 > we suggest to also apply this concepts to lightweight TLS server > implementations. > > On 10/07/2016 11:59 AM, Martin Thomson wrote: >> On 7 October 2016 at 20:45, Hannes Tschofenig >> wrote: >>> the problem is that with embedded implementations you need to be >>> prepared to receive this amount of data when the specification says so. >> >> How are you managing 65k session tickets, extensions, cipher suite >> lists, supported group lists, etc...? >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HMAC context of ClientFinished in TLS 1.3
Hi, Thank you very much for the clarification and the advise. I had indeed forgotten to consider the client certificate and its verify message. iPhoneから送信 2016/10/07 19:14、Ilari Liusvaara のメッセージ: >> On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote: >> Hi, >> >> Recently I have started writing a TLS 1.3 implementation. While >> working on it, I have noticed the following. >> >> In section 4.4.3, the hash value used for building the HMAC is defined >> as: Hash(Handshake Context + Certificate* + CertificateVerify*). >> >> For ServerFinished, this corresponds to the statement following the >> formula that states, quote: >> >>the HMAC input can generally be implemented by a running hash, >> i.e., just the handshake hash at this point. >> >> since Handshake Context for 1-RTT server is (as defined in section >> 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest. >> >> However, for ClientFinished, the two descriptions do not match, since >> Handshake Context for 1RTT client is: ClientHello … ServerFinished. >> >> If we follow the way it is defined in the formula, then Certificate >> and CertificateVerify needs to be applied to the hash after >> ServerFinished, which is in discordance with the statement that it >> could be implemented using a running hash. > > Nope, it is a running hash: > > The server Finished includes the following messages, in this order: > > - ClientHello > - HelloRetryRequest (if sent) > - Clienthello (another, if HRR was sent) > - ServerHello > - EncryptedExtensions > - CertificateRequest (if sent) > - Certificate (server's) > - CertificateVerify (server's) > > And this exactly corresponds to the send/receive order. > > > The client finished includes, in this order: > > - ClientHello > - HelloRetryRequest (if sent) > - Clienthello (another, if HRR was sent) > - ServerHello > - EncryptedExtensions > - CertificateRequest (if sent) > - Certificate (server's) > - CertificateVerify (server's) > - Finished (server's) > - Certificate (client's, if CR was sent). > - CertificateVerify (client's, if non-empty client cert was sent) > > And this exactly corresponds to the send/receive order. > > > One place to be careful of is client application keys: The hash used > for those is taken immediately after ServerFinished, but the keys are > only commissioned after ClientFinished (whereas server keys have the > hash taken in the same time as those are commissioned in). > > > > -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] certificate_request_context
Hi Martin, post-handshake authentication is indeed probably something that is less likely to happen in the embedded environment and I will check whether there are some use cases that require it. If it isn't required then the best possible alternative at the moment is for an embedded client implementation to immediately return a Certificate message containing no certificates followed by Finished. Thanks for your thoughts on this topic! Ciao Hannes On 10/07/2016 01:51 PM, Martin Thomson wrote: > I don't think it would be sensible to set an upper limit in this case > (those lead to regrets in my experience), however, recommending that > the value be kept as small as possible seems OK. It's probably > redundant advice though. > > Since this is extremely transitory state, I sort-of assumed that it > would be OK. And it's zero-length during the handshake. Were you > planning on having super-constrained devices with post-handshake auth > support? > > On 7 October 2016 at 21:30, Hannes Tschofenig > wrote: >> Hi Martin, >> >> this may be an implementation specific issue but some of the parameters >> I have to keep in memory while others I "only" have to parse. In some >> cases the embedded implementation also has control over the number of >> parameters being included in a message (which is useful for bandwidth >> reasons as well). >> >> Ideally, I would prefer to have the length of a field somehow relate to >> the content. >> >> Going through all the parameters and re-evaluating whether the size is >> indeed appropriate might be a good idea. >> >> Ciao >> Hannes >> >> PS: For the reason that embedded devices don't have an endless amount of >> RAM the max_fragment_length extension was introduced and in >> https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 >> we suggest to also apply this concepts to lightweight TLS server >> implementations. >> >> On 10/07/2016 11:59 AM, Martin Thomson wrote: >>> On 7 October 2016 at 20:45, Hannes Tschofenig >>> wrote: the problem is that with embedded implementations you need to be prepared to receive this amount of data when the specification says so. >>> >>> How are you managing 65k session tickets, extensions, cipher suite >>> lists, supported group lists, etc...? >>> >> signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Finished stuffing/PSK Binders
After the discussion on PR #615, I took another pass at this with some help from the research community. Please see: https://github.com/tlswg/tls13-spec/pull/672 Key changes in this PR: 1. I have merged the HMAC into the PreSharedKey message, where it is now called "PSK Binder" to make very clear what the purpose of the HMAC it is (this suggestion due to Karthik Bhargavan) This also makes implementation somewhat easier and avoids creating another extension. 2. It is now possible to have >1 PSK, each with its own binder. 3. The binder is now computed over the ClientHello prefix rather than filling the MAC with zeroes. 4. I've taken a suggestion from David Benjamin to move the negotiation of the PSK key exchange parameters out of the PSK itself and into a separate message. This cleans things up and also lets us drop the currently non-useful auth_mode parameter. This text is still a bit rough but I think shows the right direction. As usual, comments welcome, but I think the key question we need to resolve is whether we really need multiple PSKs. It's clearly simpler not to support them but it seems like we need to worry about the case where we are resuming a session created with a PSK. I've come to the conclusion that if we want to have multiple concurrent PSKs at all, then this is the right structure, rather than having one PSK and using HRR to fix it. ISTM that the other major alternatives are to say: 1. You can't resume sessions created with a PSK. 2. Tickets created in sessions created with a PSK have a hard lifetime value and it's a failure if the server forgets during the lifetime (this seems like it's going to interact badly with clock skew). Note that if we decide that we only want one PSK, I'll just revise the PreSharedKey section to have one, not a list [0]. Thanks, -Ekr [0] In fairness, it's also worth noting that if we decide to only have one, it's possible in the future to replace the PreSharedKey extension with a MultiplePreSharedKey extension. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Earlier exporters
Please see the following PR: https://github.com/tlswg/tls13-spec/pull/673 This includes various changes to make exporters/resumption work better. Basically: 1. Add a 0-RTT exporter and change the transcript for the regular exporter so it only includes the transcript up to ServerFinished. This gives it parity with the rest of the traffic keys. If we need an exporter with the full transcript we can always add it later 2. Point out that you can predict ClientFinished for NST when not doing Client auth. This lets you issue tickets on the server's first flight, while still ensuring that if you do client auth you still bind resumption to the client's full transcript. These are pretty straightforward changes, so absent objections I'll merge them early next week. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Finished stuffing/PSK Binders
On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > After the discussion on PR #615, I took another pass at this with some > help from the research community. Please see: > >https://github.com/tlswg/tls13-spec/pull/672 > > > Key changes in this PR: > > 1. I have merged the HMAC into the PreSharedKey message, where it is > now called "PSK Binder" to make very clear what the purpose of the > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes > implementation somewhat easier and avoids creating another extension. > > 2. It is now possible to have >1 PSK, each with its own binder. > > 3. The binder is now computed over the ClientHello prefix rather than > filling the MAC with zeroes. > > 4. I've taken a suggestion from David Benjamin to move the negotiation > of the PSK key exchange parameters out of the PSK itself and into a > separate message. This cleans things up and also lets us drop the > currently non-useful auth_mode parameter. Eeh... From the text, it seems to currently require the kex modes extension if PSK extension is present. Which seems worse than useless if the meaning is to get rid of the kex mode parameter from PSK extension (since you will have the value anyway, but need to dig it from another extension... Blech). > This text is still a bit rough but I think shows the right direction. I would talk about PSKs established by NST, not resumption PSKs. Also, didn't notice what prevents pathology like this (I presume this is not allowed): (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> [0-RTT data, encrypted using AES-128-GCM-SHA256] <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] <-- EncryptedExtensions[EarlyDataIndication] Note the record protection algorithm mismatch. Also, to straightforwardly prove that collision resistance of HKDF and HMAC (as used) follows from collision resistance of the underlying hash function, yon need to take the output to be at least the hash output size. As otherwise it is not guaranteed that any collision in HKDF or HMAC can be reduced into collision of the underlying hash. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Finished stuffing/PSK Binders
On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > After the discussion on PR #615, I took another pass at this with some > > help from the research community. Please see: > > > >https://github.com/tlswg/tls13-spec/pull/672 > > > > > > Key changes in this PR: > > > > 1. I have merged the HMAC into the PreSharedKey message, where it is > > now called "PSK Binder" to make very clear what the purpose of the > > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes > > implementation somewhat easier and avoids creating another extension. > > > > 2. It is now possible to have >1 PSK, each with its own binder. > > > > 3. The binder is now computed over the ClientHello prefix rather than > > filling the MAC with zeroes. > > > > 4. I've taken a suggestion from David Benjamin to move the negotiation > > of the PSK key exchange parameters out of the PSK itself and into a > > separate message. This cleans things up and also lets us drop the > > currently non-useful auth_mode parameter. > > Eeh... From the text, it seems to currently require the kex modes > extension if PSK extension is present. Which seems worse than useless > if the meaning is to get rid of the kex mode parameter from PSK > extension (since you will have the value anyway, but need to dig it > from another extension... Blech). > I guess this is a matter of taste, but what convinced me was that: 1. It put all the logic on the server side. 2. It removed the auth mod parameter. Maybe david can say more. > This text is still a bit rough but I think shows the right direction. > > I would talk about PSKs established by NST, not resumption PSKs. > Willdo. > > Also, didn't notice what prevents pathology like this (I presume this > is not allowed): > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> > [0-RTT data, encrypted using AES-128-GCM-SHA256] > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > <-- EncryptedExtensions[EarlyDataIndication] > > Note the record protection algorithm mismatch. > Yes, this is forbidden by the combination of: "The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK. The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension." (though I think I just recently added cipher suite). and: "Any ticket MUST only be resumed with a cipher suite that is identical to that negotiated connection where the ticket was established." Also, to straightforwardly prove that collision resistance of HKDF and > HMAC (as used) follows from collision resistance of the underlying hash > function, yon need to take the output to be at least the hash output > size. As otherwise it is not guaranteed that any collision in HKDF or > HMAC can be reduced into collision of the underlying hash. > Right. I have some text here but please feel free to suggest more. -Ekr > > > > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Add max_early_data_size to TicketEarlyDataInfo
Hello, Cloudflare's current (not definitive) plan for 0-RTT is essentially to decide whether or not to answer to requests in the 0.5 flight on a case-by-case basis. That obviously requires reading all of them and caching the ones we don't want to answer. To mitigate the obvious DoS concern we plan to use the ticket age and a per-machine replay cache. However, chatting with Drew (cc'd) we realized that clients could still send huge amounts of 0-RTT data that we would have to buffer. Once a client sent early data, there's no way to accept only a part of it or to verify that the client is not replaying before reading it all. But if we were to close the connection after a given amount of data we risk failing connections from legal clients. I propose to add a field max_early_data_size to TicketEarlyDataInfo, to inform clients about the maximum amount of 0-RTT data they are allowed to send, allowing servers to safely terminate connections that exceed it. https://github.com/tlswg/tls13-spec/pull/674 [Please keep me in the CC of replies] ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Finished stuffing/PSK Binders
On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > 4. I've taken a suggestion from David Benjamin to move the negotiation > > > of the PSK key exchange parameters out of the PSK itself and into a > > > separate message. This cleans things up and also lets us drop the > > > currently non-useful auth_mode parameter. > > > > Eeh... From the text, it seems to currently require the kex modes > > extension if PSK extension is present. Which seems worse than useless > > if the meaning is to get rid of the kex mode parameter from PSK > > extension (since you will have the value anyway, but need to dig it > > from another extension... Blech). > > I guess this is a matter of taste, but what convinced me was that: > > 1. It put all the logic on the server side. > 2. It removed the auth mod parameter. > > Maybe david can say more. I mean if server is to accept PSK, it must now go fishing for another extension, check that it is present and pay attention to values there. As opposed to having the data in where it is needed. > > Also, didn't notice what prevents pathology like this (I presume this > > is not allowed): > > > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> > > [0-RTT data, encrypted using AES-128-GCM-SHA256] > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > > <-- EncryptedExtensions[EarlyDataIndication] > > > > Note the record protection algorithm mismatch. > > > > Yes, this is forbidden by the combination of: > > "The parameters for the 0-RTT data (symmetric cipher suite, > ALPN, etc.) are the same as those which were negotiated in the connection > which established the PSK. The PSK used to encrypt the early data > MUST be the first PSK listed in the client's "pre_shared_key" extension." > (though I think I just recently added cipher suite). > > and: > "Any ticket MUST only be resumed with a cipher suite that is identical > to that negotiated connection where the ticket was established." If 0-RTT is used with manually provisioned PSKs (might not be allowed currently, but might be allowed soon), does that still hold? Also, I think it is problematic that externally provisioned PSKs can be used with any protection with given prf-hash, while NST-provisioned PSKs can only be used with one protection and prf-hash. 0-RTT requirements are separate matter, since those would apply to all. The original purpose of resumption-as-PSK was AFAIK to unify the two mechanisms to simplify things. Therefore those two should be as similar as possible. > > Also, to straightforwardly prove that collision resistance of HKDF and > > HMAC (as used) follows from collision resistance of the underlying hash > > function, yon need to take the output to be at least the hash output > > size. As otherwise it is not guaranteed that any collision in HKDF or > > HMAC can be reduced into collision of the underlying hash. > > > > Right. I have some text here but please feel free to suggest more. Yes, but the text says 256 bit output is enough. One isn't guaranteed to be able to reduce such collision to collision of >256 bit hash. (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely unlikely to reduce). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Finished stuffing/PSK Binders
On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > 4. I've taken a suggestion from David Benjamin to move the > negotiation > > > > of the PSK key exchange parameters out of the PSK itself and into a > > > > separate message. This cleans things up and also lets us drop the > > > > currently non-useful auth_mode parameter. > > > > > > Eeh... From the text, it seems to currently require the kex modes > > > extension if PSK extension is present. Which seems worse than useless > > > if the meaning is to get rid of the kex mode parameter from PSK > > > extension (since you will have the value anyway, but need to dig it > > > from another extension... Blech). > > > > I guess this is a matter of taste, but what convinced me was that: > > > > 1. It put all the logic on the server side. > > 2. It removed the auth mod parameter. > > > > Maybe david can say more. > > I mean if server is to accept PSK, it must now go fishing for another > extension, check that it is present and pay attention to values there. > As opposed to having the data in where it is needed. > This is a reasonable argument (and the reason I stuffed the binder here). However, David's argument was that this applied to *all* PSKs even new ones. -Ekr > > Also, didn't notice what prevents pathology like this (I presume this > > > is not allowed): > > > > > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > > > > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] > ---> > > > [0-RTT data, encrypted using AES-128-GCM-SHA256] > > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > > > <-- EncryptedExtensions[EarlyDataIndication] > > > > > > Note the record protection algorithm mismatch. > > > > > > > Yes, this is forbidden by the combination of: > > > > "The parameters for the 0-RTT data (symmetric cipher suite, > > ALPN, etc.) are the same as those which were negotiated in the connection > > which established the PSK. The PSK used to encrypt the early data > > MUST be the first PSK listed in the client's "pre_shared_key" extension." > > (though I think I just recently added cipher suite). > > > > and: > > "Any ticket MUST only be resumed with a cipher suite that is identical > > to that negotiated connection where the ticket was established." > > If 0-RTT is used with manually provisioned PSKs (might not be allowed > currently, but might be allowed soon), does that still hold? > > Also, I think it is problematic that externally provisioned PSKs can > be used with any protection with given prf-hash, while NST-provisioned > PSKs can only be used with one protection and prf-hash. > > 0-RTT requirements are separate matter, since those would apply to all. > > The original purpose of resumption-as-PSK was AFAIK to unify the two > mechanisms to simplify things. Therefore those two should be as similar > as possible. > > > > > Also, to straightforwardly prove that collision resistance of HKDF and > > > HMAC (as used) follows from collision resistance of the underlying hash > > > function, yon need to take the output to be at least the hash output > > > size. As otherwise it is not guaranteed that any collision in HKDF or > > > HMAC can be reduced into collision of the underlying hash. > > > > > > > Right. I have some text here but please feel free to suggest more. > > Yes, but the text says 256 bit output is enough. One isn't guaranteed > to be able to reduce such collision to collision of >256 bit hash. > > (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely > unlikely to reduce). > Right. I can update. -Ekr > > > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Finished stuffing/PSK Binders
On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > mailto:ilariliusva...@welho.com>> wrote: > > On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara > mailto:ilariliusva...@welho.com>> > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > 4. I've taken a suggestion from David Benjamin to move the > negotiation > > > > of the PSK key exchange parameters out of the PSK itself and > into a > > > > separate message. This cleans things up and also lets us > drop the > > > > currently non-useful auth_mode parameter. > > > > > > Eeh... From the text, it seems to currently require the kex modes > > > extension if PSK extension is present. Which seems worse than > useless > > > if the meaning is to get rid of the kex mode parameter from PSK > > > extension (since you will have the value anyway, but need to > dig it > > > from another extension... Blech). > > > > I guess this is a matter of taste, but what convinced me was that: > > > > 1. It put all the logic on the server side. > I was going to ask whether this also includes the decision on whether to send a Certificate to authenticate the server (even for PSK modes), but it looks like this change is intentionally removing the ability to do PSK keyex and auth with a certificate? > > 2. It removed the auth mod parameter. > > > > Maybe david can say more. > > I mean if server is to accept PSK, it must now go fishing for another > extension, check that it is present and pay attention to values there. > As opposed to having the data in where it is needed. > > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > Implementations already have to do some amount of "scan through all extensions to detect certain things, do some initial processing, and then finish process everything [else]", not least because SNI can change what cert types you have, configuration knobs, etc.. So, yes it's bad, but how bad is it in a relative sense? I think there is some value in the client indicating to the server whether it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future NSTs, though it's perhaps not of the utmost importance. That property does support a separate psk_key_exchange_modes extension in preference to rolling it into pre_shared_keys (as a separate list next to identities and binders), but it seems to only be a weak argument for separation. I do think that keeping the psk kex mode orthogonal to the individual keys is helpful, though. Anyway, maybe it's time to bite the bullet and actually write up the description of the proper procedure for ClientHello processing (scan extensions for SNI, load up servername-specific config+cert/key, etc.). Which would make this stuff any prettier, but would at least help people not get it wrong. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Application layer interactions and API guidance
On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara wrote: > On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote: >> Dear all, >> We've got API guidance and application layer interactions on the TODO >> list, and both of these are important and don't show up yet. I can't >> credibly commit to taking a big stab at them, but hopefully this email >> is detailed enough that it serves as a starting point. >> >> The problems with the application layer interaction center around >> 0-RTT and client post-authentication. 0-RTT data is replayable, and >> furthermore does not authenticate SNI or other extensions that might >> affect its interpretation at the server. I smell possible bugs where >> extension data isn't properly treated with 0-RTT vs. 1-RTT fallback: >> the current draft probably should include something like "any >> extensions which influence the interpretation of this data must be the >> same". > > In composing my list of extensions to pay attention when doing 0-RTT > (SNI and ALPN), I considered matters like: > > - Does this seem like it would affect 0-RTT interpretation. > - What are the TLS 1.2 rules on it? > - Is it even meaningful with PSK? > - Is it just low-level connection control? > > ALPN was included because it definitely affects 0-RTT interpretation > (even against TLS 1.2 rules) and SNI because of TLS 1.2 rules (SNI > was later removed from the list). Are we sure this is safe to remove? It probably depends on higher layer protocol semantics. I would suggest that we make 0-RTT per application layer support: each application needs to opt in to 0-RTT, and we should ensure each higher level protocol is aware of the interactions and writes a description of what to do for each extension. Yes, this is hideous and a ton of work. I'm not convinced there is a safe alternative. > > There might be future extensions that do have an effect on 0-RTT > (some proposed extensions to Token Binding perhaps?). And it is of > course theoretically possible that TLS stack implements some extension > in a very odd way. > >> The difference between received 0-RTT data and other data doesn't >> necessarily line up with connection state while processing, as the TLS >> stack could have transitioned to normal 1-RTT operation while 0-RTT >> data is still sitting around waiting to be processed. This is really >> an API problem, but can also be caused by application layer choices: >> if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT, >> life gets a bit weird. > > Is "life gets a bit weird" an euphemism for "there will likely be > security issues here"? :-) > > Also, it is very likely that 0-RTT would need its own read API, because > it is pretty unlikely that existing API could be safely retrofitted > or even purpose-built unified API be designed that isn't just asking > for security problems via mixing 0-RTT and 1-RTT data. Yes. In particular I think the TLS state machine transitions need to be ordered with respect to the arrival and sending of data. The challenge for a multithreaded program (yes, some programs have multiple threads sending and receiving at once) is making this make sense, or even a single-threaded program where the TLS stack can change state at times not visible to the sending thread. Maybe there is some slop here, like 0-RTT can become 1-RTT on send, but this raises all sorts of problems for receiving. I think we need to require separation in the API. > > > It gets even more fun in DTLS, where 0-RTT packets can be reordered > after Client Finished, so more 0-RTT data arrives when the connection > has already transitioned to 1-RTT. > > Perhaps the last one could be solved by requiring the library to > discard any such packets and not pass them forward. This is the sanest solution I can think of. When DTLS 1.3 is produced it should be noted. > > >> Post-handshake auth is an ugly one for both. It can complete >> asynchronously with respect to data exchange, which is not what the >> desired semantics usually are. Generally we want each request to have >> a single authentication context. Designing APIs to handle this is >> hard, and applications will have to be aware of how TLS authentication >> works to have rules for it. Add in the ability to stream data in both >> directions, and life gets interesting. I'm really not sure what this >> should look like. > > At least you must have client and server agree on authentication > context of every given request. If they don't, vulernabilities WILL > result. > > And then there have been multiple CVEs due to applications using > wrong authentication context in some situation. > > (This is the reason one needs to be especially careful when combining > dynamic client certificates with HTTP/2... Basically, it can not be > done safely without coordination on application layer). > > One likely wants application protocol to be able to specify part of > or the entiere request context and to extract that part in the other > end when request
Re: [TLS] Finished stuffing/PSK Binders
On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote: > On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: >> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < >> ilariliusva...@welho.com> >> > wrote: >> > >> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: >> > > > 4. I've taken a suggestion from David Benjamin to move the >> negotiation >> > > > of the PSK key exchange parameters out of the PSK itself and into a >> > > > separate message. This cleans things up and also lets us drop the >> > > > currently non-useful auth_mode parameter. >> > > >> > > Eeh... From the text, it seems to currently require the kex modes >> > > extension if PSK extension is present. Which seems worse than useless >> > > if the meaning is to get rid of the kex mode parameter from PSK >> > > extension (since you will have the value anyway, but need to dig it >> > > from another extension... Blech). >> > >> > I guess this is a matter of taste, but what convinced me was that: >> > >> > 1. It put all the logic on the server side. >> > > I was going to ask whether this also includes the decision on whether to > send a Certificate to authenticate the server (even for PSK modes), but it > looks like this change is intentionally removing the ability to do PSK > keyex and auth with a certificate? > Yes, while preserving the ability to add it later by adding a PskAuthMode extension parallel to this one. -Ekr > > 2. It removed the auth mod parameter. >> > >> > Maybe david can say more. >> >> I mean if server is to accept PSK, it must now go fishing for another >> extension, check that it is present and pay attention to values there. >> As opposed to having the data in where it is needed. >> > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > > > Implementations already have to do some amount of "scan through all > extensions to detect certain things, do some initial processing, and then > finish process everything [else]", not least because SNI can change what > cert types you have, configuration knobs, etc.. So, yes it's bad, but how > bad is it in a relative sense? > > I think there is some value in the client indicating to the server whether > it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future > NSTs, though it's perhaps not of the utmost importance. That property does > support a separate psk_key_exchange_modes extension in preference to > rolling it into pre_shared_keys (as a separate list next to identities and > binders), but it seems to only be a weak argument for separation. I do > think that keeping the psk kex mode orthogonal to the individual keys is > helpful, though. > > Anyway, maybe it's time to bite the bullet and actually write up the > description of the proper procedure for ClientHello processing (scan > extensions for SNI, load up servername-specific config+cert/key, etc.). > Which would make this stuff any prettier, but would at least help people > not get it wrong. > > -Ben > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Earlier exporters
I was assuming that there were two exporters: Export() --> the same API as in 1.2 and computed as described here Export0RTT -> A new API that computes the early_exporter. -Ekr On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: > Does the wording of this PR mean that the value from the exporter changes > depending on whether it's run before or after exporter_secret can be > computed? I think it would be better to keep an RFC 5705-style exporter > that remains constant for the connection. The 0-RTT exporter from an API > perspective can be a separate thing that a caller has to explicitly choose > to use. > > On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: > >> Please see the following PR: >> https://github.com/tlswg/tls13-spec/pull/673 >> >> This includes various changes to make exporters/resumption work better. >> >> Basically: >> 1. Add a 0-RTT exporter and change the transcript for the regular >> exporter so it >> only includes the transcript up to ServerFinished. This gives it >> parity with the >> rest of the traffic keys. If we need an exporter with the full >> transcript we can >> always add it later >> >> 2. Point out that you can predict ClientFinished for NST when not doing >> Client auth. This lets you issue tickets on the server's first >> flight, while still >> ensuring that if you do client auth you still bind resumption to the >> client's >> full transcript. >> >> These are pretty straightforward changes, so absent objections I'll merge >> them early next week. >> >> -Ekr >> >> >> ___ >> 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] Earlier exporters
That's my assumption as well. On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote: > I was assuming that there were two exporters: > > Export() --> the same API as in 1.2 and computed as described here > Export0RTT -> A new API that computes the early_exporter. > > > -Ekr > > On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: > >> Does the wording of this PR mean that the value from the exporter changes >> depending on whether it's run before or after exporter_secret can be >> computed? I think it would be better to keep an RFC 5705-style exporter >> that remains constant for the connection. The 0-RTT exporter from an API >> perspective can be a separate thing that a caller has to explicitly choose >> to use. >> >> On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: >> >>> Please see the following PR: >>> https://github.com/tlswg/tls13-spec/pull/673 >>> >>> This includes various changes to make exporters/resumption work better. >>> >>> Basically: >>> 1. Add a 0-RTT exporter and change the transcript for the regular >>> exporter so it >>> only includes the transcript up to ServerFinished. This gives it >>> parity with the >>> rest of the traffic keys. If we need an exporter with the full >>> transcript we can >>> always add it later >>> >>> 2. Point out that you can predict ClientFinished for NST when not doing >>> Client auth. This lets you issue tickets on the server's first >>> flight, while still >>> ensuring that if you do client auth you still bind resumption to the >>> client's >>> full transcript. >>> >>> These are pretty straightforward changes, so absent objections I'll merge >>> them early next week. >>> >>> -Ekr >>> >>> >>> ___ >>> 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] Earlier exporters
Good. I will try to clarify. PRs welcome On Fri, Oct 7, 2016 at 2:37 PM, Nick Harper wrote: > That's my assumption as well. > > On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote: > >> I was assuming that there were two exporters: >> >> Export() --> the same API as in 1.2 and computed as described here >> Export0RTT -> A new API that computes the early_exporter. >> >> >> -Ekr >> >> On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: >> >>> Does the wording of this PR mean that the value from the exporter >>> changes depending on whether it's run before or after exporter_secret can >>> be computed? I think it would be better to keep an RFC 5705-style exporter >>> that remains constant for the connection. The 0-RTT exporter from an API >>> perspective can be a separate thing that a caller has to explicitly choose >>> to use. >>> >>> On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: >>> Please see the following PR: https://github.com/tlswg/tls13-spec/pull/673 This includes various changes to make exporters/resumption work better. Basically: 1. Add a 0-RTT exporter and change the transcript for the regular exporter so it only includes the transcript up to ServerFinished. This gives it parity with the rest of the traffic keys. If we need an exporter with the full transcript we can always add it later 2. Point out that you can predict ClientFinished for NST when not doing Client auth. This lets you issue tickets on the server's first flight, while still ensuring that if you do client auth you still bind resumption to the client's full transcript. These are pretty straightforward changes, so absent objections I'll merge them early next week. -Ekr ___ 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] Add max_early_data_size to TicketEarlyDataInfo
On 10/07/2016 11:57 AM, Filippo Valsorda wrote: > Hello, > > Cloudflare's current (not definitive) plan for 0-RTT is essentially to > decide whether or not to answer to requests in the 0.5 flight on a > case-by-case basis. That obviously requires reading all of them and > caching the ones we don't want to answer. > > To mitigate the obvious DoS concern we plan to use the ticket age and a > per-machine replay cache. > > However, chatting with Drew (cc'd) we realized that clients could still > send huge amounts of 0-RTT data that we would have to buffer. Once a Well, "have to" is perhaps a bit of a stretch; the client should be prepared to cope reasonably if you abort the connection arbitrarily. > client sent early data, there's no way to accept only a part of it or to > verify that the client is not replaying before reading it all. But if we > were to close the connection after a given amount of data we risk > failing connections from legal clients. > > I propose to add a field max_early_data_size to TicketEarlyDataInfo, to > inform clients about the maximum amount of 0-RTT data they are allowed > to send, allowing servers to safely terminate connections that exceed > it. But this seems like a good idea; I left a couple of ~editorial notes on github. -Ben > https://github.com/tlswg/tls13-spec/pull/674 > > [Please keep me in the CC of replies] > > ___ > 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] Application layer interactions and API guidance
On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > wrote: > > > > Also, it is very likely that 0-RTT would need its own read API, because > > it is pretty unlikely that existing API could be safely retrofitted > > or even purpose-built unified API be designed that isn't just asking > > for security problems via mixing 0-RTT and 1-RTT data. > > Yes. In particular I think the TLS state machine transitions need to > be ordered with respect to the arrival and sending of data. The > challenge for a multithreaded program (yes, some programs have > multiple threads sending and receiving at once) is making this make > sense, or even a single-threaded program where the TLS stack can > change state at times not visible to the sending thread. Maybe there > is some slop here, like 0-RTT can become 1-RTT on send, but this > raises all sorts of problems for receiving. I think we need to require > separation in the API. 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- retransmit, which needs to be disableable, as sometimes that just plain won't work). This impiles that the application always needs to explicitly signal the end of 0-RTT data, even just to abort sending it. > > (This is the reason one needs to be especially careful when combining > > dynamic client certificates with HTTP/2... Basically, it can not be > > done safely without coordination on application layer). > > > > One likely wants application protocol to be able to specify part of > > or the entiere request context and to extract that part in the other > > end when requesting a certificate selection. This is to allow putting > > part of coordination data into the request itself. However, this is not > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at > > application layer. > > > > And then upon completion of the authentication (either successful or > > explicitly rejected), signal the application with the new certificate > > chain and the context the request had. > > This is going to require major changes to APIs and to the HTTP/2 > layer. It also interacts with token binding, whee! My question then > becomes one of what we actually need: can we assume that leakage > between authentication contexts over a single session is safe because > all contexts represent the same principal, by restricting the usages, > or is this overly restrictive? Yes, it is going to reuqire such changes. And you absolutely can not assume that all contexts present the same principal. And as I said, in multiplexed protocol like HTTP/2, you need application- level coordination on top. TLS just can't do that. > When we have multiple requests and replies in flight and the > authentication state changes, things get nasty. If we think of TLS as > sending a stream of events including authentication changes to the > application, this fits the semantics of the TLS draft as I understand > them to be, but does not necessarily fit what application protocols > want. There might be a semantic mismatch here requiring reworking of > one or another part. Also, some applications presumably want the events done synchronously, so they don't move with data reads. Basically, post-handshake auth is heckuva nasty problem. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Application layer interactions and API guidance
On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > wrote: > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > it is pretty unlikely that existing API could be safely retrofitted > > > or even purpose-built unified API be designed that isn't just asking > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > Yes. In particular I think the TLS state machine transitions need to > > be ordered with respect to the arrival and sending of data. The > > challenge for a multithreaded program (yes, some programs have > > multiple threads sending and receiving at once) is making this make > > sense, or even a single-threaded program where the TLS stack can > > change state at times not visible to the sending thread. Maybe there > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > raises all sorts of problems for receiving. I think we need to require > > separation in the API. > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > retransmit, which needs to be disableable, as sometimes that just plain > won't work). > Can you explain why that is? -Ekr This impiles that the application always needs to explicitly signal > the end of 0-RTT data, even just to abort sending it. > > > > (This is the reason one needs to be especially careful when combining > > > dynamic client certificates with HTTP/2... Basically, it can not be > > > done safely without coordination on application layer). > > > > > > One likely wants application protocol to be able to specify part of > > > or the entiere request context and to extract that part in the other > > > end when requesting a certificate selection. This is to allow putting > > > part of coordination data into the request itself. However, this is not > > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at > > > application layer. > > > > > > And then upon completion of the authentication (either successful or > > > explicitly rejected), signal the application with the new certificate > > > chain and the context the request had. > > > > This is going to require major changes to APIs and to the HTTP/2 > > layer. It also interacts with token binding, whee! My question then > > becomes one of what we actually need: can we assume that leakage > > between authentication contexts over a single session is safe because > > all contexts represent the same principal, by restricting the usages, > > or is this overly restrictive? > > Yes, it is going to reuqire such changes. > > And you absolutely can not assume that all contexts present the same > principal. > > And as I said, in multiplexed protocol like HTTP/2, you need application- > level coordination on top. TLS just can't do that. > > > When we have multiple requests and replies in flight and the > > authentication state changes, things get nasty. If we think of TLS as > > sending a stream of events including authentication changes to the > > application, this fits the semantics of the TLS draft as I understand > > them to be, but does not necessarily fit what application protocols > > want. There might be a semantic mismatch here requiring reworking of > > one or another part. > > Also, some applications presumably want the events done synchronously, > so they don't move with data reads. > > > Basically, post-handshake auth is heckuva nasty problem. > > > -Ilari > > ___ > 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] Add max_early_data_size to TicketEarlyDataInfo
We were also expecting to want to bound how much traffic a server could be compelled to skip over without making progress. It actually didn't occur to me we could let the client know the bounds, rather than just making up a conservative bound (there's only so much data you can get into an RTT) and hoping nothing breaks. That's a good idea. Units is a little interesting. For those purposes, this limit would kick in whether or not the early data could be decrypted, so the server-side limit would be measured in ciphertext, possibly even including record headers. (Although any inaccuracies in converting could be done by just advertising an underestimate and breaking peers that send pathologically silly things like all one-byte records. So it doesn't matter much.) On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk wrote: On 10/07/2016 11:57 AM, Filippo Valsorda wrote: Hello, Cloudflare's current (not definitive) plan for 0-RTT is essentially to decide whether or not to answer to requests in the 0.5 flight on a case-by-case basis. That obviously requires reading all of them and caching the ones we don't want to answer. To mitigate the obvious DoS concern we plan to use the ticket age and a per-machine replay cache. However, chatting with Drew (cc'd) we realized that clients could still send huge amounts of 0-RTT data that we would have to buffer. Once a Well, "have to" is perhaps a bit of a stretch; the client should be prepared to cope reasonably if you abort the connection arbitrarily. I think the concern is that a well-meaning client may not necessarily do a retry here and instead read this even as a network error. And if it did, the next attempt, if there is still a 0-RTT-able ticket available, may hit this again anyway... client sent early data, there's no way to accept only a part of it or to verify that the client is not replaying before reading it all. But if we were to close the connection after a given amount of data we risk failing connections from legal clients. I propose to add a field max_early_data_size to TicketEarlyDataInfo, to inform clients about the maximum amount of 0-RTT data they are allowed to send, allowing servers to safely terminate connections that exceed it. But this seems like a good idea; I left a couple of ~editorial notes on github. -Ben https://github.com/tlswg/tls13-spec/pull/674 [Please keep me in the CC of replies] ___ TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls ___ 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] Making post-handshake messages optional in TLS 1.3 (#676)
There has been a lot of discussion lately about post-handshake messages that do not contain application data and how to handle them. This PR is an attempt to make the story more explicit by adding a new post_handshake extension to TLS 1.3. Supporting all types of post-handshake messages can require extra complexity and logic, even when the features that these messages enable are not needed. Some types of connections/implementations don't need to support key updates (some unidirectional connections), session tickets (pure PSK implementations) and post-handshake client auth (most browsers). These are all currently SHOULDs in the spec and they don't need to be. In order to simplify the logic around dealing with post-handshake messages, this proposal makes support for each of these modes explicit via a new handshake extension. This change also makes the path to introducing other types of post-handshake messages in future drafts more explicit. PR: https://github.com/tlswg/tls13-spec/pull/676 Nick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
