On 7/23/19 4:14 PM, Viktor Dukhovni wrote:
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.
If you have any specific text suggestions, please let us know.
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. ]
We will take another look at this part.
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.
It all depends on what you are willing to accept. I still see a
difference with TLS 1.3 here.
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.
Ok - thanks for the feedback.
-- Flemming
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
