Subject: [wpkops] draft-housley-web-pki-problems-00

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jul 2015 10:57:11 -0400

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

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 7 Jul 2015 19:36:39 +0000

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:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, July 7, 2015 8:57 AM
To: [email-masked]
Subject: [wpkops] draft-housley-web-pki-problems-00

Russ

_______________________________________________
wpkops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/wpkops

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jul 2015 16:04:14 -0400

On Tue, Jul 7, 2015 at 3:36 PM, Jeremy Rowley <[email-masked]>
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.
>

I have a slightly different concern about the mention of CABForum.

CABForum was originally started to develop industry standards for
Organizational Validation certs which turned into EV certs over time. As
such I always regarded it as a successor in spirit to the ABA group that
Michael Baum used to run.

CABForum is not set up as a governance body. It does not manage a trust
store or decide on inclusion of trust roots. It isn't an industry
association either, there is a separate body that has that role.

I think that the problem the paper identifies is actually a more
fundamental issue with the WebPKI, the fact that browser providers are not
ideally placed to act as curators of trust stores because they have two
conflicting concerns: security and interoperability.

While browsers do their best to achieve a balance between those concerns,
they can't be expected to provide customized tradeoffs for different
purposes. It is inevitably one size fits all.

One of the ways I am looking to address this in the mesh is to provide a
mechanism that allows individual users more control of their network
environment by defining a custom network profile that can be easily
transferred from one device to another.

In ordinary circumstances, it is not practical for a user to manage a
custom set of WebPKI roots on each of their machines or for that matter to
delegate that configuration to a trusted party.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 7 Jul 2015 14:53:43 -0700

On 7/7/15 12:36 PM, Jeremy Rowley 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.

In general, I'd look at a 00 draft published against the deadline for a
particular meeting as the opening salvo in a conversation someone wants
to have, in this case somewhere at ietf 93.

I have this somewhere in my queue along with some fraction of the other
thousand or so drafts submitted against the monday cutoff.

> 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:[email-masked]] On Behalf Of Russ Housley Sent:
> Tuesday, July 7, 2015 8:57 AM To: [email-masked] Subject: [wpkops]
> draft-housley-web-pki-problems-00
> 
> _______________________________________________ wpkops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/wpkops
> 
> _______________________________________________ wpkops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/wpkops
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 7 Jul 2015 22:41:09 +0000

(speaking for myself and not Russ… )

Joel is correct that this was an initial draft to start a conversation. The point was to collect some of the technical and non-technical issues associated with deployment and use of PKI. This might then be used to scope a conversation about possible things that could improve the situation and venues for the development of those interventions. This is the first step and any comments or additions are welcome. 

(apologies to Joel and others about the “at the deadline” submissison). 

> On Jul 7, 2015, at 5:53 PM, joel jaeggli <[email-masked]> wrote:
>

---

From: Gervase Markham <[email-masked]>
Date: Wed, 8 Jul 2015 12:15:16 +0100

> 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

---

From: Rick Andrews <[email-masked]>
Date: Wed, 8 Jul 2015 12:47:13 -0700

3.1 It's true that many browsers don't do certificate status checks by
default, but only Firefox (AFAIK) gives the user the option to enable those
checks.

3.4 " Despite this situation, at least one major browser does not support
name constraints, and as a result, CAs are reluctant to use name
constraints." That's true, but it's only part of the story. Symantec (as an
example) issues certificates to FQDNs in practically all TLDs, ccTLDs, gTLDs
including many of the newly-approved ones. It's simply not practical for us
to use name constraints on our issuing CAs. And in the small number of cases
where we issued an issuing CA to an external third party, every single one
has rejected the idea of name constraints because they all wanted the
ability to issue to newly-acquired domain names. 

4.1.  Determination of the Trusted Certificate Authorities
" The browser vendors and the CAs determine what should and should not be
trusted by default." Not true; only the browser vendors determine what
should and should not be trusted. CAs have no control over their decisions.

Under " 5.  Emerging Technical Improvements" you might add the use of
Content Delivery Networks. Most major CAs today use CDNs to deliver CRLs and
OCSP responses, resulting in high availability and low latency for clients.
However, browser vendors still eschew status checking. 

5.1.1 " Sadly, few CAs take advantage of the CRLDP certificate extension." I
don't agree. Most of the CAs I'm aware of still add CRLDP extensions, even
though they're not required by the CABF Baseline Requirements and largely
ignored by browsers.

5.2.1 DANE
" DNSSEC has a single root domain as opposed to a multiplicity of trusted
CAs" It's true that DNSSEC has a single root domain, but if fully deployed,
every domain owner would also have to manage their own PKI. It's not
trivial, and there are no audit or compliance standards for this. 

I would suggest that you mention the multiple DANE modes of operation. In
two of the modes, no PKIX chain validation is needed; hence a self-signed
cert might appear as trustworthy as a CA-signed cert.

---

From: Ralph Holz <[email-masked]>
Date: Thu, 9 Jul 2015 11:40:58 +1000

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

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 9 Jul 2015 03:05:55 +0000

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:[email-masked]]
Sent: Wednesday, July 8, 2015 7:41 PM
To: Jeremy Rowley
Cc: Russ Housley; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

Jeremy

-----Original Message-----
From: wpkops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Russ Housley
Sent: Tuesday, July 7, 2015 8:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [wpkops] draft-housley-web-pki-problems-00

Russ

_______________________________________________
wpkops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/wpkops

_______________________________________________
wpkops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/wpkops