Subject: [http-auth] Alexey Melnikov's No Record on draft-ietf-httpauth-mutual-10: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 02 Nov 2016 12:20:46 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-httpauth-mutual-10: No Record

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

I only reviewed sections 1-6, but I am sending my comments so far:

In Section 1, next to the last paragraph:

   The Mutual authentication protocol proposed in this document is a
   strong cryptographic solution for password authentications.  It
   mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you
forget to delete this instance?

3.2.  Values

   The parameter values contained in challenge/credentials MUST be
   parsed strictly conforming to the HTTP semantics (especially un-
   quoting of the string parameter values).  In this protocol, those
   values are further categorized into the following value types: tokens
   (bare-token and extensive-token), string, integer, hex-fixed-number,
   and base64-fixed-number.

   For clarity, implementations are RECOMMENDED to use the canonical
   representations specified in the following subsections for sending
   values.  Recipients SHOULD accept both quoted and unquoted
   representations interchangeably as specified in HTTP.

I think the last SHOULD must be a MUST, because clients that generate
these values
might be using libraries that automatically quote values. So this is
really not
under sender's control.

3.2.2.  Strings

   All character strings MUST be encoded to octet strings using the
   UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
   [ISO.10646-1.1993].

This is the same as Unicode 1.1. Unicode now released version 9.0! I
suggest you use a Unicode reference.

In 3.2.3:

   The numbers represented as base64-fixed-number SHALL be generated as
   follows: first, the number is converted to a big-endian radix-256
   binary representation as an octet string.  The length of the
   representation is determined in the same way as mentioned above.
   Then, the string is encoded using the Base 64 encoding [RFC4648]

I assume you meant Section 4 alphabet and not Section 5 alphabet from
this
RFC. Please add section reference to the above.

   without any spaces and newlines.  Implementations decoding base64-
   fixed-number SHOULD reject any input data with invalid characters,
   excess/insufficient padding, or non-canonical pad bits (See Sections
   3.1 to 3.5 of [RFC4648]).