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

[Eric Rescorla <[e-mail]>]

On Mon, Mar 17, 2014 at 8:08 AM, Michael StJohns <[e-mail]>wrote:

> On 3/17/2014 12:23 AM, Watson Ladd wrote:
>
>> Dear Mr. StJohns,
>>
>> Suppose you work at the Chinese Ministry of Truth, in the department
>> of web truthmaking, domain forgetting division.
>>
>> Right now, if you want to ensure HTTP content is in conformance with
>> the truth you simply scan for the Host header and check against a
>> list.
>>
>> For HTTPS life could get nasty. But luckily we decided to put SNI
>> information on the outside, so you can see if that connection needs to
>> go down the memory hole.
>>
>
> Or the CMT just blocks all access to the device because its a known SNI
> encryption box.    If you get to assign super powers to an entity to make
> your point, then so do I.
>
>
>
>> Now you hear about this TLS 1.3 coming along, and how it obfuscates
>> SNI. So you present the following design to your boss:
>> 1: Each device on the filtering maintains a global IP->[Hosts] mapping.
>> 2: When an obfuscated SNI comes along, you check against all hosts in
>> the mapping
>> 3: If it is marked as untruthful block
>> 4: If unknown, transmit it to a dedicated cracking machine.
>>
>> Within a week the cracking machine is likely to figure out what the
>> hostname is, at which point it can be added to the list. If the agents
>> watching the spreading of untruth see a domain, we can just add it.
>> The computational cost will never exceed that of the hosting device.
>>
>> Your proposal doesn't stop censorship or even make it more expensive.
>> It doesn't hide visits to websites effectively if the attacker is
>> interested in checking against a big list. It doesn't accomplish any
>> of the goals we need it to.
>>
>
> 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.


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.




>  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]:

- 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.

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.