WebSec face-to-face summary, Monday, 26 March 2012 HSTS document is in WGLC. Major outstanding issues discussed at the meeting: 1). Some ABNF consistency issue 2). Discussed implications/handling of "all subdomains" option. Some edge cases might not be covered in the document/not explicitly mentioned in the draft. For example handling of 0-lifetime HSTS pins in subdomains. 3). Discussed at length whether "no user recourse" should be allowed on any TLS error, or should exceptions be made for TLS certificate expiration. It looks like there doesn't seem to be consensus to change the current text (which doesn't make any exceptions for expired certificates). Some support for having a new "this site is testing HSTS" directive. Some agreement that informing users (and administrators) of why the site hard-failed is important, instead of just showing "you can't connect to this HSTS site, I will not tell whether CRL verification failed, or your cert is malformed, or the chain can't be verified". 4). Discussion on whether access to OCSP/CRL content should be exempted from HSTS policy covered by "all subdomains" flag (they are frequently retrieved over HTTP). There are ways of addressing this in other ways (e.g. move the OCSP/CRL service to a different domain not covered by HSTS). No consensus to change the current text. Yoav Nir presented his "Extended Origin" idea , to allow a single website be partitioned in multiple pieces. The Extended Origin is then going to be protocol+host+port+partition_name. Several participants commented that browsers are not going to implement this. Future discussion should be taken to the mailing list, no consensus to work on this in the WG so far. Some quick refresher about FRAME/X-FRAME drafts ("don't put content of this site into a HTML Frame unless ..."). Chairs will ask on the mailing list to accept these drafts as WG drafts. Some questions of whether this should be done in IETF or W3C. Several people (including W3C liaison and the responsible) commented that doing this in WebSec is fine. Chairs also quickly talked about MIME sniffing (an editor and reviewers are needed) and CSP header field registration draft, which will be done in W3C with reviews requested from WebSec and HTTPBIS IETF WGs. -------------- More detailed information about the meeting is below (slightly edited jabber logs): [11:09:57] agenda slides: http://www.ietf.org/proceedings/83/agenda/agenda-83-websec.txt [11:10:01] er, agenda [11:10:24] agenda SLIDES: http://www.ietf.org/proceedings/83/slides/slides-83-websec-3.pdf [11:11:01] now up: jeff hodges on hsts [11:11:29] slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-5.pdf [11:11:49] slide: Progress since IETF 82 [11:13:30] issue #33 [11:13:57] question to the room: are people aware of the quoted-string grammar discussion? [11:14:37] Julian: If there is consensus to make changes to the grammer, I will provide more specifics [11:15:21] JeffH: Concern is mainly around max-age; julian argues that value for max-age is either token or quoted string (currently just token) [11:15:57] issue is that in HTTPbis cleanup work, julian is trying to move everyone toward using either tokens or quoted strings uniformly [11:16:23] that way, if people are sloppy on the server side, the client will be more relaxed/accepting [11:17:03] julian: Proliferation of header formats means there's huge parser proliferation, lots of pain/bugs [11:17:22] Carsten Bormann at the mic [11:17:30] similar issue in the CORE WG [11:17:54] carsten: in CORE, we have re-used the Link header format, and found that implementors didn't get the fine point about tokens vs. quoted strings [11:18:07] jeff: would you have every parameter value in either syntax? [11:18:16] carsten: yeah, just handle all the parameters the same way [11:18:36] julian: Link header does have that problem, erratum has been filed [11:19:28] adam barth was opposed to quoted-string, but this may not still be true [11:20:33] chairs: action item to julian to submit something substantial [11:20:54] BTW, the erratum against RFC 5988 was http://www.rfc-editor.org/errata_search.php?rfc=5988&eid=3158 [11:21:27] Hannes: is this the same discussion as in oauth? [11:21:32] julian: yes [11:22:15] HANDS: Who is comfortable providing an opinion on this issue? [11:22:21] (~10 hands) [11:22:28] HANDS: Who supports Julian's proposal [11:22:33] (~10 hands) [11:22:43] HANDS: Who opposes Julian's proposal? [11:22:50] (no hands) [11:22:58] On issue 37 [11:23:54] tobias clarified that you need to cache subdomains even if they're overridden by parents [11:24:34] paul hoffman [11:24:37] Thomas Hardjono joins the room [11:24:50] paul: add a sentence explicitly about what max-age=0 means [11:25:42] think that people are throwing away 0-lifetime HSTS pins [11:25:50] issue 39 [11:25:56] jeff: will note that as well [11:26:19] jeff: still reading through issue 39 text [11:26:31] on issue 41/42 [11:27:12] on issue 41: hard fail has been built in from the beginning [11:27:28] users are not given the option to "click through" [11:27:42] moved it from normative language to advice, because we don't do UI [11:28:12] William Chan joins the room [11:28:20] yoav proposes that we add an indication of whether the browser should hard fail [11:28:49] jeffh: haven't had any issues with test deployment [11:29:11] yoav: thought some things skipped the hard fail in the event of expired certs [11:29:48] this could be a real barrier to entry, especially for small players [11:30:14] would like the option of soft roll-out [11:30:53] hoffman: jeff was incorrect when he said it was non-normative, says MUST terminate [11:31:06] jeff: that's correct, we were talking more about user recourse [11:31:31] york joins the room [11:32:22] hoffman: [missed core of it] [11:32:35] tobias: how are foreseeing these things breaking, given they're under control of web site? [11:32:50] key question here seems to be cert expiry [11:33:47] can see a point for soft fail, but obviously we need to go hard fail at the end [11:34:11] farrell [missed] [11:34:23] salowey: in prototypes, have you run into trouble with captive portals? [11:34:53] jeffh: we've had push-back from captive portal vendors [11:35:22] hoffman: to farrell: would you be ok with this if there were a time limit in the document? [11:35:54] yoav: expiry happens, need to be able to recover [11:36:01] audio is now working [11:36:15] ah, great, i might slow down a little [11:36:27] hillbrad: thanks for the report [11:36:30] farrell: expiry and rollout are completely different issues [11:36:49] jeffh: some folks have said not to hard-fail on *just* expiry [11:37:32] sullivan: sounds like people want a do "what i mean" protocol, uncomfortable with that [11:38:14] if the problem is "it fails when i screw something up", don't accommodate screw-ups, learn how to do things right [11:38:23] tobias: +1 to andrew [11:40:20] hoffman: if we don't add this parameter, we might need a "pitfalls" document [11:40:42] similar issues with CRL/OCSP checking as with expiry [11:41:43] jeffh: we do touch on those things, send comments on docs [11:42:03] yoav at the mic [11:43:53] I think his point is that you can't force the user to go clear, because the site doesn't ever operate clear. [11:44:30] I don't get that - for yoav's case, what's listening on port 80? [11:44:52] yngve petterson at the mic [11:45:21] nothing... that's the point. he doesn't care to hardfail, because he just wants the user to always use https:, but doesn't care if some other https validation fails... he's not going to be forced to http, because he doesn't speak http. [11:46:07] yngve: instead of hard failing on things like OCSP, we just show the site as insecure [11:47:10] tobias: trouble seeing where we're going with this [11:48:08] Iljitsch van Beinum at the mic [11:48:16] iljitsch: clarification: is there a third option between user click-through and complete hard fail? [11:48:38] sullivan: disagree really strongly with that [11:49:33] iljitsch: user is more involved in https than dnssec [11:49:45] sullivan: either way, there's a site operator involved [11:50:08] [personal opinion: +1 to mr. sullivan] [11:50:34] yngve: if there's no hard fail, people will just have users click through [11:51:23] I'm not getting up again, but if the answer is "if we don't let this thing softfail, people will just disable it", then we might as well not standardize the mechanism at all [11:51:23] stpeter: you said earlier that hard fail was not failing the connection, it was not allowing click-through [11:52:18] jeffh: we really are talking about UI advice [11:52:26] hoffman: that doesn't come across clearly in the draft [11:52:45] [not_scribe: andrew: it's also not clear what a "soft fail" means, where the bounds lie] [11:54:21] ekr: browsers typically hang up the connection pretty soon after the TLS handshake complete [11:54:26] yngve: we try to keep it open [11:55:23] tobias: asking some shows of hands [11:55:36] HANDS: do you feel comfortable judging on this? [11:55:40] (>10 hands) [11:55:54] HANDS: in favor of no recourse? [11:55:59] (10-15 hands) [11:56:09] HANDS: Option for hard-fail=no? [11:56:14] (~2 hands) [11:56:22] HANDS: Specific cases in which hard-fail=no? [11:56:28] (~2 hands, different people) [11:56:45] tobias: pretty strong indication toward remaining with hard fail [11:57:15] ekr: suggest an alternative interpretation of this? CSP has a "don't puke, just tell me" directive [11:57:51] rather than having a feature that says "don't hard fail", have something like the "report URI" function from CSP [11:58:05] risk of having a feature that could completely brick your site [11:58:54] hoffman: maybe inform the users of why the site hard-failed [11:59:58] crocker: informing users won't do anything; let's not make this a user interface group [12:01:18] crocker is wrong. Administrators are users. Administrators and support people have only the same tools as the users. They only way they can escalate to the right people is to get the details. [12:01:29] MIC: There is a huge difference between the decision to communicate information to the user (or not) and being a UI group [12:01:42] iljitsch: [sounds like something like what ekr said] [12:01:51] MIC the TLS protocol use in HTTP and the web relies on the users being informed in particular ways [12:01:54] The user makes an informed decision ;_0 [12:01:57] mcr: do you want that to the mic? [12:02:03] okay. [12:02:13] PHB: will mic for you [12:02:52] hannes: look at HTTP auth vs. form-based auth; too hard a fail can make things less useful [12:03:00] "nothing fails like failure" [12:03:48] Lucy Lynch’s iPad joins the room [12:03:55] So the WG is discussing how to redefine failure to make it a success [12:04:13] Tom Lowenthal (Mozilla?): if we specify more than that it must fail, then this is not a standard that browsers can implement correctly [12:04:33] ekr: suggesting a mode where you proceed as if HSTS had not been used [12:04:35] PHB: still mic? [12:04:48] It may be that the consequent of what Tom said is true even without the antecedent. [12:05:32] unless the room is agreed crocker is wrong on that point, yes [12:06:04] ekr: clarify, not suggesting that there be a mode where users can click through [12:06:07] I believe the room has [12:06:19] [PHB: pretty sure the room diagrees with crocker] [12:06:39] [that sounds ok then] [12:06:39] [PHB's comment being relayed] [12:08:11] iljitsch: the issue when hsts fails isn't really the site giving stuff to the user, it's more user data going to server [12:08:31] lowenthal: either option here is pretty untenable, ordering browsers to show or hide information [12:09:21] tobias: conclusion is, no conclusion [12:09:33] now on issue 42 [12:09:38] I agree... browsers should neither be forced to display, nor prevented from doing so. [12:10:28] [mcr: it's a little bit of a false dichotomy, given that the current language is not normative, just advisory] [12:10:47] I disagree about trying to hide such failures from the user [12:11:02] the connection can't be established for security reasons. The end. [12:11:11] no choice, MUSTs all the way down [12:11:46] if you can't do this for security then we may as well remove RFC 2119 language from all our documents. [12:11:47] jeffh: CAs should do the right thing, instead of us modifying the protocol [12:12:28] hoffman: if CA.com turns on HSTS, then it can block access to OCSP / CRL content [12:15:10] jeffh: could also violate HSTS by leaking cookies on unsecure connections [12:17:10] tobias: there's still some circular conditions you can get in, e.g., for a site hosting a CRL for itself [12:17:16] hoffman: just put it on a separate domain! [12:17:22] tobias: it already does [12:17:32] jeffh: want to close this ticket without addressing [12:18:31] next presenter: yoav nir on Extended Origins [12:18:54] slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-0.pdf [12:19:02] slide: What's the problem [12:20:03] slide: The proposal [12:20:39] [ adds a path parameter to origin (making it a 4-tuple) that allows the domain to constrain path as well ] [12:22:52] tlr: in partial deployment, doesn't this fail unsafe? [12:23:29] yoav: these are internal, so they're not likely to attack each other [12:23:56] andrew: your third option won't work, it's hopelessly broken [12:25:01] [third option == Yet Another Alternate Solution] [12:25:54] Richardson: [concern about login pages] [12:28:24] jeffh: hillbrad and i think this is really broken, no way we're going to change origin [12:29:18] tobias: call for conversation on the list [12:29:29] using host names as suggested on list is good solution for VPN [12:29:54] wildcard certificates ought to be cheaper :-) [12:30:31] tobias: update on a couple of w3c issues [12:30:33] x-frame-options [12:30:50] slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-2.pdf [12:30:51] antonin.bas leaves the room [12:30:56] slide: frame-options: history [12:32:41] I like the "DENY" option. [12:33:33] slide: frame-options - Drafts [12:34:58] slide: frame-options [12:35:57] iljitsch: why is this not in W3C, in HTML? [12:36:59] I think it needs to be here, because the content being displayed (or not being displayed) is not necessarily *HTML* [12:36:59] tlr: there are two things going on here. one is the normative question (what should happen), other is that this is existing, partially deployed header, and documenting that [12:37:17] [ mcr: what else can you put in a ? ] [12:37:56] can't an