Change:
Current client implementations allow more flexible certificate ordering than the spec allows and some server implementations send certificates in orders that the spec says "MUST" not be done. Relaxing the language here to a "SHOULD" is appropriate so implementers following this spec know that such situations need to be handled. Enforcing this more strictly would cause interop problems for no practical gain. The modified language here is based on the mailing list discussion.
This seems like a really bad idea, since it will reduce interoperability even further.
If you'd like to explain how formally documenting existing behavior (that we are not otherwise proposing be changed) will somehow reduce interoperability further, then please do so on the mailing list. This proposal is only to properly document existing capabilities such that all readers of the spec actually know what to expect here. Not doing this requires either intentionally having a part of the spec we know to be wrong in practice, or changing this to require more strict error enforcement that would break interop.
Ryan Sleevi posted to the list an in-depth argument as to why the prior requirement can be considered harmful. I'll cite it here for reference, as the threads on this topic got long and winding: URL
Rebased. NAME Last discussion of this on-list ended with lots of agreement and one strong dissenter. Are you able to declare a rough consensus to merge this, or is more discussion needed? Note that this is already in "running code", as this merely documents existing practice in some implementations.
NAME can this be merged?
NAME Ok, revised and rebased. Please take a look.
Rebased. FTR in this PR, question from NAME answered on-list: URL URL (GitHub's logic is that if you comment on a commit directly, as apposed to the changeset in the PR, then rebasing ditches your comment from the PR; old comments on the PR get collapsed above, but are still here) NAME I don't know the WG policy here. Is NAME approval sufficient sign-off for you to merge, or do we need NAME Quoting from the list: On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote: [question asked and satisfactorily answered by Viktor Dukhovni; link above] On Wed, Aug 26, 2015 at 10:25:07PM -0700, Joseph Salowey wrote: So, is this finally ready to land now? Thanks Viktor, I missed this part of the discussion. The text looks fine to me as is. Joe , Viktor Dukhovni wrote: >
That's not true. I've explicitly stated it's a BAD requirement, and tried to give concrete examples. I'll be explicit: 1) I think clients, such as Martin's, that implement normative checking of ordering and are used for the Internet at large (e.g. between servers and clients that are not controlled by a single entity) are bad for Internet security. 2) I think clients, such as Martin's and Geoff's, that do not implement RFC 4158 path discovery are bad for Internet security. 3) I think language that encourages or requires clients to normatively enforce such ordering are bad for Internet security. So to be clear, I disagree with my colleague, Ben Laurie, rather substantially here. The context is that: 1) I'm involved in maintaining one of the largest client web browsers' PKI stack. Thus, I deal with brokenness on a daily basis. 2) I'm involved in dealing with the PKI stacks of a variety of platforms, some open-source, some closed-source, and with a variety of versions. 3) I'm involved in the CA/Browser Forum and have spent the past several years trying to work in deprecation of insecure cryptography (in the case of certificates, SHA-1, RSA signatures <= 1024-bits, and in general, RSA signatures vs ECC) I say all this to say "I've seen things", and when it comes to gross hacks, few people are as more affected and have more visibility to them than those doing things similar to me. All of that to say I think the current language encourages bad practice. In my original email, I tried to establish why: 1) Clients have disparate trust-stores. Absent the X.500 directory, this is a fact of life. The set of trust anchors recognized by Microsoft will and is different than those recognized by Mozilla, for a variety of legitimate reasons that will not change, no matter what the IETF does. 2) As such, there is no single trusted path. RFC 4158 spells this out in abundant detail, and the figures contained should be "required skimming" for any of this discussion. 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also necessary, as the first two points here spell out. Clients that don't support RFC 4158 "break" if a trusted path cannot be found. In order to handle deprecations of SHA-1, for example, certificate paths need to be replaced with their SHA-256 equivalent. To handle the deprecation of RSA-1024 bit, alternative paths must be supplied. To handle the deprecation of RSA in favour of ECC, alternative paths must be supplied. If you fail to supply those, clients break. When clients break, servers have to choose between breaking clients and doing the right thing or keeping clients working. For obvious and understandable business reasons, "keeping clients working" is always going to be the preferable case. "Keeping clients working" is equivalent to "holding security back" So servers do the sensible thing. They try to find a way to keep clients working WHILE doing the right thing. This takes many forms. The most obvious and understandable being supply all the paths the server knows about to the client. Clients that don't do "insecure AIA fetching" (as Martin likes to pejoratively phrase it, as I disagree with him on this point substantially), but that thankfully don't implement Martin's strict checking (which luckily, few do), this works as a viable means of providing acceptable paths to them. At the cost of violating the TLS RFC in a part of language that enforcing requires more work and introduces more security issues to clients. If every client had RFC 4158 capable path discovery, would I still advocate relaxing the language? Honestly, yes, because it should be up to the server to balance the tradeoffs between client interoperability. If every client enforced the TLS requirements, as Martin advocates, it would directly and concretely harm the ability to push for reform in the PKI system used by the most prominent deployment of TLS (the HTTPS Web), because clients that lack "insecure AIA fetching" would simply break when the Web PKI changes. There are many ways to mitigate this, and luckily, modern cryptographic libraries are starting to see the wisdom that Microsoft saw nearly 10 years ago, when they made CryptoAPI automatically update the trust store and handle trust migrations. However, in an IoT world, where things are using libraries like OpenSSL, and which lack RFC 4158 path discovery, I'm increasingly concerned that we will see greater ossification and calcification of the PKI stores, preventing much needed security reform. So yes, I do see this current language as objectively and quantifiably BAD for security. I think implementing it in a TLS client library (since it is NOT required of PKI libraries or implementations, and RFC 4158 rightly dissuades it) introduces more attack surface and more complexity for negative gains on security and maintainability.

Discussion:
Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. <ins> Relax certificate_list ordering requirement to match current practice. </ins> draft-07 Integration of semi-ephemeral DH proposal.

%%% Authentication Messages opaque ASN1Cert<1..2^24-1>; <del> This is a sequence (chain) of certificates.  The server's </del> <ins> This is a sequence (chain) of certificates.  The sender's </ins> certificate MUST come first in the list.  Each following <del> certificate MUST directly certify the one preceding it.  Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certification authority (CA) MAY be omitted from the chain, under the assumption that the client must already possess it in order to validate it in any case. </del> <ins> certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates they may require. Note: Prior to TLS 1.3, "certificate_list" ordering was required to be strict, however some implementations already allowed for some flexibility.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version (with the exception of the sender's certificate).  Some servers are configured to send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly by clients capable of doing so. Whilst the chain MAY be ordered in a variety of ways, the peer's end- entity certificate MUST be the first element in the vector, and implementations MUST abort with a fatal "bad_certificate" alert in the event that this is not the case. </ins> The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY