Re: Updating RFC7616 in BCP56bis

> On Aug 1, 2021, at 11:12 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Drawing everyone's attention to <https://github.com/httpwg/http-extensions/issues/1582>:
> 
> The security directorate review of BCP56bis brought up an issue:  RFC7616 already places a SHOULD requirement on the use of a secure channel when Digest HTTP authentication is used. The current language in BCP56bis strengthens that to a MUST, but also weakens it to allowing an insecure channel if the hash algorithm is not "md5".
> 
> I think it's uncontroversial that the requirement in BCP56bis should be at least as strong as in 7617. I suspect there's also a lot of support for strengthening it, in two ways:
> 
> * Changing the SHOULD to a MUST
> * Deprecating the md5 hash algorithm
> 
> However, those are both things that are not specific to HTTP APIs (the subject of BCP56bis). 
> 
> So, the "correct" way forward is to remove this text completely and make a *very* small document that updates 7616 with the two bullet points above. 
> 
> That seems like a lot of extra effort for little practical return. So the question is whether we can do those things in this document (for all uses of 7616, not just HTTP APIs), thereby updating 7616 with bcp56bis.
> 
> Does anyone object to that plan? If so, we can fall back to the "correct" way (as outlined above).

This is not how a BCP is supposed to be written. It is fine to say that
folks configuring their services should avoid certain features if possible,
for whatever reason. It is wrong to say that a BCP updates or otherwise
obsoletes portions of a standards track protocol, because BCPs are not
subject to the same standardization reviews by implementers.

Like most HTTP developers, I don't believe BCPs have any relevance to
implementations. Removing MD5 because it's "not secure" is particularly
idiotic because that is a deployed feature which exists for the sole
purpose of exchanging an MD5 hash instead of a password. It's better
than the alternative. Recommending that it not be used, for good reasons,
is fine.

Regardless, we can't remove it from our implementations because that
would break interop with deployed systems that contain data which
belongs to users, not us. Those systems cannot be updated by us (they
belong to someone else) and won't be updated by the original developers
(they are long gone).

This is just bad advice for implementations of the protocol.
But saying the feature shouldn't be used by new deployments is fine.

If you want to say a feature shouldn't be used, say that in a BCP.
If you want to deprecate or forbid the protocol bits, that would
have to be in a standards track protocol update.

....Roy

Received on Monday, 2 August 2021 17:25:34 UTC