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

[Michael StJohns <[e-mail]>]

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.

Assuming super powers that let me twiddle with packets in flight - I 
modify the MAC over the negotiation records to cause it to fail 
verification at the server.  Or I intercept the response from the server 
and replace it with an unsigned "sorry, no cached key" error message.  
Either way causing the client to fall back into unencrypted mode.

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

Mike



>
> Sincerely,
> Watson Ladd