W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: draft-richsalz-httpbis-https-downgrade-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 13 Mar 2019 11:58:53 +1100
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Rich Salz <rsalz@akamai.com>, Brian Sniffen <bsniffen@akamai.com>, "Bishop, Mike" <mbishop@akamai.com>, Erik Nygren - Work <nygren@akamai.com>
Message-Id: <743E9A7F-47A1-4CD9-B4AC-E31841ABBF9A@mnot.net>
To: Erik Nygren <erik+ietf@nygren.org>
Hey Erik et al,

Thanks for publishing this.

I know there's been some discussion about this in the past -- especially about a CDN-to-browser signal. As I recollect, that got stuck on how to meaningfully present that to the user without complicating the security signals from the browser.

I agree with Alessandro's concern about hobbling the protocol in these situations; it seems like a very artificial kind of pain.

I've been wondering for a little while about an adjacent concern -- that origin configuration for CDNs is often ad hoc, with things like SNI and Host headers getting in the way. If we could define a profile (or profiles) of a CDN origin that is easy to configure and meets the basic use cases as well as security requirements, we might be able to encourage people towards a common goal; i.e., a carrot, rather than a stick. It might also be interesting to consider something like a dedicated origin configuration URI scheme. Are those sorts of things interesting to you?

*chair hat on* Would you like some time to talk about this in Prague? The agenda is getting a bit tight, but I think we could squeeze you in.

Cheers,


> On 12 Mar 2019, at 1:52 pm, Erik Nygren <erik+ietf@nygren.org> wrote:
> 
> This draft on "Best practices for TLS Downgrade" is intended as a starting point for discussion on a topic that many people would like to ignore but which introduces risk into the ecosystem.  We'd like to bring some co-authors onboard (especially from other CDNs and browsers/OSes) and incorporate lessons learned elsewhere as well.  While "don't downgrade!" is almost always the "correct" solution, it isn't always viable.  Getting alignment on best practices may at least help provide better visibility into the associated risks, such as by exposing to clients when an insecure downgrade to cleartext is happening and by stripping request data most likely leak private information..
> 
> Feedback and suggestions for additions are most welcome, and we're also interested in discussing more in Prague.
> 
>     Erik
>  
> 
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Mar 11, 2019 at 4:08 PM
> Subject: I-D Action: draft-richsalz-httpbis-https-downgrade-00.txt
> To: <i-d-announce@ietf.org>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Best practices for TLS Downgrade
>         Authors         : Brian Sniffen
>                           Mike Bishop
>                           Erik Nygren
>                           Rich Salz
>         Filename        : draft-richsalz-httpbis-https-downgrade-00.txt
>         Pages           : 8
>         Date            : 2019-03-11
> 
> Abstract:
>    Content providers delivering content via CDNs will sometimes deliver
>    content over HTTPS (or both HTTPS and HTTP) but configure the CDN to
>    pull from the origin over cleartext and unauthenticated HTTP.  From
>    the perspective of a client, it appears that their requests and
>    associated responses are delivered over HTTPS, while in reality their
>    requests are being sent across the network in-the-clear and responses
>    are delivered unauthenticated.  This exposes user request data to
>    pervasive monitoring [RFC7258]; it also means response data may be
>    tampered with by active adversaries.  Terminating TLS connections on
>    a load balancer and contacting a backend over cleartext has long been
>    common within data centers, but doing this TLS termination and
>    downgrade to HTTP at a CDN introduces additional risk when the
>    unprotected traffic is sent over the general Internet, sometimes
>    across national boundaries.
> 
>    While it would be nice to say "never do this," customer demand,
>    content provider use-cases, and market forces today make it
>    impossible for CDNs to not support downgrade.  However, following a
>    set of best practices can provide visibility into when this is
>    happening and can reduce some of the risks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richsalz-httpbis-https-downgrade/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-richsalz-httpbis-https-downgrade-00
> https://datatracker.ietf.org/doc/html/draft-richsalz-httpbis-https-downgrade-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 13 March 2019 00:59:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 March 2019 00:59:30 UTC