Subject: 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

From: Peter Gutmann <[email-masked]>
Date: Tue, 19 May 2015 12:11:07 +0000

Dave Garrett <[email-masked]> writes:

>Who else is in favor or against, at the moment?

I'm in favour of relaxing the requirements to match real-world practice.

Peter.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 19 May 2015 16:38:59 +0000

+1. Since we're not going to change implementations to conform to the current strict requirements (because it would have been a breaking change), we can as well relax the requirements.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Tuesday, May 19, 2015 5:11 AM
To: <[email-masked]>
Subject: 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

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 May 2015 21:23:16 +0200 (CEST)

Andrei Popov wrote:
>
> +1. Since we're not going to change implementations to conform
> to the current strict requirements (because it would have been
> a breaking change), we can as well relax the requirements.

Please do not mess this up *again* -- and clearly sort out where you
see any requirements that you feel are a problem.

The existing text does not place *ANY* requirement on what the client
may accept.  The requirements are exclusively about what the server
is required to send.

Andrei:  Is it possible to make Microsoft SChannel send arbitrary heaps
of certificates in the Server Certificate handshake message?  If yes,
how is it exactly configured what junk in what order gets sent?

Or were you actually thinking about client behaviour -- where the
existing text does not (and never intended to) place any specific
behaviour.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Wed, 20 May 2015 22:27:28 +0000

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?

Cheers,

Andrei

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2015 12:23 PM
To: Andrei Popov
Cc: Peter Gutmann; <[email-masked]>
Subject: 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

Andrei Popov wrote:
> to the current strict requirements (because it would have been a 
> breaking change), we can as well relax the requirements.

Please do not mess this up *again* -- and clearly sort out where you see any requirements that you feel are a problem.

The existing text does not place *ANY* requirement on what the client may accept.  The requirements are exclusively about what the server is required to send.

Andrei:  Is it possible to make Microsoft SChannel send arbitrary heaps of certificates in the Server Certificate handshake message?  If yes, how is it exactly configured what junk in what order gets sent?

Or were you actually thinking about client behaviour -- where the existing text does not (and never intended to) place any specific behaviour.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 May 2015 02:22:23 +0200 (CEST)

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

---

From: Dave Garrett <[email-masked]>
Date: Wed, 20 May 2015 22:15:51 -0400

> are trying to make our software interoperate with such clients or servers.
[...]
> 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).

> problems and headaches as a result.

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

(replying to quote out of order)
> 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.

> 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

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 May 2015 04:35:05 +0200 (CEST)

> 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

---

From: Dave Garrett <[email-masked]>
Date: Wed, 20 May 2015 23:21:51 -0400

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

> 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

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 May 2015 10:11:07 +0000

Dave Garrett <[email-masked]> writes:

>not just by your customers.

That was what I was going to reply to Martin's post with, "how many embedded
devices did you sample when you came to the conclusion that the problem was
negligible"?  I was only yesterday dealing with one, a PLC, that (a) returned
a handshake failure if you connected to it with a TLS version greater than
1.0, (b) sent out garbled (but arguably valid) DH parameters, (c) seemed to
order the certs in its chain at random (or at least it wasn't consistent over
multiple connections), and (d) had an invalid cert.  Their defence was that
other vendors had been successfully interoperating with them for years, and my
code was at fault.  However if your world consists only of IIS and Apache (and
presumably NetWeaver?) then it's easier to pretend that this stuff doesn't
happen.

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 May 2015 18:42:54 -0400

> nor incorrect order of path certificates

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

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

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

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

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