Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi

[[e-mail] (Martin Rex)]

Dave Garrett wrote:
> On Wednesday, May 20, 2015 08:22:23 pm Martin Rex wrote:
>> Currently, the amount of TLS servers and TLS clients that are sending
>> junk seems to either negigible small, or limited to pure Web-Browser to
>> third-party Web-Server scenarios, i.e. pretty much none of our customers
>> are trying to make our software interoperate with such clients or servers.
>[...]
>> For the handful of customers who had that interop problem, contacting
>> the server admin and having them fix their server configuration was
>> possible every time, and I could point to the spec after analyzing
>> the problem to pass the blame.
> 
> That said, your argument is basically just that it doesn't affect you so it's
> not worth dealing with. TLS is a general security protocol used on the Web,
> not just by your customers. In the same way that IoT people will have to
> deal with stuff that isn't ideal for tiny embedded systems, people not
> accustomed to the mess that is the Web will have to deal with stuff that
> isn't ideal for people who can actually contact server admins every time.
> 
> The ability to reliably contact server admins to deal with interop reports
> from users sounds wonderful, but it's a fantasy to us trying to triage the
> mess on the Web side of the spectrum. Seriously; we're not debating
> this issue from the same world, but TLS has to operate in both.

You are totally missing the point.
I *DO* care quite a lot about interoperability, and about
the amount of work that others will have to interop with us.


The issue here is about improving implementations that they become
easier to use.  It is not possible to "misconfigure" our SSL implementation
so that it sends junk in the TLS handshake.  The admin will face an
error and a refusal to install&use an incomplete certificate chain
on the server side, so that no peer will ever have to deal with
the problem with our software sending junk in a Certificate
handshake messages.  I added this check into our PKI credentials
maintenance on purpose about a decade ago.

The proposed change does not encourage other implementers to improve
their implementations to catch and complain problems as soon as they
are created to the person that is in the best position to fix it,
but rather the opposite.
Because I *DO* care, I do not want to see others promoting a mess
that currently seems to be limited (and still fixable).


-Martin