Re: [TLS] Consensus call for keys used in handshake and data messages

[Eric Rescorla <[e-mail]>]

Nobody seems super-excited about either Option 1 or Option 2, so it's
at least worth noting that there's one of the options I claimed was
rejected earlier, namely separately encrypting the content type in
roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for
Doug/Felix for prompting me on this.


NOTE: I don't promise any of the below is secure, though it probably
can be made so with enough work. Actually doing so is an exercise
for the reader.


The basic idea is as follows:

1. In each direction generate a separate "content_type_key"
2. Separately encrypt the content type from the rest of the record
   using the content_type_key.
3. On the receiving side, first decrypt the content type and then use
   that to determine what key to decrypt the record.

The trivial version of this is just to AEAD encrypt the content type
separately, but this has unacceptable bandwidth and CPU properties, so
is probably not viable. However, there are more efficient designs,
which can get the overhead down to modest levels (<= 1 byte of
expansion and <=1/16 of a block computation/record).

The obvious construction is to use the content_type_key to compute a
per-record masking value (effectively an ad hoc stream cipher) and
then use that to encrypt the content type (or potentially just a key
type bit) without integrity (though you might later protect it in the
additional data block under the main key). This gives you an
encryption function without expansion. If you have a mask function
which outputs one block at a time, you can use pieces of the block for
each record (e.g., for record N you use byte N/16) [1]


Obvious objections to this:
1. This isn't integrity protected. This is probably the most serious
complaint and has the potential to actually leak information about
the content type unless you're careful [2], even if you eventually
integrity protect this information.

2. It's odd to just use a piece of the AEAD cipher (the encryption
function), especially if we ever had a really non-composite cipher.
This can be alleviated by using HKDF-Expand to produce the stream
of bits.

3. Maybe it doesn't get the whole job done, especially wrt the fact
that we're not rekeying the app data after client auth.

4. It's gross. Yes, yes it is.


I'm not really in love with this idea, but I did want people to know
that maybe we don't *have* to choose between option 1 and option 2
in case that changes people's opinions.

-Ekr


[0] Note, I'm specifically not trying to protect length here. That
might be attractive, but my sense is that for the reasons Kenny
indicates it's harder to get right and I'm generally pretty skeptical
of length hiding in TLS given that we already have added padding.

[1] There are some subtleties about not breaking the record format.
If we don't care, then we can strip the first three bytes and then
steal a bit from the length to use for "key type" (the length will
never hage the high bit set). If we do care, then we could use the
key bit to toggle between "app data" and "handshake" in the dummy
record type byte.

[2] Naively, if you try encrypting the whole content type, some
transformations on the encrypted value will produce invalid types,
which leaks information if the receiver sends an alert.


On Fri, Jun 17, 2016 at 1:18 PM, Hugo Krawczyk <[e-mail]>
wrote:

> I am abstaining on the choice of alternative 1 and 2 since I do not
> understand
> enough the engineering considerations and ramifications of the different
> choices. Also, I have not put any thought into the privacy issues related
> to
> hiding content type and I certainly did not do any formal analysis of these
> aspects.
>
> I do want to say that from a cryptographic design and analysis point of
> view,
> key separation is of great importance. It allows to have more modular
> analysis
> and design, and prove composability properties of protocols and
> applications.
> I believe it has significant practical advantages particularly with
> respect to
> "maintaining" a protocol, namely, making sure that changes and extensions
> to a
> protocol are secure and do not jeopardize its security. The more modular
> the
> design the easier it is to reason about changes and additions to the
> protocol
> (and for a protocol like TLS, future changes and adaptations to different
> settings are unavoidable).
>
> As for the specific cryptographic considerations in TLS 1.3, I would have
> "fought" greatly to preserve key separation at the level of the basic
> handshake
> protocol (three first flights). It guarantees that the application key is
> *fresh* at its first use for protecting application data. Freshness means
> that
> the key can serve any purpose for which a shared random secret key can be
> used.
> (In contrast, a non-fresh key, e.g. one used during the handshake itself,
> can
> only be used with applications that are aware of how exactly the key was
> used
> in the handshake.) Since my understanding is that the current
> base-handshake
> specification does preserve the freshness of the application key, I am
> happy
> with that design.
>
> The issue of using the application key to protect post-handshake messages
> is
> more involved. First, post-handshake client authentication authenticates
> ("a
> posteriori") the application key but only after this key has already been
> used.
> In this sense this mechanism cannot possibly achieve key freshness for the
> application key. The best one can hope for is that this post-authentication
> authenticates the key without jeopardizing its use in the particular
> application
> it is intended for, namely, protecting TLS record layer data. Luckily,
> this can
> be proved. So now the question is whether using the application key to
> encrypt
> the very messages that provide post-handshake authentication (e.g.,
> client's
> signature) may lower the security of this key. The answer is that it does
> not.
> That is, the security of the key for protecting record layer data is not
> jeopardized by using it to encrypt post-handshake messages.
>
> I feel moderately confident about the above paragraph as I have been
> working on
> the analysis of client authentication, including (encrypted) post-handshake
> authentication. On the other hand, I have not studied the effects of
> encrypting
> other post-handshake messages such as New Ticket or re-keying messages so I
> don't have an "educated conclusion" here. I do expect that there are
> analytical
> advantages for not using the application key for encrypting these messages
> but I
> cannot say for sure.
>
> In all, it is good and prudent practice (not just theory) to enforce key
> separation wherever possible, and I would be happier if there was no
> instance
> where the application key is applied to non-application data. But I also
> know
> that one has to weigh other engineering considerations and in this case the
> trade-off does not seem obvious to me. Hence, as said, I abstain.
>
> Hugo
>
>
> On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey <[e-mail]> wrote:
>
>> For background please see [1].
>>
>> Please respond to this message indicating which of the following options
>> you prefer by Monday June, 20, 2016
>>
>> 1. Use the same key for handshake and application traffic (as in the
>> current draft-13)
>>
>> or
>>
>> 2. Restore a public content type and different keys
>>
>> Thanks,
>>
>> J&S
>>
>>
>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>