Re: [TLS] TLS Impact on Network Security draft updated

[Viktor Dukhovni <[e-mail]>]

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.