Early Review of draft-ietf-httpapi-privacy-02
review-ietf-httpapi-privacy-02-secdir-early-huitema-2025-08-13-00

This short draft outlines the perils of sending authentication tokens
or cookies over unencrypted HTTP connections. The draft proposes a series
of mitigations that could be implemented in the server or in
the HTTP/HTTPS client.

The draft correctly points out that the real mitigations have to be
implemented in the client, because of MITM attacks. The attacker would
"accept" (or intercept) an HTTP connection from the client, obtain
the credentials, and then use them on an HTTPS connection to the server.
If we believe that, we should wonder how much to invest in the
server-based mitigations described in section 2 -- although the proposed
actions may indeed help educate users.

The client recommendations are reasonable: lookup HTTPS records,
support HSTS, don't send secure credentials over insecure channels,
and only use plain HTTP if expressly configured to do so.

Reading this draft left me wondering what exactly is pushing the
authors to write this draft now. Do we have statistics about
rampant transmission of credentials over insecure HTTP connections? Are
the authors motivated by some juicy anecdotes? Explaining such
motivations in simple terms would make the draft stronger.
Back in the early 90's, we insisted that users and applications "don't
send passwords in clear text over the Internet" -- and
"don't send security cookies over HTTP" is a variant of that. Why do
we need to repeat that same message now?