On 2011-02-05 13:28 PDT, Zack Weinberg wrote: > On 2011-02-05 1:13 PM, Nelson B Bolyard wrote: >> Zack, thanks for bringing this to this list/group. I think many of >> us were caught by surprise by it, because it is a browser policy >> proposal rather than a technical discussion of the protocols. > > Personally, I was a little surprised to be asked to discuss this here > rather than a more policy-focused group.
There is a list/newsgroup focused specifically on the browser policy governing the admittance of CAs to mozilla's root CA list. That probably seems like the more obvious place, but it's where all the CA representatives hang out, and some fear that any proposal that appears to be intended to displace PKI will not get a fair hearing in that venue. But feel free to brave mozilla.dev.security.policy if you wish. > I have been trying to stay out of any PKI versus DANE arguments, and > (as you may see from the proposal) I still see a role for "traditional" > CAs in providing additional validation beyond "the server for this DNS > name should be using this public key". I think CAs still get most of their revenues from DV, and so perceive DANE as a direct threat. > However, I wouldn't especially miss the current state of affairs with > DV certification if DANE totally supplanted it. Sadly, I'm sure you're not alone. >> 1) I suggest you eliminate the word "bogus", > "bogus" in this case is a term-of-art defined by RFC 4033. > > # Bogus: The validating resolver has a trust anchor and a secure > # delegation indicating that subsidiary data is signed, but the > # response fails to validate for some reason: missing signatures, > # expired signatures, signatures with unsupported algorithms, > # data missing that the relevant NSEC RR says should be present, > # and so forth. > > I think deferring to that document for definitions of DNSSEC validation > outcomes is what the IETF is going to want. Yes, thanks for that info. I obviously wasn't aware of that definition. Would a parenthetical reference to it in that sentence be redundant? >> 2) After 14 years of working on SSL/TLS for browsers, I can tell you >> that browsers will all ignore the paragraph that says "Clients SHOULD >> NOT allow users to force a connection ...". I suppose that surprises >> no-one. > > If I have anything to say about it (and I intend to), Mozilla will > *not* ignore that paragraph. ;-) There's at least a little precedent > in the Strict Transport Security specs. All the browsers live in mortal fear of losing market share. Anything that causes users to TRY another browser is to be avoided at ALL COST. Historically, unbypassable security errors have been among the leading causes. The only way to get browsers to do it is to get ALL browsers to do it at the same time. I believe that is not possible. Many failed attempts by lots of people to make that happen back by belief. If you're not on this list, please join it. Customarily, replies go only to the list with no CC's to others. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
