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

[Eric Rescorla <[e-mail]>]

I'm not seeing a lot of enthusiasm for this option either.

Do any of the people who were in favor of #1 or #2 want to say they prefer
some variant of this proposal?

-Ekr


On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <[e-mail]> wrote:

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