- From: Adam Roach <adam@nostrum.com>
- Date: Wed, 10 Jan 2018 10:04:32 -0600
- To: Mark Nottingham <mnot@mnot.net>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-origin-frame@ietf.org, Patrick McManus <mcmanus@ducksong.com>, httpbis-chairs@ietf.org, ietf-http-wg@w3.org
On 1/9/18 9:01 PM, Mark Nottingham wrote: > Hi Adam, > >> On 10 Jan 2018, at 12:34 pm, Adam Roach <adam@nostrum.com> wrote: >> >> 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. > Not specifically. 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. > >> Is the omission of wildcard-style origins intentional? > Yes, this was discussed a fair amount. > >> 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). > 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. >> 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. > 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/
Received on Wednesday, 10 January 2018 16:08:09 UTC