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

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> 
> 1) I think clients, such as Martin's, that implement normative checking of
> ordering and are used for the Internet at large (e.g. between servers and
> clients that are not controlled by a single entity) are bad for Internet
> security.

Huh?  I never described anything like that "normative checking".

My client simply feeds the certificate chain from the TLS Certificate
handshake message, up to an issure that is recognized as trust anchor
directly into the certificate path validation function (rfc5280,
section 6.1) just like rfc5246 and rfc5280 _designed_ this to be.


>
> 2) I think clients, such as Martin's and Geoff's, that do not implement
> RFC 4158 path discovery are bad for Internet security.

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

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).


>
> 3) I think language that encourages or requires clients to normatively
> enforce such ordering are bad for Internet security.

You are misreading the existing language.  What has been written, applies
to the *SENDER* of the Certificate handshake message, not to the recipient.
As previously described, the purpose is to make the job of verifying
the server certificate easy for the recipient.


> 
> In my original email, I tried to establish why:
> 1) Clients have disparate trust-stores. Absent the X.500 directory, this
> is a fact of life. The set of trust anchors recognized by Microsoft will
> and is different than those recognized by Mozilla, for a variety of
> legitimate reasons that will not change, no matter what the IETF does.

Correct.  Not a problem with the existing text.


> 2) As such, there is no single trusted path. RFC 4158 spells this out in
> abundant detail, and the figures contained should be "required skimming"
> for any of this discussion.

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.


> 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also
> necessary, as the first two points here spell out. Clients that don't
> support RFC 4158 "break" if a trusted path cannot be found.


Implementing rfc4158 will pretty much always result is serious security
problems (or an unmanagable monster).

rfc4158 is not a standard and actively ignored by rfc5280, so it is
not even part of the Internet Security Architecture.


> 
> In order to handle deprecations of SHA-1, for example, certificate paths
> need to be replaced with their SHA-256 equivalent. To handle the
> deprecation of RSA-1024 bit, alternative paths must be supplied. To handle
> the deprecation of RSA in favour of ECC, alternative paths must be
> supplied.

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.

But noone with a security clue would be using ECDSA for online signatures.
And doubly so, not with NSA-backdoored curves.


> 
> Clients that don't do "insecure AIA fetching" (as Martin likes to
> pejoratively phrase it, as I disagree with him on this point
> substantially), but that thankfully don't implement Martin's strict
> checking (which luckily, few do), this works as a viable means of
> providing acceptable paths to them. At the cost of violating the TLS RFC
> in a part of language that *enforcing* requires more work and introduces
> more security issues to clients.

You're putting words in my mouth that I certainly never said.

The current language applies *ONLY* to the sender of the Certificate
handshake message.  It does not require any particular behaviour for
the client to verify the server certificate.

Which kind of certificate path discovery are you thinking of?
Forward/upward AIA chasing is a formally provable security problem.
Web Browsers may not care about this, because the aggressively
execute active content received over insecure channels all the time,
and perform millions of requests without consent from the user and
entirely careless about the security implications.  non-negligent
programmatic TLS clients are different, and so are non-negligent servers.


> 
> If every client had RFC 4158 capable path discovery, would I still
> advocate relaxing the language? Honestly, yes, because it should be up to
> the server to balance the tradeoffs between client interoperability. If
> every client enforced the TLS requirements, as Martin advocates,

I'm not, and never did advocate for a specific client behaviour.

The existing text is purely about requirements on the *SENDER* of the
Certificate handshake PDU.


-Martin