Subject: Adam Roach's No Objection on draft-ietf-httpbis-origin-frame-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 09 Jan 2018 17:34:38 -0800

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-origin-frame-04: 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-origin-frame/

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

This seems a good mechanism overall. The security property of no longer
requiring DNS checks seems a slight bit troublesome, as it (as the draft
acknowledges) makes mounting an attack significantly easier: all that is
required is exploiting a CA, rather than the two-step process of doing that
plus hijacking DNS in some way. Was there consideration given to advising that
implementations perform DNS checks after the fact? This would provide the
latency benefits this mechanism is defined for while allowing at least for
detection of origin hijacking.

Is the omission of wildcard-style origins intentional? Or was this an
oversight? It seems that being able to, e.g., send an ORIGIN frame that claims
authority over "https://*.blogspot.com:443" would be far more efficient than
blasting out the several million or so origins that such machines would be
authoritative for (yes, I know this won't be done in practice -- such domains
simply won't be able reap the benefits of this mechanism). Ideally, I'd like to
see text in here explaining why wildcards shouldn't be specified, or indicating
that they might be specified in a future document.

Minor nit in Appendix B:

   Generally, this information is most useful to send before sending any
   part of a response that might initiate a new connection; for example,
   "Link" headers [RFC5988] in a response HEADERS, or links in the
   response body.

Presumably, this should reference [RFC8288].

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Jan 2018 14:01:10 +1100

Hi Adam,

> On 10 Jan 2018, at 12:34 pm, Adam Roach <[email-masked]> wrote:
> 

Not specifically. 

> Is the omission of wildcard-style origins intentional?

Yes, this was discussed a fair amount.

> Or was this an
> simply won't be able reap the benefits of this mechanism).

The common case for a wildcard cert is to support all of the origins covered by the wildcard. This is already supported by NOT using ORIGIN.

The other case is supporting *most* of the certs, but leaving some out. That would require us to have a way to say "NOT these origins", and that was judged too complex.

> Ideally, I'd like to

We don't generally document why we don't do things; that would make our RFCs much longer and more difficult to use. Making statements about the future doesn't seem like a great idea either.

> Presumably, this should reference [RFC8288].

Will be fixed in -05.

Thanks!

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 10:04:32 -0600

>> detection of origin hijacking.

Given that Mistakes Do Happen[1][2][3][4][5][6][7][8][9][10], it seems 
it probably should have been. I believe the document needs a bit more 
treatment of this issue before it moves forward.

> The common case for a wildcard cert is to support all of the origins covered by the wildcard. This is already supported by NOT using ORIGIN.

So it ends up being an either/or proposition, then? That is, if I've 
claimed authority for a set of origins using a wildcarded cert, then I 
can't use the ORIGIN frame without blowing that away, right?

> The other case is supporting *most* of the certs, but leaving some out. That would require us to have a way to say "NOT these origins", and that was judged too complex.

I agree that the complication involved in introducing a mechanism like 
this is not warranted by its utility.

> We don't generally document why we don't do things; that would make our RFCs much longer and more difficult to use. Making statements about the future doesn't seem like a great idea either.

On the contrary, when a question is obvious but its answer is not, RFCs 
will frequently include rationale. For example -- we're in the middle of 
processing 
<https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/> 
right now, and the introduction includes significant discussion of 
design rationale, including in particular why certain things were not done.

/a

____
[1] 
https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
[2] 
https://www.csoonline.com/article/2623707/hacking/the-real-security-issue-behind-the-comodo-hack.html
[3] https://www.wired.com/2009/07/kaminsky/
[4] 
https://nakedsecurity.sophos.com/2011/07/26/unpatched-iphonesipads-secure-connections-not-so-secure/
[5] 
https://news.netcraft.com/archives/2014/02/12/fake-ssl-certificates-deployed-across-the-internet.html
[6] 
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_L:_Any_Port_.28Jan_-_Apr_2015.29
[7] 
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29
[8] 
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_T:_alicdn.com_Misissuance_.28June_2016.29
[9] 
https://www.agwa.name/blog/post/domain_validation_vulnerability_in_symantec_ca
[10] 
https://arstechnica.com/information-technology/2017/01/already-on-probation-symantec-issues-more-illegit-https-certificates/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Jan 2018 17:24:03 +0000

Hiya,

> treatment of this issue before it moves forward.

Just want to check a thing - if one added some DNS check, am
I right that any privacy benefit of the ORIGIN frame might
then be lost? If so, maybe this is more of a trade-off? If
not, then maybe I'm just as confused as usual;-)

S.

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 11:47:08 -0600

> not, then maybe I'm just as confused as usual;-)

I didn't see this mechanism billed as a privacy enhancement. If that's 
part of the impetus, it's certainly worth mentioning in the Introduction 
and/or Security Considerations section. But, in actuality, I would 
prefer that it not: if DNS privacy is desired, then a more comprehensive 
solution (such as those coming out of DPRIVE) is more appropriate than a 
partial solution that exposes some (but not all) origin names to a 
presumed hostile DNS server.

But even if the draft is reconstrued to also be a privacy-related 
mechanism, the trade-off you hint at above needs to be discussed.

In thinking through the privacy implications you bring up, I noticed 
another potentially problematic aspect of ORIGIN that probably needs 
treatment in the Security Considerations section. With the ongoing work 
to hide SNI from third-party observers [1], OPTIONS may divulge more 
information to such a third party than would otherwise be easily 
obtainable: if I see you connect to an IP address, I can connect to the 
same destination and wait for OPTIONS frames to indicate to me all of 
the potential hosts you could be actually looking for.

/a

____
[1] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 (yes, I 
know *you* are aware of this -- I'm citing it for other people who may 
not be).

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 11:52:12 -0600

On 1/10/18 11:47 AM, Adam Roach wrote:
> treatment in the Security Considerations section. With the ongoing 
> work to hide SNI from third-party observers [1], OPTIONS may divulge 
> more information to such a third party than would otherwise be easily 
> obtainable: if I see you connect to an IP address, I can connect to 
> the same destination and wait for OPTIONS frames to indicate to me all 
> of the potential hosts you could be actually looking for. 

Gah. Of course, I mean "ORIGIN" instead of "OPTIONS" above.

/a

---

From: Patrick McManus <[email-masked]>
Date: Wed, 10 Jan 2018 18:19:01 +0000 (UTC)

On Wed, Jan 10, 2018 at 12:24 PM, Stephen Farrell <[email-masked]
> wrote:

> then be lost?

making fewer queries is privacy friendly.

But there's something more fundamental:

experience has shown that HTTP/2's requirement to
establish server authority using both DNS and the server's
certificate is onerous.

adding a post-facto DNS check doesn't help with that part of things. ORIGIN
does not expect to be consistent with the DNS rule of 7540 coalescing.

This is especially true when DNS is not consistent for everyone (i.e. I
have 2000 different servers that will answer for a.example.com but
obviously not every query for a.example.com can return the same set to
everyone) it leads to less coalescing going on than the server wants when
done 7540 style. There are also load management issues (i.e. a particular
server can opt-in to a subresource via ORIGIN on a per connection basis,
rather than an Internet-wide basis by publishing in DNS) etc..

Origin takes the position that that certificate validity is the more useful
signal and encourages the implementer to be extra careful about it now that
it has more weight.. that's why the examples deal with the mis-issuance
infrastucture (i.e. CT) and revocation (i.e. OCSP stapling) rather than
bringing in other factors.

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 12:42:03 -0600

On 1/10/18 12:19 PM, Patrick McManus wrote:
>
> Origin takes the position that that certificate validity is the more 
> useful signal and encourages the implementer to be extra careful about 
> it now that it has more weight.. that's why the examples deal with the 
> mis-issuance infrastucture (i.e. CT) and revocation (i.e. OCSP 
> stapling) rather than bringing in other factors.
>

I've always viewed DNS + TLS as kind of a belt-and-suspenders kind of 
thing, where one needs to mount two (usually unrelated) exploits to 
successfully hijack an origin. I'm uncomfortable with backing down from 
that, but this might just be due to a misperception on my part: is CT 
deployed broadly enough that it provides a viable backstop against such 
attacks? (On a quick glance, I believe that zero of the ten defects I 
cited in my earlier message would have been thwarted by OCSP).

/a

---

From: Patrick McManus <[email-masked]>
Date: Wed, 10 Jan 2018 20:25:34 +0000 (UTC)

> attacks? (On a quick glance, I believe that zero of the ten defects I cited
> in my earlier message would have been thwarted by OCSP).
>
> /a
>

The tradeoffs here are well tread ground by the working group.

Chrome will be requiring CT participation for all new publicly trusted
certificates issued after April 2018. Being in a public log is currently
very common because of this and of course an ORIGIN implementation is free
to ignore ORIGIN where it doesn't feel there are sufficient suspenders in
place.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jan 2018 07:28:15 +1100

> On 11 Jan 2018, at 3:04 am, Adam Roach <[email-masked]> wrote:
> 
> Given that Mistakes Do Happen[1][2][3][4][5][6][7][8][9][10], it seems it probably should have been. I believe the document needs a bit more treatment of this issue before it moves forward.

We didn't discuss the particular mitigation that you suggest; that doesn't mean we didn't discuss the risk overall, along with several other potential mitigations (as outlined in the document, along with some others on the cutting room floor). 

What's the nature of the additional treatment you'd like to see? Please note this has been discussed pretty extensively in the WG, and the current text represents a consensus that I believe takes your point of view into account (i.e., I don't see any new argument here).

Later, you say:

> I've always viewed DNS + TLS as kind of a belt-and-suspenders kind of thing, where one needs to mount two (usually unrelated) exploits to successfully hijack an origin. I'm uncomfortable with backing down from that, but this might just be due to a misperception on my part: is CT deployed broadly enough that it provides a viable backstop against such attacks? (On a quick glance, I believe that zero of the ten defects I cited in my earlier message would have been thwarted by OCSP).

I think I agree if you mean OCSP-as-deployed, but note that the suggested mitigation in the document is to positively require they have a recent OCSP response that shows the certificate was not revoked, which is different than what's currently done by most browsers. Or CT (as discussed).

> So it ends up being an either/or proposition, then? That is, if I've claimed authority for a set of origins using a wildcarded cert, then I can't use the ORIGIN frame without blowing that away, right?

Yes.

> I agree that the complication involved in introducing a mechanism like this is not warranted by its utility.
> 
>>> Ideally, I'd like to
> On the contrary, when a question is obvious but its answer is not, RFCs will frequently include rationale. For example -- we're in the middle of processing <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/> right now, and the introduction includes significant discussion of design rationale, including in particular why certain things were not done.

I'm not disputing that in some circumstances it makes sense to define architecture or otherwise illuminate decisions. However, it's a judgement call as to what's appropriate to document in these cases, and in my judgement (as an editor of this document), this doesn't need explaining; it follows from the design. If we explained everything that people didn't understand on a first reading of the document, it would quickly become unreadable.

That said, I would agree with an argument that we should explicitly say that they aren't supported, so as not to confuse.

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Jan 2018 12:51:21 -0800

> to ignore ORIGIN where it doesn't feel there are sufficient suspenders in

I'm not sure I agree with Adam about the tradeoffs here, but I don't really
see that CT helps that much.

Consider the case where the attacker gets a certificate for server A. They
also get an OCSP response for A (with validity of a week or so). If they do
OCSP stapling, they will be able to impersonate A for the entire duration
of the OCSP response. That's a pretty significant time period. And for
attackers who control the network, you get an even longer period if they
block OCSP (the central revocation mechanisms used by Chrome and Safari
might be partial mitigations here or might not, depending...)

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 14:52:28 -0600

> I think I agree if you mean OCSP-as-deployed, but note that the suggested mitigation in the document is to positively require they have a recent OCSP response that shows the certificate was not rev…

I find Patrick's answer here compelling. I think the big problem I had 
here was the hand-wavy nature of the Security Considerations (the 
repeated use of "ought to" seems like deliberately steering around 
normative behavior). The apparent state of CT deployment makes this much 
better, so I'm happy to let it drop.

As an aside, I suspect that the references to "Remote Authentication 
Dial In User Service (RADIUS) Protocol Extensions" are not intended? My 
best guess is that these were supposed to point at RFC6962 rather than 
RFC6929.

> That said, I would agree with an argument that we should explicitly say that they aren't supported, so as not to confuse.

Yes, please do that. It would also (in my opinion) be worthwhile 
mentioning that using ORIGIN is incompatible with the use of wildcard 
certs to indicate authority over wildcarded origins; but, if you don't 
want to, I'm not going to press the point.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jan 2018 07:59:03 +1100

> On 11 Jan 2018, at 7:52 am, Adam Roach <[email-masked]> wrote:
> 
> I find Patrick's answer here compelling. I think the big problem I had here was the hand-wavy nature of the Security Considerations (the repeated use of "ought to" seems like deliberately steering around normative behavior). The apparent state of CT deployment makes this much better, so I'm happy to let it drop.

That's intentional, FWIW. We wanted to impose *some* bar, but recognise that there isn't a common approach that will work for all implementers, depending on what they implement / prefer.

> As an aside, I suspect that the references to "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions" are not intended? My best guess is that these were supposed to point at RFC6962 rather than RFC6929.

How embarrassment -- will fix, thanks.

> Yes, please do that. It would also (in my opinion) be worthwhile mentioning that using ORIGIN is incompatible with the use of wildcard certs to indicate authority over wildcarded origins; but, if you don't want to, I'm not going to press the point.

Will see what I can do.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jan 2018 09:56:47 +1100

> On 11 Jan 2018, at 7:59 am, Mark Nottingham <[email-masked]> wrote:
> 

"""
Note that the ORIGIN frame does not support wildcard names (e.g., "*.example.com") in Origin-Entry.
As a result, sending ORIGIN when a wildcard certificate in use effectively disables any origins
that are not explicitly listed in the ORIGIN frame(s).
"""

Seem reasonable?

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 17:59:36 -0600

> that are not explicitly listed in the ORIGIN frame(s).

Yes. Thanks. (Grammar nit: "...when a wildcard certificate is in use..." 
or "...with a wildcard certificate in use...")

/a