Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

["Ryan Sleevi" <[e-mail]>]

On Tue, May 12, 2015 6:14 am, Martin Rex wrote:
>  Huh?  I never described anything like that "normative checking".

"Up to 2013 our SSL implementation has been hard failing TLS handshakes
with TLS peers that are sending garbled or incomplete chains."

This, in context, and combined with your follow-up qualifiers, suggested a
level of checking beyond RFC 5280.

>  rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard.
>  It is explicitly ignored by PKIX (rfc5280).

Only to the extent that RFC 5280 Section 6 deals specifically with the
validation of a given certification path, while leaving out of scope (but
acknowledged rather extensively throughout the documentation, especially
for extensions) the building/discovery of said paths.

Indeed, Section 3.2 calls out some of the complexities and acknowledgement
that inherent in the PKI is the possibility of multiple certification
paths. Section 6.2 further acknowledges this.

Merely I think it's a mistake and misleading to suggest that RFC 4158 is
an interesting side-note in the history of PKI, when in fact it describes
the behaviour of some of the largest (by end-user) clients out there
(Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's
JCA/CertPath APIs).


>  btw. there is *NO* secure approach described for path discovery in
>  rfc4158.  So if you do not have a prepopulated local store with
>  all intermediate certs, it can not possibly work in a secure fashion
>  (and a universal, trusted, omniscient directory which can be securely
>   accessed is non-existent).

Probably not for the TLS list, but since you bring this up virtually every
time when discussing PKI issues, it may help if you actually write up the
threat model or where you see it as "not secure". I see Watson has equally
requested this.

It's probably not suitable for the PKIX WG (given the impeding/actual shut
down - I can't remember timelines), but I think it'd be useful for the
community at large, and separate from the TLS WG, for you to actually
elaborate on this claim.

>  The existing requirements do *NOT* say that there can only be one trusted
>  path.  It is up to the server to decide which path to send.  If there
>  are multiple possible pathes, the choice of which particular path the
>  server sends will have an impact on interoperability, because not all
>  clients might be able to verify all paths.

I think this is the heart of the matter.

The current language forces a choice for server operators that is often
untenable - reject a set of valid clients, who COULD work, in order to
preserve spec purity that few clients enforce explicitly.

The proposed language change reflects the reality - that when options
exist that require a server operator to choose between, say, 25% of their
clients working while respecting the spec, 50% of their clients working
while respecting the spec, or 70% of their clients working while ignoring
the spec, they will choose the 70%, even if it means violating the spec.

(As to why 70 < 50 + 25, let's pretend, for sake of discussion, that 5% of
the clients behave like yours and enforce a strict ordering, either
implicitly by only using an RFC 5280 algorithm, or explicitly by imposing
such a requirement during the TLS handshake)

>  Not at all.  Whether the server uses a ECDSA certificate instead of
>  an RSA certificate is determined by the cipher suite that the server
>  chooses (ECDHE_ECDSA vs ECDHE_RSA), so the path has been determined when
>  the Server's certificate handshake message needs to be composed.

This was not the issue I was referring to; you can have an ECC leaf issued
off an RSA intermediate or root. Indeed, this is not at all uncommon, and
while decrying it probably won't be useful for this thread, we should at
least acknowledge it.

There are a variety of business and operational reasons that led to this,
but there are situations in which a given CA may have an ECC root
recognized in one set of clients, and an RSA root recognized in a set of
other clients, and thus again, multiple paths exist.

And I'm further setting aside the issues between ServerKeyExchange
authentication vs Server Certificate authentication, which is a whole host
of other worms w/ the existing SignatureAndHashAlgorithms. That's its own
issue that I'm not wanting to dive into.


>  But noone with a security clue would be using ECDSA for online signatures.

...

>  And doubly so, not with NSA-backdoored curves.

...

Such incredible claims that I'm going to have to leave them unaddressed,
as apparently I and my colleagues are not true Scotsmen.