Subject: [perpass] NSA inspired PKIX limitations?

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Oct 2013 11:24:36 -0400

There are a bunch of changes to PKIX that were blocked for quite some time.
The opposition coming from a cabal of DoD etc. contractors. This opposition
has proven ultimately futile since the industry has decided to ignore the
specification and set its own standards in two cases.

I don't want to get into a discussion of Snowden etc. I will however note
that I suspected something of the sort was going on several years ago and
that is why I was looking to take the standards process to a forum where
such interference could be prevented. The only practical effect of Snowden
is that I can now explain the reasons for that decision without sounding
like a black helicopter paranoid nut.

1) Name Constraints MUST be marked critical

And utterly stupid restriction since the semantics of the criticality bit
are 'break backwards compatibility'. Use of name constraints provide a
significant reduction in the attack surface and would have prevented the
Flame attack. However marking a name constraint critical breaks Safari and
provides no security benefit in the Web PKI.

Outcome: Industry has decided that the standard is that name constraints
MAY be marked non-critical.

2) OCSP reports success for unknown/unissued certificates.

One of the reasons that the DigiNotar incident was so severe is that the
OCSP responder reported 'Valid' status for certificates that the CA had not
issued. This limit is allegedly a consequence of the DoD's billion dollar
PKI being unable to issue OCSP responses except by using CRLs as a source.

One important consequence of this constraint is that it provides a weak
form of CA transparency. It is possible to determine whether a CA is
consistently defaulting on this requirement or not.

Outcome: Industry has mandated OCSP responses report INVALID status if the
certificate was not issued.

-- 
Website: http://hallambaker.com/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 19 Oct 2013 16:46:31 +0100

Hiya,

FWIW, I don't buy Phill's theory at all.

I do think its fair to say that the US DoD set of requirements
for PKI have dominated discussion at various times. Now that
is a complex PKI and not much like the web PKI so that has
generated some friction, but I don't see any need at all for
conspiracy theories to explain that. It just seems to me like
a normal case of different reasonably large sets of folks
having very similar but slightly different requirements.

On the specific topics below, if I recall correctly, both
were uncontroversial parts of the "design" of PKI for years
before they became problematic for the web PKI when it
finally started to seriously consider revocation. And it
seems to me that both "sides" in that debate were inflexible
and unwilling to make changes. I still don't know why that
was, and it still seems dumb to me, but life's full of little
mysteries like that.

And I am just not seeing how this is related to pervasive
monitoring except very very tangentially - Phill, can you
please explain its relevance?

And finally the subject line also seems unwise as it'll probably
just annoy folks and just distract us from getting real work
done. (So, if it does annoy you, please try be moderate in
your response, or maybe don't even send that mail, until we
see how Phill justifies its relevance.)

Cheers,
S.

On 10/19/2013 04:24 PM, Phillip Hallam-Baker wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Oct 2013 13:48:55 -0400

On Sat, Oct 19, 2013 at 11:46 AM, Stephen Farrell <[email-masked]
> wrote:

> FWIW, I don't buy Phill's theory at all.

We have a document that states there is a $250 million budget set for a
program that includes infiltrating the standards process as a stated part
of the program.

Now we can dispute the authenticity of the document but I see it as
confirming my earlier strong suspicion.

> finally started to seriously consider revocation.

They were uncontroversial until the DigiNotar and Flame incidents and until
the EFF certificate observatory started a FUD attack making spurious claims
. Until that point I was mainly concerned with the risk that one of my CAs
might be breached. I did not see the need for Name constraints because I
had other controls that I consider to be sufficient.

The OCSP feature was very controversial at the time the limitation was
originally introduced. The reason I did not press the issue then was that I
did not see it as critical and insisting on a strong status result could
arguably be seen as interfering with the Valicert business model at the
time.

> And it

My position is based on the actions taken by the deployed base. I can't
change that and so I don't have much ability to change my position.

