- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 27 Feb 2016 08:11:52 +1100
- To: Roy Fielding <fielding@gbiv.com>
- Cc: HTTP WG <ietf-http-wg@w3.org>
> 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? > 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. > > 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 -- Mark Nottingham https://www.mnot.net/
Received on Friday, 26 February 2016 21:12:26 UTC