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

[Watson Ladd <[e-mail]>]

On Tue, May 12, 2015 at 6:14 AM, Martin Rex <[e-mail]> wrote:
> 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.

How does the server know which trust anchors will be accepted,
particularly in cases involving cross-validation?

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

Let's look at actual code implementing this "complex and dumb idea".
https://golang.org/src/crypto/x509/verify.go What security property is
violated by this code, as a result of implementing RFC 4158?

Of course, I'm not saying this idea isn't complex and dumb. It has
exponential complexity in some cases, may encode 3-SAT (I've been
thinking hard about how to do that, and have some ideas involving path
constraints) etc, etc. But it's a unfortunate result of how badly PKIX
is designed that something like this becomes necessary. The
restriction in RFC 5280 won't function in many reasonable scenarios.

Or are you saying that cross-validation doesn't exist, that all
clients have the same root stores, so we don't need it anyway, and
that we can use multiple chains for the cases of algorithm
depreciation?
>
>
>>
>> 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.

How does the server know which path a client that connects to it will trust?

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

That only determines which leaf was used. It's of course true that one
could provide two separate paths, and have servers pick between them
based on the leaf. Is that how you propose we deal with this problem?

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

I didn't know you were an algebraic geometer, or a cryptographer. What
security problem does ECDSA have when used online? P256 is backdoored
how again?

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

What exactly is the issue here? I'm not familiar enough with AIA to
understand what you think people do and why you think it is a problem.
If you could actually explain the problems, preferably with example
exploits, it would be appreciated.

Sincerely,
Watson Ladd


-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.