Subject: Re: [TLS] Update spec to match current practices for certificate chain order

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 May 2015 14:43:45 +0000

Martin Rex <[email-masked]> writes:

>PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify
>the end-entity certificate.  In TLS, the identification is the first position
>in certificate_list.  So it is not possible to "blindly reuse" the code with
>respect to identifying the end-entity certificate.

Yes it is, as I mentioned in my previous message my code looks for the server
FQDN/whatever and uses the cert that contains that as the leaf cert.  It's the
same process that's used for IssuerAndSerialNumber, SCEP client IDs, and
various other things, "find the cert for the identified party, then follow
parent links to build the chain".

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 May 2015 15:51:48 +0000

> parent links to build the chain".

I don't see such an ad-hoc approach as a compelling reason to remove
the requirement that the end-entity certificate must come first.  The
MUST needs to stay.

The TLS layer does not always know which SAN value will be used to
authenticate the peer.  Certificate verification can be delayed
until the handshake is complete, and can be performed outside the
TLS stack.  The TLS stack needs the leaf certificate for key
agreement.

I summary, the only thing that could be tweaked is the requirement
to order the intermediate certificates.  The first MUST and final
MAY are correct as they stand.  And I think that the second MUST
is a fine example of Postel's principle.  Tolerance by many clients
of servers that ignore the requirement does not invalidate the
requirement.

-- 
	Viktor.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 7 May 2015 10:08:04 -0700

>  of servers that ignore the requirement does not invalidate the

To the extent this problem was caused (largely) by browsers, it's a
problem that could (largely) be solved by browsers.

The root cause I think is best captured by the fact that we don't have an
X.500 directory, and thus RFC 2459/3280/5280 have never been sufficient to
work in isolation because there's no notion of a global, shared trust
store for who is authoritative and all of the trust relationships.
Instead, we have the ad-hoc trust stores of major software vendors, and
you find them in various different states through time and versions (e.g.
the massive amounts of cross-signing that go on for CAs like
Symantec-Verisign, StartCom, or Verizon-(GTE/Baltimore) Cybertrust)

The disconnect exists because the TLS and X.509 subsystems are
disconnected (as they reasonably can be), with TLS opting for RFC 5246
(and earlier), and X.509 clients needing to implement something like RFC
4158. In an RFC 4158 world, your inputs of intermediate CAs are unsorted (
https://tools.ietf.org/html/rfc4158#section-2.7.2 ) - and may even be
ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 )

These sections aren't specs-leading-implementations - the leading
implementations of path building were already doing what the spec merely
documented after-the-fact.

If a client wanted to ensure RFC 5246 compliance, it would need to
explicitly add code to test that - coupling the TLS and X.509
implementations more tightly.

In recent years, with the necessary attention on PKI, more clients (not
exclusively browsers, but especially browsers) are bringing their
PKI/X.509 implementations closer to their TLS implementations, and maybe
this coupling isn't so bad.

In an ideal world, I'd prefer the second MUST remain a MUST, because it
makes implementing a TLS + RFC 5280 validator easier (e.g. without
*requiring* an RFC 4158 discovery phase).

However, in a pragmatic world, because major clients implement RFC
4158-like behaviours, and because in the changing landscape of CA
hierarchies (both through acquisitions, but also through the deprecation
of weak crypto like SHA-1 or RSA-1024 bit keys and the adoption of
stronger crypto, such as ECC), it's increasingly necessary to implement
something like RFC 4158 to work on the Internet at large, changing the
second MUST to a SHOULD seems imminently sensible and reflects the reality
today and going forward.

The first MUST should remain - I can't see how any sane client would or
could avoid that. The final MAY is also necessary/correct, judging by how
the Web PKI actually works (plus the whole "self-issued for key rollover"
captured in https://tools.ietf.org/html/rfc5280#section-6.1 that makes it
problematic for a client to determine whether or not the 'root CA' is
actually a 'self-issued for key rollover' intermediate)

