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

[Flemming Andreasen <[e-mail]>]

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