Re: [wpkops] draft-housley-web-pki-problems-00
On 07/07/15 15:57, Russ Housley wrote: I want to make people on this list aware of this draft that was posted yesterday. Stephen Farrell suggested that this list might be a good place to discuss it. https://tools.ietf.org/html/draft-housley-web-pki-problems-00 Some comments: 3.1: See: https://wiki.mozilla.org/CA:RevocationPlan 3.2/3.3: See HPKP, CAA and CT. 3.4: Bug Apple :-) 3.5: See Let's Encrypt, DigiCert Express Install, SSLMate etc. etc. 3.6: The entire point of Trustwave is that browsers could _not_ ordinarily detect the MITM. But anyway: it has been suggested that MITM certs should be required to have a special marking which browsers can detect, but this solution, when investigated, has a number of problems. Ideas welcome. 3.7: 1024-bit: See https://bugzilla.mozilla.org/show_bug.cgi?id=1156844 for roots, CAB Forum policy for intermediates and EE certs. SHA1: See Microsoft and Google policy and CAB Forum policy. MD5 is already dead. RC4 is being worked on: see https://bugzilla.mozilla.org/show_bug.cgi?id=1138101 . 4.1: With regard to the Mozilla root program, I refute the first suggestion here. See http://www.mozilla.org/projects/security/certs/policy/ and many other places. 4.2: The actions we took in the CNNIC case were specifically designed to be generalisable to a CA otherwise considered too big to fail. 4.3: Given the existence of the above-mentioned services and APIs, this seems like a Simple Matter of Programming to me. :-) 5.1.1: Browsers don't use such extensions because CRLs suck. 5.1.2: Indeed. Please put polite pressure on the Apache project and/or Linux distributions to allow OCSP stapling to be enabled by default. 5.2.1: See https://www.imperialviolet.org/2015/01/17/notdane.html . 5.2.2: CAA is fine. 6.1: The CAB Forum is a lot more open, inclusive and transparent than it once was, in part due to Mozilla pressure. For example, voting is no longer secret, and nor are the mailing lists. Third parties can now take part (although not vote) in working groups. Organizations can become associate members. And while this is not full openness and transparency, mozilla.dev.security.policy is always open to hear input from the Internet community on what Mozilla should be doing or advocating. The chances of browser makers handing over the right of decisions about who to trust to a 3rd party body are vanishingly small. Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] draft-housley-web-pki-problems-00
I’m not sure this is detailing short-comings in technology. Instead, the draft is really pointing to issues in implementation? For example, revocation checking exists. Some browsers choose not to use it in the traditional sense for various well-documented reasons. Should the RFC detail why the user agents are not implementing instead of saying it’s not snappy enough? Same with “too big to fail”. Instead of saying that it’s an issue, the draft should say there’s a difficulty in enforcing requirements against root store operators because their decision tends to be binary (either trust or not trust). Although, as Gerv pointed out, Mozilla has shown there are non-binary alternatives. From: Ralph Holz [mailto:ralph.i...@gmail.com] Sent: Wednesday, July 8, 2015 7:41 PM To: Jeremy Rowley Cc: Russ Housley; wpkops@ietf.org Subject: Re: [wpkops] draft-housley-web-pki-problems-00 Informational RFCs that detail shortcomings of technology exist - see, e.g., the work done in the UTA WG (disclaimer: I am an co-author of one such RFC). Calling for specific mechanisms or forums is indeed odd. I'd suggest to rather go for a list of pointers instead. Ralph On 8 July 2015 at 05:36, Jeremy Rowley jeremy.row...@digicert.commailto:jeremy.row...@digicert.com wrote: This paper sounds like a wish list of select issues taken from the Mozilla forums. I don't see why it would be published as informational RFC? Is the goal to make a list of issues that community members feel need to be discussed? I don't get it. The conclusions seem to be 1) Have a CAB Forum that is more transparent (which is out of scope of the IEFT - I'm not sure I've ever seen an IETF paper specifically call out to another industry body requesting a change in its membership?) and 2) Use Let's Encrypt - one specific member of the CA community. Many CAs already offer free tools to automate issuance, making the call out to Let's Encrypt very odd in an IETF document, especially where the touted feature - new automated tools - already exist (https://www.digicert.com/express-install/). I have a similar complaint about the reference to acme where PHB has been proposing something similar for a LONG time (https://tools.ietf.org/html/draft-hallambaker-omnibroker-06). I'm also not sure why you selected the specific issues for inclusion in the paper. For example, the paper doesn't mention inconsistencies in validation levels, which (imo) is a bigger issue than the too big to fail scenario. Cost also is a weird issue to include in the document since it's always relative. It's also very difficult to discuss without running afoul of anti-trust laws. Jeremy -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.orgmailto:wpkops-boun...@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, July 7, 2015 8:57 AM To: wpkops@ietf.orgmailto:wpkops@ietf.org Subject: [wpkops] draft-housley-web-pki-problems-00 I want to make people on this list aware of this draft that was posted yesterday. Stephen Farrell suggested that this list might be a good place to discuss it. Russ ___ wpkops mailing list wpkops@ietf.orgmailto:wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.orgmailto:wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] draft-housley-web-pki-problems-00
This paper sounds like a wish list of select issues taken from the Mozilla forums. I don't see why it would be published as informational RFC? Is the goal to make a list of issues that community members feel need to be discussed? I don't get it. The conclusions seem to be 1) Have a CAB Forum that is more transparent (which is out of scope of the IEFT - I'm not sure I've ever seen an IETF paper specifically call out to another industry body requesting a change in its membership?) and 2) Use Let's Encrypt - one specific member of the CA community. Many CAs already offer free tools to automate issuance, making the call out to Let's Encrypt very odd in an IETF document, especially where the touted feature - new automated tools - already exist (https://www.digicert.com/express-install/). I have a similar complaint about the reference to acme where PHB has been proposing something similar for a LONG time (https://tools.ietf.org/html/draft-hallambaker-omnibroker-06). I'm also not sure why you selected the specific issues for inclusion in the paper. For example, the paper doesn't mention inconsistencies in validation levels, which (imo) is a bigger issue than the too big to fail scenario. Cost also is a weird issue to include in the document since it's always relative. It's also very difficult to discuss without running afoul of anti-trust laws. Jeremy -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, July 7, 2015 8:57 AM To: wpkops@ietf.org Subject: [wpkops] draft-housley-web-pki-problems-00 I want to make people on this list aware of this draft that was posted yesterday. Stephen Farrell suggested that this list might be a good place to discuss it. Russ ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] draft-housley-web-pki-problems-00
Good idea, I forwarded it on some CA lists as well. One omission I think needs to be called out is that the WebPKI scope is limited to server authentication. While I don't think that the draft should consider client auth in detail, it is something that should be pointed out as a shortcoming. I think that the main reason we haven't got client auth working on a large scale is that the administration and usability issues that impact the Web Server PKI are even more severe for client PKI. My Mesh project is an attempt to address those issues. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