There's always the possibility that as browsers become increasingly
proactive in communicating 'bad' (misconfigured), 'insecure', and
'sub-optimal' configurations, we'll find a world where major clients can
safely and correctly *enforce* the 5246 behaviour as part of encouraging
good server hygiene...

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 May 2015 19:51:35 +0200 (CEST)

> parent links to build the chain".

I'm sorry, but I fail to understand what you mean.  The TLS protocol
layer explicitly has no business whatsoever with names in certificates,
that has been spelled out clearly in all existing TLS specs.
A TLS client should not know or care about the hostname of the server
it is talking to, and there is no requirement what kind of stuff is
contained in the server's certificate.  Our TLS client does _not_ know
the server's hostname (it gets a connected socket).

  https://tools.ietf.org/html/rfc5246#page-5

                                 the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
*> exchanged are left to the judgment of the designers and implementors
*> of protocols that run on top of TLS.

As I said, it is impossible for the client to use the PKCS#7/CMS
approach to locate the client certificate.

The Definition of the TLS Certificate PDU has always contained this
paragraph:

  https://tools.ietf.org/html/rfc6101#section-5.6.2
  https://tools.ietf.org/html/rfc5246#page-48

   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
   vector because PKCS #6 [PKCS6] extended certificates are not used.
   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
   of parsing the list more difficult.

Personally, I find it quite appalling how many broken TLS
implementations out there fail to properly encode an ordered list
of certificates into the Certificate handshake message.

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Thu, 7 May 2015 14:35:15 -0400

> of certificates into the Certificate handshake message.

or more concisely:

On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> Bleh.

I think we're in fair agreement that this is sloppy, but it's sloppiness that should've been fixed long ago if we still wanted to fight it.

I brought this issue up in response to a bug report for Firefox fully validating an EV cert list with an extra cert and things out of order. Mozilla and others seem to accept it just fine, so either the spec needs updating to reality or everyone should be adding new security errors to break it. The former makes more sense.

> ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 )
[...]
> actually a 'self-issued for key rollover' intermediate)

Ok, so it looks like:
1) Fair bit of push-back against Peter's suggestion of relaxing the first MUST.
2) Begrudging agreement that the second MUST can be a SHOULD to match current realities.
3) The MAY shouldn't be a MUST, or SHOULD.

Current:  https://tools.ietf.org/html/rfc5246#section-7.4.2

certificate_list requirements draft 3a:
------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate MUST come first in the list.
     Additional certificates needed to construct a valid certificate
     chain SHOULD be ordered by increasing scope of authority.
     (e.g. sender, intermediate(s), certificate authority)
     Root certificate authority certificates MAY be omitted from
     this list under the assumption that the peer possesses it
     in its trust store.
------------------------------------------------------------

This gets the 2119-ing as desired, with rewording to cover the reasoning needed to follow or not follow the SHOULD.

certificate_list requirements draft 3b:
------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate MUST come first in the list.
     Additional certificates needed to construct a valid certificate
     chain SHOULD be ordered by increasing scope of authority.
     (e.g. sender, intermediate(s), certificate authority)
     It is NOT RECOMMENDED to include root certificates that
     peers must already possess in order to validate the
     given chain.
------------------------------------------------------------

This rewords the CA cert part into a more clear recommendation. (i.e. more than a MAY, but not quite a SHOULD)

Which, if either, of those two sounds good? Please also correct me if I've missed a subtlety here that needs to be taken into account. (or, or course, if I outright screwed something up ;)

Dave

---

From: Fabrice Gautier <[email-masked]>
Date: Thu, 7 May 2015 12:21:37 -0700

> On May 7, 2015, at 11:35, Dave Garrett <[email-masked]> wrote:
> 
> so either the spec needs updating to reality or everyone should be adding new security errors to break it. The former makes more sense.

How about fixing the servers ?

-- Fabrice

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 May 2015 20:18:33 +0000

> certificate_list requirements draft 3a:

