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

[Dave Garrett <[e-mail]>]

On Wednesday, May 20, 2015 10:35:05 pm Martin Rex wrote:
> 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.

But it is very possible to do that with other server implementations. Yeah,
you could say it's _because_ clients allowed otherwise, but... they _did_.

Here's a 7 year old post from this list that I stumbled over when searching
for info on the topic:
https://www.ietf.org/mail-archive/web/tls/current/msg02962.html

This is not a new issue. Sorry, you lost this argument a decade ago and
we're trying to clean up the mess after the fact. It's a topic that apparently
didn't get discussed properly in the past, and I'm trying to change that so
that interop doesn't get worse.

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

As I said prior, this is where I agree with you and disagree with Ryan. It is,
however, only something that can be done if everyone enforces it, which is
most certainly not the case. Strictly enforcing this is simply not viable. This
would've needed to have been done at the end of the prior century to be a
thing we could rely on.

Someone else suggested creating a TLS implementation test suite that
everyone could be expected to pass in order to ensure the known pitfalls
are all addressed. That would really help with this sort of issue.

> that currently seems to be limited (and still fixable).

Sorry, it's not. You're very lucky to be in an environment where server crap
is fixable to deal with clients enforcing the spec fully. Again, there are also
legitimate reasons to have lists that are not strictly linear, and planning
for them is very helpful.


Dave