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

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2016-06-03 17:54:53 -0400, Joseph Salowey wrote:
>    Trial decryption has serious implementation problems
>    -
>    Double-encrypting handshake messages in both the handshake key and the
>    application key does not actually provide the required key separation
>    -
>    Separately encrypting the content type is inefficient in a number of
>    ways, especially for DTLS (and would need separate security analysis). This
>    is probably the most viable of the “try to get both” designs.

I'm saddened by this analysis :( I understand that trial decryption
precludes inplace decryption, and i can see why that makes it a
non-starter for some implementations.

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.

> This leaves us with two primary alternatives:
>
>    1. Use the same key (as in the current draft-13)
>    2. Restore a public content type and different keys

Between these two options, I strongly prefer option 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.

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

      --dkg