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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Sep 2019 18:58:41 -0500

On Sat, Aug 31, 2019 at 12:25:02AM +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 30/08/2019 23:24, Benjamin Kaduk 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".
> 
> 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?

I don't remember hearing about substsantial formal analysis, though I do
note that the draft acknowledges that (at best) it has the security
properties of a shared symmetric group key, given the nature of the setup.
I think we may need to be in Viktor's "raise the ceiling, not the floor"
mindspace here.

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

My crystal ball went missing, but I kind of expect lots of pitchforks if
the security ADs tried to insist on formal analysis of any TLS extension,
especially ones produced from non-security-area groups.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Sep 2019 17:08:57 -0700

> especially ones produced from non-security-area groups.

It's of course worth noting that extensions in general are not subject to
any kind of IETF approval, but merely to Specification Required.  Only the
Recommended flag requires IETF approval.

This document is different in that it registers a Handshake Type, and those
are subject to Standards Action, so one might argue that a higher degree of
analysis is required. I'm not sure how practical that would be in this
case. One compromise would perhaps be to demonstrate that this did not
weaken TLS itself?

I would be interested in Richard Barnes's thoughts.

-Ekr

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Sep 2019 10:28:36 +1000

Which value do they want?  As we have previously established in relation to the discussion on connection IDs and handshake types, there are values that would be sent in the clear in (D)TLS 1.3, which have very tight constraints, and those that would be sent under encryption, which might not need so close scrutiny.

I get the impression that there are constraints here.  This will likely be multiplexed in an RFC 7983 sense in DTLS 1.2, so the range of values here is narrow.  But not as narrow as to require access to the prime space between 20 and 31 that we are using for handshake types that need to be sent in the clear. I think that we should encourage the use of a value >= 32 in this case.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Sep 2019 22:22:46 -0500

> Which value do they want?  As we have previously established in relation to the discussion on connection IDs and handshake types, there are values that would be sent in the clear in (D)TLS 1.3, whi…

This one would be sent encrypted -- the contents need to be encrypted,
which impacted which mechanisms were viable for them.

> I get the impression that there are constraints here.  This will likely be multiplexed in an RFC 7983 sense in DTLS 1.2, so the range of values here is narrow.  But not as narrow as to require acce…

I don't think the specific value to allocate has come up yet; I'll try
to remember to keep an eye out once IANA gets to that point.

Thanks!

-Ben

---

From: Richard Barnes <[email-masked]>
Date: Tue, 3 Sep 2019 13:58:33 -0400

Thanks for invoking me by name, EKR :)

tl;dr: We considered all available options, and using a new handshake type
was the least bad.

Watson has correctly summarized the goal here, which is to distribute a key
that encrypts another key, which encrypts media.

1. Keys from the DTLS handshake encrypt the EKTKey message, which contains
an EKTKey value
2. The EKTKey value is used to encrypt an EKTCiphertext, which contains an
SRTP key
3. The SRTP key is used to encrypt SRTP media.

Steps (2) and (3) are independent of DTLS, so we can put them aside.  The
design question the PERC WG faced was how to accomplish (1).  As Watson
points out, there are several approaches here, each with trade-offs
(copy/pasted from an earlier discussion of the options with EKR).

"""
1. TLS extension
Pro: Simple / natural, since server always sets EKTKey
Con: Dependency on DTLS 1.3

2. New DTLS Handshake Message type
Pro: Encrypted in all versions of DTLS; already needed in 1.3
Con: Not a natural extension point; new-ish in pre-1.3

3. New DTLS record content type
Pro: Encrypted in all versions of DTLS
Con: Not a natural extension point

4. DTLS application data
Pro: No impact on DTLS or SRTP stacks
Con: Have to demux from actual application data

5. EKT message type in SRTP
Pro: No impact on DTLS stack; no demux
Con: KD has to originate SRTP; MD has to forward
"""

For the authors (subsequently ratified by the working group), the decision
process went roughly as follows:

