Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 09:59 AM, Erwann Abalea wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. That doesn't seem like enough of a justification to me. It may not be mandatory, but please explain why it is not *necessary* (i.e. why no security guarantees depend on it). zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTWorRAAoJEJH8wytnaapkkO8QAI4IrF43KkSBzkN6YcZ6gvUu 2xqzkZGSJJDHJkrJJCIEAlcpLPWlXfrhCuhhr5+tXQ6hgKm+i5HCCsE+vkd9bqHx FQO+Qg/pG+Y1UWfJ57/0FuUwffl42ox+6zXeQPSEVDmB3nXaVxpJuLgIQpU6Pvp2 E/pc8E6FHJ1Ua6SHqSNFYj8qirtu8wnKu2ubhnbYfNJKRqgLjufe6bAPjunnwj/5 TbABPSkgll9drHtc5KzNyG6zWlboVdyNLZEVOkzsmXAusy0fRYiqK5U05BexGPdZ m7lsfmj78hvSe1Un+C6h4scvi9MLs851HBiJopAV0rltvZBryZZxE0nmYswZp3bo GrHylX/Yxx5AddQl8A3BDR5HfI/xSFej0VgAhSChNmkSVLROAFpSlK0IuYfhtxd6 OkxfDhBDgCVY/tB89kXmu0vzW9xwjsgmFQ0vvHHVJwdOfJXs8Cky1LWextIdUc5y zEmiM5pfd/GRutTHKjK7dWNqj1mpK6uJbM8QIG0tMOcpJ41Ja8rXYhKem9LIBjf6 s2j19puGw0Vgi9mmSfqrRL4IiW677m3vizXHMgeFkyKwMkJHRNU7IVN+8N+KTQ7n flhjXTf/A8OJWpcQWIdiQrx73ul/jxGoROsQ+HkcfWhTQWa/ZHdPxd2ivyl3xGc0 yxo93+ET5uXRGoY24EVx =dTnD -END PGP SIGNATURE- -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 2013-08-19 2:06 PM, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM is (AIUI) preferred because it's immune to BEAST. I share concern about new side channel attacks due to GMAC, though. As far as I understand it, there is nothing wrong with 3DES other than that it's slower. I am under the impression that the 64-bit block size is also considered a serious flaw nowadays. zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 2013-08-20 2:33 PM, Tom Ritter wrote: On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote: On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Not Tor Browser, but the Tor protocol itself. For more information, the spec document that deals with this is: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt I expect if all the browsers change their ciphersuite selection, Tor will follow suit. Looking like an *old* browser would eventually become suspicious. zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
IETF standardization of SSL authentication via DNS nearing completion -- please critique
The IETF has a working group developing a standard for new DNS records that let a zone admin declare the public key(s) belonging to SSL servers in that zone; this can be used as a complement to the existing CA infrastructure, or instead of that infrastructure. The specification is in WG Last Call; now would be an excellent time for critique from implementors. http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-17.txt Please send comments directly to d...@ietf.org. (You'll need to sign up for the mailing list -- https://www.ietf.org/mailman/listinfo/dane -- or they'll get stuck in a moderation queue.) zw Original Message Subject: [dane] I-D Action: draft-ietf-dane-protocol-17.txt Date: Wed, 29 Feb 2012 07:47:24 -0800 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org CC: d...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS) Author(s) : Paul Hoffman Jakob Schlyter Filename: draft-ietf-dane-protocol-17.txt Pages : 31 Date: 2012-02-29 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-17.txt ___ dane mailing list d...@ietf.org https://www.ietf.org/mailman/listinfo/dane -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: implement a MITM report addon
On 2011-06-28 4:00 AM, Kai Engert wrote: Hi Ralph, if you have resources to work on this or to coordinate this, please go ahead. I haven't yet. If I should, I would contact you to coordinate. Regarding traceroute, you could look at the existing WorldIP Add-On, which claims to support it, and potentially copy that code, under the assumption the MITM Add-On uses the MPL license. I tried to do something like this as a Test Pilot study. The brick wall I ran into was that, if a MITM is detected, you really want to know the globally routable IP block that the client was using. But the only way to know that is to phone a server that will tell you. I tried to get Mozilla to host such a server and didn't get anywhere. I don't think I was even talking to the right people. zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: implement a MITM report addon
On 2011-06-28 7:45 AM, Zack Weinberg wrote: On 2011-06-28 4:00 AM, Kai Engert wrote: Hi Ralph, if you have resources to work on this or to coordinate this, please go ahead. I haven't yet. If I should, I would contact you to coordinate. Regarding traceroute, you could look at the existing WorldIP Add-On, which claims to support it, and potentially copy that code, under the assumption the MITM Add-On uses the MPL license. I tried to do something like this as a Test Pilot study. The brick wall I ran into was that, if a MITM is detected, you really want to know the globally routable IP block that the client was using. But the only way to know that is to phone a server that will tell you. I tried to get Mozilla to host such a server and didn't get anywhere. I don't think I was even talking to the right people. (I meant to add: maybe WorldIP solves this problem somehow?) 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 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 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 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
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
