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)]

Andrei Popov wrote:
>
> This isn't about a specific TLS implementation. As Ryan explained
> (http://www.ietf.org/mail-archive/web/tls/current/msg16238.html),
> servers today have to deviate from the certificate_list ordering
> requirements for a variety of practical reasons. Clients can't take
> advantage of these requirements, because servers violate them.
> So if neither clients nor servers can in practice implement this
> RFC language, why don't we drop it?

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

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.

I get to see most non-trivial SSL interop problems that our customers
report for usage scenarios, and what I've seen looks like a _very_low_
number of misconfigured Apaches with OpenSSL with these three kinds
of problems:
   - missing path CA certificates
     (e.g. yesterday, after a service provider for invoicing has switched
      from a verisign-issued server certificate, where it properly sent
      all path certificates to a GeoTrust-issued server certificate,
      where the server is sending only the server certificate)

  - duplicate certificate in the chain

  - garbled certificate chain (wrong oder of path certificates)

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.


So what "flexibility" there is in some implementations is much
less relevant than with how much actual abuse there currently
is in the installed base.  And to me, the visible level of abuse
is low, so the resulting amount of de-facto interop problems is low.


The only motivation that has been given for changing the requirements
is that folks consider it necessary to promote the amount of abuse
in the installed base -- which is going to create interoperability
problems and headaches as a result.


For those who have been and still are ignoring the requirements in
the specification today, why do you need these requirements changed?
You seemed to not have a problem ignoring the reasonable guidance
(that greatly simplifies implementations) all the time anyway -- you
evidently do not need this change.


-Martin