Re: TLS server keys in DNS: client policy proposal
On Sun, Feb 13, 2011 at 5:20 AM, Eddy Nigg eddy_n...@startcom.org wrote: I can see how DANE could be useful with CA issued certificates. The above is a non-starter (at least for me) and rather dangerous for any third party relying on it. But those are my opinions at least if and until this gets implemented anywhere and I can prove my point. Er, it is no more dangerous than DV, and quite possibly less so. DNSSEC is simply another way of asserting a verifiable chain of signatures. The registrar (acting under ICANN authority) accepts a public key token from the domain owner (which claim it has already authenticated) which can be used to verify the authoritative signature on the DNS responses. This is an order of magnitude more secure than DV alone, as it gets targeted DNS attacks out of the picture, and permits the domain owner to assert his own key without having to give anyone other than ICANN his information or pay anyone other than ICANN for the privilege of operating his system and domain. Remember, the state's subjects are the CA's peers. They aren't simply subjects of the CA, as they have sovereign right to ignore anything that the CA attempts to command or demand. Following from this, if the individual CA has no power, the conglomeration of CAs has no power either. If this were the only mechanism used to authenticate the connection, I would be leery of transacting business. Identity CAs are perfect for telling me who someone is. Identity CAs are not perfect, however, for telling me I can't talk to a site just because that site has decided to keep its owner's state identity hidden. In transactions with the site, a red X should appear on the submit button. If it's clicked, a dialog much like Hey, you're about to send information to a site which DOES NOT PROVIDE STATE IDENTITY INFORMATION. If you are wronged by the owner or operator of this site, your LEGAL RECOURSE WILL BE LIMITED. Continue? would be appropriate. DANE will solve one of the main problems with the current Identity CA model: that DV certificates are issued under the same trust anchors as state identity (OV/EV) certificates, with no standardized means of determining if the state identity of the enrollee can be known to legal process. At least with DANE you'll know that you're getting the ICANN-authoritative key for the domain, rather than a minimally-verified DV cert which may or may not have been issued to the correct entity. -Kyle H-- 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/12/2011 05:57 PM, From Stephen Schultze: Not at all. I was inviting others to voice their support of your position as well, but so far it's just you. Don't take this as an indicator of such - I'm usually more vocal (than others) and others might be not willing to enter into discussions with those that try to disrupt their business (or however the intention of the advocates (You) is perceived). Also this is not the policy list and the reason I thought this might be a place to share some arguments in favor and against. DANE is probably not a bad thing, it can be quite useful, depending on how this is applied. The proposed standard however states: Instead of trusting a certification authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. I can see how DANE could be useful with CA issued certificates. The above is a non-starter (at least for me) and rather dangerous for any third party relying on it. But those are my opinions at least if and until this gets implemented anywhere and I can prove my point. -- 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 02/12/2011 05:44 AM, From Steve Schultze: Not that many phishing attacks rely on HTTPS. That report also details phishing attacks *on people seeking to purchase SSL certificates* in which the phishing happens over plaintext. If there's any community that would require an HTTPS connection in order to be successfully phished, it would be that one. Right, financial institutions and CAs really should use something else than user name and password pairs. I know some that use client certificates instead (hint, hint). If anybody else on this list would like to present a more compelling argument than you have as if your arguments are more convincing and the only ones that count :-) but I don't think that the two of us will make any progress with more back-and-forth. Full agreement this time between us. -- 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 2/12/11 7:03 AM, Eddy Nigg wrote: If anybody else on this list would like to present a more compelling argument than you have as if your arguments are more convincing and the only ones that count :-) Not at all. I was inviting others to voice their support of your position as well, but so far it's just you. I am just a messenger on the DANE stuff, but I do think I've represented it accurately. As you may recall, this whole thread started when Zack proposed a statement of support of DANE (with some helpful edits to the draft spec). There are people far more qualified than me who can go into greater detail on the DANE WG list: https://www.ietf.org/mailman/listinfo/keyassure -- 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
Zack, I think having some kind of statement from the Moz community could be helpful, and a good excuse for Moz folks to get up to speed on the spec. With respect to the Section 3 text, it may be best simply to voice your thoughts directly on the DANE list. I don't think the current text is considered settled by the group. For instance, you can see my recent message suggesting changes consistent with Matt's suggested text: http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html I think your suggestions below track similarly to Matt's suggestion, but I need to take a closer look. I'd suggest we do this on the DANE list. If DANE seems to settle on something, and Moz folks don't like it, maybe we can coordinate on a counter-proposal. Does that seem reasonable? Cheers, Steve On 2/1/11 12:52 AM, Zack Weinberg wrote: [Some of you may have seen an earlier draft of this proposal before. I originally sent it to secur...@mozilla.org and was asked to bring it here.] 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 and the mailing list archives may be found here: http://www.ietf.org/mail-archive/web/keyassure/current/threads.html -- cover letter to WG begins -- I [We, Mozilla] would like to see the DANE specification's section 3 (Use of TLS certificate associations) expanded considerably. The present text is a great improvement on having no policy at all (as in earlier drafts) but is still vague enough that all client software might not behave in the same way in response to a TLSA record set; similarly, a server administrator might misunderstand the consequences of adding a TLSA record to their zone. Without a clear, unambiguous specification of client policy, I do not think DANE will offer any security benefits. Therefore I have drafted a policy which is suitable for the needs of Web security. It seems to me that it should also suit other protocols secured with TLS, but I could be wrong, and would welcome corrections. We see four primary benefits from DANE to the Web, and our proposal is written with them in mind: * It could provide additional security in the presence of untrustworthy middleboxes, such as home routers vulnerable to remote exploitation and conversion to MITM attackers. * It could provide a mechanism for preventing the suborned CA attacks described in http://files.cloudprivacy.net/ssl-mitm.pdf. * It could provide an alternative to DV certification for sites that currently opt to use self-signed certs. * It could eliminate inconveniences and security-degrading workarounds in the use of CDNs for TLS-secured content, such as very long subjectAltName lists. The proposal below is a complete replacement for section 3 of DANE. Small wording changes would also be required in some other sections; I am prepared to write those changes if the WG adopts this proposal. -- proposal begins -- # Client application behavior when TLSA records are present Clients that wish to make use of TLSA records in securing a connection MUST be security-aware in the sense of RFC 4033. (In subsequent text, it is assumed that the clients under discussion wish to make use of TLSA records if possible.) Clients MUST ignore TLSA records whose DNSSEC validation state is insecure or indeterminate. Clients MUST also ignore TLSA records they do not understand (for instance, records with a cert type or hash type they do not implement). Clients that receive *any* bogus records for a server that they wish to connect to (whether or not this affects a TLSA record) MUST NOT proceed with the connection. Clients that receive a secure TLSA record for a server MUST treat this as an assertion by the zone administrator that *only* end-entity certificates that can be associated with the domain name, according to the procedure in section 2.1, are legitimate. Therefore, if a client receives a secure TLSA record, and subsequently receives an in-band certificate chain that does *not* match the record, it MUST reject the certificate and abort the connection. This rule applies even if the in-band chain would have been trusted in the absence of TLSA information. Clients SHOULD NOT allow users to
Re: TLS server keys in DNS: client policy proposal
On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote: snip - OCSP and CRLs are unnecessary with DANE Steve, may we presume that you only intended this statement to apply to the use of self-signed certs with DANE? When an EV (or OV) certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs are still essential, because these certificates make claims (about organizational identity) that can't be assured by DNS(SEC)/DANE. When a DV certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs may be less than essential but they are still useful (e.g. the CA may subsequently detect that the key or hash algorithm used in the certificate is weak). Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- 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/11/2011 07:08 AM, From Steve Schultze: Can you give an example? Who the subscriber is (not higher level validation, sanity check), what the requested host name is, what's the purpose of a certificate, cryptographic weaknesses, to name a few. Would these checks be necessary under DANE or are they specific to the CA third-party-domain-validator model? I believe that they are necessary and requires involvement of a third party (if you want, you can call it something else than CA ;-) ) With DANE, such checks are part of the spec and the client implementation. As we have seen repeatedly on m.d.s.p., relying on CAs to enforce checks consistently is far less effective than implementing hard client checks. Well, as a matter of fact, the specs exists today for CAs too and are not enforced on the client side. What makes you believe that anything will change in this respect? By all means, how should individual users be more compliant to specs than CAs? Unnecessary with DANE. A review of the requested properties in a certificate are an obvious benefit, it's not unnecessary with keys-in DNS, it's not possible. I've made clear that I'm not a fan of such nannyism. So? Maybe you are not (that's your own problem which is not shared by the software vendors amongst other things), but it's a one of the tools CAs have and use when necessary. To the extent that it has to be done, the registries/registrars are simply a more direct path. You make me laugh - registrars couldn't care less as the facts show! Otherwise why should CAs and software vendors have to use phishing and other detections, why huge blacklists of hostnames exists for domains that are never pulled, being used for anything from spam, phishing, malware distribution and more. This has been going on for more than a decade and nothing has been done by the registrars. And you want to convince the audience that they will suddenly turn inside-out and be even more responsive and responsible than CAs? LOL In many cases they already have revocation-for-bad-behavior policies in place. If your registrars would have done a better job and perform some due diligence, this wouldn't be necessary in first place. And interestingly you are defending such policies by registrars and deny the same for CAs as useless. :-) With DANE, revocation of keys by the owner of the domain You are joking, aren't you? :-) (I will phish, spam, distribute malware and viruses, scam, all the while using secure TLS channels and even revoke my own keys because I have been a naughty boy doing all those things :-) ) Additionally, DV may protect against a shortcoming of DNS that is happening now and possible wrongful issuance of a DV certificate may be detected due to shortcoming of DNS. Those are just the very obvious points I mentioned before. Keys-in-DNSSEC can't provide that without the involvement of a third party like a CA. I can't figure out what this means. A flaw in DNS (we will probably see them with and without DNSSEC), a compromise thereof can be prevented even with DV certs, not with Keys-in-DNSSEC. It will be Kaminsky all over again. - OCSP and CRLs are unnecessary with DANE It's not unnecessary, it's not possible. There is no meaningful oversight and no option to intervene besides the ever so responsible registrars. That's why CA certificates are so great :-) - Can you point me to the place in the Moz Cert Policy that requires a contact for misuse or defines what that term would mean? I believe it was discussed and incorporated into the policy, will look for it. - Audits and the like serve only to limit the *additional* risks that the CA DV model poses *on top of* its blind reliance on DNS. Which clearly shows your lack of knowledge. As I said earlier, I've been on both sides of the fence and I believe you simply are missing a couple of important things here. The above statement illustrates it best. So all of these items you mentioned really only pertain to domain validation, and involve implicitly trusting DNS, as I originally stated. Well, you can call white black and vice versa and we'll probably will not convince each other. Also not necessary. -- 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 2/11/11 4:39 AM, Rob Stradling wrote: On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote: snip - OCSP and CRLs are unnecessary with DANE Steve, may we presume that you only intended this statement to apply to the use of self-signed certs with DANE? When an EV (or OV) certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs are still essential, because these certificates make claims (about organizational identity) that can't be assured by DNS(SEC)/DANE. When a DV certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs may be less than essential but they are still useful (e.g. the CA may subsequently detect that the key or hash algorithm used in the certificate is weak). I meant that DANE's revocation of any of its prior assertions is built into the architecture via DNS TTL and removal of records. For, CA-issued certs that contain greater-than-domain-validation data, the CA needs the ability to revoke the certificate. This is because they are the ones that made the assertion in the first place. Perhaps there is some argument that even for DV certs CAs will be better about detecting weak key or hash algorithms, but as I noted elsewhere in my message we have repeatedly seen that the best way to do this is to implement hard client checks rather than trying to get hundreds of CAs in line. In any case, the revocation mechanism of DANE is far more straightforward. Thus, the CA DV model provides no clear comparative benefit with respect to revocation abilities. In fact, by removing the need to proactively revoke, DANE improves reduces the spectrum of exploits. It also places revocation power directly in the hands of the subscriber. -- 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 2/11/11 5:57 AM, Eddy Nigg wrote: On 02/11/2011 07:08 AM, From Steve Schultze: Can you give an example? Who the subscriber is (not higher level validation, sanity check) I still can't decipher this. what the requested host name is There is no ambiguity in DANE. what's the purpose of a certificate There is no ambiguity in DANE cryptographic weaknesses Better done in the client. Would these checks be necessary under DANE or are they specific to the CA third-party-domain-validator model? I believe that they are necessary and requires involvement of a third party (if you want, you can call it something else than CA ;-) ) With DANE, such checks are part of the spec and the client implementation. As we have seen repeatedly on m.d.s.p., relying on CAs to enforce checks consistently is far less effective than implementing hard client checks. Well, as a matter of fact, the specs exists today for CAs too and are not enforced on the client side. What makes you believe that anything will change in this respect? By all means, how should individual users be more compliant to specs than CAs? Right, the spec exists today for CAs and we continue to see problems with enforcement. Individual users do not need to implement the checks, the client validating resolvers do. This is a far smaller surface area than the thousands of entities issuing DV CA certs. Unnecessary with DANE. A review of the requested properties in a certificate are an obvious benefit, it's not unnecessary with keys-in DNS, it's not possible. The only relevant properties are domain and key. The domain is implicit and the key needs no review other than basic sanity checks done in the client. I've made clear that I'm not a fan of such nannyism. So? Maybe you are not (that's your own problem which is not shared by the software vendors amongst other things), but it's a one of the tools CAs have and use when necessary. My policy position, shared by many, is that giving arbitrary intermediaries control of internet communications is not a good idea. Mozilla's approach to anti-phishing and malware protection supports this approach by giving clients tools to make their own decisions. To the extent that it has to be done, the registries/registrars are simply a more direct path. You make me laugh snip I readily concede that some CAs have revoked DV certs for sites that were doing things that most people would consider bad, and perhaps that revocation actually prevented them from doing more bad things (although I suspect that the vast majority of phishing/malware/etc doesn't rely on HTTPS whatsoever). I do know that millions of domains accused of such behavior have been removed by just one NIC. Which is more effective? It's not clear. In any case, the policy question of whether policing by intermediaries is a good thing makes it complicated to say whether or not we should value more effective policing in the first place. Mozilla does not consider CA revocation for bad behavior as a factor in accepting DV root certs (nor do I imagine that they want to be in that business). But all of the above has to do with your claims about what disadvantages DANE has relative to CA DV. You persistently ignore the clear disadvantages of CA DV relative to DANE, such as exclusivity, delegation, smaller surface area of vulnerabilities, etc. CAs stand to benefit greatly by leveraging DANE to add these characteristics to their more highly validated certs. They should be cheerleading such efforts (and several are). Your pattern of reasoning, on the other hand, is to assert that DV CAs simply know best -- therefore we should continue to let them insert themselves into a process that could be run far more securely and efficiently without a third party. I don't buy it. Steve -- 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 2/11/11 3:11 PM, Eddy Nigg wrote: improves reduces the spectrum of exploits... does this make any sense? Thanks typo cop. I'm sure it's clear what I meant. . It also places revocation power directly in the hands of the subscriber. That's the same as self-assertion. Most subscribers that have their certificates revoked not due to their own request, are probably not very happy about it. They certainly wouldn't revoke their own certificate and it's not meant to be that way. The issuer is obviously not the same entity as the end user - surprise. It's the assertion by a third party that provides the value. Today's DV CAs already rely on a self-assertion of domain control, and they in turn assert that they observed this. In plain english, a DV cert says, The guy holding the corresponding private key asserted that he controls the domain in question by replying to an email address at the domain in question. It is a self-assertion via DNS. Cryptographic validation of this self-assertion is precisely what signed DNS enables, and DANE is the mechanism for doing so. Any other assertions have no place in DV. You seem to think that DV CAs also assert some vague guarantee to police the domain in question for non-enumerated bad behaviors. Mozilla doesn't communicate any such assertion to end users, nor do any other clients. Indeed, the recent Mozilla security UI changes were done precisely to reduce any possible confusion about this. The only thing you are accomplishing is establishing potential liability for yourself if someone can show that they suffered harm after reasonably relying on a cert that you didn't effectively police as you promised. Steve -- 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/12/2011 12:32 AM, From Stephen Schultze: Who the subscriber is (not higher level validation, sanity check) I still can't decipher this. I didn't expected that you do :-) what the requested host name is There is no ambiguity in DANE. Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.COM, BANK0FAMERICA.COMall goes. what's the purpose of a certificate There is no ambiguity in DANE Of course not, that's why we have this: http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf cryptographic weaknesses Better done in the client. Not done or insufficient implemented mostly due to backward compatibility and other considerations. A review of the requested properties in a certificate are an obvious benefit, it's not unnecessary with keys-in DNS, it's not possible. The only relevant properties are domain and key. The domain is implicit and the key needs no review other than basic sanity checks done in the client. That's your opinion, I don't share it. Networks that repeatably are used for those unfavorable purposes are happily served by the client, but CAs don't necessarily issue certificates to them. I readily concede that some CAs have revoked DV certs for sites that were doing things that most people would consider bad, and perhaps that revocation actually prevented them from doing more bad things (although I suspect that the vast majority of phishing/malware/etc doesn't rely on HTTPS whatsoever). True - did you wonder why? Did you hear about the complaints at Mozilla about one such site that had a certificate from a CA? I do know that millions of domains accused of such behavior have been removed by just one NIC. Which is more effective? How come that there were millions in first place? The most used TLDs are however .BE, .COM, .EU, .NET, .EU, and .UK. and not .CN according to the APWG. But all of the above has to do with your claims about what disadvantages DANE has relative to CA DV. You persistently ignore the clear disadvantages of CA DV relative to DANE, such as exclusivity, delegation, smaller surface area of vulnerabilities, etc. That's because I don't believe it's a solution in itself, it can become part and increase security clearly for all CA issues certificates (including DV). Having this advantage in addition to the existing trust model (one that is increasingly improving as well) is an excellent goal. CAs stand to benefit greatly by leveraging DANE to add these characteristics to their more highly validated certs. They should be cheerleading such efforts (and several are). They might have a particular agenda I don't share. Obviously I'll go for something I believe in which is not what you are proposing. Your pattern of reasoning, on the other hand, is to assert that DV CAs simply know best -- therefore we should continue to let them insert themselves into a process that could be run far more securely and efficiently without a third party. I believe that CAs provide exactly the value necessary to make a difference which you think is superfluous. I don't buy it. Fine with me. Was nice discussing (again). -- 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
Last reply, I promise... On 02/12/2011 12:50 AM, From Stephen Schultze: Today's DV CAs already rely on a self-assertion of domain control, and they in turn assert that they observed this. In plain english, a DV cert says, The guy holding the corresponding private key asserted that he controls the domain in question by replying to an email address at the domain in question. It is a self-assertion via DNS. With the difference that he had to jump through the validation procedure of the CA and the CA has control over the to-be issued certificate properties and revocation thereof. Cryptographic validation of this self-assertion is precisely what signed DNS enables, and DANE is the mechanism for doing so. The authentication of the DNS is very strong indeed, that's why CAs should use it if it becomes adopted to a reasonable level (and CAs might opt to require it too). The only thing you are accomplishing is establishing potential liability for yourself if someone can show that they suffered harm after reasonably relying on a cert that you didn't effectively police as you promised. Thank you for your concern, but why should we police our own policy differently in first place? -- 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 2/11/11 6:04 PM, Eddy Nigg wrote: Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.COM, BANK0FAMERICA.COMall goes. Of course not, that's why we have this: http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf Have you actually read that report? It details a rapid response by many registries to suppress phishing outbreaks like Avalanche, ultimately leading to its demise and a radically improved takedown rate of phishing attacks. To the extent that it didn't work, it was due to phishers targeting less responsive registries (although it discusses improvements in this area). On the contrary, attackers seeking to get DV certs from CAs can get a new cert for the *same domain* from any less diligent DV CA. Huzza. Not that many phishing attacks rely on HTTPS. That report also details phishing attacks *on people seeking to purchase SSL certificates* in which the phishing happens over plaintext. If there's any community that would require an HTTPS connection in order to be successfully phished, it would be that one. cryptographic weaknesses Better done in the client. Not done or insufficient implemented mostly due to backward compatibility and other considerations. Fortunately, no backwards compatibility problems with DANE. Look, I tire of this exercise. This comes down to your claim that inserting non-accountable third parties to do some inconsistent policing of bad behavior and inconsistent checking of key standards (when any enforcement simply directs attackers to another CA) is more valuable than the demonstrable systemic benefits of using signed DNS directly. If anybody else on this list would like to present a more compelling argument than you have, I'm happy to discuss it... but I don't think that the two of us will make any progress with more back-and-forth. Steve -- 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 2/6/11 1:01 PM, Eddy Nigg wrote: On 02/06/2011 07:11 PM, From Zack Weinberg: I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? One of the points to consider is anti-phishing and flagging features built into CAs systems (not all, but some). Ability to revoke certificates by a responsible third party is however probably a strong point in favor for CA issued certificates, CA provided warranties on top yet another. There is certainly more into what CAs do, provide and stand for besides the mere point to point authentication. Zack, arguing with Eddy on this point is a losing proposition. DNSSEC+TLSA is has some demonstrably superior characteristics to CA DV, but Eddy is not willing to concede this or even give detailed reasoning. See for example this extensive thread from m.d.s.p: http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/c52b6de458ad54be/e87ecb2e5d632244?lnk=gstq=dnssec#54f6778267375e67 He has yet to actually address what I said in that thread: The potential strength of putting Keys-in-DNSSEC is that it locates control of domain validation in the most logical place for it... in DNS. The proposal starts with the observation that CA DV *already inherently* relies on the DNS for validation (emails to the domain, etc). Why is it likely to be more secure than CA DV? First of all, it subtracts hundreds of otherwise-unrelated entities from the process and provides a single clear and public trust path that the Subscriber gets to choose. Indeed, this generates in the market a virtuous race to the top rather than the current race to the bottom. His only claim, which he makes again here, is that CAs are somehow better than registrars/registries at being the internet intermediary cops. As a policy matter, I don't want more internet intermediaries with control over my communications, but he does. In any case, there is ample evidence that the intermediaries in the DNS system can have their hands forced by the government too (witness recent ICE domain seizures, COICA, etc.) so even if I concede that more control is a good thing, it's not at all clear that the CA model offers a comparative advantage. -- 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 2/7/11 6:31 PM, Robert Relyea wrote: My primary worry of the this spec as is is that DNSSEC is trying to be the end-all-be-all authority. That's a recipe for disaster. Keeping all my server keys in sync with the DNSSEC record? And if I have OV/EV, I have to keep it in sync with the certificate I have. If the spec requires us to reject certificates that don't match DNSSEC key records, then conservative websites just won't use DNSSEC+TLSA (or they will, get out of sync, and browsers will ignore the requirement and do what the market requires). Your point about sync issues is well taken. I have a hard time believing that it will be a blocker to adoption, but that's just opinion. I imagine that mechanisms for updating TLSA records will be streamlined, but it is indeed true that often server maintenance and DNS maintenance have operational boundaries between them. That's a legitimate point. The more significant barrier to adoption in my view is client implementation, including the need to validate DNSSEC responses within the client itself. This is not insurmountable, but it is hard. Fortunately, client implementation does not block server adoption because DNSSEC+TLSA acts as a value-add to any existing CA-based certs. Also, folks are making progress on client validation of DNSSEC results, including this FF addon: https://os3sec.org/ The requirement, from a security point of view, assumes that the DNSSEC infrastructure will be more trustworthy then CA's in you trust store. I think that is a value judgement, not a security judgement, and therefore has not place in a spec. There are concrete structural reasons why the DNSSEC infrastructure is more trustworthy *for key-to-DNS mappings* than CAs. To begin with, CA DV already relies on the DNS/DNSSEC infrastructure, so it can only make the situation worse. Add to that the fact that there are thousands of entities that can issue CA certs considered valid by Moz, and the risk of negligence or bad behavior is amplified. Finally, the CA model does not provide excludability or delegation in the sense that any CA can issue a cert for any domain. So, I don't think it's opinion to say that the pure-DNSSEC+TLSA approach is superior from a system architecture perspective. -- 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/10/2011 07:20 PM, From Steve Schultze: Zack, arguing with Eddy on this point is a losing proposition. DNSSEC+TLSA is has some demonstrably superior characteristics to CA DV, but Eddy is not willing to concede this or even give detailed reasoning. Well, we know about the advantages and shortcomings of CAs, you still have to provide a loot of proof about the supposed superiority of DNSSEC and what potential shortcomings will be. Eventually you don't have to convince the convinced and not even myself, but the software vendors that invested into a particular trust model of which you want them to give up partly. Or in addition. Or a combination of those. I just mentioned in the previous mail a couple of arguments, perhaps you've got some answer to those instead of ranting against me? -- 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 02/10/2011 08:51 PM, From Stephen Schultze: As I have said repeatedly (and you have never addressed) the CA DV model relies on DNS and thus imports any vulnerabilities that exist in a DNS-based model. CA DV blindly trusts DNS. That's exactly your mistake, you are not correct. The only thing it can do relative to a pure-DNS approach is add more vulnerabilities. Absolutely not - another mistake. Performing a validation check is only one part of the story and DNSSEC *might* help to improve that part, that's all what me concerns. As mentioned there is more into it, even if you deny it. I'm not ranting against you. I'm trying to focus the discussion on actual claims and verifiable facts. Good. -- 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 2/10/11 3:33 PM, Eddy Nigg wrote: On 02/10/2011 08:51 PM, From Stephen Schultze: As I have said repeatedly (and you have never addressed) the CA DV model relies on DNS and thus imports any vulnerabilities that exist in a DNS-based model. CA DV blindly trusts DNS. That's exactly your mistake, you are not correct. The only thing it can do relative to a pure-DNS approach is add more vulnerabilities. Absolutely not - another mistake. Performing a validation check is only one part of the story and DNSSEC *might* help to improve that part, that's all what me concerns. As mentioned there is more into it, even if you deny it. Until you actually explain why you think it's not correct that DV relies on DNS, or what beyond domain validation that you think DV actually does, there's really nothing to respond to. -- 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/10/2011 10:40 PM, From Stephen Schultze: Until you actually explain why you think it's not correct that DV relies on DNS, I didn't say DV doesn't rely on DNS, almost everything on the DNS uses it. or what beyond domain validation that you think DV actually does, there's really nothing to respond to. At least you could read the mail to which you responded originally. Here the three points I mentioned again for your convenience: One of the points to consider is anti-phishing and flagging features built into CAs systems (not all, but some). Ability to revoke certificates by a responsible third party is however probably a strong point in favor for CA issued certificates, CA provided warranties on top yet another. -- 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 02/11/2011 12:36 AM, From Eddy Nigg: I didn't say DV doesn't rely on DNS, almost everything on the *NET* uses DNS. Corrected. -- 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 02/11/2011 01:33 AM, From Stephen Schultze: You cut off the end of the sentence, which made clear that I was referring to how the *trust* of the CA model relies on blind trust of the data in DNS. Any fundamental trust model shortcoming of DNS is likewise a shortcoming of CA DV. You've never explained how you think this could be false. I tried - let me try again. But actually I should start with your last question in this post first and it would make a lot more sense (you can scroll down if you want)... There are additional steps CAs can/should/do besides checking domain control - even in the DV settings. Those range from basic sanity checks, checks on weak/small keys, weak hashes, domains with obvious problems, re-validation and other flagging mechanisms before issuance, phishing detection and so forth. It continues with the ability to revoke certificates upon detection/reporting of misuse or other issues - it's a very strong point why a CA is beneficial. Additionally, DV may protect against a shortcoming of DNS that is happening now and possible wrongful issuance of a DV certificate may be detected due to shortcoming of DNS. Those are just the very obvious points I mentioned before. Keys-in-DNSSEC can't provide that without the involvement of a third party like a CA. FWIW, it should be obvious that the EV trust model does *not* rely on blind trust of DNS because it incorporates OOB confirmation of identity rather than just domain ownership. This is a good thing. Well, even WHOIS needs DNS - obviously the better the organization validation, the lesser the chance of misuse. The only thing that Mozilla requires of DV CA's is that they validate domain ownership. Well no, Mozilla requires a bunch of other things CAs must provide and do, including OCSP and CRLs, ability to report misuse, revocation requirements, sound PKI implementations (through WebTrust, ETSI), an audit regime, its own policies and reviews and and and...just look at the new policy requirements and how to apply. And this is just the beginning, more is to come from Mozilla and elsewhere. Anti-phishing and other punishments for actions that the CA doesn't approve of are irrelevant Why should they be irrelevant? They are certainly beneficial and very relevant indeed, otherwise why having them in first place. Subscriber obligations are not just here for fun. I really don't understand why this has been such a problem, given that your work and reasoning on other topics is so good. It is a mystery to me. Since this is NOT the policy list, I'm willing to share some thoughts... I'm knowing both sides very closely. Those of the relying parties (including software vendors) and those of the CAs. I know the ins and outs of running a CA with everything it entails. If you haven't been there, you probably don't know enough yet. But I'm also putting my money where my mouth is and I take some credit for changes that occurred and are occurring in this industry. Being it for providing an alternative (business model) to commonly known and conventional CAs and being it for guiding and demonstrating better and more responsible policies and practices and pushing for those to become applied evenly. By doing that, I can assure you that DV is not just authenticated point-to-point encryption - even though DV is really the lowest level which should be used only for its intended purpose and stands just for that. But that's not all, there are things I don't want to publicly disclose and they are nowhere required. They still exists and contribute nevertheless. Having said that, of course I'm not taking responsibility for every CA out there, but that's also the reason I'm working with Mozilla and elsewhere to improve existing practices and remove the problematic practices that do exist today, but are about to be addressed. I believe this will happen rather soon and within a useful time-frame. From there we can improve even further if possible. Regarding DNSSEC - it will take years from now to get to an anywhere useful level. I've seen some attempts to replace conventional X.509 PKI trust come and go, this wouldn't be the first. However should software vendors ever rely on DNSSEC exclusively for TLS on the web (e.g. without third party issued certificates), I fear a disaster and SSL will become most likely entirely meaningless. Instead I believe that CAs should take the best out of DNSSEC for their validation procedures and this is my intention too. Time will tell if I'm right. -- 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 05/02/11 21:13, Nelson B Bolyard wrote: 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. It's all about precedent. If all browsers begin by not allowing it, no-one will expect it to be allowed. Disallowing something that was previously allowed is much harder than disallowing something which has always been disallowed. Gerv -- 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/08/2011 07:56 AM, Gervase Markham wrote: On 05/02/11 21:13, Nelson B Bolyard wrote: 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. It's all about precedent. If all browsers begin by not allowing it, no-one will expect it to be allowed. Disallowing something that was previously allowed is much harder than disallowing something which has always been disallowed. So, we are already there. What they are talking about is disallowing cert is the DNSSEC record is there and the key doesn't match the cert. Those certs were allowed, and now they are not, so I think that you are already in the harder case. bob -- 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 09:11 AM, Zack Weinberg wrote: On 02/05/2011 02:55 PM, Eddy Nigg wrote: 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. I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? I really doubt we will see that world. I expect the DNSSEC could take a significant portion of the DV market, but I doubt it will completely replace it, any more than I think DNSSEC+TLSA can be ignored. Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? One primary place the DV has the advantage over DNSSEC is on large, rotating server farms. These farms don't need to keep track of each key on each of their servers. The certificate and key are always together on the server. For them, keeping the DNSSEC+TLSA keys up to date for all of their servers behind firewalls would be an administrative nightmare. My primary worry of the this spec as is is that DNSSEC is trying to be the end-all-be-all authority. That's a recipe for disaster. Keeping all my server keys in sync with the DNSSEC record? And if I have OV/EV, I have to keep it in sync with the certificate I have. If the spec requires us to reject certificates that don't match DNSSEC key records, then conservative websites just won't use DNSSEC+TLSA (or they will, get out of sync, and browsers will ignore the requirement and do what the market requires). The requirement, from a security point of view, assumes that the DNSSEC infrastructure will be more trustworthy then CA's in you trust store. I think that is a value judgement, not a security judgement, and therefore has not place in a spec. zw bob -- 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/05/2011 02:55 PM, Eddy Nigg wrote: 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. I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? 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 07:11 PM, From Zack Weinberg: I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? One of the points to consider is anti-phishing and flagging features built into CAs systems (not all, but some). Ability to revoke certificates by a responsible third party is however probably a strong point in favor for CA issued certificates, CA provided warranties on top yet another. There is certainly more into what CAs do, provide and stand for besides the mere point to point authentication. I see a value in DV like IV/OV provide others. It all depends on the intended purpose. I believe in using the added capabilities of DNSSEC for CA issued certificates once it gets to adopted to a usable level, I don't believe that just keys in DNS can provide something that third parties can rely on (also entirely from a technical point of view). And having a CA take responsibility is obviously not only a technical solution to a certain problem. -- 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-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
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-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 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 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/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
TLS server keys in DNS: client policy proposal
[Some of you may have seen an earlier draft of this proposal before. I originally sent it to secur...@mozilla.org and was asked to bring it here.] 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 and the mailing list archives may be found here: http://www.ietf.org/mail-archive/web/keyassure/current/threads.html -- cover letter to WG begins -- I [We, Mozilla] would like to see the DANE specification's section 3 (Use of TLS certificate associations) expanded considerably. The present text is a great improvement on having no policy at all (as in earlier drafts) but is still vague enough that all client software might not behave in the same way in response to a TLSA record set; similarly, a server administrator might misunderstand the consequences of adding a TLSA record to their zone. Without a clear, unambiguous specification of client policy, I do not think DANE will offer any security benefits. Therefore I have drafted a policy which is suitable for the needs of Web security. It seems to me that it should also suit other protocols secured with TLS, but I could be wrong, and would welcome corrections. We see four primary benefits from DANE to the Web, and our proposal is written with them in mind: * It could provide additional security in the presence of untrustworthy middleboxes, such as home routers vulnerable to remote exploitation and conversion to MITM attackers. * It could provide a mechanism for preventing the suborned CA attacks described in http://files.cloudprivacy.net/ssl-mitm.pdf. * It could provide an alternative to DV certification for sites that currently opt to use self-signed certs. * It could eliminate inconveniences and security-degrading workarounds in the use of CDNs for TLS-secured content, such as very long subjectAltName lists. The proposal below is a complete replacement for section 3 of DANE. Small wording changes would also be required in some other sections; I am prepared to write those changes if the WG adopts this proposal. -- proposal begins -- # Client application behavior when TLSA records are present Clients that wish to make use of TLSA records in securing a connection MUST be security-aware in the sense of RFC 4033. (In subsequent text, it is assumed that the clients under discussion wish to make use of TLSA records if possible.) Clients MUST ignore TLSA records whose DNSSEC validation state is insecure or indeterminate. Clients MUST also ignore TLSA records they do not understand (for instance, records with a cert type or hash type they do not implement). Clients that receive *any* bogus records for a server that they wish to connect to (whether or not this affects a TLSA record) MUST NOT proceed with the connection. Clients that receive a secure TLSA record for a server MUST treat this as an assertion by the zone administrator that *only* end-entity certificates that can be associated with the domain name, according to the procedure in section 2.1, are legitimate. Therefore, if a client receives a secure TLSA record, and subsequently receives an in-band certificate chain that does *not* match the record, it MUST reject the certificate and abort the connection. This rule applies even if the in-band chain would have been trusted in the absence of TLSA information. Clients SHOULD NOT allow users to force a connection under any of the conditions described in the previous two paragraphs. A client that has good reason not to comply with this requirement (for instance, a forensic tool) SHOULD treat all content received over a forced connection as actively malicious; in particular, no downloadable code should be executed, and nothing in the content should trigger further network traffic without explicit user instructions. Clients MAY treat a secure TLSA record as providing positive assurance that a certificate is valid. However, if a client receives a secure TLSA record, then a certificate chain that matches the record but, in the absence of a TLSA record, would have been rejected for any reason other than lack of a trust anchor, it SHOULD still reject that certificate. (For instance, a certificate that has been
TLS server keys in DNS: client policy proposal
[Some of you may have seen an earlier draft of this proposal before. I originally sent it to secur...@mozilla.org and was asked to bring it here.] 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 and the mailing list archives may be found here: http://www.ietf.org/mail-archive/web/keyassure/current/threads.html -- cover letter to WG begins -- I [We, Mozilla] would like to see the DANE specification's section 3 (Use of TLS certificate associations) expanded considerably. The present text is a great improvement on having no policy at all (as in earlier drafts) but is still vague enough that all client software might not behave in the same way in response to a TLSA record set; similarly, a server administrator might misunderstand the consequences of adding a TLSA record to their zone. Without a clear, unambiguous specification of client policy, I do not think DANE will offer any security benefits. Therefore I have drafted a policy which is suitable for the needs of Web security. It seems to me that it should also suit other protocols secured with TLS, but I could be wrong, and would welcome corrections. We see four primary benefits from DANE to the Web, and our proposal is written with them in mind: * It could provide additional security in the presence of untrustworthy middleboxes, such as home routers vulnerable to remote exploitation and conversion to MITM attackers. * It could provide a mechanism for preventing the suborned CA attacks described in http://files.cloudprivacy.net/ssl-mitm.pdf. * It could provide an alternative to DV certification for sites that currently opt to use self-signed certs. * It could eliminate inconveniences and security-degrading workarounds in the use of CDNs for TLS-secured content, such as very long subjectAltName lists. The proposal below is a complete replacement for section 3 of DANE. Small wording changes would also be required in some other sections; I am prepared to write those changes if the WG adopts this proposal. -- proposal begins -- # Client application behavior when TLSA records are present Clients that wish to make use of TLSA records in securing a connection MUST be security-aware in the sense of RFC 4033. (In subsequent text, it is assumed that the clients under discussion wish to make use of TLSA records if possible.) Clients MUST ignore TLSA records whose DNSSEC validation state is insecure or indeterminate. Clients MUST also ignore TLSA records they do not understand (for instance, records with a cert type or hash type they do not implement). Clients that receive *any* bogus records for a server that they wish to connect to (whether or not this affects a TLSA record) MUST NOT proceed with the connection. Clients that receive a secure TLSA record for a server MUST treat this as an assertion by the zone administrator that *only* end-entity certificates that can be associated with the domain name, according to the procedure in section 2.1, are legitimate. Therefore, if a client receives a secure TLSA record, and subsequently receives an in-band certificate chain that does *not* match the record, it MUST reject the certificate and abort the connection. This rule applies even if the in-band chain would have been trusted in the absence of TLSA information. Clients SHOULD NOT allow users to force a connection under any of the conditions described in the previous two paragraphs. A client that has good reason not to comply with this requirement (for instance, a forensic tool) SHOULD treat all content received over a forced connection as actively malicious; in particular, no downloadable code should be executed, and nothing in the content should trigger further network traffic without explicit user instructions. Clients MAY treat a secure TLSA record as providing positive assurance that a certificate is valid. However, if a client receives a secure TLSA record, then a certificate chain that matches the record but, in the absence of a TLSA record, would have been rejected for any reason other than lack of a trust anchor, it SHOULD still reject that certificate. (For instance, a certificate that has been