- (1) is not workable because a dependency on DTLS 1.3 is not acceptable
- (5) is not a good fit with the PERC architecture (in which the Key
Distributor (KD) has no other reason to originate SRTP)
- (4) would require updating the demuxing rules in DTLS-SRTP, which are
already challenging (see https://tools.ietf.org/html/rfc7983 for example)

Between (2) and (3) was a closer choice.  What tipped it for us at the time
was that, looking at a handful of existing TLS stacks in 2017, it appeared
there was pretty good support for new handshake types, but not for new
content types.  (In the language of GREASE, the joint was rusty. It maybe
that this picture looks different now that we're a bit further along with
DTLS 1.3 and Ack is now a different content type.  It is true that much
like Ack, EKTKey does not need to be included in the transcript.)  In
addition to that, DTLS has no pre-defined mechanism for reliability for
anything other than handshake messages, so EKT would have to invent one if
we used a new content type.

All that said, my personal inclination here is to stick with the new
handshake type.  Switching to a new content type, and thus adding all the
spec text to make it reliable, would be a major change at this stage of the
process.  And it's not clear that there's sufficient benefit in terms of
architectural cleanness to merit it.

Finally, to Stephen's question of analysis -- This doesn't affect the DTLS
analysis.  All that's being done here is that another value is being
encrypted with the keys from the DTLS handshake.  In that regard, it's like
any other application protocol.  In the current approach, where we use a
different handshake type, it is true that the EKTKey messages are fed into
the DTLS transcript hash, which could affect future keys.  But this
shouldn't allow any undue influence on those future keys, because unless
the hash function has a preimage attack, an attacker can't choose a
malicious input that leads to a particular value.

--Richard

On Sun, Sep 1, 2019 at 8:10 PM Eric Rescorla <[email-masked]> wrote:

> This document is different in that it registers a Handshake Type, and
> those are subject to Standards Action, so one might argue that a higher
> degree of analysis is required. I'm not sure how practical that would be in
> this case. One compromise would perhaps be to demonstrate that this did not
> weaken TLS itself?
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 Sep 2019 21:59:52 +0100

Hiya,

> malicious input that leads to a particular value.

Thanks. However, we're previously seen unexpected comments
from people who do such analyses (e.g. "if you did it <this
other way> it'd be easier to analyse"), so personally I'd
prefer we still had that kind of analyst do that kind of
analysis.

I think there's real value in not lowering the bar for
TLS changes like this, and this does still smell like that
to me.

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Sep 2019 23:38:37 -0700

I wish I understood the analysis of TLS 1.3 better, but a core feature
of the protocol is compositionality: the keys from the handshake are
fresh, unlike in TLS 1.2 where they were used to encrypt the Finished
thus posing an obstacle to analysis. Here the handshake key gets used
to encrypt a message that has nothing at all to do with the handshake:
probably fine, but not obviously fine. What's more of a problem is
that the application level keys are now used multiple times: first to
encrypt part of the handshake (the EKTKey message) and then
potentially other data (RFC 5764 doesn't say you close the channel and
only do SRTP). That breaks compositionality. Safer would be to derive
separate keys for everything.

The other question I have is with the assertion that cut and paste of
the same EKTCiphertext across senders is harmless. The data obtained
will not be random. In some cases (say if unauthenticated counter mode
is being used) it will have a very predictable relation to the
original data, and the resulting errors may leak information. These
sorts of attacks have a long history of happening: it may be more of
an issue for other parts of this whole effort, but I don't think it's
as harmless as the draft says.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 5 Sep 2019 17:36:39 -0400

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <[email-masked]> wrote:

> probably fine, but not obviously fine.

Minor clarification (which agrees with your text below): THe EKTKey message
is not encrypted with the handshake traffic key, but with the application
traffic keys, just like other post-handshake handshake messages (e.g.,
KeyUpdate).

What's more of a problem is
> separate keys for everything.

Isn't this already the case with DTLS?  The application-level keys are used
to encrypt both application messages and post-handshake handshake messages.

> the same EKTCiphertext across senders is harmless.

Just for clarity: This is not related to the TLS HandshakeType request;
it's about the part of EKT that happens in the SRTP stream.

The data obtained
> as harmless as the draft says.

If it would help make people more comfortable, I think restricting EKT to
be used only with AEAD transforms would be tolerable.  What you would
really like here is a committing encryption scheme [1], but unfortunately
there aren't any of those readily available.  And although neither GCM nor
ChaCha/Poly is committing [2], it's not clear that that matters here,
because the attacks listed in [2] require that the attacker know both keys
involved in the collision (whereas here the attacker would know neither).

--Richard

[1] https://eprint.iacr.org/2003/254
[2] https://eprint.iacr.org/2017/664.pdf

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 15:06:21 +0000

But it seems entirely reasonable for the Sec AD's to require that the security considerations mention that this has not had the extensive analysis that TLS 1.3 received.  Many people, not seeing that sentence, will conclude that this is just as good as straight TLS 1.3, which we don't know.