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
