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

Hi, Julian, and thanks for the quick reply on a holiday extended weekend.

Only on the items for which I have further comment...

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

I didn't see a response to this.  I expect we might see comments about
this from the Security Directorate or ADs.

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

It's a small thing, and it's up to the working group, of course.  I
would prefer the change, because (1) I think it makes it more
readable, and (2) we have put 7405 on the Standards Track, so we
should use it.  It wouldn't be a bad thing for us to break ground on
it.

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

I don't understand that.  I particularly don't understand why we'd
prefer to specify the content of the string only in the comment, when
it's perfectly easy and clear to put it into the ABNF, and have it be
verifiable.

I'm generally not a fan of putting substantive ABNF information into
ABNF comments, and prefer to reserve that sort of thing for cases when
it's *not* reasonable to do otherwise.

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

Thanks.  To clarify, it could go either of these ways, and they're equally good:

- "The field value consists either of a list of values, each of which
indicates one alternative service"

- "The field value consists either of a list of values, each
indicating one alternative service"

...but "each of which indicating" doesn't work.

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

Three questions here, really, bundled into one:

1. Why "1DIGIT", rather than "DIGIT"?  Purely editorial, of course...
what's the benefit of using the "1"?

2. Why does "persist" have to be digits at all?  I'm generally not a
fan of unnecessarily coding concepts into numbers, rather than using
short words.  If it's necessary (or useful), that's fine.  I don't see
why here.

3. Do you expect a lot of additional values?  Clearly not, if you're
limiting it to ten possible ones.  In that case, as above, I prefer
when the ABNF is specific about it.  Consider, for example, RFC 2045's
definition of Content-Transfer-Encoding (in Section 6.1):

     encoding := "Content-Transfer-Encoding" ":" mechanism

     mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token

Here, "mechanism" could have just been defined as << ietf-token /
x-token >>, but enumerating the existing values in the ABNF is useful.
And the fact is that "persist=2" is not currently valid.

There's also, I suppose, the question of whether you'd want
"persist=2" to be considered acceptable (and ignored), and "persist=a"
to cause the whole field to be rejected as invalid.  If so, maybe
this, to specify what's valid now and how to extend?:

   persist = "1" / persist-ext
   persist-ext = DIGIT ; extensions can be specified in future

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

There was, of course, nothing actionable in my comment, so let me add
something here: Because I think there's little value in telling
clients to be more strict about authentication when switching from a
system port to a user port, I think it could give a false sense of
security if implementors do that... particularly if they think they
can be lax about authentication on system ports, because only trusted
software can listen on system ports.  We should be careful about
giving that impression.

Yes, more feedback from others, please.

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

And I'm leaving this in the message just to encourage further
discussion as people <strike>sober up</strike> return from their new
year's celebrations.

Barry

Received on Thursday, 31 December 2015 16:39:23 UTC