On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > > 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. > > Indeed that's effectively what you get with DANE TLSA "3 1 1", when > the client, the server or at present typically both don't support > RFC 7250. > > > 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. > > The signal has pros and cons. Absent channel-binding at the next > layer up, it makes it clear to adversaries that active attacks are > "safe". On the other hand, it allows servers to detect that a > client is not planning to authenticate the server, which has forensic > value, and can be used to grant appropriately restricted access. > > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. > How does anon-DH have different privacy properties than doing RFC 7250 with a fresh signing key for each connection? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
