Subject: Re: [httpwg/http-extensions] Consulting the DNS on expanding ORIGIN set? (#330)

From: HTTP issue updates <[email-masked]>
Date: Tue, 01 Aug 2017 14:18:57 +0000 (UTC)

how about a non normative should.. that way you're describing the tradeoffs
in a way that sheds some light on the situation (with examples) but not
doing a normative "do something unspecific"

On Mon, Jul 31, 2017 at 7:52 PM, Mark Nottingham <[email-masked]>
wrote:

> Hmm. I suspect a requirement that's so vague won't get through IESG, but I
> guess we can try it.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/httpwg/http-extensions/issues/330#issuecomment-319228529>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5syDDXgoZVomlOAAPMBOMGirt8jraks5sTmjBgaJpZM4NEzUM>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-319383835

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 01 Aug 2017 07:22:37 -0700

Seems ripe for an RFC6919 MAY WISH TO or SHOULD CONSIDER.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-319384967

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 01 Aug 2017 19:47:27 +0000 (UTC)

/me is very tempted to get a 6919 ref in there

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-319476562

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 04 Aug 2017 00:15:13 -0700

I think we're almost there; see latest revision.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-320175938

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 16 Aug 2017 21:37:18 +0000 (UTC)

On the commits:

- From discussions, I think the CT and OCSP responses should be an "and" not an "or".  They both address different threats and both are needed.  CT helps reduce some of the risks around mis-issuance while OCSP allows any mis-issuance to be addressed in a reasonable period of time.  

- I think for "Additionally, clients MAY avoid consulting DNS to establish the connection's authority for new requests." we may want append "when employing adequate additional mitigations to security and operational risks."

Is there a precedence or convention for having the "adequate additional mitigations" be defined in a future RFC?

My general concern continues to be that we're changing the security profile of a complex system in ways that crosses protocol layers.  Even if solving some of those problems requires a much more in-depth risk analysis, people looking to exploit these changes won't be constrained by a "but that violates layering to specify more!".

Note that as discussed above, there is also a class of issues which might require a not-as-yet-defined certificate extension to make some of the people here fully comfortable.  (Which would possibly be in-addition to the OCSP and CT requirements.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-322906710

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 16 Aug 2017 14:40:16 -0700

> From discussions, I think the CT and OCSP responses should be an "and" not an "or". They both address different threats and both are needed. CT helps reduce some of the risks around mis-issuance while OCSP allows any mis-issuance to be addressed in a reasonable period of time.

My sense of the discussion was that we flirted with "and" but settled on "or". Happy to be corrected there; @mcmanus?

> I think for "Additionally, clients MAY avoid consulting DNS to establish the connection's authority for new requests." we may want append "when employing adequate additional mitigations to security and operational risks."

Seems reasonable to me.

> Is there a precedence or convention for having the "adequate additional mitigations" be defined in a future RFC?

That's possible, but as noted there's been a historical reluctance to define the exact requirements in RFCs. Remember that Web browsing is just one use of HTTP.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-322907369

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 16 Aug 2017 14:40:19 -0700

I think we also want to change the intro sentence for consistency:
> This specification relaxes the requirement to check DNS when the ORIGIN frame is in use.
to:
> This specification relaxes the requirement to check DNS when the ORIGIN frame is in use in-combination with additional security mitigations.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-322907386

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 17 Aug 2017 01:23:05 +0000 (UTC)

The "or" seems appropriate here, given that these are examples only.  We might add new higher requirements for this over time.  For instance, we might require that these sites include Expect-Staple or Expect-CT policies (to match the checks for OCSP or CT), or we might devise new and better schemes for avoiding key theft and require those as well.  That certainly doesn't mean that "and" won't be the actual requirement.

We have to be careful not to overproscribe client policy here.  Browsers have a lot of resources to throw at these problems, but we could exclude other types of clients from these features by the sheer weight of the set of requirements that come with them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-322942923

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 18 Aug 2017 17:47:15 +0000 (UTC)

I think the direction this is going is to say something along "Examples of
mechanisms that can give additional confidence in a certificate are [ct]
[ocsp]".. both "or" and "and" in the current text seem to convey more
policy than is meant.

On Wed, Aug 16, 2017 at 9:23 PM, Martin Thomson <[email-masked]>
wrote:

> The "or" seems appropriate here, given that these are examples only. We
> might add new higher requirements for this over time. For instance, we
> might require that these sites include Expect-Staple or Expect-CT policies
> (to match the checks for OCSP or CT), or we might devise new and better
> schemes for avoiding key theft and require those as well. That certainly
> doesn't mean that "and" won't be the actual requirement.
>
> We have to be careful not to overproscribe client policy here. Browsers
> have a lot of resources to throw at these problems, but we could exclude
> other types of clients from these features by the sheer weight of the set
> of requirements that come with them.
>
> —
> You are receiving this because you were mentioned.
> <https://github.com/httpwg/http-extensions/issues/330#issuecomment-322942923>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s4nA8QgvkAKYllvpWoRRR5QXdM0dks5sY5X3gaJpZM4NEzUM>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-323417961

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 18 Aug 2017 10:52:36 -0700

@mcmanus seems reasonable. There will need to be an "and" in there because english, but it'll be clear it's not requiring the set (because examples).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-323419239

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 26 Aug 2017 02:18:49 +0000 (UTC)

Looks good, thanks!

One missing thing is that there is no way to limit the Origin Set (which was the original motivation behind this draft) without allowing clients to bypass DNS, leading to the aforementioned operational issues with DNS-based load balancing. This could be easily solved with 1-bit flag, but it's such an edge case, that I'm not sure if it's worth accommodating.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-325074473

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 21:47:30 -0700

I remember some conversations about that (although I don't *think* it was in a WG session); the conclusion was that it probably wasn't worth the trouble. The biggest use case is sending the empty origin frame (i.e., limiting to SNI), which means that the DNS bypass is a no-op.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-326188679