On 11/7/17 12:23 PM, Eric Rescorla wrote:
On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen <fandr...@cisco.com
<mailto:fandr...@cisco.com>> wrote:
Thank you for the feedback Ekr - please see below for responses
On 11/6/17 12:43 PM, Eric Rescorla wrote:
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.
Thanks for the bringing that one up - we will make sure to include
that in the next version.
Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3,
it's an integral part of the protocol that cannot be disabled. The
TLS 1.2 extension does not share that property.
It seems like an odd complaint that we are making protection against
Unknown Key Shares an integral part of the protocol
I understand your point. What I am saying is that there are some side
effects of doing so that impacts use case scenarios that exist today. If
you cannot drop out, then you have two choices:
1) Always be a MITM, which you may not want to (e.g. consider sessions
with financial institutions)
2) Never be a MITM, which means you cannot do any of the network-based
security use cases we have highlighted
What you really want is the ability to do it more selectively.
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.
We have several different use case scenarios in there, and I agree
with the observation that they cannot all be satisfied at the same
time. For example, we cannot scan for malware in an encrypted
stream to a financial institution that we are not allowed to
decrypt. That doesn't mean either use case is invalid. Customers
do both in real-life (just not at the same time).
I'm finding it a bit puzzling what you claim customers do.
Specifically, you seem to be saying that customers examine the
beginning of the connection and then stop. What are they scanning for
and what makes them stop?
It's the handshake process, which typically governs the associated
policy for the session (e.g. decrypt-and-inspect or do-not-decrypt). You
will try to determine whether the session should undergo inspection at
the time the ClientHello passes through the box, however sometimes, you
end up making a final (and different) decision when the ServerHello is
received. The decision is guided by policies configured for the
middlebox which may determine it based on various criteria (e.g.
category of the destination such as "Financial Services", geography, etc.)
- 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
<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.
If that is indeed the case, then I would suggest changing the spec
language to a MUST here instead so we can guarantee it.
I don't believe this is necessary. There are certainly reasons why you
would want to do PSK w/o (EC)DHE (e.g., you are really PSK only).
Agree with the example, but is that really a resumption scenario ?
- 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.
I agree we should distinguish between between conformant and
non-comformant.
For the conformant case, I do not know to what extent we can rely
on the client always sending the SNI, but even if it is always
sent, there are still use case scenarios around certificate audit,
etc. that cannot be satisified in TLS 1.3 without becoming an
active MITM.
You can do certificate audit by making an independent connection and
eliciting the certificate.
Not always. The certificate audit may be for an external server you
connected to (outbound scenario). Even for inbound scenarios, you would
have to ensure you actually find the local servers and check their
certificates, which would imply a need for continuous scanning of all of
your infrastructure. I guess it's technically doable (similar to
vulnerability scanners), but it's difficult on an IPv6 enabled network
due to the size of the address space.
With the recently adopted proposal around SNI encryption, there
are more use cases that cannot be satisfied without becoming an
active MITM.
Yes, I agree with that.
For the non-conformant case, you bring up some good points. We can
reduce the set of bypass scenarios there, but we cannot eliminate
them.
I'm not persuaded that you can meaningfully reduce them. What
technical approach do you believe would do so?
Let me rephrase that: A determined attacker will be able to bypass the
above mechanism, however what we see in practice today is that malware
is increasingly using TLS to hide command and control traffic (not to
mention that it often gets downloaded over a TLS protected session to
begin with). I am not aware of specific examples of malware that try to
bypass inspection using techniques as described above (nor have I
looked), but it's certainly possible. There are other discrepancies that
will show up though when you start looking at the actual destination
reached and possibly do other analysis over the (encrypted) session.
Thanks
-- Flemming
-Ekr
Thanks again for the feedback - we will update accordingly in the
next version of the draft.
-- Flemming
-Ekr
[0] Note: the use of static DH is very rare.
On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing)
<ncamw...@cisco.com <mailto:ncamw...@cisco.com>> 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
<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
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls