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

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