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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 01 Mar 2016 04:24:15 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-alt-svc-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

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

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

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Mar 2016 10:13:22 +1100

Hi Stephen,

> that might lead to some new security considerations text, here

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.

> that if they do, this will still work for that. I think that's

It is still the basis, yes.

> assume not, but just checking.

No, they're completely separate.

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 13:51:33 +0000

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

Great, ta.

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

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

> """ 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/
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 4 Mar 2016 11:30:05 -0500

> noting though, as I'd say it'd be non-obvious for people deploying.
I think the right place to document this would be alongside the
documentation of the replay cache mitigation.. as far as I understand that,
the issue is that the cache is a physical resource and any kind of load
balancing (l4, DNS A records, or alt-svc) is going to limit its efficacy.

---

From: Erik Nygren <[email-masked]>
Date: Fri, 4 Mar 2016 13:49:39 -0500

> balancing (l4, DNS A records, or alt-svc) is going to limit its efficacy.

A replay cache is not sanely possible to protect against TLS 1.3 0RTT for
any distributed deployment (multi-site with or without Alt-Svc).

It will likely make sense for the HTTP WG to pull together a draft on how
HTTP can be safely used in scenarios where replays can't be prevented.
(TLS 1.3 0RTT, QUIC 0RTT, and perhaps TCP FastOpen for HTTP-over-TCP.)
Much of the responsibility ends up landing on the client to not send
non-idempotent Early Data, but there are also questions and challenges
around how proxies and other middle-boxes should handle data received via
Early Data, how they need to indicate it to the next-hop, and whether it's
ever safe for them to send something not received over Early Data to a next
hop over Early Data.
(With the assumption that Early Data is always replayable, which is why TLS
mandates it has a separate interface to use.)

        Erik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Mar 2016 13:19:16 +1100

> On 5 Mar 2016, at 12:51 AM, Stephen Farrell <[email-masked]> wrote:
> 

It's just saying that clients can and use additional means to validate certificates; i.e., they're not obligated to accept a cert if it passes the 2818 checks.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Mar 2016 14:27:10 +1100

> It's just saying that clients can and use additional means to validate certificates; i.e., they're not obligated to accept a cert if it passes the 2818 checks.

In practice, browsers do pinning checks, blacklist checks, revocation
checks [1], CT signature checks, user override checks, and probably
things that I'm not aware of.  The intent was to avoid limiting
validation behaviour.  My initial reaction was that this wasn't
interoperable.  I still think we could do better, but don't want to
burden this effort unreasonably, defining what it means to validate a
certificate turns out to be hard.

[1] Hah, had you going there, we don't. Well... unless there is a
must-pin policy.