Re: Working Group Last Call: draft-ietf-httpbis-http2-encryption-04

Hi there,

see below for mostly editorial feedback (in document order)...

Best regards, Julian

-- snip --
1.  Introduction

    This document describes a use of HTTP Alternative Services
    [I-D.ietf-httpbis-alt-svc] to decouple the URI scheme from the use
    and configuration of underlying encryption, allowing a "http" URI
    [RFC7230] to be accessed using TLS [RFC5246] opportunistically.

NIT: expand "TLS" on first use (the mention in the abstract IMHO does 
not count)

    Opportunistic Security [RFC7435] does not provide the same guarantees
    as using TLS with "https" URIs; it is vulnerable to active attacks,
    and does not change the security context of the connection.
    Normally, users will not be able to tell that it is in use (i.e.,
    there will be no "lock icon").

    By its nature, this technique is vulnerable to active attacks.  A
    mechanism for partially mitigating them is described in Section 5.

NIT: the first sentence just repeats something already stated in the 
paragraph before.


3.  Server Authentication

    As defined in that specification, one way of establishing this is
    using a TLS-based protocol with the certificate checks defined in
    [RFC2818].  Clients MAY impose additional criteria for establishing
    reasonable assurances.

NIT: second sentence repeats normative language from alt-svc. Just use 
prose to point that out instead.

    When the client has a valid http-opportunistic response for an
    origin, it MAY consider there to be reasonable assurances when:

Q: I assume that refers to the response to a GET on the well-known URI? 
(the example supports that, but then, it's just an example...)

4.  Interaction with "https" URIs

    Since "https" URIs rely on server authentication, a connection that
    is initially created for "http" URIs without authenticating the
    server cannot be used for "https" URIs until the server certificate
    is successfully authenticated.  Section 3.1 of [RFC2818] describes
    the basic mechanism, though the authentication considerations in
    [I-D.ietf-httpbis-alt-svc] also apply.

NIT: make that reference more specific.

    Connections that are established without any means of server
    authentication (for instance, the purely anonymous TLS cipher
    suites), cannot be used for "https" URIs.

NIT: comma seems to be misplaced.

5.1.  Opportunistic Commitment

    An origin can reduce the risk of attacks on opportunistically secured
    connections by committing to provide an secured, authenticated

s/an/a/

    alternative service.  This is done by including the optional "commit"
    member in the http-opportunistic well-known resource (see Section 6).
    This feature is optional due to the requirement for server
    authentication and the potential risk entailed (see Section 5.3).

s/optional/OPTIONAL/?

6.  The "http-opportunistic" well-known URI

    o  The client has obtained a 200 (OK) response for the well-known URI
       from the origin, or refreshed one in cache [RFC7234], and
    o  That response has the media type "application/json", and

Q: maybe this should use a custom media type.

    o  That response's payload, when parsed as JSON [RFC7159], contains
       an object as the root.
    o  The "origins" member of the root object has a value of an array of
       strings, one of which is a case-insensitive character-for-
       character match for the origin in question, serialised into
       Unicode as per [RFC6454], Section 6.1, and

Q: list truncated?

    This specification defines one additional, optional member of the
    root object, "commit" in Section 5.  Unrecognised members MUST be
    ignored.


7.  IANA Considerations

    This specification registers a Well-known URI [RFC5785]:

    o  URI Suffix: http-opportunistic
    o  Change Controller: IETF
    o  Specification Document(s): [this specification]

NIT: make reference more specific.


8.  Security Considerations

8.2.  Downgrade Attacks

    A downgrade attack against the negotiation for TLS is possible.  With
    commitment Section 5, this is limited to occasions where clients have

NIT: weird section link.

    no prior information (see Section 8.3), or when persisted commitments
    have expired.


8.3.  Privacy Considerations

    Cached alternative services can be used to track clients over time;
    e.g., using a user-specific hostname.  Clearing the cache reduces the
    ability of servers to track clients; therefore clients MUST clear
    cached alternative service information when clearing other origin-
    based state (i.e., cookies).

Q: is this a new normative requirement, or does it just restate what 
alt-svc says?

8.4.  Confusion Regarding Request Scheme

    Many existing HTTP/1.1 implementations use the presence or absence of
    TLS in the stack to determine whether requests are for "http" or
    "https" resources.  This is necessary in many cases because the most
    common form of an HTTP/1.1 request does not carry an explicit
    indication of the URI scheme.

    HTTP/1.1 MUST NOT be used for opportunistically secured requests.

    Some HTTP/1.1 implementations use ambient signals to determine if a
    request is for an "https" resource.  For example, implementations
    might look for TLS on the stack or a port number of 443.  An
    implementation that supports opportunistically secured requests
    SHOULD suppress these signals if there is any potential for
    confusion.

This section looks a bit unstructured. Paragraph 3 seems to restate what 
Paragraph 1 already says.

Paragraph 2 IMHO needs to be clearer: it refers to the protocol used to 
perform the opp-sec-ed request, not the original one, right? FWIW, I 
still think that the reasoning for this is weak (an HTTP/2 server stack 
might suffer from the same problem), and thus should either be relaxed, 
or better explained.

Received on Wednesday, 30 March 2016 13:19:51 UTC