Re: [TLS] Certificate validation can of worms

[Watson Ladd <[e-mail]>]

On Tue, Apr 8, 2014 at 6:39 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Tue, Apr 8, 2014 at 4:06 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote:
>>
>>> > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look
>>> > exactly at rfc2818 for any checks that the client will do on the
>>> > Server certificate, and again *NOT* in PKIX.
>>>
>>> This is really a problem with RFC2818. The whole idea of X509v3 is
>>> that you should be able to issue certificates that have meaning beyond
>>> assertions of identity, such as for use as code-signing. But because
>>> implementations don't respect the PKIX standard, we can't do that.
>>
>> I think PKIX is far from being described as standard. It looks more than
>> a set of rules that the implementer is expected to distill and select
>> the relevant ones, as most of the described rules are legacy baggage
>> (e.g. DN comparison rules that assume that the DN is copied by a
>> secretary that introduces case changes and alters spaces, rather than a
>> memcpy).
>>
>> PKIX's requirements are pretty strange to put it mildly. One example are
>> the key purposes that Martin described. Another is the name constraints
>> which is optional to implement for DNS or e-mails (that everyone uses),
>> and mandatory for DistinguishedNames (that no-one uses); then it becomes
>> an issue when people realize that no-one implements name constraints
>> (and the only certificates that I've seen that contained constraints,
>> had syntactical errors in them). There are much more issues in PKIX (and
>> Peter Gutmann is much better in providing a good overview). We certainly
>> need something better than rfc5280.
>
> Name constraints are in use today. They are supported in all the
> browsers with the possible exception of OSX (which I am told is fixed
> but I have not checked).
>
> The issue with Name Constraints is that the Industry has rejected the
> IETF specification which requires that a Name Constraint be marked
> 'break backwards compatibility' aka the 'critical bit'. This
> requirement is stupid and wrong and so the industry has decided to
> override RFC5280 on this point and the correct specification as far as
> the industry is concerned is that the setting of the critical bit is
> at the option of the issuing CA.
>
> If IETF produces rubbish specifications we will ignore them.
>
> The requirement to mark the certificate critical enabled the NSA
> attack on Microsoft in the Flame malware attack. Marking the bit
> critical makes it impossible to issue a certificate with that
> extension as about half a billion deployed devices don't support name
> constraints.

?? Flame was a MD5 collision. Nothing saves you from that one.

>
> The consensus model does not really work when a specification has been
> poisoned by an attacker who can block changes to correct the spec.
> Fortunately IETF specifications are not definitive, industry practice
> is. The industry consensus on this point is unanimous: name
> constraints need not be marked critical.

Which makes them useless: the point of name constraints is that I can
issue a name constrained certificate without issuing a global
intermediate CA certificate. If the extension is not marked critical,
then I've issued a global intermediate CA certificate for those who
don't check it, and so need to be just as strict as if it was an
intermediate CA certificate, so I might as well not bother with the
constraint.

>
>
> Industry consensus is also unanimous that RSA1024 is inadequate for
> any form of PKI infrastructure use including for ZSKs. So right now
> DNSSEC is not adequately deployed in the ICANN root or in .com in a
> form that can be considered fit for purpose. So the idea that the
> world is going to move to a DANE validity chain is rather peculiar.
>
> Fixing this situation requires a minor configuration change next time
> the keys are rolled. So don't take this as an argument against DNSSEC
> per se. I think it is just indicative of the reason why having ICANN
> in charge of global PKI is not exactly a sound proposition.

No, this one is IETF. The spec for ECDSA in DNSSEC is only from 2012.
As a result there wasn't an alternative when the root zone was being
signed. Furthermore, changing the root key is an interesting exercise.

Sincerely,
Watson Ladd
>
> --
> Website: http://hallambaker.com/



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin