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

[Hugo Krawczyk <[e-mail]>]

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