I can't see why the inability of the DoD to support an accurate status
result should require the rest of us to adopt their lowest common
denominator security.

> please explain its relevance?

I believe that the vulnerability exploited in Flame would have been closed
had the standards changes resisted by the DoD been adopted in a timely
fashion and that the DigiNotar incident might have been detected earlier.

The documentary evidence shows that interfering with the standards process
to prevent deployment of countermeasures is part of the cost of running
PRISM etc. That is a cost that I am not prepared to pay because these
generals who I have to sit in rooms with and listen to their plans for
cyber-attack are making use less safe by compromising our ability to
achieve strong cyber-defense.

The question of how we can build open standards to defend against covert
pervasive monitoring in the face of attempts to disrupt these efforts is a
very difficult one.

> see how Phill justifies its relevance.)

Well we could spend the next few years dancing round the subject and
pretending that the elephants are not in the room but I have no intention
of doing so.

Now that my question on Alexander has been answered, I am looking for an
answer to the question I raised at the RSA conference this year: How can we
have a government-industry partnership to improve cyber security when a
part of the military is actively engaged in subverting the standards
process to protect vulnerabilities they might use in attacks? This is not
the only forum I am raising this question, I am raising it with the policy
makers in government as well.

I am quite used to being accused of peddling an agenda. For some reasons
CAs are always accused of having some covert agenda and raising this on the
lists is never seen as objectionable because it is so frequent. But the
response I give is not 'how dare you ask that question' but instead 'why
don't you hold all the other parties you rely on to the same degree of
scrutiny'.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 20 Oct 2013 14:47:17 +0100

Hi Phill,

> program that includes infiltrating the standards process as a stated part

I'll come back on that in a separate mail.

> arguably be seen as interfering with the Valicert business model at the

Right, I tihnk we're agreeing that these features were introduced
years ago as part of the normal process. No conspiracy needed nor
credible.

> result should require the rest of us to adopt their lowest common

That's re-litigating the argument though. You had your position,
others had theirs. All of 'em had merits. None of the relevant
parties seemed willing to change. 'twas just dumb IMO.

However, we now have the wpkops wg, which should provide a better
venue and process for handling any similar issues that arise in
future. If the web PKI folks do actively work on that, (and I'm
more hopeful on that than I was a month or two ago) then we
shouldn't hit that kind of problem again I'd hope.

> had the standards changes resisted by the DoD been adopted in a timely

Flame was relatively targetted and more of a host-based attack tool
rather than an attack on the n/w. But yes, its relevant to monitoring
though arguable as to whether its in scope here I think. (I do agree
its a relevant part of the background for sure though.)

> fashion and that the DigiNotar incident might have been detected earlier.

Again, that's fairly weak I think.

> pervasive monitoring in the face of attempts to disrupt these efforts is a

I'll respond in a separate mail on the general inferference issue.

My conclusion here is that the specific issues you raise aren't
convincingly part of this and is better not intertwined with the
generic point about interference.

S.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Oct 2013 12:12:56 -0400

PHB,

