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...@rtfm.com> wrote: > > > On Sun, Sep 1, 2019 at 4:59 PM Benjamin Kaduk <ka...@mit.edu> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
