Re: draft-ietf-httpapi-privacy-02 early Httpdir review

On Sun, Jul 27, 2025, at 02:50, Mark Nottingham via Datatracker wrote:
> ## Issues
>
> - "This document describes actions API servers and clients should take
>    in order to safeguard credentials. These recommendations are not
>    directed at resources where no authentication is used."
>
> Is that the only reason we use HTTPS? Considering RFC7258, I'd say we have many
> reasons for encrypting HTTP APIs on the Internet and even in "private" networks
> (cue: slide showing Google's infrastructure circa 2013). It's hard to see why
> this document doesn't have a stronger requirement for encryption in general, as
> well as multiple motivations for its use in APIs. If there's been discussion of
> that, the reasoning should be included here.

I raised a similar issue: https://github.com/ietf-wg-httpapi/httpapi-privacy/issues/7

I was not convinced by the response, but didn't make a point of pursuing the argument further at the time.  For instance, Mike said:

> There are too many scenarios, including testing, where clear-text will still be used.

The draft uses SHOULD an awful lot when it comes to security requirements that - in any other context - are bare minimums that would use MUST.

I remain firmly of the view that there are no situations where cleartext HTTP is the right choice.  For testing, which is a common complaint, there are ways to configure trust anchors or admit self-signed certificates for testing purposes.  That is far superior to cleartext.

Another issue is that the draft assumes that the client is configured with a domain name or cleartext http:// URI, not an https:// URI.  I think that's a mistake.  APIs generally start with a URI and insisting that this be https://whatever isn't so difficult.

If clients are given https:// URIs, the draft could recommend that no cleartext HTTP be used at all.

Overall, while this draft might be good advice for 2011, the baseline expectations are different now.

Received on Monday, 28 July 2025 05:06:19 UTC