Re: #148: Reasonable Assurances and H2C

["Roy T. Fielding" <[e-mail]>]

> On Feb 19, 2016, at 6:16 PM, Mark Nottingham <[e-mail]> wrote:
> 
> I've created
>  https://github.com/httpwg/http-extensions/issues/148
> to track this.
> 
> I think removing h2c from the examples and clarifying the example as Kari explained (1 and 2 in the issue) are not controversial (verging on editorial).
> 
> The remaining question (3 in the issue) is whether we should firm up the definition of "reasonable assurances" to require another way of achieving that to be documented in an RFC that updates this one.
> 
> Mike B has already supported this approach; what do others think? 

FWIW, I think the entire section is nonsense.  Having the same https certificate
doesn't say anything about how many different authorities might be present on
a single server.  It only says the domain name is owned by the certificate holder.
There is no way for a client to know whether that means the alternative service
is valid for the whole origin or just a single resource within that origin.

Likewise, changing the port number means the destination is a different authority.
It may have the same owner, but it is still a different authority.

As such, I don't see how this section does anything to mitigate the attacks
described in changing-ports and host_security.  It certainly doesn't protect
against MITM attacks resulting in a persistent redirection.

I think it would be better to make more explicit requirements in the main section
that define the protocol and to ensure that the requirements are properly targeted
to specific types of implementations (like we did for RFC7230). Furthermore,
differentiate the requirements based on the nature of the original connection:

   If the original connection is not secured to a specific authority (e.g.,
   TLS was not negotiated and a secure connection established prior to receipt
   of the Alt-Svc header field), then

     [require that the alternative service use TLS (or equivalent) and provide
      a certificate valid for the original host]

     [explain that the (many) potential attacks are no worse than
      the existing lack of content and header field integrity]

   Otherwise,

     [do more, like require that the certificate used in the original connection
      be identical to that used by the alternative service, since anything less
      allows the authority to persist longer than the original cert validity.
      Yes, this requires caching the cert id along with the persisted alt-svc.]

     [explain that this limits potential attacks to what is already possible
      as within-origin attacks on an existing https connection.]

This will allow the security discussion to be more relevant to the existing
security conditions, and make it harder to persistently attack a service that
is already protected via https.

Yeah, I know… my comments are probably too big and too late.

....Roy