Subject: Secdir last call review of draft-ietf-httpbis-bcp56bis-12

From: Joseph Salowey via Datatracker <[email-masked]>
Date: Sun, 25 Jul 2021 10:30:26 -0700

Reviewer: Joseph Salowey
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is has issues

The document is well written and very useful.  There are a few issues I think
need to be addressed.

Major Issues:

+ I had trouble with section 4.12 Client Authentication which states:

"Applications can use HTTP authentication Section 11 of
[I-D.ietf-httpbis-semantics] to identify clients. 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). The Digest scheme [RFC7616] MUST NOT
be used unless the underlying transport is similarly secure, or the chosen hash
algorithm is not "MD5"."

I'm not sure what the "or chosen hash algorithm is not "MD5" is meant to say. 
What I think the document should say is:

The Digest scheme [RFC7616] MUST NOT be used unless the underlying transport is
similarly secure. The "MD5" digest algorithm MUST NOT be used.

+ There is a security consideration that I think the document should cover. 
Many HTTP based protocols make heavy use of bearer tokens, such as session
cookies, for authentication and authorization purposes.  This means that an
attacker that can eavesdrop on HTTP communications can often escalate their
privilege to perform operations on resources.   I think you could add this to
the security considerations:

" Section 4.4.2 requires support for 'https' URLs, and discourages the use of
'http' URLs, to provide authentication, integrity and confidentiality, as well
as mitigate pervasive monitoring attacks.  Many HTTP based protocols make heavy
use of bearer tokens, such as session cookies, for authentication and
authorization purposes.  This means that an attacker that can eavesdrop on HTTP
communications can often escalate their privilege to perform operations on
resources. "

Minor Issues:

+ Section 4.5.1 - This could be a good place to mention RFC-8470 on TLS 1.3
early data which can also be a source of GET request replay

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Jul 2021 12:43:44 +1000

Thanks for the review. I've opened an issue to track it:
  https://github.com/httpwg/http-extensions/issues/1582

Responses below.

> On 26 Jul 2021, at 3:30 am, Joseph Salowey via Datatracker <[email-masked]> wrote:

Hmm. I forgot that RFC7616 has a pre-existing requirement in Section 5.1:

> If Digest Authentication is being used, it SHOULD be over a secure channel like HTTPS [RFC2818].

Are we saying that that SHOULD is really a MUST for all uses of HTTP, or just those in scope for this document? Likewise for the effective deprecation of md5.

If so, perhaps the easiest thing to do would be to state that clearly; e.g.,

"""
[RFC7616] Section 5.1 recommends that the Digest scheme be used over a secure channel like HTTPS. This document strengthens that recommendation to MUST, and deprecates the md5 hash algorithm in the Digest scheme.
"""

... and listing 7616 as being updated by this document.

Thoughts?

> communications can often escalate their privilege to perform operations on

See https://github.com/httpwg/http-extensions/commit/fe3f298e4d60514306e391398cc870abaedd8bf9

> early data which can also be a source of GET request replay

See https://github.com/httpwg/http-extensions/commit/b03c376179e278deb3d994eac152c6a131702840

Cheers,

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