On Sun, Jul 21, 2019 at 01:51:32PM +0000, Nancy Cam-Winget (ncamwing) wrote:
> Thanks to all the feedback provided, we have updated the > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04 > draft. At this point, we believe the draft is stable and would like to > request its publication as an informational draft. I found the language of the draft (especially the introduction) somewhat turgid and repetitive to the point of significantly detracting from readability. I think the draft needs substantial editing for simplicity and clarity. As to specific technical issues, I don't understand the point being made in Section 2.2.2 about client key shares and resumption: In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), which can be negotiated as part of an initial handshake and then used in a subsequent handshake to perform resumption using the PSK. TLS 1.3 states that the client SHOULD include a "key_share" extension to enable the server to decline resumption and fall back to a full handshake, however it is not an absolute requirement. Example scenarios that are impacted by this are middleboxes that were not part of the initial handshake, and hence do not know the PSK. If the client does not include the "key_share" extension, the middlebox cannot force a fallback to the full handshake. If the middlebox policy requires it to inspect the session, it will have to fail the connection instead. [ AFAIK, even with PSK-based resumption, and even when the client's initial key share was not acceptable to server, the server can still perform a full handshake after HRR. An MiTM middle-box can replace the server's HRR with its own, and then decline the client's PSK and perform a full handshake. ] I also found the malicious server argument in section 2.2.1 somewhat unconvincing, since malicious servers have lots of (previously) innocuous domains to choose from, or can present self-signed certificates for any SNI of their choice. The impact of TLS 1.3 is largely limited to making it more difficult to whitelist "known good" servers from MiTM inspection. With TLS 1.3 a middle box that wants to be sure to MiTM sessions to "bad" servers, must also MiTM sessions to "good" servers (in order to determine that they're really "known good"), because authenticating a "good" server is no longer possible without MiTM interception. Blacklists of "known bad" are easily bypassed even with TLS 1.2. Middleboxes that are limited to closing TCP connections for the "known bad", are not particularly effective with TLS 1.2, and will be increasingly less so as attacks become more sophisticated. A middlebox that wants to detect the bad must do MiTM interception, and with TLS 1.3 will need to intercept *all* traffic, even the previously "known good", once the "known good" peer deploys TLS 1.3. Yes, optimizing out interception of the "authenticated known good" is no longer possible. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls