Subject: Requesting reviews of draft-vanrein-httpauth-sasl

From: Tommy Pauly <[email-masked]>
Date: Tue, 05 May 2020 15:11:17 -0700

Hello HTTPbis,

At the virtual meeting of secdispatch at IETF 107, a proposal for SASL in HTTP was presented. The outcome of that discussion was to discuss it at the next HTTPbis meeting.

This document is on our virtual interim agenda for May 19 (https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/agenda.md):

https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-04

There was some brief discussion on the mailing list about this document in January, but there hasn’t been substantial discussion since. Ahead of our virtual meeting, it’d be great to get a few more eyes on this document and have some reviews or thoughts posted to the list.

Thanks!
Tommy (as co-chair)

---

From: Rick van Rein <[email-masked]>
Date: Wed, 06 May 2020 13:14:08 +0200

Hello Tommy,

This is too early for us -- we planned it for July.

I don't know if that was a misundersanding, but can you please take it
off the agenda for this meeting?

-Rick

---

From: James <[email-masked]>
Date: Thu, 14 May 2020 16:32:46 +0100

I've had a brief review of this document and  have a comment to a part 
of the security considerations:

 > This means that a secure transport layer must be used, like TLS.  The 
termination of such a secure layer MUST also terminate any ongoing SASL 
handshakes.

Isn't this incompatible with use cases where TLS termination is 
separated from the processing of the HTTP request such is common in 
CDNs, or where a trusted proxy is involved?

- J

---

From: Michiel Leenaars <[email-masked]>
Date: Thu, 14 May 2020 17:52:45 +0200

Hi James,

>> This means that a secure transport layer must be used, like 
>> TLS.  The termination of such a secure layer MUST also 
>> terminate any ongoing SASL handshakes.
>
> separated from the processing of the HTTP request such is common 
> in CDNs, or where a trusted proxy is involved?

arguably, resources fetched from a public CDN are (or should be) 
exclusively static assets, which of course can be used in an authenticated 
session but are not part of it. TLS can be provided for integrity, but not 
for confidentiality.

Since a CDN is essentially a cache with man-in-the-middle capabilities 
allowing to observe all the traffic that passes by, it cannot be end-to-end 
secure in the actual sense of the word and should not be used as such. So I 
do not see an incompatibility...

Best,
Michiel Leenaars
NLnet Foundation

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 May 2020 09:07:49 -0700

On Thu, May 14, 2020 at 9:01 AM Michiel Leenaars <[email-masked]>
wrote:

> exclusively static assets,

"Arguably" is doing a lot of work here, as CDNs have already evolved well
beyond this (cf. edge compute).

> which of course can be used in an authenticated
> session but are not part of it.

I'm not sure how to formalize this as a security property. Certainly from
the perspective of the origin
model and the browser the CDN *is* the origin. And for that reason, as a
practical matter it is in
part responsible for anything that the browser generates, including
authenticated traffic. (For instance,
it can cause the browser to make authenticated HTTPS requests just as the
origin server can).
Can you elaborate on what you mean here?

TLS can be provided for integrity, but not
> for confidentiality.

This seems wrong to me. It's certainly important to users to have the
information they exchange
with the CDN be confidential from other actors on the network. Consider,
for instance, a photo
sharing site; I don't want random people to know which photos I view.

-Ekr

---

From: Michiel Leenaars <[email-masked]>
Date: Thu, 14 May 2020 19:00:37 +0200

Hi Eric,

> "Arguably" is doing a lot of work here, as CDNs have already 
> evolved well beyond this (cf. edge compute).

that would be companies providing CDN also (or actually) providing cloud 
services on their distributed infastructure, rather than an actual delivery 
network: an intermediate (but passive) cache layer with high availability, 
for static assets. As you rightly point out, in the case of outsourced 
cloud services any such infrastructure would in fact be the origin for all 
intents and purposes - even if some data is fetched once in a while from 
some back end.

> I'm not sure how to formalize this as a security property. 
> Certainly from the perspective of the origin
> model and the browser the CDN *is* the origin. And for that 
> reason, as a practical matter it is in
> part responsible for anything that the browser generates, 
> including authenticated traffic. (For instance,
> it can cause the browser to make authenticated HTTPS requests 
> just as the origin server can).

What I mean is that here SASL in my opinion is meant to facilitate 
unforgeable authentication and confidentiality between the end points at 
hand. If the edge point is an 'edge compute' node run by a company that 
also delivers CDN services, that would I believe work fine with the 
proposed technology - and there is no problem. 

My considerations revolve around a CDN in the classical sense of the word, 
which as a passive relay has no right to look into an authentication 
protocol exchange between end points. Essentially, I do not think end users 
should want to expose a confidential session to an intermediate cache layer 
intended for static assets only. There is no value add in terms of security 
or functionality.

> TLS can be provided for integrity, but not for confidentiality.
>
> This seems wrong to me. It's certainly important to users to 
> have the information they exchange
> with the CDN be confidential from other actors on the network. 

Agreed. I should have stated that there cannot be full end-to-end 
confidentiality.

> Consider, for instance, a photo

If random people includes the employees of CDN's (which could be anyone), 
then arguably the images should be stored in the CDN encrypted and be 
decrypted client-side with a key exchanged via another channel than the 
CDN. There is nothing that would prevent this from happening, although I am 
not aware of any browser implementing something like that.

But that is another topic. I hope I've answered your questions.

Best,
Michiel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 May 2020 12:12:04 -0700

> intended for static assets only. There is no value add in terms of

I think you're drawing a distinction which is not present in the technology.

Consider a Web application which has an origin server at www.example.com
and also hosts static assets including JS hosted ad example.cdn.example.net.
Even if the SASL exchange only goes between the browser and www.example.com,
because the JS gets loaded into www.example.com's origin, the CDN has
the ability to initiate its own requests to www.example.com's origin.

> If random people includes the employees of CDN's (which could be anyone),

Well, this could just as well apply to the employees of the origin site or
of the hosting
provider the origin site resides on. I appreciate that it's not very
satisfying but
the state of the Web ecosystem now is that many sites just rely on a pile of
different third parties that have potential access to your data and you have
to trust those as well. CDNs are just one such entity.

-Ekr

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 May 2020 20:26:25 +0000

> intents and purposes - even if some data is fetched once in a while from

i don't think your attempt to define CDN is relevant. the companies selling 
things under that umbrella are either leading or following the market, rather 
than consulting a dictionary to find our what business they are in. see here:

https://www.fastly.com/edge-cloud-platform

as far as i know all players in the CDN market offer similar services, except 
perhaps a commercial publication services provider whose primary liability 
shield comes from saying that they are "just a proxy" and that they don't host 
anything. if so that can be expected to change, because "content" is no longer 
primarily static or passive and that trend will accelerate.

whether it's done with docker images or python applets doesn't matter. the 
nature of content has changed, and the nature of content delivery networks has 
changed with it. no protocol or platform or business which refuses or ignores 
this change will make a new world-line. this is the future we're in. http 
authentication will have to account for this, but whether that happens inside 
the IETF or outside in the market is a choice this WG can still make.

-- 
Paul

---

From: Michiel Leenaars <[email-masked]>
Date: Fri, 15 May 2020 10:13:38 +0200

Hi Paul,

(@all: I moved this into a separate thread, as a newcomer to this 
particular list I do not know is appropriate, but I do not think it is 
useful to continue diluting the responses to the original thread which had 
an actual action to them. And I apologise for diverting your attention from 
more important discussions, and for the length of my response to follow. 
Feel free to ignore, or to contact me directly should you wish to discuss 
further) 

> than consulting a dictionary to find our what business they are 
> in.

I certainly agree that market actors will gladly use and abuse any 
technical term as marketing terminology, no matter if it makes absolutely 
no sense or is even an outright lie. I have seen cable companies in our 
part of the planet deliver so called 'ADSL' services to consumers with a 
straight face, because 'their marketing department said that people 
associated that with fast internet'. The inability to make certificate 
providers see that a logo 'protected by SSL' is inadequate 'because people 
do not understand what TLS means' goes in the same direction.

I agree of course also that all relevant use cases, such as 
container-orchestration systems, need to be taken into account. This 
belongs back in the original thread.

