Subject: draft-ietf-httpbis-bcp56bis-11, "4.12. Client Authentication"

From: Julian Reschke <[email-masked]>
Date: Mon, 5 Apr 2021 18:39:17 +0200

"...The Basic authentication scheme [RFC7617] MUST NOT be used unless
the underlying transport is authenticated, integrity-protected and
confidential (e.g., as provided the "HTTPS" URI scheme, or another using
TLS). ..."

This actually modifies a SHOULD-level requirement from RFC 7617 -- is
that really the right thing to do here?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2021 17:30:52 +1000

For the scope of this specification (recommendations to IETF-defined standards that use HTTP), I think it is. 

What do others think?

> On 6 Apr 2021, at 2:39 am, Julian Reschke <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 19 Apr 2021 17:37:52 +1000

I agree with Mark; the narrow focus here allows us to make stronger recommendations.

Note also that the current text also prohibits Digest with MD5, but says nothing about SHA1.  Preimage resistance in SHA-256 is also weak for low entropy inputs, like passwords.  Even with something like PBKDF2 or Argon2 (which is not specified anywhere for use with these schemes) sending a hash in the clear is unwise.

I'd be happier prohibiting both Basic AND Digest here.  It is, after all, only for IETF-defined works.  Well, and for anyone who is sensible enough to view our advice to ourselves as being well-considered enough to follow, which is a non-trivial number of people.

IOW, strike >>, or the chosen hash algorithm is not "MD5"<<