Re: Stephen Farrell's No Objection on draft-ietf-httpbis-alt-svc-12: (with COMMENT)

Hi Stephen,

> - If TLS1.3 continues to have 0rtt replayable early-data,
> could that interact badly with Alt-Svc? Or what about
> false-start? For example, if such a combination meant that an
> otherwise functional replay detection scheme would fail to
> spot a replay that would be bad. This is not a DISCUSS, as
> neither TLS1.3 nor false-start are formally "done" so blocking
> this for that reason would be "odd";-) However, both are
> implemented or will be, so I would love to chat about it and
> that might lead to some new security considerations text, here
> or in a TLS document.

I don't think there's any interaction, because an Alt-Svc is "just another HTTP connection" as far as replay goes; of course one still needs to be mindful of not using it for things like POST.


> - Does this still all work for opportunistic security for
> HTTP? If not, why not? Note: I'm not asking if the WG have
> reached consensus on oppo, rather I'd like to be reassured
> that if they do, this will still work for that. I think that's
> all ok, though, right?

It is still the basis, yes.


> - section 3: with "clear" you say alternatives are to be
> invalidated. Does that mean anything about cached resources? I
> assume not, but just checking.

No, they're completely separate.


> - section 5: I wondered why you didn't include the ALPN
> identifier here?

That didn't come up. Generally, it's because the alternative hostname isn't available to the server (thanks to DNS), whereas the negotiated protocol generally is. I say "generally" because the scope of the ALPN identifier is somewhat fuzzy, and some have talked about using it to indicate out-of-band information (e.g., whether certs are checked).

I'd be interested to hear what WG members think about this -- do we need to include this? Arguably, it would be more useful than knowing what the port is (information that the server *does* have).


> - 9.2: What does "might also choose" mean and which "other
> requirements" have you in mind? That's very vague.

Browsers can -- and do -- add other checks to certificates, and this gives them wiggle-room to do so. This might be CT as it's not required now, it might be a browser-specific blacklist based upon its own data, it might be additional limits on validity periods, it might be Perspectives or a similar approach, etc. 


> - 9.5: What are you telling me with the last para?

This?

"""
  When the protocol does not explicitly carry the scheme (as is usually
  the case for HTTP/1.1 over TLS), servers can mitigate this risk by either
  assuming that all requests have an insecure context, or by refraining from
  advertising alternative services for insecure schemes (for example, HTTP).
"""




--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 2 March 2016 23:13:55 UTC