That's mostly fine (singular/plural conflict), though one might
clarify the MAY further:

  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate MUST come first in the list.  Additional
     certificates needed to construct a valid certificate chain
     SHOULD be ordered by increasing scope of authority.  (e.g.
     sender, intermediate(s), certificate authority).  Root
     certificate authority certificates MAY be omitted from the
     list, provided supported peers are known to possesses any
     omitted certificates they may require in their trust stores.
     (When DANE-TA(2) trust-anchors are self-signed roots, they
     MUST not be omitted [draft-ietf-dane-ops]).

Note, [draft-ietf-dane-ops] will be an RFC long before TLS 1.3 is
done.

> certificate_list requirements draft 3b:

I think, that's still too strong.  Note that often the chain
construction is done by a library that augments the server leaf
certificate  with additional certificaets from the server's trust
store, and this code does not know whether the root is needed in
the chain or not.

-- 
	Viktor.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 7 May 2015 14:37:40 -0700

>       MUST not be omitted [draft-ietf-dane-ops]).

While I appreciate the attentiveness to DANE's needs, it seems unnecessary
to specify profile-specific details in the TLS specification, much in the
same way we don't discuss profile-specific aspects of ciphersuite
negotiations or the like. That is, I consider DANE-TA(2) trust anchors as
a profile of how the TLS exchange works, not an intrinsic property that
belongs in this spec.

Regarding Dave's suggested rewording on the additional certificates, I
think there's actually sizable ambiguity with respect to the terms chosen
(sender, intermediate(s), certificate authority) that the original
language is much clearer and less ambiguous on.

At the risk of a bike-shed, I'll throw my contribution in, which aligns
closer to the existing language, save for avoiding the notion of "root
certificate authority certificates" in favour of the RFC 5280 term of
trust anchor, which need not necessarily be a certificate. Functionally,
this is equivalent, but hopefully provides clearer understanding.

  This is a sequence (chain) of certificates. The sender's certificate
  MUST come first in the list. Each following certificate SHOULD
  directly certify the one preceding it. Because certificate validation
  requires that trust anchors be distributed independently, a
  self-signed certificate that specifies the trust anchor MAY be omitted
  from the chain, provided supported peers are known to possess any
  omitted certificates they may require.

So, for the DANE-TA(2) trust-anchor form, it requires that the trust
anchor be express as a self-signed certificate, and is not possessed by
the peer, ergo the MAY doesn't apply and the peer MUST send the
certificate. But it avoids the cross-reference to a particular trust
validation method.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 May 2015 21:45:03 +0000

> a profile of how the TLS exchange works, not an intrinsic property that

Sure, the parenthetical is by way of a "footnote", and can be droppped.
The key point is the preceding sentence.

>   omitted certificates they may require.

Works for me.

> certificate. But it avoids the cross-reference to a particular trust

No problem, I had no major issues with the current MAY, and this
new language improves on it by covering the essential caveat.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 7 May 2015 18:46:51 -0400

> certificate. But it avoids the cross-reference to a particular trust

"Trust anchor" is notably better, yes.

However, the language of "directly certify the one preceding it" is problematic with multiple intermediates. I was looking to have the wording be more general to provide expectations there. I think the simplest way to resolve this might be to just drop usage of the word "the" here. So:

   This is a sequence (chain) of certificates. The sender's certificate
   MUST come first in the list. Each following 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 supported peers are known to possess any
   omitted certificates they may require.

This has the same ordering expectations as the more significant rewordings, but is very similar to the current language.

Dave

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 May 2015 16:19:26 +0200 (CEST)

Dave Garrett wrote:
> I think we're in fair agreement that this is sloppy, but it's sloppiness
> that should've been fixed long ago if we still wanted to fight it.
> 
> I brought this issue up in response to a bug report for Firefox fully
> validating an EV cert list with an extra cert and things out of order.
> Mozilla and others seem to accept it just fine, so either the spec
> needs updating to reality or everyone should be adding new security
> errors to break it. The former makes more sense.

No, the former is clearly detrimental.

