Re: [TLS] TLS 1.3 Problem?
On 9/29/20 19:51, Martin Thomson wrote: It's symmetric crypto[1]. Hardly worth noting. [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that server clusters can share session ticket encryption keys without needing interconnects. But encryption or decryption only happens once per instance. Well, you also need a MAC, right? (encrypt-then-mac) This requires another key and a bunch of computation. Then you have to decode the cookie back into the server state, and then check whether the new ClientHello (CH) matches the original from the cookie, with possible changes, making sure that the key_share supplied in the new CH was in the original CH, checking that the list of PSK's was not tampered with in invalid ways, etc. Much of this is required of any handshake involving HRR even if not stateless. Seems worth noting. Have you measured? And how do you prevent someone from sending an old cookie back? If the server is truly stateless Did you (or a client) actually have a data center full of memory-bound servers which are now handling many more connections using the stateless HRR feature? I'm not trying to be unkind, I genuinely don't understand how stateless HRR can be beneficial. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Wed, Sep 30, 2020, at 01:14, Michael D'Errico wrote: > Also, are you sure you want to do this? The design of > TLS 1.3 was supposed to make it fast, but creating a > pseudo session ticket for every connection requiring a > HRR and then validating and decoding it is going to be > really slow. And your data center is going to get hotter > because your servers will be compute bound instead of > memory bound (if they even were). It's symmetric crypto[1]. Hardly worth noting. [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that server clusters can share session ticket encryption keys without needing interconnects. But encryption or decryption only happens once per instance. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Michael D'Errico wrote: > > Since RFC 8446 obsoletes RFC 5246, this is a serious problem. > > How is this supposed to work? Sorry but I did not follow the > development of TLS 1.3. I felt that I was unwelcome in this > group by some of the "angry cryptographers" as I call them. The "Obsoletes" Markers used in TLS documents (rfc4346, rfc5246, rfc8446) are pure crypto-political bullshit, they are completely non-sensical with respect to the Editorial meaning of "Obsolete:" in the RFC document series, as it was explained in rfc2223: Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. IPv6 specification(s) can not possibly obsolete IPv4 specifiation(s) HTTP/2 spec does not obsolete HTTP/1.1 spec (and does not try to) Example for *correct* obsoletion: If you want to implement the Simple Mail Transfer Protocol (SMTP), it will be sufficient that you only ever read and refer to rfc5321 and _never_ look at rfc2821 nor rfc821 at all -- and still can expect to your implementation of rfc5321 to interop fine with older implementations there were created based on rfc821 or rfc2821. The same is impossible for TLSv1.1 (rfc4346), TLSv1.2 (rfc5246) and TLSv1.3 (rfc8446). An implementor reading only rfc8446 will be completely unable to interop with TLSv1.0, TLSv1.1 and TLSv1.2 implementations -- and I am not even sure whether TLSv1.3 can be implemented with rfc8446 alone and never looking at rfc5246. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Dear Michael, On Tue, 29 Sep 2020 at 17:14, Michael D'Errico wrote: > OK, so it sounds like you put something similar to a > NewSessionTicket (TLS 1.2) in the cookie with enough > information to recreate the server state. Whilst getting to grips with TLS 1.3, I wrote a tutorial (https://arxiv.org/abs/1904.02148), I think you might find it useful. For instance, I explain the cookie on page 19. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared against the state from the cookie as an extra sanity check. We chose to do this for a few reasons, but one thing is that it encourages us to use the second ClientHello for negotiating everything. OK, so it sounds like you put something similar to a NewSessionTicket (TLS 1.2) in the cookie with enough information to recreate the server state. This is quite a lot more information than just a "hash" as the spec implies. Also, are you sure you want to do this? The design of TLS 1.3 was supposed to make it fast, but creating a pseudo session ticket for every connection requiring a HRR and then validating and decoding it is going to be really slow. And your data center is going to get hotter because your servers will be compute bound instead of memory bound (if they even were). Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Tue, Sep 29, 2020, at 10:38, Watson Ladd wrote: > > Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared against the state from the cookie as an extra sanity check. We chose to do this for a few reasons, but one thing is that it encourages us to use the second ClientHello for negotiating everything. > QUIC depends on it iiuc. It did, but it doesn't any more. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020 at 3:33 PM Michael D'Errico wrote: > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > I don't think this is very likely. The TLS list can get a bit competitive, but other IETF lists (say, anything related to DNS), are much worse. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020 at 6:33 PM Michael D'Errico wrote: > > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > > Anyway, back on the topic of stateless HelloRetryRequest, I > don't see how this can work given that the client can make > several modifications to the ClientHello which will invalidate > the hash sent in the "cookie" (even if the client echos it back > as required without modification). The hash isn't used for validation, but for continuing the running hash of the transcript to ensure that the negotiation isn't interfered with. See section 4.4.1. > > Is stateless HelloRetryRequest even being used? If so, how? QUIC depends on it iiuc. Sincerely, Watson -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > Luckily, we don't have any angry cryptographers in this group. Were they all pushed away too? Anyway, back on the topic of stateless HelloRetryRequest, I don't see how this can work given that the client can make several modifications to the ClientHello which will invalidate the hash sent in the "cookie" (even if the client echos it back as required without modification). Is stateless HelloRetryRequest even being used? If so, how? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Hi Mike, > I felt that I was unwelcome in this group by some of the "angry > cryptographers" as I call them. No reason to worry. Luckily, we don't have any angry cryptographers in this group. On top of what Richard mentioned in his response, take a look at Appendix D of the spec, see https://tools.ietf.org/html/rfc8446#appendix-D. Ciao Hannes -Original Message- From: TLS On Behalf Of Michael D'Errico Sent: Sunday, September 27, 2020 9:52 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 Problem? Hi, Took a quick look at RFC 8446 and noticed that there is no definition of ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior. A 1.3 client talking to a 1.2 or earlier server is likely going to receive both of these messages: RFC 5246 TLSAugust 2008 Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data <---> Application Data Figure 1. Message flow for a full handshake Since RFC 8446 obsoletes RFC 5246, this is a serious problem. How is this supposed to work? Sorry but I did not follow the development of TLS 1.3. I felt that I was unwelcome in this group by some of the "angry cryptographers" as I call them. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Sun, Sep 27, 2020, at 22:28, Michael D'Errico wrote: > > I'm afraid to keep reading In section 4, HandshakeType and Handshake are missing the value for the HelloRetryRequest message. Oh wait, never mind, it's the same value as ServerHello (?). Everything appears to be a hack within a hack If I hadn't already implemented TLS 1.0..1.2 I'd be completely lost reading RFC 8446. In fact I AM completely lost reading it. There's a mention of stateless HelloRetryRequest where the server sends a "cookie" containing a hash of the ClientHello. Is it supposed to rely on the client to echo this back? What if it doesn't? Or it puts in a different value? Or it gets modified in transit? Or it sends an initial ClientHello with a cookie extension as if it got a HelloRetryRequest? Am I worried about nothing here? OK, time for bed Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
The client is expected to adapt its behavior based on the negotiated version indicated in the ServerHello. If the server selects TLS 1.2, for example, then the client behaves as specified in RFC 5246. This is no different from previous version of TLS. --Richard On Sun, Sep 27, 2020 at 10:29 PM Michael D'Errico wrote: > On Sun, Sep 27, 2020, at 16:53, Ben Smyth wrote: > > The client will reject the server's ServerHello in your example. > > OK, so all eggs in one basket? I'm afraid to keep reading > > Mike > > ___ > 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 1.3 Problem?
On Sun, Sep 27, 2020, at 16:53, Ben Smyth wrote: > The client will reject the server's ServerHello in your example. OK, so all eggs in one basket? I'm afraid to keep reading Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
The client will reject the server's ServerHello in your example. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 Problem?
Hi, Took a quick look at RFC 8446 and noticed that there is no definition of ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior. A 1.3 client talking to a 1.2 or earlier server is likely going to receive both of these messages: RFC 5246 TLS August 2008 Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data <---> Application Data Figure 1. Message flow for a full handshake Since RFC 8446 obsoletes RFC 5246, this is a serious problem. How is this supposed to work? Sorry but I did not follow the development of TLS 1.3. I felt that I was unwelcome in this group by some of the "angry cryptographers" as I call them. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
