Re: TLS server keys in DNS: client policy proposal
On 02/05/2011 03:28 PM, Zack Weinberg wrote: "bogus" in this case is a term-of-art defined by RFC 4033. You have made my day. :-) I am so tweeting that. - Marsh https://twitter.com/marshray/status/34121219292790784 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 2011-02-05 2:02 PM, Nelson B Bolyard wrote: On 2011-02-05 13:28 PDT, Zack Weinberg wrote: >> ... 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. Since the conversation has started here, let's keep it here for now. 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. Quite possible. 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. In this hypothetical, what would you consider to have been lost? (This is not a rhetorical question, and in fact I have a concrete answer to it myself, but I'd like to hear yours first.) "bogus" in this case is a term-of-art defined by RFC 4033. [...] Yes, thanks for that info. I obviously wasn't aware of that definition. Would a parenthetical reference to it in that sentence be redundant? No, that's a good idea, I'll add one. 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. Allow me my optimism for the moment, please. It certainly *was* the case in the past that "anything that causes users to try another browser is to be avoided at all cost" but I think that is no longer true, and the STS experience says that browsers *can* manage un-bypassable security errors with opt-in from the site (which DANE can be considered as). Note that if we can't get this language (or any of the rest of it) into the IETF's spec, my fallback plan is to put it forward as browser consensus behavior for HTTPS, working through the W3C, the CABforum, or WHATWG; so I don't think getting all browsers to do something at the same time is impossible in this case. If you're not on this list, please join it. Customarily, replies go only to the list with no CC's to others. I am reading it via the newsgroup. zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 02/06/2011 12:02 AM, From Nelson B Bolyard: I think CAs still get most of their revenues from DV I'm not sure if that's correct (revenues != market share)... and so perceive DANE as a direct threat. and I believe that DV certs issued by CAs provides what the proposed keys in DNS can't. Most likely we'll get to that at some point... 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. However probably the optimal approach will be CA issued certs in DNS that also make use of DNSSEC to validate the former (DV). Eventually I believe that this will emerge as the real improvement and most useful approach for software vendors and CAs alike - providing real value for what DV is supposed to do and by closing the entire circle. And most likely this is not what the Anti-CA crowd wants to achieve, but nevertheless might get in the end. :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
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
Re: TLS server keys in DNS: client policy proposal
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. Technical details of DANE are still up for discussion in the working group; if anyone feels like it, I would say that the present argument over exactly where in the DNS namespace TLSA records should appear, and whether or not TLSA should be coupled to some sort of service discovery mechanism, is in need of feedback from people who implement TLS-based application layer protocols. I, however, am mostly interested in policy. > Some of us have not been following the DANE work actively, and will need some time to read up on it and appreciate all its implications. Quite a few of us are (or, have been) die hard PKI advocates and some have seen DANE as an attempted threat to PKI. I think some of us have hoped it would fail and go away, but it seems to be becoming a juggernaut, and I think those who ignore it do so at their own peril. With regard to NSS, I think that if NSS ignores it, and is found to not adequately facilitate the implementation of DANE, it may become irrelevant. 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". However, I wouldn't especially miss the current state of affairs with DV certification if DANE totally supplanted it. 1) I suggest you eliminate the word "bogus", replacing it with a much more precise description of records that MUST NOT be trusted in the establishment of a connection. Bogus is too open to interpretation, which can only lead to future disagreement. "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. 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. zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 2011-02-01 07:57 PDT, Zack Weinberg wrote: > I've been following the mailing list for the IETF's "keyassure" > working group, which plans to standardize a mechanism for putting > application-layer server keys (or their hashes) in DNS, certified by > DNSSEC. TLS/SSL is the first target, and of course also the most > interesting for the Web. > > While the current proposal seems sound technically, the WG has been > avoiding client policy -- there is a bit of policy in the current > draft, but it's worded vaguely enough to be (IMO) useless. I've > drafted a policy spec which I'd like to propose to the WG. However, > before doing so, I thought I would run it by y'all. If you like it, > perhaps we could present this as the Mozilla consensus position rather > than just one guy's opinion; if you don't like it I am eager to hear > why. > > For reference, this is the current draft proposal: > > http://tools.ietf.org/html/draft-ietf-dane-protocol-03 [snip] 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. Some of us have not been following the DANE work actively, and will need some time to read up on it and appreciate all its implications. Quite a few of us are (or, have been) die hard PKI advocates and some have seen DANE as an attempted threat to PKI. I think some of us have hoped it would fail and go away, but it seems to be becoming a juggernaut, and I think those who ignore it do so at their own peril. With regard to NSS, I think that if NSS ignores it, and is found to not adequately facilitate the implementation of DANE, it may become irrelevant. That said, at this time, I have a few comments that apply directly to your proposal. I may have more later. 1) I suggest you eliminate the word "bogus", replacing it with a much more precise description of records that MUST NOT be trusted in the establishment of a connection. Bogus is too open to interpretation, which can only lead to future disagreement. 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. I hope others will join a discussion here. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