Browsers, which haved added fancy colors and stuff to address bars
for EV certs, really ought to punish servers sending bogus Certificate
handshake messages by reducing the color feedback to mere black&white
and not attributes (_not_ produce a warning!  I believe the Google
Chrome 42 behaviour for sha1-Signatures is totally wrong, because
hardly anyone understands what the real issue is, and Chrome will
not tell you which signature algorithms in which certs it is unsatisfied
with).

I believe that one of the causes why the problem exists at all
is a lack of sensible PKI credential management on the server side.

Properly done, the PKI software on the server side will refuse
installation of a server certificate with an incomplete certification
path directly to the administrator who is trying to install the certificate.
The only person who can "fix" such a configuration error is the server
admin, so the admin (a) should get to see that error and (b) get to 
see it upfront, even before starting a server with a bogus configuration.

After successful server certificate chain verification (normally on
maintenance operations on a server's PKI credential, or for servers
lacking PKI credentials management, at least once on server start)
the correct ordering of certificates is known, and that known ordering
can then be used for thousands/millions of TLS handshakes without
wasting any further CPU cycles.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 8 May 2015 14:51:09 +0000

There is nothing wrong with the client accepting a bag 'o certs that is 1) incomplete, 2) has extra certs, or 3) has the exact number of certs in the exact order needed to chain back to a server-trusted root, as long as the client can validate a path back to a client-trusted root (using either cached or fetched certs if the bag doesn't work).  PKIX specifies validation requirements that do not require servers to send anything, and sending a full path with every handshake is an efficiency gain for the first connection but a waste for all the rest.

Servers can be strict in what they send by sending a server-trusted path in chaining order as you suggest.   But clients that cannot construct a valid path on their own if the server's doesn't satisfy them are insufficiently liberal.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, May 08, 2015 10:19 AM
To: Dave Garrett
Cc: [email-masked]
Subject: Re: [TLS] Update spec to match current practices for certificate chain order

Dave Garrett wrote:
>> implementations out there fail to properly encode an ordered list of 
>> certificates into the Certificate handshake message.
> 
> or more concisely:
> 
> I think we're in fair agreement that this is sloppy, but it's 
> sloppiness that should've been fixed long ago if we still wanted to fight it.
> 

Browsers, which haved added fancy colors and stuff to address bars for EV certs, really ought to punish servers sending bogus Certificate handshake messages by reducing the color feedback to mere black&white and not attributes (_not_ produce a warning!  I believe the Google Chrome 42 behaviour for sha1-Signatures is totally wrong, because hardly anyone understands what the real issue is, and Chrome will not tell you which signature algorithms in which certs it is unsatisfied with).

I believe that one of the causes why the problem exists at all is a lack of sensible PKI credential management on the server side.

Properly done, the PKI software on the server side will refuse installation of a server certificate with an incomplete certification path directly to the administrator who is trying to install the certificate.
The only person who can "fix" such a configuration error is the server admin, so the admin (a) should get to see that error and (b) get to see it upfront, even before starting a server with a bogus configuration.

