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

[Richard Barnes <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Sun, Sep 1, 2019 at 4:59 PM Benjamin Kaduk <[e-mail]> wrote:
>
>> 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.
>>
>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>