And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today". There's nothing in here that degrades security (except maybe the legacy crypto in the DNS); it's just not meeting the bar that you are setting. That doesn't mean there's not still some utility to be had.
--Richard On Wed, Apr 4, 2018, 22:57 Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams <n...@cryptonector.com> > wrote: > >> On Thu, Apr 05, 2018 at 02:39:43AM +0000, Richard Barnes wrote: >> > Re-adding the list. >> >> Removing one level of quotes. >> >> > On Wed, Apr 4, 2018, 22:34 Nico Williams <n...@cryptonector.com> wrote: >> >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> >> > I don't think that this comparison is particularly apt.The >> >> > representation in HSTS is simply "I support HSTS". The representation >> >> > in HPKP is "I will use either consistent keying material *or* a >> >> > consistent set of CAs". The representation here is "I will continue >> to >> >> > have DNSSEC-signed DANE records". That is a significantly more risky >> >> > proposition than continuing to support TLS (and I'm ignoring the risk >> >> > of hijacking attacks that people were concerned with with HPKP), and >> >> > so this seems rather more like HPKP to me. >> >> >> >> Without a TTL (with zero meaning "clear the pin to DANE") this >> extension >> >> can only really be used with mandatory-to-use-with-DANE protocols, >> where >> >> the commitment to "continue to have DNSSEC-signed DANE records" is >> >> implied. >> > >> > This is just not true. As I said in my earlier message, servers can >> > switch based on the ClientHello. >> > >> > Clients advertise which methods they support, servers switch, and they >> > both see how often DANE gets used. When it gets high enough, they turn >> off >> > the fallback. Just like every other TLS feature we've ever done. >> >> If clients and servers just negotiate the use of DANE, then there's a >> downgrade attack when DANE is the only outcome desired by the server >> operator but some WebPKI CA is willing to issue a rogue certificate for >> it. >> >> That downgrade is a fatal flaw for any protocols where this extension >> isn't mandatory. >> >> QED. >> >> We cannot be serious about security while promoting a protocol with a >> glaring downgrade attack. >> > > Unfortunately, you are conflating the assertive and restrictive use cases. > > To recap, there are two potential reasons why one might want thi > technology: > > 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's > a pain). This rationale was stronger back before Let's Encrypt, but > I suppose some people may still feel that way. > > 2. Restrictive: To protect yourself from compromise of the WebPKI. > > Yes, if your motivation is #2, then the flow you suggest is a real problem, > but it's not a problem for #1. While not an author of this document, I'd > understood it's primary motivation to be #1, and that's what Richard's > earlier notes have said as well. > > -Ekr > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