After successful server certificate chain verification (normally on maintenance operations on a server's PKI credential, or for servers lacking PKI credentials management, at least once on server start) the correct ordering of certificates is known, and that known ordering can then be used for thousands/millions of TLS handshakes without wasting any further CPU cycles.

-Martin

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

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 May 2015 17:03:58 +0200 (CEST)

Kemp, David P. wrote:
> There is nothing wrong with the client accepting a bag 'o certs that
> is 1) incomplete, 2) has extra certs, or 3) has the exact number of
> certs in the exact order needed to chain back to a server-trusted
> root, as long as the client can validate a path back to a
> client-trusted root (using either cached or fetched certs if the
> bag doesn't work).

This is the TLS WG mailing list and the TLS protocol.  You might be
confusing this discussion with PKIX and CMS.

None of what you enumerate applies to the TLS Certificate handshake
message, because this carries well-explained MUSTs.

>
> PKIX specifies validation requirements that
> do not require servers to send anything, and sending a full path
> with every handshake is an efficiency gain for the first connection
> but a waste for all the rest.

For PKIX (rfc5280), the building of a certification path has been EXPLICITLY
declared "out of scope", and it is pretty normal for TLS peers to not
contain any kind of path building functionality and not to know more
than "trust anchors" for verification of certificate chains provided
by peers.

What we're looking at here, is **interoperability** requirements.

> 
> Servers can be strict in what they send by sending a server-trusted
> path in chaining order as you suggest.

This is an obvious misunderstanding of the TLS specification and the
requirements keyword MUST:

https://tools.ietf.org/html/rfc2119#section-1

  1. MUST
   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Sending a complete and ordered certificate chain in the "certificate_list"
element of the TLS Server Certificate handshake message is not an option,
is is an "ABSOLUTE REQUIREMENT".

>
> But clients that cannot construct a valid path on their own if the
> server's doesn't satisfy them are insufficiently liberal.

Clients do not have to accomodate server that violate MUSTS.  In most cases,
it is detrimental and often dangerous to work around such protocol
violations by the peer.

And if all of what the client has is a very short list of trust anchors
(in the optimal and safe configuration just one single trust anchor),
then there is nothing besides a simple reordering and duplicate cert
elimination that a sensible client can do about a misconfigured server
that is using a defective TLS implementation.

Either the certification path presented by the server crosses through
the trust anchor(s) of the client or ends there -- then you get interop,
or it doesn't then you get interop failure.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 8 May 2015 15:19:26 +0000

Martin Rex wrote:
> Clients do not have to accomodate server that violate MUSTS.

Absolutely correct.   Accommodating a compliant server is the only mandatory to implement requirement on clients.

> In most cases, it is detrimental and often dangerous to work around
> such protocol violations by the peer.

How ???

> or it doesn't then you get interop failure.

Clients that provide value-added (optional) path construction functionality do not fail, either operationally or security-wise.   Perhaps no such clients exist, now or in the future.  But if they do, satisfying more than the MUSTS does not make them non-compliant.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 8 May 2015 11:29:56 -0400

> not tell you which signature algorithms in which certs it is unsatisfied

Let me be clear: I don't fundamentally disagree with you. I think that protocols should be treated far more strictly than they tend to be and stuff like this should be a mandatory error if it's against the current spec. That said, if we step ~way~ far back, we're sort of hitting a standard human societal problem: given a problem, and a set of solutions, arguing for the ideal you can't get is an argument for the problem. Do you think we could compel every browser vendor to apply this (effectively) new standard uniformly, and make the changes all at the same time? I don't, especially not from the TLS spec. Vendors can't even drop critically insecure protocols in unison. I don't even have confidence that everyone could coordinate a token change of coloring in the UI for this one narrow case.

This is a wire format issue, rather than a security one, so as long as we have an accepted format that is secure, then it doesn't really matter beyond that. I would agree that browsers should probably throw a warning into their consoles for this sort of thing, but not a user-facing action. Of all the problems TLS has, this is not one I think is worth worrying about too much. ;)

> is a lack of sensible PKI credential management on the server side.

Likely true, but outside of the current scope of action.

Dave

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 May 2015 17:35:37 +0200 (CEST)

Kemp, David P. wrote:
> Absolutely correct.   Accommodating a compliant server is the
> only mandatory to implement requirement on clients.
> 

Detrimental because it hides a server configuration error that can
only be fixed on the server.  The resulting behaviour of the end-user
becomes seemingly non-deterministic.  It may work with some clients
and not work with others, and it may work after having been to other
servers, but not directly after reboot.  Just crazy.

> Clients that provide value-added (optional) path construction
> functionality do not fail, either operationally or security-wise.

I've seen epic failures here before.  Such as chasing AIA for missing
intermediate certs (not having a trusted cert store that contains it).
That's a real security goof, and it was implemented by some clients.

>
> Perhaps no such clients exist, now or in the future.  But if they do,
> satisfying more than the MUSTS does not make them non-compliant.

For a number implementors, convenience is more important than security,
and they will skip anything that is difficult.  Such as skipping
certificate and certicate path validation for the peer completely.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 May 2015 17:41:12 +0200 (CEST)

Fixing typo (I'm sorry, I should have reviewed before sending):

only be fixed on the server.  The resulting behaviour for the end-user

-Martin

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 8 May 2015 14:10:19 -0700

On Fri, May 8, 2015 8:29 am, Dave Garrett wrote:
>  Let me be clear: I don't fundamentally disagree with you.

While I have great respect for Martin, I do disagree and think he's
fundamentally wrong here, for the reasons I already explained in my first
message as to why what he's asking is not only *wrong*, but *unwise* and
an unnecessary coupling of two intentionally-independent layers.

> Do you
>  think we could compel every browser vendor to apply this (effectively) new
>  standard uniformly, and make the changes all at the same time?

As I said elsewhere, requiring ordering might be something browsers do in
the future, but it's fundamentally coupling two things which are
explicitly decoupled (and better off so)

>  I don't,
>  especially not from the TLS spec. Vendors can't even drop critically
>  insecure protocols in unison. I don't even have confidence that everyone
>  could coordinate a token change of coloring in the UI for this one narrow
>  case.

And of course, coloring is the unquestionably wrong answer here from a
usability study. It's not so much a bikeshed discussion as demonstrably
bad for users and homeopathic cybersecurity :)

>  Likely true, but outside of the current scope of action.

The only way in which this protocol could have worked as described is in
an X.500 world that no one should reasonably/sanely want. Outside of that,
we're talking about tradeoffs and compromise, and those are both sensible
and necessary, so I agree wholeheartedly here :)

