Re: #148: Reasonable Assurances and H2C

> On Feb 26, 2016, at 1:11 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> On 27 Feb 2016, at 7:59 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>>> On Feb 19, 2016, at 6:16 PM, Mark Nottingham <mnot@mnot.net> 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).
> 
> Can you give a little more detail here?

Kind of too lazy at the moment to do a complete rewrite, but here is one example:

  This means that clients using an alternative service can change the host, port
  and protocol that they are using to fetch resources, but these changes MUST NOT
  be propagated to the application that is using HTTP; from that standpoint, the
  URI being accessed and all information derived from it (scheme, host, port) are
  the same as before.

would be IMO better written as

  The alternative service does not change an application's understanding of the
  origin of a given resource. A client using an alternative service MUST retain
  the original scheme, host, and port when referring to that resource even when
  it communicates with that resource via the alternative's protocol, host, and port.

and further on

  An ALTSVC frame from a server to a client on stream 0 indicates that the conveyed alternative
  service is associated with the origin contained in the Origin field of the frame. An association
  with an origin that the client does not consider authoritative for the current connection &MUST;
  be ignored.

would be better phrased as

  An ALTSVC frame from a server to a client on stream 0 indicates that the conveyed alternative
  service is associated with the origin contained in the Origin field of the frame.
  A client MUST ignore received ALTSVC frames that contain an Origin field value that
  is not authoritative for the current connection.

There are many, many more cases where MUST/SHOULD are used as statements of fact rather
than as a requirement on sender or recipient (or both).

>> 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]
> 
> I like the "secured to a specific authority" language, but...
> 
>>  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.]
> 
> That goes against pretty broad security practice; people don't want a server's key pair to leave a machine.

I don't follow.  Sure, the private key shouldn't be replicated across the network,
but certainly each TLS-terminating endpoint needs to be configured with a copy of
the same website certificate, somehow.  We don't have a separate certificate
for every server in a farm.

I think proof of such shared knowledge (or something equivalent) is the minimum
necessary to allow some other server to answer authoritatively to an https request.
I don't think matching on the strings within the certificate fields is sufficient.

OTOH, my suggestion won't help with MiTM TLS, anyhow, since the client being
redirected only sees the bad M's certificate.  Bah, humbug.

Okay, maybe just require the alternative service to be secured with the original
authority and just punt on the remaining security issues as non-solved.

....Roy

Received on Friday, 26 February 2016 22:25:50 UTC