Subject: [sipcore] Barry Leiba's Yes on draft-ietf-sipcore-digest-scheme-10: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Thu, 17 Oct 2019 14:01:07 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-sipcore-digest-scheme-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for doing this.  I have some editorial comments, and one substantive
suggestion that we state more strongly here what's said in 7616: that MD5 is
NOT RECOMMENDED.

— Abstract —
   to replace the broken MD5 algorithm, which might be used
   for backward compatibility reasons only.

I suggest that the “, which…” part isn’t useful in the Abstract, and should be
removed.  It's said in the Security Considerations, and we don't need to lead
with it.

— Section 2 —

   It replaces the reference to [RFC2617] with a reference to [RFC7616]
   in [RFC3261], and describes the modifications to the usage of the
   Digest mechanism in [RFC3261] resulting from that reference update.

I had a hard time with this sentence.  Let me suggest this:

NEW
   It replaces the reference used in [RFC3261] for Digest Access
   Authentication, substituting [RFC7616] for the obsolete [RFC2617],
   and describes the modifications to the usage of the Digest
   mechanism in [RFC3261] resulting from that reference update.
END

— Section 2.1 —

   The IANA
   registry named "HTTP Digest Hash Algorithms" specifies the algorithms
   that correspond to 'algorithm' values.

That is not the name of the registry; it’s “Hash Algorithms for HTTP Digest
Authentication” (which you correctly cite in other sections).

— Section 2.2 —

   If the MD5 algorithm is used to
   calculate the digest, then the digest will be represented as 32
   hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal
   characters.

As we’re phasing out MD5, I suggest not using it as an example.  Just:

NEW
   If the SHA-256 or SHA-512/256 algorithm is used to
   calculate the digest, then the digest will be represented as 64
   hexadecimal characters.
END

— Section 2.4 —

   If the UAC cannot respond to any of the challenges in the response,
   then it SHOULD abandon attempts to send the request, e.g. if the UAC
   does not have credentials or has stale credentials for any of the
   realms, unless a local policy dictates otherwise.

This is really hard to parse; I think your “e.g.” clause gets in the way.  I
suggest this:

NEW
   If the UAC cannot respond to any of the challenges in the response,
   then it SHOULD abandon attempts to send the request unless a local
   policy dictates otherwise.  For example, if the UAC does not have
   credentials or has stale credentials for any of the realms, the UAC
   will abandon the request.
END

— Section 2.5 —

   When the forking proxy places multiple WWW-Authenticate and Proxy-
   Authenticate header fields from one received response into the single
   response it MUST maintain the order of these header fields.  The
   ordering of values received from proxies relative to values received
   from other proxies is not significant.

I can’t make sense of this; can you try rephrasing it?  There’s one response
and a single response.  I don’t follow.  There’s values received from proxies
and values received from other proxies.  What’s the difference between
“proxies” and “other proxies”?  I don’t follow.

— Section 3 —

   This specification adds new secure algorithms to be used with the
   Digest mechanism to authenticate users, but leaves the broken MD5
   algorithm for backward compatibility.

I recommend being stronger about this by using text from 7616:

NEW
   This specification adds new secure algorithms to be used with the
   Digest mechanism to authenticate users. The broken MD5 algorithm
   remains only for backward compatibility with [RFC2617], but its use is
   NOT RECOMMENDED.
END

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 17 Oct 2019 17:57:35 -0400

Hi Barry,

Thanks for the detailed review, comments, and suggested text.
I like all of your suggestions and will incorporate these into the next
version of the document.

With regards to text in section 2.5, how about the following:

"When the forking proxy places multiple WWW-Authenticate and
Proxy-Authenticate header
fields received from one downstream proxy into a single response, it MUST
maintain
the order of these header fields.  The ordering of values received from
different downstream
proxies is not significant."

Regards,
 Rifaat

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Oct 2019 21:26:19 -0400

> I like all of your suggestions and will incorporate these into the next version of the document.

Thanks!

> "When the forking proxy places multiple WWW-Authenticate and Proxy-Authenticate header
> fields received from one downstream proxy into a single response, it MUST maintain
> the order of these header fields.  The ordering of values received from different downstream

Perfect, Rifaat: I understand that just fine, and thanks for re-wording.

Barry