Re: [TLS] Update spec to match current practices for certificate chain order

[Dave Garrett <[e-mail]>]

On Friday, May 08, 2015 10:19:26 am Martin Rex wrote:
> Dave Garrett wrote:
> > On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote:
> >> Personally, I find it quite appalling how many broken TLS
> >> implementations out there fail to properly encode an ordered list
> >> of certificates into the Certificate handshake message.
> > 
> > or more concisely:
> > 
> > On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> >> Bleh.
> > 
> > I think we're in fair agreement that this is sloppy, but it's sloppiness
> > that should've been fixed long ago if we still wanted to fight it.
> > 
> > I brought this issue up in response to a bug report for Firefox fully
> > validating an EV cert list with an extra cert and things out of order.
> > Mozilla and others seem to accept it just fine, so either the spec
> > needs updating to reality or everyone should be adding new security
> > errors to break it. The former makes more sense.
> 
> No, the former is clearly detrimental.
> 
> Browsers, which haved added fancy colors and stuff to address bars
> for EV certs, really ought to punish servers sending bogus Certificate
> handshake messages by reducing the color feedback to mere black&white
> and not attributes (_not_ produce a warning!  I believe the Google
> Chrome 42 behaviour for sha1-Signatures is totally wrong, because
> hardly anyone understands what the real issue is, and Chrome will
> not tell you which signature algorithms in which certs it is unsatisfied
> with).

Let me be clear: I don't fundamentally disagree with you. I think that protocols should be treated far more strictly than they tend to be and stuff like this should be a mandatory error if it's against the current spec. That said, if we step ~way~ far back, we're sort of hitting a standard human societal problem: given a problem, and a set of solutions, arguing for the ideal you can't get is an argument for the problem. Do you think we could compel every browser vendor to apply this (effectively) new standard uniformly, and make the changes all at the same time? I don't, especially not from the TLS spec. Vendors can't even drop critically insecure protocols in unison. I don't even have confidence that everyone could coordinate a token change of coloring in the UI for this one narrow case.

This is a wire format issue, rather than a security one, so as long as we have an accepted format that is secure, then it doesn't really matter beyond that. I would agree that browsers should probably throw a warning into their consoles for this sort of thing, but not a user-facing action. Of all the problems TLS has, this is not one I think is worth worrying about too much. ;)

> I believe that one of the causes why the problem exists at all
> is a lack of sensible PKI credential management on the server side.

Likely true, but outside of the current scope of action.


Dave