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

Thank you for posting the actual concrete reason why you're opposing this.
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.

Also, I don't care about blame; I don't want to pass the buck; I just want
the thing to work (without affecting security, which this does not).

> in the installed base -- which is going to create interoperability
> problems and headaches as a result.

You're worried about creating the reality that already exists.

(replying to quote out of order)
> Not adhering to the requirements will cause *REAL* interoperability
> problems in the installed base, because there are implementations
> that will fail if TLS peers start sending junk.  For 13 years,
> our implementation was very strict and tolerated not even duplicates
> nor incorrect order of path certificates

The requirements are still a SHOULD, though. As said elsewhere, unless
an actual case as to why not to can be provided, a SHOULD should be
interpreted as a MUST. In your case of an admin screw up, you still can
point at it and say "I told you so". (Though, I'd much rather the server
implementor fix the fact that the admin was capable of configuring it
wrongly in the first place.) If you get a list you can't parse because
of two intermediates that are different but both valid, yeah, you'll
want to update your implementations to handle that.

If you want a hard requirement of an aborted handshake and error
message on something stupid like an exact duplicate, I'd actually
be on your side for that one, but I suspect others would not be.

> For those who have been and still are ignoring the requirements in
> the specification today, why do you need these requirements changed?

I'm going to point to Ryan's big post again:
https://www.ietf.org/mail-archive/web/tls/current/msg16238.html

If all paths the server has can be provided to the client, then various
different clients with different capabilities can all be supported, and
the server can transition to newer capabilities with less breakage.
This is directly helpful to adoption rates in the real world. A tactic
of forcing everyone to "Break the Web" and just cut off the old stuff all
at once might actually be a better idea, but you try convincing anyone
to actually do that. We can't even kill off stuff like insecure fallback that
was _never_ legitimate. :/


Dave