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.
The proposal to use raw public keys sends a similar signal to
servers that don't publish DANE-EE(3)/SPKI(1) TLSA records. X.509
clients can no longer to PKIX authentication. A server that does
publish DANE-EE(3)/SPKI(1) records on the other hand can no longer
conclude that authentication is not done. And of course clients
may be doing public key pinning, be it TOFU, or via some out-of-band
means.
Clearly getting along without anon_DH is possible, since many
servers or clients don't enable anon_DH ciphers and yet interoperate
just fine with those that do.
My view is that anon_DH should either be supported properly (be
defined for the same symmetric cipher combinations as ciphersuites
with certs or public keys) or as proposed not supported at all.
Replacement by public keys is not semantically equivalent, it just
saves a bit of network and code space relative to self-signed X.509.
So I'm not yet convinced that the proposal is progress, we lose
some and gain some.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
