AD review of draft-ietf-httpbis-alt-svc-10

Some comments, none very serious.  Let's have a quick chat about the
non-editorial ones before I send out the last call request.  And thanks,
Mike Bishop, for the really good and helpful shepherd writeup.

-- Section 2.1 --

   Clients MUST NOT use alternative services with a host that is
   different than the origin's without strong server authentication;

Total nit: make it "different from", not "different than".

-- Section 2.4 --

   By their nature, alternative services are OPTIONAL: clients do not
   need to use them.  However, it is advantageous for clients to behave
   in a predictable way when they are used by servers (e.g., for load
   balancing).

The antecedent to the last "they" is unclear: it looks like it's "clients",
when it should be "alternative services".  Best to re-word, as "...in a
predictable way when alternative services are used by servers...."

   If a client becomes aware of multiple alternative services, it MAY
   choose the most suitable according to its own criteria (again,
   keeping security properties in mind).

I don't think this is a 2119 "MAY": what *else* can it do?  You have no
other guidance about which alternative alternative to pick, so....  I think
this should just say, "it chooses the most suitable...."

   Furthermore, if the connection to the alternative service fails or is
   unresponsive, the client MAY fall back to using the origin or another
   alternative service.  Note, however, that this could be the basis of
   a downgrade attack, thus losing any enhanced security properties of
   the alternative service.  If the connection to the alternative
   service does not negotiate the expected protocol (for example, ALPN
   fails to negotiate h2, or an Upgrade request to h2c is not accepted),
   the connection to the alternative service MUST be considered to have
   failed.

I don't understand how this stops a downgrade attack if the alternative
service has better security than the existing connection.  The attacker
prevents me from establishing the better security, so I consider the
alternative service to have failed and fall back to the existing
connection... and the attack has succeeded, blocking me from upgrading the
security.  No?

-- Section 3 --
Please consider using RFC 7405 for the ABNF for "clear".

   alt-authority = quoted-string ; containing [ uri-host ] ":" port

This seems poor.   Why not this?:

NEW
   alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE
END

   The field value consists either of a list of values, each of which
   indicating one alternative service, or the keyword "clear".

Typo: "indicates"

-- Section 3.1 --
For the persist ABNF, why 1DIGIT, and not just DIGIT?  Or, for that matter,
why not simply "1" ?  Other specifications might then add other values
using << persist =/ "2" >>, for example.

-- Section 9.1 --
The third paragraph assumes that system ports are inherently more secure
than user ports, and, as discussion during the development of RFC 6335
raised, that hasn't been the case for some time.  Many systems no longer
make a distinction, and no longet require root authority to listen on
system ports.

-- Section 9.4 --

   Clients concerned by the additional fingerprinting can choose to
   ignore alternative service advertisements.

Is there really any chance of this being exposed to users as an option?
Maybe it'd be good to add to this something like, "In particular, clients
configured for anonymous usage SHOULD NOT use alternative services." ?

--
Barry