> There are a bunch of changes to PKIX that were blocked for quite some 
> time. The opposition coming from a cabal of DoD etc. contractors. This 
> opposition has proven ultimately futile since the industry has decided 
> to ignore the specification and set its own standards in two cases.
A cabal? Gee do member have secret handshakes and a secret clubhouse? 
That sounds like fun. Can I join? Oh, you're
saying that I _am_ a member!
> I don't want to get into a discussion of Snowden etc. I will however 
> note that I suspected something of the sort was going on several years 
> ago and that is why I was looking to take the standards process to a 
> forum where such interference could be prevented. The only practical 
> effect of Snowden is that I can now explain the reasons for that 
> decision without sounding like a black helicopter paranoid nut.
The fact that the PKIX WG did not elect to adopt every proposal you made 
is hardly a justification for name calling.
Moving your crusade to the CABF was a good strategy; fewer folks to 
convince and a focus on outcomes independent of
architectural considerations. This is the same group that wanted to give 
CAs 3 years to fix a serious security bug,
before the ICANN SSAC insisted otherwise, if I recall Warren's briefing 
in SAAG.
> And utterly stupid restriction since the semantics of the criticality 
> bit are 'break backwards compatibility'. Use of name constraints 
> provide a significant reduction in the attack surface and would have 
> prevented the Flame attack. However marking a name constraint critical 
> breaks Safari and provides no security benefit in the Web PKI.
>
> Outcome: Industry has decided that the standard is that name 
> constraints MAY be marked non-critical.
It might be worth emhpasizing that the principal reason cited for not 
marking the extension critical, as per X,.509
and RFC 5280, was a single vendor's unwillingness to fix a bug in their 
browser. The CABF members, being browser vendors
as well as third-party CAs, was the prefect venue in which elect to 
given precedence to a vendor's intransigence.
> One of the reasons that the DigiNotar incident was so severe is that 
> the OCSP responder reported 'Valid' status for certificates that the 
> CA had not issued. This limit is allegedly a consequence of the DoD's 
> billion dollar PKI being unable to issue OCSP responses except by 
> using CRLs as a source.
>
> One important consequence of this constraint is that it provides a 
> weak form of CA transparency. It is possible to determine whether a CA 
> is consistently defaulting on this requirement or not.
>
>
> Outcome: Industry has mandated OCSP responses report INVALID status if 
> the certificate was not issued.
A number of folks have long wanted OCSP to be a cert status protocol, 
instead of a cert _revocation_ status protocol.
DoD is probably not the only CA that uses CRLs to generate OCSP replies. 
The relevant RFCs have always allowed
this practice, and it's a reasonable one, especially if the OCSP service 
providers is not the CA.

There are a number of ways that the major problems associated with 
DigiNotar breech could have been mitigated, many
of them not requiring any changes to protocols.

The fundamental issue here, for both of the examples cited, is that the 
browser PKI model is a terrible one.
DANE is a much better solution, except for the CAs that might lose 
business as a result.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 22 Oct 2013 15:00:45 +0100

On 21 October 2013 17:12, Stephen Kent <[email-masked]> wrote:

> bit are 'break backwards compatibility'. Use of name constraints provide a
> as well as third-party CAs, was the prefect venue in which elect to given
> precedence to a vendor's intransigence.
>
>   Even if that vendor had been willing to fix the bug, you'd still need
name constraints to be non-critical, or they'd break every outdated
browser. Which would mean they could not be used for many years. So clearly
they had to be non-critical, as will future extensions have to be, I'm sure.

So, I don't think the emphasis is worth it.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Oct 2013 17:18:51 -0400

Ben,
>
>
>>     ...
>     It might be worth emhpasizing that the principal reason cited for
>     not marking the extension critical, as per X,.509
>     and RFC 5280, was a single vendor's unwillingness to fix a bug in
>     their browser. The CABF members, being browser vendors
>     as well as third-party CAs, was the prefect venue in which elect
>     to given precedence to a vendor's intransigence.
>
> browser. Which would mean they could not be used for many years. So 
> clearly they had to be non-critical, as will future extensions have to 
> be, I'm sure.
>
So, are you saying that other browsers also are not complaint with 5280 
in this respect, or is this more
or a rhetorical distinction?

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Oct 2013 16:49:56 -0400

Just to clarify, I was not suggesting that anyone in the WG is an NSA mole.

The model I had in mind was more one where someone on the classified side
decides that a certain proposal would close a zero day vulnerability that
they plan to exploit. A plausible argument is then constructed as to why
this would be a bad idea and this is farmed out to people who cross the
internal/external line without an explanation as to why.

If you read Sun Tsu, this is the bit about the unknowing spy.

My point was that I think we have to be a lot more careful about arguments
that end up leaving the Internet insecure.