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

Hi Barry,

thanks for the feedback; I'm tracking the changes in 
<https://github.com/httpwg/http-extensions/issues/130>.


On 2015-12-31 07:38, Barry Leiba wrote:
> 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.

Indeed.

> -- 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".

<https://github.com/httpwg/http-extensions/commit/f4d972afc73257940390834cf566aac2a898a8ed>

> -- 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...."

<https://github.com/httpwg/http-extensions/commit/ba8920eac4d40252fe43b0d4511c18ebb825c9fa>

>     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...."

Agreed. I haven't changed that yet as it affects normative language but 
I will unless somebody wants to defend it soonish.

>     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".

That would replace

   clear         = %x63.6C.65.61.72; "clear", case-sensitive

with

   clear         = %s"clear"; case-sensitive

(and add a dependency to the ABNF extension).

I'm not super-excited about this notation, and it seems we would be the 
first ones to actually use it (implying lack of validation tools etc).

What do others think?

>     alt-authority = quoted-string ; containing [ uri-host ] ":" port
>
> This seems poor.   Why not this?:
>
> NEW
>     alt-authority = DQUOTE [ uri-host ] ":" port DQUOTE
> END

In HTTP specs, we don't like to use DQUOTE unless the thing being quoted 
used quoted-string syntax.

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

That wasn't a typo, but as you are at least the second one complaining I 
changed it in 
<https://github.com/httpwg/http-extensions/commit/cc7946abe12ce8c4cd3db1bd1f8a7c2e71eb9943>.

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

I believe the intent was that new values do not imply changing the 
parser (which would be implied by changing the ABNF), but simply would 
allow new values here.

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

I have no opinion on this. More feedback appreciated.

> -- 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." ?

That's an interesting proposal. What do the client implementers think?

Best regards, Julian

Received on Thursday, 31 December 2015 14:30:09 UTC