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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Aug 2019 17:24:02 -0500

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

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Fri, 30 Aug 2019 15:57:23 -0700

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

>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Aug 2019 18:05:18 -0500

> doesn't change the DTLS keys? Why is this a handshake message and not

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 31 Aug 2019 00:25:02 +0100

Hiya,

> it at this point, so this is expected to just be an "FYI".

I guess I ought read the draft properly, but a scan
of the draft doesn't seem to show any references to
the kind of analyses that were done for tls1.3. I'm
not clear why that's ok. Is there a reason why that
is ok?

It was great that many people worked to do security
proofs for tls1.3. It'd be a shame to lose that via
extensions that are less well analysed.

Thanks,
S.