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

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"<<

On Mon, Apr 19, 2021, at 17:30, Mark Nottingham wrote:
> 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 <julian.reschke@gmx.de> wrote:
> > 
> > "...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
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 

Received on Monday, 19 April 2021 07:38:27 UTC