Re: [TLS] draft-rescorla-tls13-new-flows-01 - Thoughts post-meeting

[Michael StJohns <[e-mail]>]

On 3/17/2014 11:33 AM, Eric Rescorla wrote:
>
>
>
> On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     And unfortunately, I don't think EKRs proposal does it either.
>
>     There are a few things you need to do symmetric encryption - a
>     mutual key and an agreed upon cipher suite.  EKR proposes
>     retaining the keys and suite from a previous connection and using
>     them to encrypt the negotiation for the next connection.  To do
>     this, both client and server cache the previous keys.   If you
>     have no previous connection, or you or the server have timed out
>     the cached keys, EKR has you fall back to doing an unencrypted
>     negotiation followed by an encrypted negotiation.  Unfortunately,
>     as I understand how this works, the SNI needs to be in the first
>     negotiation so that the director can steer the packets to the
>     appropriate server.
>
>
> Just for clarity, this is not quite what I was proposing. Rather, I was
> proposing that if the cached keys expired, you did an anonymous
> DH exchange, so you get protection for the target server against
> passive attack but not active attack. I agree that you can mount
> an active attack as suggested below, though it cannot be done
> totally transparently.

Right - what I said - you do an unencrypted negotiation by offering an 
ANON suite or suites (probably the latter to prevent DH from becoming 
indispensible) in a clear text ClientHello.  You then re-use the key 
from that negotiation to encrypt the re-negotiation handshake exchanges.

>
>
>     This gets worse when the virtual server director isn't actually on
>     the same server as the actual server, as the director will need
>     copies of the keys in the same timely fashion as the servers.  And
>     that makes the director a big juicy target.  (Seriously a single
>     box with all the session keys for 1000s of sessions with 100s of
>     servers? Let me at it)
>
>
> Note that this situation is a fairly standard configuration for SSL 
> acceleration
> devices in any case. What's different here is primarily that the load 
> balancer
> is not generally required to be trusted.

Yup.

>
>
>      The threat could be partly mitigated by deriving a separate set
>     of keys for "next session encryption negotiation", but that would
>     change the current key expansion stages a bit.  And still begs the
>     question of how keys get from the virtual server to the director
>     so this can be done.
>
>     Another approach might be for the client (only) to retain the
>     public key of the specific destination server, or a special use
>     public key handed to the client by the server as part of another
>     negotiation (and which related private key is shared with the
>     director - said key being very long lived).  Use that to encrypt
>     the SNI (either RSA encryption, or something like ECIES for
>     elliptic curve).   And even use that as the encryption over the
>     negotiation.
>
>
> Without digging too much into the details just yet, it seems to me
> that the key element if you want to have protection against active
> attack is that the client must be able to directly verify that a given
> key is owned by the server in a way that cannot be substituted by
> the attacker. The challenge, of course, is that the information
> that the server uses to authenticate that key inherently reveals
> the server's identity. I see two basic options [0]:
three?

>
> - Have the client acquire the server's key over some untrusted channel
> and accept that it can be monitored the first time.
>
> - Have the server provide a large set of keys (like all the ones that
> it supports) to the client and then the client can choose one.
Do this as a public key operation instead of a symmetric key op, and 
have the server provide a public key specific to the "encrypt the 
handshake" protection during one of the prior connections.  That gets 
cached by the client.

I mention this for completeness.  It has the benefit of not requiring 
the server to cache anything, but the potential downside of a DOS attack 
based on the cost to derive a key.  But that's no worse than an ANON 
negotiation I think.  If you cache the client public key and/or the 
derived shared secret you mostly eliminate that issue (but loses you 
some of the benefit of the approach).

>
> Note that in either case, this represents a commitment by the server to
> use that key through it's expiry window. i.e., it's hard state rather
> than soft state, which people have been so far reluctant to do with
> HPKP. Both of these have obvious drawbacks, so it's a
> compromise.
>
> -Ekr
>
> [0] I'm assuming we restrict ourselves entirely to the TLS channel.
> If we are willing to have data in, for instance, the DNS, there are other
> options for disseminating the initial key data.
>