On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla <e...@rtfm.com> wrote: > Watson, > > Thanks for your comments! > > On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> Hello, >> >> Looking at the history of TLS implementation attacks we see that many >> result from the standard not strictly enough prescribing behavior, >> particularly of the state machine. This draft does not actually fix >> this problem, but continues to present example flows without >> explicitly requiring them to be the only possible flows. > > > >> For example, consider HelloRetryRequest. Do servers only send one of >> these per connection, or can it be resent multiple times? Obviously >> there is a DoS possibility here, but I do not see where this behavior >> is explicitly defined. I think we should require that the server only >> ever sends one HelloRetryRequest, and then terminates the connection >> if the ClientHello is unacceptable. > > > > The server is forbidden to send multiple HRRs and the client is required > to enforce it. See: > > https://tlswg.github.io/tls13-spec/#hello-retry-request > > I agree that we don't require the server to behave this way. I can fix the > draft to say this.
That sounds good. The more we can turn bugs into ones that violate the spec, the easier it will be to get them fixed. (Hopefully) > > >> At no point is it stated that only >> the example flows should be supported. I would prefer more clarity >> about what messages are to be expected when, especially with alerts. > > > Actually the text does say something here: > https://tlswg.github.io/tls13-spec/#handshake-protocol > > "Protocol messages MUST be sent in the order defined below (and shown in the > diagrams in Section 2). A peer which receives a handshake message in an > unexpected order MUST abort the handshake with an “unexpected_message” > alert. Unneeded handshake messages are omitted, however." > > However, this text was also in 5246, so I think there's a fair argument > that it's not strong enough. I'm not quite sure how to make it better. > Suggestions? So I was reading in order, so I saw the diagrams first, which seemed like examples and then missed this sentence in the draft. Maybe a sentence in section 2 would help? > > >> ECDSA cannot be used with x25519 or x448, but the draft seems to >> require support in TLS 1.2 for this as a consequence of its >> description of the fallback mode. > > > I don't *think* that that's true: can you point to the specific text that > you are concerned with? It's the interaction between https://tlswg.github.io/tls13-spec/#negotiated-groups and the statement that ECDSA needs to be supported with any curve appearing in the supported_groups extension when negotating a TLS 1.2 hello. We explicitly call x25519 an elliptic curve there. Yes, I doubt anyone will end up making an implementation that does this (except by accident). > > >> ALPN, resumption, and 0-RTT remain problematic. For instance we see >> that 0-RTT data is sent with the same ALPN state when the PSK was >> derived, but this could be different from the ALPN transmitted and >> negotiated during the handshake, which is explicitly allowed later in >> the document. I do not understand what is supposed to happen in this >> scenario. > > > Here's the relevant text: > https://tlswg.github.io/tls13-spec/#early-data-indication > > "If any of these checks fail [ALPN is in the list above] the server MUST NOT > respond with the extension and must discard all the remaining first flight > data (thus falling back to 1-RTT). If the client attempts a 0-RTT handshake > but the server rejects it, it will generally not have the 0-RTT record > protection keys and must instead trial decrypt each record with the 1-RTT > handshake keys until it finds one that decrypts properly, and then pick up > the handshake from that point." > > Is there anything else you'd like to see here? > >> Appendix B removes the text about upper-layer protocol interactions >> with 0-RTT I provided, merely discussing the API. I think this is a >> mistake: how 0-RTT should be used safely depends on the upper-layer >> protocol, and can be complex. API guidance is not enough. > > > This ended up in the main text: > https://tlswg.github.io/tls13-spec/#zero-rtt-data > > "Protocols MUST NOT use 0-RTT data without a profile that defines its use. > That profile needs to identify which messages or interactions are safe to > use with 0-RTT. In addition, to avoid accidental misuse, implementations > SHOULD NOT enable 0-RTT unless specifically requested. Special functions for > 0-RTT data are RECOMMENDED to ensure that an application is always aware > that it is sending or receiving data that might be replayed." > > Is this missing pieces you think we need? Yes, thanks for pointing out where I missed it. > > >> There is still a note about needing a channel binding mechanism in the >> text. I think this should be resolved soon so it can be analyzed, >> probably built on top of the exporter mechanism. Either that, or we >> consciously punt and remove the note and replace with something else. > > > The idea here is that we need a separate draft that just says "use exporters > with > label X". I think we remove the note and see if we can get someone to write > that draft. > > >> As for process, I support the idea of having a last call on November >> 20th, and then completing the security analysis by January 20th (or >> whatever date was decided). This will prevent a flurry of changes >> potentially breaking things. > > > That's the idea. > > -Ekr > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
