[http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-httpauth-mutual-10: No Objection

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-httpauth-mutual/



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

= Section 1 =

I agree with Terry that the introduction would benefit from an edit
pass.

= Section 2.3 =

"The server MAY have thrown out the corresponding session from the
      session table."
    
This seems like an inappropriate use of normative MAY, as it is
describing behavior in the past. Either "MAY throw out" or "may have
thrown out" would be appropriate.

"Under the
   appropriate settings and implementations, most of the requests to
   resources are expected to meet both criteria, and thus only one
   round-trip of request/response will be required."

This statement seems to presume much wider deployment than I would
anticipate for this experiment. If I understand correctly, you would need
mutual auth implemented by a sufficient proportion of servers to justify
providing a knob in a browser that allows the user to indicate that he
wants to send a key exchange in the first request to sites that have
required mutual auth in the past. Is that what is meant by "settings"? If
so, I think this either requires more explanation about the circumstances
under which "most" requests can be reduced to 1 RT, or this statement
needs to be qualified at a level below "most."

= Section 4.1 =

			"user-unknown: this is a special case of auth-
                     failed, suggesting that the provided user name is
                     invalid.  The use of this parameter is
                     NOT RECOMMENDED due to security implications,
                     except for special-purpose applications where it
                     makes sense."

The exception case here seems underspecified. It's not clear what kind of
"special-purpose" application would warrant this in light of the
information it potentially leaks and the fact that such applications, if
they do not have scripting capabilities, do not require transport
security when using this protocol according to Section 7.

I have the same question about invalid-credential.