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

On Wed, May 20, 2015 at 8:22 PM, Martin Rex <mrex@sap.com> wrote:
> 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

What about junk following the chain, as needed in the case of updates
to signature algorithms?

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

So none of your clients are dealing with bridge CAs, CAs that are
handling migrations in the way that Ryan Sleevi indicated some are, or
are dealing across organizational boundaries?

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

As you admitted above, you don't see any of the problems in the wild
the web browser people do.

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

Or is it going to warn the implementor that all sorts of junk will be
expected to work, and of some of the dragons that may exist?
Documenting the *actual* problems in the world is far more useful than
ignoring them entirely.

>
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.