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
