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. 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. 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. The mandated use of uncompressed points invites easy wrong-curve attacks: mandating support and use for compressed points would solve this problem. I think at minimum we should fix the text to make clear what we mean about TLS 1.2. 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. 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. 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. 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. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
