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

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> On Tue, May 12, 2015 11:54 am, Martin Rex wrote:
> >  X.509 would require an omniscient trusted directory to perform certificate
> >  path discovery, and the Certificate Path Validation algorithm in
> >  rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
> >  approach for certificate path discovery, because this approach would
> >  be clearly insecure and irresponsible.
> 
> Again, Martin, you're making unsubstantiated and inaccurate claims.
> 
> To the extent it's relevant to the discussion for the TLS WG, I will
> simply note that RFC 5280 does not say anything about path discovery
> precisely because discovery is out of scope for validation. Validation is
> consistent, while discovery depends on a myriad of cases and protocols
> outside of the narrow view of TLS. e.g. the validation of certificates in
> PKCS#7 or in S/MIME.
> 
> So yes, RFC 5280 doesn't discuss how to do path discovery, because it's
> out of scope, even though it repeatedly describes extensions and options
> for how to do path discovery *that rely on parsing the untrusted
> certificate*

*Parsing* an untrusted certificate is not the problem.

But doing _more_ than comparing contents to something you trust is
where the security problem starts.  


> 
> RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges
> it exists precisely to make discovery possible.


With the prerequisite of a conscious and informed active consent by a human
administrator during out-of-band maintenance/administration, using AIA to
download a certificate can be an accetable security trade-off.

But a machine/automata/algorithm that will automatically download objects
from URLs from still-untrusted data provided by the peer is definitely
insecure and irresponsible.


> 
> However, to the points at hand, at least it establishes why you object to
> the change. You view it as predicated upon a fundamentally insecure
> algorithm. While I (and many others, as evidenced by implementation and
> discussion) would disagree with you, and I personally feel your claims of
> standards imprimatur to be lacking, it at least provides a clear rationale
> for your disagreement.
> 
> I don't think it'd be helpful for consensus building for me to try and
> demonstrate where I think even RFC 5280 would disagree with your
> conclusions, but if others feel themselves swayed by Martin's arguments, I
> would be happy to add that fuel to the discussion.
 

I'm still waiting for an example why you would need to send junk in
the Certificate handshake message, which could not be avoided by the
offending CAs issuing proper crossCAs instead.

-Martin