---

From: Dave Garrett <[email-masked]>
Date: Fri, 8 May 2015 17:34:47 -0400

> an unnecessary coupling of two intentionally-independent layers.

This is a two decade old set of security standards. If you want any strict
separation of layers, you're going to need to start from scratch. (which we're
hopefully doing soon with something QUIC based) Anything other than
acknowledging this current situation as a mess and doing what you can
where you can (e.g. HPKP) is not really practical.

Wise as it may be to try to keep things decoupled, it's not the current reality.

> usability study.

It's wrong just from a biological perspective, seeing how colorblindness of
various forms is not uncommon.

Dave

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 8 May 2015 14:53:34 -0700

>  Wise as it may be to try to keep things decoupled, it's not the current

I think you've misunderstood me. Hopefully a re-read of the original
message will provide clarity.

The "problem" caused is precisely *because* the layers are decoupled. To
satisfy Martin's requirement (e.g. at a browser), you would necessarily
*need* to couple the layers. And while it's true that browser's internal
implementations have begun to blur the layers such that a tight coupling
may not be entirely unreasonable, they are *not* coupled to the degree
necessary to satisfy the second MUST, which is why we're in the present
state.

So by accepting the status quo and having the spec updated to reflect
that, we agree that the decoupling/loose coupling is good.

By changing clients to enforce the second MUST, we promote more coupling
at the clients. That's not good in my view.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 8 May 2015 19:07:46 -0400

On Friday, May 08, 2015 05:53:34 pm Ryan Sleevi wrote:
> I think you've misunderstood me.

I think we've both misunderstood each other a bit, which unfortunately tends to happen sometimes with larger responses and quotes. I'll be brief, as we're veering off-topic a bit.

> that, we agree that the decoupling/loose coupling is good.

Yes, in this case.

> at the clients. That's not good in my view.

What I was saying that I "don't fundamentally disagree" with is the notion that ideally the second MUST should be enforced more strictly. This is not a clean system where we can expect layers to be loosely coupled. We're just long past the point where this is realistic, and in this case strictness wouldn't give us any direct benefit.

Dave

---

From: Ben Laurie <[email-masked]>
Date: Mon, 11 May 2015 12:28:54 +0100

>> such protocol violations by the peer.

Failure to strictly enforce protocols leads to security issues. For
example: https://www.owasp.org/index.php/HTTP_Request_Smuggling