%% You should probably cite draft-richsalz-httpbis-https-downgrade-02 instead of this revision.
@techreport{richsalz-httpbis-https-downgrade-00,
    number =    {draft-richsalz-httpbis-https-downgrade-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-richsalz-httpbis-https-downgrade/00/},
    author =    {Brian Sniffen and Mike Bishop and Erik Nygren and Rich Salz},
    title =     {{Best practices for TLS Downgrade}},
    pagetotal = 8,
    year =      2019,
    month =     mar,
    day =       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.},
}