Re: [TLS] network-based security solution use cases

[Eric Rescorla <[e-mail]>]

I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized.  Those techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
   methods with RSA and DH key exchanges.  When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Second, this property is really only available with RSA. Although
it is possible for an attacker to synchronize DH keys by generating
bogus DH parameters, the technique described by Bhargavan et al
results in an insecure MS (i.e., the server's public DH share).
[See Section V-B of https://www.mitls.org/downloads/tlsauth.pdf]
Any middlebox doing this, therefore, has completely broken TLS
for the endpoints on both sides of it. Your document suggests
that people do use this technique: I sincerely hope not.

In short, this property of TLS 1.3 is really a property of the use
of (EC)DHE [0], the use of which is important for security even in TLS 1.2
(hence the rapid increase in the use of ECDHE and the corresponding
decline in static RSA). Even if TLS 1.3 were never deployed, the
continued use of static RSA is going to be come increasingly
nonviable.

Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.


- PSK and resumption
You write:

   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.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
    the server can forget it at any time
    (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage).
Thus,
    a client which does not allow a full handshake will often
    find itself unable to connect.

(b) The relevant question is not whether the client offers a key share
    extension but whether it advertises any DH groups. If the client sends
    a group but not a key share, the server can send HelloRetryRequest
    to force the client to send a key share.

For these reasons, as far as I know, every client (and at least every
browser client) should allow a full handshake even when trying to resume.


- Server Certificate Concealment
You note that in TLS 1.2 the middlebox can examine both the SNI and the
server's certificate in order to decide whether to MITM the connection,
but that in TLS 1.3, the middlebox cannot guarantee that the SNI in
uses is correct:

   In TLS 1.2, the ClientHello, ServerHello and Certificate messages are
   all sent in clear-text, however in TLS 1.3, the Certificate message
   is encrypted thereby hiding the server identity from any
   intermediary.  Note that even _if_ the SNI is provided (in cleartext)
   by the client, there is no guarantee that the actual server
   responding is the one indicated in the SNI from the client.

In this case, it's important to distinguish between conformant and
nonconformant clients. In the former case -- as when the user is
not attempting to evade inspection -- the SNI will reflect the
identity that the client expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting to evade
inspection, the certificate might not match. However, in this
scenario, the client and server are colluding and so there are
a variety of ways to avoid inspection, even when doing TLS 1.2.

For example:

1. The client and server can share a prearranged public key and then
negotiate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
under the server's prearranged key and continues with TLS as usual.
This cannot be detected by the middlebox without decrypting the EPMS.

2. If an (EC)DHE cipher suite must be negotiated, then the attack
described above does not work directly because the server's signature
over the ServerKeyExchange can be validated, and of course the
attacker server does not have the legitimate server's key. However,
the server can forward the ClientHello to the legitimate server,
capture the Certificate and ServerKeyExchange and the proxy those to
the client. This looks legitimate to the inspection device and then
the client can simply send the Encrypted PMS in the first chunk of
data that is apparently encrypted under the server's key.

For these reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.

-Ekr


[0] Note: the use of static DH is very rare.


On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) <
[e-mail]> wrote:

> All,
>
>
>
> @IETF99, awareness was raised to some of the security WGs (thanks Kathleen
> ☺) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and
> asked what the implications would be for the security solutions today.
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an
> initial draft to describe some of the impacts relating to current network
> security solutions.  The goal of the draft is NOT to propose any solution
> as a few have been proposed, but rather to raise awareness to how current
> network-based security solutions work today and their impact on them based
> on the current TLS 1.3 specification.
>
>
>
> Regards, Nancy, Flemming and Eric
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>