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

Hiya,

On 02/03/16 23:13, Mark Nottingham wrote:
> 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; 

Hmm... seems to me that the probability of having an effective
replay detection cache in place has to be lower with Alt-Svc.
I'd be interested if that is wrong.

That said, the probability of having an effective replay cache
in place is probably quite small for any significantly sized
site, so this isn't likely a major deal. Could still be worth
noting though, as I'd say it'd be non-obvious for people deploying.

I do accept that might be better noted as a security consideration
in some other document. I'm not sure if the tls1.3 spec will be
the best place for that or if there'll be a need for some
guidance on using tls1.3 with HTTP, but if there were to be a
document like that, noting it there would be good.

> of course one still
> needs to be mindful of not using it for things like POST.

Right, I suspect if 0rtt stays in tls1.3 then someone will need
to write down how to safely use that for the web, e.g. also noting
that DELETE/PUT could also involve some ickiness if replayable.

>> - 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.

Great, ta.

> 
> 
>> - 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.

Ditto.

> 
>> - 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).
> 

I'd also be interested if folks think this useful.

>> - 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.
> 

I have to say I'm still not clear on what could usefully be done
there - are you envisaging e.g. paying attention to whether the
new host name is in a SAN in the cert or matches a wildcard cert
or something?

I also don't see how CT would interact with Alt-Svc at all, but
maybe there's something.

>> - 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). """
> 

Yep, I still don't get what it's saying. Maybe I just find "assuming
that all requests have an insecure context" hard to grok.

Cheers,
S.

PS: Just to note again, none of the above ought be considered
blocking - if you/the-WG think I'm wittering on about nonsense, then
please do just ignore me:-)


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