This seems fine to me, though I'll note that 7250 only really saves you space when it comes down to it. You can wrap your raw public key in a certificate, just like we do in WebRTC, and then you don't need 7250 support in your library. Noting you can only do any of these variations in a context where there is some preexisting understand that what you choose to use is acceptable to the other side.
Regarding the explicit nature of having an explicit DH_anon signal, I tend to think that (on balance) removing this signal does more good than harm. I expect certain others to disagree, of course, but we can talk about why a vigorous defense of the cipher suite signal isn't a good use of their energy later. On 28 August 2015 at 10:35, Eric Rescorla <e...@rtfm.com> wrote: > https://github.com/tlswg/tls13-spec/issues/233 > > Folks, > > We presently have some support for DH_anon cipher suites. I agree that this > is a useful use case, but it's yet another mode. > > I would like to suggest that we instead deprecate it and instead always use > Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that > the client would simply indicate support for a raw public key and the > server could then either (a) spin a new key for this use or (b) use a > long-term > one. To my mind this has three advantages: > > 1. Complexity: It means that we have one less operational mode. And all the > public key > modes would look cryptographically similar. > > 2. It resolves the question of how you bind to the server's identity in > 0-RTT mode > (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key > that goes in the Certificate message. > > 3. It makes it easier to do an SSH-style leap-of-faith mode since the server > can > use the same signing key for a long time while maintaining PFS. > > It seems to me that the two major counterarguments are: > > 1. Extra computational cost from the signature. I'm not worried too much > about that since generally the anonymous contexts don't do a lot of > connections > and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes > anyway. > > 2. It's less explicit that this is unverified. Arguably this is a feature > rather than > a bug. > > Thoughts? > -Ekr > > > > > _______________________________________________ > 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
