Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

[Benjamin Kaduk <[e-mail]>]

On Fri, Aug 30, 2019 at 03:57:23PM -0700, Watson Ladd wrote:
> On Fri, Aug 30, 2019 at 3:24 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > Hi all,
> >
> > New values for core types like TLS HandshakeType and ContentType don't
> > happen very often, so I thought people might be interested to know that
> > draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocating
> > a HandshakeType, to carry key information used to encrypt SRTP media key
> > material.
> > Obviously "it's never too late to change until the RFC is published", but I
> > think there would need to be some pretty serious issues in order to change
> > it at this point, so this is expected to just be an "FYI".
> 
> Design issues: Am I reading the doc right, that this handshake message
> goes after the finished? And then contains a key that is used to
> decrypt another key that is then used to decrypt (some) traffic, but
> doesn't change the DTLS keys? Why is this a handshake message and not

I think that's "yes" on all counts.

> some protocol framing in the protocol carried over DTLS? It just seems
> funny to make it be a handshake type and not something else. It's
> entirely possible this makes more sense if you know about DTLS-SRTP
> which I do not very much.

I don't consider myself an SRTP expert, but I think to zeroth order you can
model DTLS-SRTP as being a single "hybrid" protocol that takes the DTLS
handshake for key exchange and slots in a SRTP message-protection layer
that is analogous to the traditional TLS Record layer.  RFC 5764 even has a
pretty picture: https://tools.ietf.org/html/rfc5764#section-4.1 .

If you consider the "DTLS-SRTP hybrid protocol", then this new
HandshakeType becomes a way for the handshake layer to supply cryptographic
input to the SRTP record layer, which is not so crazy of a request.

You're right, of course, that it could be done in some protocol framing at
the DTLS application data layer or within the SRTP framing layer, but I'm
pretty confident that the authors/WG have considered those options and
still picked this one.

That said, I'm pretty sure some people who are more familiar with that
history than me are on this list, and hopefully not afraid to chime in and
correct me or clarify as needed.

Thanks for looking,

Ben