That does not preclude us from having a working definition of different 
roles we see in the landscape. The word 'delivery' in CDN is rather key 
here, anything more than delivering is a fundamental change of role. I 
certainly do not claim the authoritity to write the ultimate definition of 
what a CDN actually is or is not, but having a temporary working definition 
helps to subsequently distinguish passive roles (i.e. a bit bucket for high 
volume assets one can fully replace even client side, as browser plugins 
like DecentralEyes prove) from actual active nodes at the edge which 'own' 
or 'originate' unique elements and processes present nowhere else (for 
which this is fundamentally not possible). 

The passive component is instantly exchangeable and thus tolerated inside a 
trusted computing base as long as that complies with the required level of 
security and privacy, but for sure it can also be easily removed or 
instantly swapped for use cases that are different - e.g. by a local or 
external proxy that caches the content before it reaches the CDN a second 
time. It is not fundamentally necessary to deploy CDNs either, and I 
personally avoid doing so. The active end point cannot be placed outside of 
the trusted computing base in any way, it does not have the mere role of 
delivery but is a data source or service component which is unique for the 
given situation. By virtue of that, use of such a service does leak 
information about the user base of a service to a another party. 

That is a meaningful and fundamental distinction, for which I am obviously 
happy to mentally link or retrofit into to any official definition you can 
point me to rather than me trying to crudely define it myself. Correct 
terminology matters a great deal, because it provides the linguistic 
surgery tools of our thinking. The abstract distinction between the two 
different roles is what matters to me.

To illustrate, this is perhaps in part analogous to how traditional postal 
companies deliver mail which may or may not have a sealed envelope around 
it (*), versus fulfillment companies which actually do personalised mass 
mail merges and print and compile those sealed envelopes based on full 
access to their content as well. All postal companies offer fulfillment 
services, and all fulfillment services get your mail to some delivery 
company - which may be a traditional postal service or an alternative 
network of smaller delivery companies (or even a postal delivery robot as 
we saw recently). 

(*) envelopes are not always closed and postal service deliver unprotected 
postcards and print too, of course, and with enough equipment letters can 
be looked into without opening them.

If you use such a combined service, the end result is the same whichever 
operator you use. Economically, on the outside when looking at all of them 
as 'one stop' service providers it is indeed a group of actors delivering a 
similar set of services. 

But of course, a significant part of regular mail is not done through 
fulfillment. If I (or the tax office) want to send you a confidential 
letter with say access credentials, we write or print a letter ourselves 
and carefully seal a scan-proof envelope, and just use the delivery 
channel. I have no need to use a third party fulfillment service, and it 
would be unwise in terms of operational security as it vastly increases the 
attack surface. Delivering traditional mail with a sealed envelope is the 
core service which is only available from the postal company and its 
competitors in the delivery realm. This does not require a full transfer of 
trust, the delivery company does not per se have the sender nor the 
contents of the mail delivered - as long as there are enough stamps and the 
envelope is adequately sealed. I can easily replace the delivery company 
with say a courier, or deliver it myself if I hire people. 

Fulfillment (like edge computing) is a different role from delivery, as the 
content or service delived by the edge node (like the postal piece) would 
just not exist. It is outsourcing core functionality. My reason to reply to 
the original thread was that the traditional CDN role can take place fully 
without authentication (even by pushing it to another subdomain), and 
therefore is not that relevant to consider. The edge compute case is 
indistinguishable from the cloud provider case, which is fully in scope - 
but I believe that has been taken into account and should not be an issue. 

As mentioned above, apologies for the lenghty reply. I am happy to continue 
this argument offline, since it sparked off a remark made by me. But we all 
have better and more urgent things to do. I wanted to clarify since asked, 
and hope there is nothing controversial in my reply that makes it necessary 
to continues this thread.

Have a great day,
Michiel

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 May 2020 06:11:10 -0700

On Fri, May 15, 2020 at 1:17 AM Michiel Leenaars <[email-masked]>
wrote:

> without authentication (even by pushing it to another subdomain),

I'm not going to get involved in a definitional argument here about what
a CDN is, but in the Web security model, the role of hosting static assets
generally cannot be done without authentication. The reason for this is
that those assets impact the semantics of the web page into which they
are loaded.

Specifically: When JS modules are loaded into a page using
a <script> tag they become part of the context of the page and have the
same privileges as if they were loaded from the origin server. If these
are not authenticated there are trivial attacks. There are other resource
types that are more "static" from the Web's perspective (images
for instance) but these also can be used for more subtle attacks.

-Ekr