Re: [TLS] Closing on keys used for handshake and data messages

[Björn Tackmann <[e-mail]>]

Hi dkg,

sorry for my late response.

Let me start by saying that I do not believe that this is really critical; after all, we can prove alternative (1) as well — it’s just less clean and makes the proofs harder to write, read, and verify, which is generally not a good thing for a cryptographic protocol. On the other hand, the privacy improvements offered by alternative (2) appear to be rather moderate; even if we were to realistically achieve the best privacy it could offer, it would protect the fact that a “new session ticket” message (is this a gain at all?) or a client auth message was sent. If I understood correctly, client auth has not been widely used in previous TLS versions, and even if this would change, it’s not quite clear how big the gain is. Maybe you have more precise insights into this than I do?


> On Jun 9, 2016, at 11:56 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> I confess i was hoping that double-encrypting would provide some measure
> of useful key separation for cryptanalysis.  I don't think i understand
> Ilari's explanation in this thread, though, so i'd appreciate any other
> attempts to clarify.

Double encryption is not problematic. It just does not have advantages over alternative (1) in terms of cryptographic analysis (it does not quite help in modularizing the proofs). On the other hand, we’ve heard (others may want to chime in) that it /does/ make the implementation more cumbersome, in the sense that it requires more changes to the existing code base.

In that sense, it appears to be strictly dominated by alternative (1).


>> PUBLIC CONTENT TYPES
>> 
>> Clearly, having a public content type and separate keys for handshake and
>> application data provides full key separation, at the cost of revealing
>> whether a given record is handshake or application data (and potentially
>> alerts). The major question that the group had was whether it was actually
>> possible to conceal this information effectively, even with encrypted
>> content types, since hiding the handshake messages in the application
>> traffic requires detailed knowledge about the application traffic pattern
>> (e.g., packet lengths, timing, response patterns, etc.). It’s clear some
>> analysis of this is needed.
> 
> We know that traffic analysis is difficult, and may in some cases be
> impossible.  This is an area in need of active research.  However,
> deciding to make it *always* impossible to protect because we don't know
> how to protect it absolutely is "security nihilism", and i hoped we were
> moving beyond that mindset as a community.

I beg to disagree here.

First, we would not drop it for no reason whatsoever. We would drop it because dropping it has other advantages. It’s a trade-off.
Second, we should in any case carefully point out that this mechanism alone, i.e., without proper padding etc., may not provide any additional privacy guarantees. A security mechanism that does not work can be worse than no mechanism at all if people start relying on it without understanding what it achieves.

Introducing a mechanism without analyzing it is somewhat akin to what happened to encryption with compression. (Used properly, it can be useful.) I hoped we were moving beyond that mindset — sorry for echoing ;-)


> If we don't have a mechanism to hide this metadata, then we certainly
> won't develop any useful practice around actually making it
> indistinguishable.  Protecting users is a multidimensional problem.  We
> should provide a mechanism to make this information indistinguishable in
> the axis we know how to handle (encrypting the material itself) so that
> there is a reason for people to work on the axes we don't yet know how
> to handle (protecting against traffic analysis).

I’m totally in for protecting user privacy. I simply believe that we should first specify what we want, then see whether we can achieve it, and then build the mechanism that does it.


Cheers,
Bjoern


--
Björn Tackmann
Postdoctoral Research Scholar
Computer Science & Engineering, UC San Diego