Re: [websec] Re-litigating Key-Pinning
On 2014-08-27 07:44, Yoav Nir wrote: ... Fixing editorial issues like Julians’ comments about references is fine, and could even be done *after* IESG review. ... ... FWIW, I believe the ABNF issues (which are *not* editorial) absolutely need to be fixed as well. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] draft-ietf-websec-key-pinning-20 references
Hi there. Below some nits wrt references [RFC4627] Crockford, D., The application/json Media Type for JavaScript Object Notation (JSON), RFC 4627, July 2006. Obsoleted by http://tools.ietf.org/html/rfc7159. [RFC4634] Eastlake, D. and T. Hansen, US Secure Hash Algorithms (SHA and HMAC-SHA), RFC 4634, July 2006. Obsoleted by http://tools.ietf.org/html/rfc6234. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, Transport Layer Security (TLS) Extensions, RFC 3546, June 2003. ...also obsoleted, in this case apparently by a set of specs. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] draft-ietf-websec-key-pinning-20 feedback
Hi there. Some more quick feedback, somewhat unstructured... Throughout: please say header field rather than header. The Public-Key-Pins and Public-Key-Pins-Report-Only header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are new response headers defined in this specification. They are used by a server to indicate that a s/server/origin server/ maybe? Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header fields, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The field values of both header fields conform to the same rules. Public-Key-Directives = [ directive ] *( OWS ; OWS [ directive ] ) directive = simple-directive / pin-directive simple-directive = directive-name [ = directive-value ] directive-name= token directive-value = token / quoted-string pin-directive = pin- token = quoted-string 1) I would recommend not to special-case pin-directive here, as it makes the ABNF ambiguous. Just put the additional requirements into prose. 2) The value of pin-directive ought to allow token syntax as well. (Otherwise a conforming parser will need to special-case their parsing which doesn't make any sense at all). given header field. Directives are either optional or required, as stipulated in their definitions. OPTIONAL or REQUIRED, I assume? Additional directives extending the semantic functionality of the header fields can be defined in other specifications. The first such specification will need to define a reistry for such directives. registry. According to rule 5, above, the UA MUST ignore pin-directives with Repeats a requirement. Maybe do not use MUST here; instead say will. tokens naming hash algorithms it does not recognize. If the set of remaining effective pin-directives is empty, and if the host is a Known Pinned Host, the UA MUST cease to consider the host as a Known Pinned Host (the UA should fail open). The UA should indicate to SHOULD? UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. MAY? (in general: try to avoid lowercase RFC2119 terms) Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] draft-ietf-websec-key-pinning-20 feedback
Hi there. Some more quick feedback, somewhat unstructured... Throughout: please say header field rather than header. The Public-Key-Pins and Public-Key-Pins-Report-Only header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are new response headers defined in this specification. They are used by a server to indicate that a s/server/origin server/ maybe? Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header fields, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The field values of both header fields conform to the same rules. Public-Key-Directives = [ directive ] *( OWS ; OWS [ directive ] ) directive = simple-directive / pin-directive simple-directive = directive-name [ = directive-value ] directive-name= token directive-value = token / quoted-string pin-directive = pin- token = quoted-string 1) I would recommend not to special-case pin-directive here, as it makes the ABNF ambiguous. Just put the additional requirements into prose. 2) The value of pin-directive ought to allow token syntax as well. (Otherwise a conforming parser will need to special-case their parsing which doesn't make any sense at all). given header field. Directives are either optional or required, as stipulated in their definitions. OPTIONAL or REQUIRED, I assume? Additional directives extending the semantic functionality of the header fields can be defined in other specifications. The first such specification will need to define a reistry for such directives. registry. According to rule 5, above, the UA MUST ignore pin-directives with Repeats a requirement. Maybe do not use MUST here; instead say will. tokens naming hash algorithms it does not recognize. If the set of remaining effective pin-directives is empty, and if the host is a Known Pinned Host, the UA MUST cease to consider the host as a Known Pinned Host (the UA should fail open). The UA should indicate to SHOULD? UAs SHOULD make their best effort to report Pin Validation failures to the report-uri, but may fail to report in exceptional conditions. MAY? (in general: try to avoid lowercase RFC2119 terms) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] X-Frame-Options EBNF bug at Mozilla
On 2013-02-26 11:24, Tobias Gondrom wrote: Thanks a lot for bringing this to WG attention. It seems that I misread that point when I first wrote the draft. Actually the same is true for IE. I corrected the ABNF in the new version to reflect IE and Mozilla behavior. Best regards and thanks a lot for catching this! Tobias ... See https://bugzilla.mozilla.org/show_bug.cgi?id=836132#c19: Phil Ames (New to Bugzilla) 2013-02-26 08:00:53 PST From http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2 : The values are specified as ABNF strings, and therefore are case-insensitive and the relevant methods in the code use [header-value].LowerCaseEqualsLiteral(...) so they match case-insensitively. One note, I think the spec is incorrect in stating that FF/Chrome support colons in 2.2.2, Chrome has no support at all for Allow-From (just my pending patch which has the same behavior as the one that led to this bug), and obviously colons are not supported here either (and the intent seems to be to not permit them). So I believe http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2.2 needs to be fixed; in the best case by just removing it. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] X-Frame-Options EBNF bug at Mozilla
On 2013-02-26 17:28, Tobias Gondrom wrote: On 27/02/13 00:06, Julian Reschke wrote: On 2013-02-26 11:24, Tobias Gondrom wrote: Thanks a lot for bringing this to WG attention. It seems that I misread that point when I first wrote the draft. Actually the same is true for IE. I corrected the ABNF in the new version to reflect IE and Mozilla behavior. Best regards and thanks a lot for catching this! Tobias ... See https://bugzilla.mozilla.org/show_bug.cgi?id=836132#c19: Phil Ames (New to Bugzilla) 2013-02-26 08:00:53 PST From http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2 : The values are specified as ABNF strings, and therefore are case-insensitive and the relevant methods in the code use [header-value].LowerCaseEqualsLiteral(...) so they match case-insensitively. One note, I think the spec is incorrect in stating that FF/Chrome support colons in 2.2.2, Chrome has no support at all for Allow-From (just my pending patch which has the same behavior as the one that led to this bug), and obviously colons are not supported here either (and the intent seems to be to not permit them). So I believe http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2.2 needs to be fixed; in the best case by just removing it. I would be fine with removing this. Just for the record: From another reviewer/security researcher, I received on Jan-9 the following feedback: IE8+ : X-Frame-Options: ALLOW-FROM http://example.com/ IETF-draft : X-Frame-Options: ALLOW-FROM: http://example.com/ IE needs no colon between ALLOW-FROM and uri.Firefox and Chrome accept both. Firefox is in the process of getting fixed. Which indicated that Firefox and Chrome would support both, which is why I kept it in. But in reflection, it probably does not add value to talk about all other possible syntax form that could be supported in some browsers due to tolerance. ... Indeed, we should only document a single format that will work across browsers. So I would agree with you to remove 2.2.2. (And if until Sunday I don't hear any objections, I will do so.) Best regards and thanks for the feedback, Tobias Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional
On 2013-02-13 21:12, Yoav Nir wrote: Hi SM The W3C one is from a very old document, the first draft of which dates back to 2005. Anne van Kesteren has been editing it since 2007. The Origin header was first mentioned in the draft from September 2008. There it is sully explained. In 2009 the name of the document was changed to Cross-Origin Resource Sharing. Starting with the version from July 2010, that document references the WebSec draft, and later the RFC. I suppose the provisional header should be removed, but the now-defunct W3C group is no longer available to request this. I'll see what can be done. Yoav ... Well. You make it sound as if it's ok to run two different registries with partly overlapping values. It's not. It's a bug in the way IANA handles this. This is what needs to be fixed. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional
On 2013-02-13 21:43, Yoav Nir wrote: On Feb 13, 2013, at 10:24 PM, Julian Reschke julian.resc...@gmx.de wrote: Well. You make it sound as if it's ok to run two different registries with partly overlapping values. It's not. It's a bug in the way IANA handles this. This is what needs to be fixed. Best regards, Julian I don't want to turn this into a process debate, but having a provisional registry like this allows you to create interoperable implementations while the document is still at draft. I often see a push to get a document published because we need the IANA assignments for products. Yes. Of course they could still do this with a single registry where provisional entries are somehow marked (with an asterisk?). That way we wouldn't get to a situation where we have double entries. The key thing being that both registries share the same namespace, so, by definition, an entry can not appear in both. If it does, there's a process/software problem. Of course the trivial way to do this right is to implement a *single* registry, and to just store a flag for each entry. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional
On 2013-02-14 06:04, Mark Nottingham wrote: We've been talking for a while about revising 3864; it needs a lot more than this done. Cheers, ... True, but the issue applies to all registries that are split into categories. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] WGLC feedback for X-Frame-Options
On 2012-11-06 18:25, Julian Reschke wrote: Hi there, here's my feedback from the HTTP/editorial point of view: ... Just checking: is the WG still working on this draft? There doesn't seem to be any activity since October 2012... Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] WGLC for X-Frame-Options
On 2012-11-06 00:19, Alexey Melnikov wrote: Here is my review (with my co-chair hat off): [RFC3986] should be a Normative reference (as it is required to parse/generate a valid X-Frame-Options header field). [RFC6454] is normative, because there is a SHOULD requirement to use it. In Section 2.1: The ALLOW-FROM URI MUST be valid. I don't know what this mean exactly. Can you elaborate? 2.2. Backus-Naur Form (BNF) The RFC 822 [RFC0822] EBNF of the X-Frame-Options header is: Which makes [RFC0822] Normative. X-Frame-Options = Frame-Options : DENY/ SAMEORIGIN / (ALLOW-FROM : URI) With URI as defined in [RFC3986] [TBD] Or should we use the ABNF (RFC 2234) alternatively to EBNF or in addition? Yes, you should use RFC 5234. This probably means inserting [WSP] in various places, but I think that would be much better. ... Almost. You should reference HTTPbis Part 1, and, in particular, *only* define the ABNF for the field value. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-strict-transport-sec issue: directive, name and directive value
On 2012-07-10 00:42, =JeffH wrote: The following came up in my AD review of draft-ietf-websec-strict-transport-sec, and Jeff suggested that I needed to take it to the list. So here it is. The ABNF in Section 6.1 has this: directive = token [ = ( token | quoted-string ) ] Below that, bullet 3 says this: 3. Directive names are case-insensitive. And in Section 6.1.1: The syntax of the max-age directive's value (after quoted-string unescaping, if necessary) is defined as: Nothing defines what a directive name or a directive's value is. You and I know they're what's on the left side of the equals sign and the right side, respectively. We can't assume, though, that people will figure out that the ABNF definition above turns into name=value, and will thus know what those terms mean, completely unambiguously, for essentially all readers. fyi/fwiw, the manner in which the ABNF is crafted was finalized in the thread, with Julian Reschke, rooted here.. Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 https://www.ietf.org/mail-archive/web/websec/current/msg01114.html Nothing defines what a directive name or a directive's value is. You and I know they're what's on the left side of the equals sign and the right side, respectively. We can't assume, though, that people will figure out that the ABNF definition above turns into name=value, and will thus know what those terms mean, completely unambiguously, for essentially all readers. Making the grammar like this will fix it: directive = directive-name [ = directive-value ] directive-name = token directive-value = token | quoted-string If there's a good reason not to make the ABNF change above, I'm happy to accept some other way of defining the terms, but I think they must be defined. I think doing it with the ABNF is the easiest and smoothest way. I can see doing it as above, or even as a comment.. directive = token [ = ( token | quoted-string ) ] ; directive-name = directive-value Julian apparently has some reasoning for trying not to put everything into the ABNF (see the thread pointed to above). So I think it'd good if he weighed in on this. I do note that the ABNF in draft-ietf-httpbis-p2-semantics-19 for the expect header field which Julian points at does explicitly define ABNF for expect-name and expect-value, similarly to Barry's suggestion above. Adding ABNF productions for clarity seems fine to me. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08)
On 2012-06-02 02:22, =JeffH wrote: On 2012-06-01 20:32, =JeffH wrote: Alexey wrote: Most of my issues were addressed in the latest version, except for this one: 6.1. Strict-Transport-Security HTTP Response Header Field 4. UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. So this is saying that syntactically invalid STS header fields are to be ignored. This still doesn't say if unrecognized directives are to be ignored or not. (Because they can comply with the generic syntax for directives, so they would be syntactically valid, albeit unrecognized). So can you please add an explicit sentence about that? Here's the text in my working copy for that item.. t UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. UAs MUST also ignore any STS header fields containing undefined directives. /t Ok? ... That makes it basically impossible to add extensions; is that intended? No, that is not my intention, nor the WG's as far as I understand. Alexey follows up with: I agree with Julian: this will make the header field effectively non extensible. And if you update the header field by adding new values, all older implementations will start ignoring it, which is a deployment headache. Ok, so the first proposal is broken, how about this.. t UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. /t t UAs MUST ignore any directives they do not recognize, but MAY accept and process a STS header field containing an unrecognized directive but otherwise satisfying the other requirements (1 through 4) stated here. /t ..? Note that the paragraph following the above numbered list items states: Additional directives extending the semantic functionality of the STS header field can be defined in other specifications. UAs MUST ignore any directives they do not recognize, ... Yes. ...but MAY accept and process a STS header field containing an unrecognized directive but otherwise satisfying the other requirements (1 through 4) stated here. Why MAY accept here? If the MUST ignore extension directives, doesn't that mean that that MAY indeed is a MUST? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
On 2012-05-01 04:55, Murray S. Kucherawy wrote: -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Monday, April 30, 2012 10:03 AM To: Murray S. Kucherawy Cc: apps-disc...@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-...@tools.ietf.org Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec On 2012-04-29 09:11, Murray S. Kucherawy wrote: ... Section 6.1.1: I think the delta-seconds should be: delta-seconds = 1*DIGIT ; defined in Section 3.3.2 of [RFC2616] ... That would copy the rule from RFC 2616 by value. Why not just say delta-seconds is defined in Section 3.3.2 of [RFC2616] and leave out the restatement of the ABNF? Then it's truly only specified in one place. That's *exactly* what the prose ABNF rule is doing; except that it makes the in-spec ABNF complete. ... Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
On 2012-05-01 15:43, Murray S. Kucherawy wrote: -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Tuesday, May 01, 2012 1:11 AM To: Murray S. Kucherawy Cc: apps-disc...@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-...@tools.ietf.org Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec Why not just say delta-seconds is defined in Section 3.3.2 of [RFC2616] and leave out the restatement of the ABNF? Then it's truly only specified in one place. That's *exactly* what the prose ABNF rule is doing; except that it makes the in-spec ABNF complete. Yes, and I'm saying I think that's a risky thing to do. Granted, in this particular case it's pretty hard to copy and get wrong, but in general it's safer to point to an authoritative definition of something rather than copy it just so it's all local. Technically it *does* point to the authoritative definition. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
On 2012-04-29 09:11, Murray S. Kucherawy wrote: ... Section 6.1.1: I think the delta-seconds should be: delta-seconds = 1*DIGIT ; defined in Section 3.3.2 of [RFC2616] ... That would copy the rule from RFC 2616 by value. ... The angle-bracket notation you have there doesn't seem to be normal. ... It's a prose rule; see RFC 5234 prose-val. It's used here to define the ABNF rule by reference. The reference form in theory is safer because there's only a single definition, so no conflicts are possible. Best regards, Julian PS: we use the prose-val style a lot in HTTPbis for referencing ABNF from other documents, so if there's a problem with that I'd like to learn ASAP about it :-) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
On 2012-04-06 00:40, =JeffH wrote: Thanks for the feedback, proposed edits, and hacked xml2rfc source. So this - states that the given ABNF applies to the value after q-s processing (when needed) - changes the ABNF to specify only the *value* Ok. so you suggested.. 6.1.1. The max-age Directive The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 Noting a HSTS Host, below). The syntax of the max-age directive's value (after potential applying quoted-string unescaping) is: max-age-v = delta-seconds delta-seconds = 1*DIGIT, defined in [RFC2616], Section 3.3.2 Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. ..and I presently am polishing that to be.. 6.1.1. The max-age Directive The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 Noting a HSTS Host, below). The max-age directive value has the following syntax (after quoted-string unescaping, if necessary): max-age-value = delta-seconds delta-seconds = 1*DIGIT, defined in [RFC2616], Section 3.3.2 Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. Looks good to me. I'm a little concerned that without an explicit syntax declaration such as.. max-age = max-age = max-age-value ..we'll confuse some readers (what do i actually put in the STS header for this directive??), but hopefully the examples in section 6.2, as well as putting the directive name in quotes in the first paragraph, will address this. Noted. And yes, if we optimize for people not reading the spec properly, the best way to address this is to add examples. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
Here's the promised concrete change proposal: Section 6.1., paragraph 3: OLD: Strict-Transport-Security = Strict-Transport-Security : *( ; [ directive ] ) NEW: Strict-Transport-Security = Strict-Transport-Security : [ directive ] *( ; [ directive ] ) (fixes the leading ; problem) Section 6.1., paragraph 12: OLD: Additional directives extending the semantic functionality of the STS header field may be defined in other specifications (which update this specification), using the STS directive extension point. NEW: Additional directives extending the semantic functionality of the STS header field can be defined in other specifications (which update this specification). (the extension directive extension point was removed earlier on when the ABNF was simplified) Section 6.1.1., paragraph 2: OLD: The syntax of the max-age directive is defined as: NEW: The syntax of the max-age directive's value (after potential quoted- string when applicable) is defined as: Section 6.1.1., paragraph 3: OLD: max-age = max-age = delta-seconds NEW: max-age-value = delta-seconds (We just define the parameter value ABNF) Section 6.2., paragraph 0: OLD: The syntax of the includeSubDomains directive is defined as: includeSubDomains = includeSubDomains 6.2. Examples NEW: (text removed, as the directive is value-less) 6.2. Examples Section 6.2., paragraph 2: OLD: Strict-Transport-Security: max-age=31536000 NEW: Strict-Transport-Security: max-age=31536000 (changed one example to use q-s) Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
On 2012-03-26 10:29, =JeffH wrote: I'm not sure how to cleanly and unambiguously define them in terms of both token and quoted-string (and retain max-age's basis on delta-seconds). Perhaps you could propose how to do this? Just define the base grammar for the overall parsing; such as I would appreciate it if you would just plain propose the grammar you believe we should have. The base grammar in Section 6 is fine (except for the nit about the leading ; we were already discussing). For the predefined directives, for example, change: 6.1.1. The max-age Directive The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 Noting a HSTS Host, below). The delta- seconds production is specified in [RFC2616]. The syntax of the max-age directive is defined as: max-age = max-age = delta-seconds delta-seconds = 1*DIGIT, defined in [RFC2616], Section 3.3.2 Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. to 6.1.1. The max-age Directive The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 Noting a HSTS Host, below). The syntax of the max-age directive's value (after potential applying quoted-string unescaping) is: max-age-v = delta-seconds delta-seconds = 1*DIGIT, defined in [RFC2616], Section 3.3.2 Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. So this - states that the given ABNF applies to the value after q-s processing (when needed) - changes the ABNF to specify only the *value* - also we can remove the prose statement about delta-seconds; having it in the ABNF is sufficient Finally, examples should show both variants of the syntax. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] HSTS ABNF still broken: requires leading semi-colon
On 2012-03-24 11:18, Alexey Melnikov wrote: ... I think this is fine. And you can enforce can't be totally null in prose, if you don't want to fix this in ABNF. ... There will always be constraints not checkable in the ABNF. I recommend to keep the ABNF simple (in particular not to include syntactical constructs that vary by parameter name :-), and put all other constraints either into prose, or into separate ABNF rules for specific parameter values. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
On 2012-03-20 16:29, SM wrote: Hi Julian, At 02:35 19-03-2012, Julian Reschke wrote: I'd like to point out that I still think my concerns over the inconsistent use of quoted-string (http://www.ietf.org/mail-archive/web/websec/current/msg01044.html) are valid and not addressed; and I think they should be before you go to IETF LC. Wasn't a similar issue raised in another WG recently? ... Indeed; in the context of the auth parameters in the OAuth Bearer authentication scheme. There's a slight difference though, the Bearer spec defined new parameters for an HTTP header field that already exists (WWW-Authenticate), while STS is a completely new header field. In the first case, it's a bug (that got fixed), in this case it's just a bad idea. Note that HTTPbis P2 has advice with respect to this: Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in Section 6.8 of [Part3]). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for it (for an example, see the notes on parameter handling for media types in Section 2.3 of [Part3]). -- http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1.p.8 Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
On 2012-03-18 23:31, Tobias Gondrom wrote: Hello dear websec fellows, after reading the feedback, tracker entries and the updates on the HSTS draft, the WG chairs and secretary have the impression that the draft is in good shape and we like to ask for WG Last Call for this document: http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06 As we are close to the IETF meeting in Paris, this last call will be extended to three weeks and close on April-9. Please make a last careful review of the draft and submit comments, questions and discuss items for this draft ASAP. You can submit them via email to the mailing-list or make entries for HSTS in the tracker. If you perceive any major issues, it might also make sense to raise them during our meeting in Paris on March-26. Kind regards and thank you, ... I'd like to point out that I still think my concerns over the inconsistent use of quoted-string (http://www.ietf.org/mail-archive/web/websec/current/msg01044.html) are valid and not addressed; and I think they should be before you go to IETF LC. Note that since we had a long discussion with Adam Barth about quoted-string, Chrome has started supporting it in Content-Disposition, and a similar fix for Content-Type is in preparation (http://code.google.com/p/chromium/issues/detail?id=103361#c7). In http://www.ietf.org/mail-archive/web/websec/current/msg01045.html Jeff points out that Firefox doesn't support quoted-string in all parameters, but IMHO that's a bogus argument because it currently doesn't support q-s *at all*; so it will need to be fixed to conform to the current spec as well (see https://bugzilla.mozilla.org/show_bug.cgi?id=718409). I believe this could be a useful discussion topic for Paris. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
On 2012-03-09 00:41, =JeffH wrote: Thanks for the review Julian, The ABNF now is: Strict-Transport-Security = Strict-Transport-Security : directive *( ; [ directive ] ) directive = token [ = ( token | quoted-string ) ] ...and I think this is almost right. It does allow empty directives (thus repeated or trailing semicolons), but not leading semicolons. So STS: foo ; parses, but STS: ; foo does not. well, I guess a question is whether we want STS: ; foo to parse ? I'm not sure we do, but can be convinced otherwise. Part of the intention of the above ABNF is that the STS header must have at least one directive (i.e. max-age - given the constraints in the prose following the ABNF) I suppose what you're trying to say is that all of the below ought to parse successfully... STS: max-age=nn STS: max-age=nn STS: max-age=nn ; STS: max-age=nn ; ; ; STS: ; max-age=nn STS: ; ; ; max-age=nn STS: ; ; ; max-age=nn ; ; ; ? Well, either be permissive with respect to superfluous delimiters or don't; but allowing them in once place but not the other? This could be fixed by saying: Strict-Transport-Security = Strict-Transport-Security : *( ; [ directive ] ) Yes, that's allow for the constructions above, along with (at most one instance of) includeSubDomains being interspersed between any of the semicolons. I like the subsequent prose about the additional constraints. good :) For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string should be legal here (I understand that's http://trac.tools.ietf.org/wg/websec/trac/ticket/33) sections 6.1.1 and 6.1.2 describe the syntax particular to max-age and includeSubDomains directives, and neither of those directives employ quoted-string, and I don't think they need to or should. I think they should, because it's likely that people will write parses that allow both, thus you'll have an automated (and totally unneeded) interoperatility problem. I conceded to add quoted-string syntax to the generic directive syntax of.. directive = token [ = ( token | quoted-string ) ] ..in case someone at some time wishes to add an extension directive employing quoted-string syntax. Are you saying that sections 6.1.1 and 6.1.2 need to explicitly declare non-use of quoted-string ? Presently it's implied by the declared ABNF The opposite. ... Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
On 2012-03-09 17:02, =JeffH wrote: ... Well, i'm not terribly convinced about this, especially given my code reconnaissance in Firefox and Chrome. The spec clearly states what the When you checked Firefox, did it support quoted-string for extension directives? See? Speaking of which: do you have a test suite, or at least a big repertoire of examples? syntax is for those directives and it doesn't encompass quoted-string variants of the values for max-age and delta-seconds. I think adding something like that will needlessly complicate the spec, so I respectfully decline to make such a change. ... I believe both the spec and implementations will be simpler if the syntax of a parameter does not depend on the parameter name. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-16 12:43, Manger, James H wrote: agreed. that's why I'm leaning towards spec'g it with quoted-string at this time. It future-proofs the spec Quoted-string provides no future-proofing.token supports about 77 chars;quoted-string adds about 18 more -- there are another 100,000 chars to support (and even more code points) if you actually want future- proofing. Supporting quoted-string is all about past compromises. It adds no value to a new header. Well, it allows putting in ASCII characters not allowed otherwise, such as whitespace and delimiters such as ;, , and double quotes. I agree it doesn't help with I18N. ... Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-16 03:50, =JeffH wrote: ... though, I remain curious as to why the STS parsing in Firefox Chrome is apparently each a one-off and doesn't use the more generic HTTP header-field parsing routines that are available and which appear to handle quoted-string, arbitrary header field parameter ordering, etc. ... - https://bugzilla.mozilla.org/show_bug.cgi?id=718409 Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-15 22:53, Adam Barth wrote: ... It's definitely messy. I don't think it matters much what we write in this document. Even if we spec quoted-string, I doubt many folks will implement it. However, we can deal with that problem when it comes time to add extension values that actually used quoted-string. ... Apologies for the direct question: just 14 days ago you stated that you did not implement q-s in Chrome, and that you don't intend to: AB Chrome does not (and will not) implement quoted-string for the STS AB header for the reasons I've explained previously. You're welcome to AB file bugs, but I'm just going to close them WONTFIX. That's somewhat different from what you say now. Is the extensions do not exist yet the excuse for not implementing what the spec says? Will you be around for fixing Chrome when the first bug reports because of broken extensions come in? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-15 23:24, Adam Barth wrote: On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschkejulian.resc...@gmx.de wrote: On 2012-01-15 22:53, Adam Barth wrote: ... It's definitely messy. I don't think it matters much what we write in this document. Even if we spec quoted-string, I doubt many folks will implement it. However, we can deal with that problem when it comes time to add extension values that actually used quoted-string. ... Apologies for the direct question: just 14 days ago you stated that you did not implement q-s in Chrome, and that you don't intend to: AB Chrome does not (and will not) implement quoted-string for the STS AB header for the reasons I've explained previously. You're welcome to AB file bugs, but I'm just going to close them WONTFIX. That's somewhat different from what you say now. Is the extensions do not exist yet the excuse for not implementing what the spec says? Will you be around for fixing Chrome when the first bug reports because of broken extensions come in? I don't plan to implement quoted-string in Chrome. I'm saying that I'm not going to object to writing quoted-string into the spec. I still think it's a bad idea, but I'm dropping my objection to it. So when the bug reports come in, *somebody else* is going to fix Chrome? I really want to know. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-14 01:24, =JeffH wrote: In terms of this question of whether the STS header field directive ABNF should be.. 1) directive = token [ = ( token | quoted-string ) ] ..or.. 2) directive = token [ = token ] ..I can see both sides of the argument. However, I've been thinking about it and grepping thru specs as well as firefox and chrome code, which has led me to think that from an overall (specification) consistency perspective, I'm leaning towards spec'g it with quoted-string in the ABNF (ie, as (1)). And has been pointed out in +1 the discussion, it is sort of a moot point because the STS header field does not at this time make use of the quoted-string production, nor do we have on the table any extension directives that would do so. It's not a moot point at all. If you don't spec it now, extensions will not ever be able to use quoted-string, because recipients parsing over those extensions will trip over them. In going through the FF and Chrome code, I note that both of their STS header field parsing methods appear to be special-case and AFAICT don't make use of other, more general HTTP header field parsing routines that are available in both implementations, and that are used to parse other HTTP response header fields. These latter more general HTTP header field parsing routines appear to be used for processing various of the other HTTP response and request header fields (and they appear to handle quoted-string). But it isn't clear why they aren't used for STS. It also isn't clear how uniformly these parsing routines are used for the panoply of HTTP header fields -- some other header fields appear to be special-cased as well (tho my c++ foo is wanting and the code is vast..). So yeah, it does seem messy. It's true what right now there isn't a lot of re-use of header field parsers. This is likely because of historic reasons; different header fields have different parsing quirks. But of course that's not an excuse to add unneeded special cases in the future. Example: just a few weeks ago we discussed the Prefer header field in the HTTPbis WG, and we have been able to make it parse exactly like Expect (after fixing Expect as well, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/327). Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2012-01-05 09:20, Anne van Kesteren wrote: On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom tobias.gond...@gondrom.org wrote: as it seems there is disagreement on how to resolve this, with only very few people having spoken out so far, I would like to invite comments from other working group members on this topic to see whether we might have missed something. I don't really get what the advantage of allowing quoted string here is. If we can use a simpler production, what is wrong with using that? The advantages are: - you can express values that you can't express with token syntax; if future extensions need non-token characters they will need invent yet another escaping syntax - principle of least surprise and consistency - if quoted-string works in other header fields with param syntax, why not here? etc. On the other hand, I haven't seen convincing arguments for not allowing q-s. Yes, it adds to the complexity of the parser, but this has been implemented many times before already. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)
On 2012-01-03 07:26, Yoav Nir wrote: On Jan 3, 2012, at 1:29 AM, =JeffH wrote: Julian wondered.. wouldn't it make sense to have a default for max-age so it can be made OPTIONAL? hm ... I lean towards keeping max-age as REQUIRED (without a default value) and thus hopefully encouraging deployers to think a bit about this and its ramifications, and also because its value is so site-specific in terms of a web application's needs, deployment approach, and tolerance for downside risk of breaking itself. I tend to agree, but it's not deployers who are going to do the thinking - it's the implementers of web servers. So somewhere, in some control panel for IIS, or a config file for Apache, or some WebUI for some SSL-VPN, there's going to be a configuration to turn on HSTS, and that product is going to have a default max-age. The deployers are just going to check the box. I think we should provide guidance for those implementers as to what is a good default there. ... If we know a good default then it should be the default on the wire (IMHO). It would help getting predictable behavior when it's missing. (Right now the spec allows recipients to do anything they want then it's missing, right?) Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] default value for max-age ?
On 2012-01-03 10:14, Adam Barth wrote: ... We should define the behavior in any case, which I guess means I'm advocating an default max-age of zero. ... That sounds good to me; so the grammar wouldn't need to enforce this, but the effect would be the same. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-12-29 22:45, Adam Barth wrote: ... Chrome does not (and will not) implement quoted-string for the STS header for the reasons I've explained previously. You're welcome to file bugs, but I'm just going to close them WONTFIX. ... So your code intentionally is non-compliant with STS. I note that you are both a WG member and also listed as one of the authors of the spec. Don't you think that this puts you into a strange position? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-12-30 10:13, Adam Barth wrote: Using quoted-string in the extension directive is the wrong thing to do. Because none of the actual directives use quoted-string, folks are likely to write parsers that don't handle all the complexities of quoted-string (which are legion). That means when we go to actually use quoted-string in a future directive, it won't actually work in many user agents. Unless we clarify the syntax, allow q-s everywhere, and have test cases. On the other hand, if we spec the extension directives without quoted-string, future extensions will work even if folks mistakenly implement quote-string (because DQUOTE is forbidden in the extension syntax I suggested above, so we'll never trigger the mistaken quoted-string parsing code). Everyone lives a happy life. Absolutely not. First of all, some implementations will parse q-s, because that's consistent with other header fields. Also, not having q-s makes certain values impossible to send, in which case you'll need to invent yet another escaping syntax. Anyway, it's all somewhat of a moot point because the above will happen regardless of what we write in the spec. Even if we write quoted-string, when folks attempt to use these extension directives in the future, they'll find that they don't work and they'll update the syntax not to use quoted-string. Why would they find that? Implementations can be fixed. Or is this argument based on the fact that you *currently* own one implementation and claim it can't be fixed? That would be a very strange thing to do in the context of an IETF WG trying to reach consensus. Best regards, Julian PS: I note that we are in violent agreement that the syntax should be the same for all directives, predefined or extension. We just come to different conclusions about what that syntax should be. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-12-29 20:50, Adam Barth wrote: ..- As I wrote before, I don't think we should include quoted-string in the grammar. As far as I know, no one has implemented it and I have no plans to implement quoted-string in Chrome. Having quoted-string in the grammar only leads to pain., It would be helpful if you were more precise on the pain it causes, considering you need to process extension directives anyway... ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] mimesniff feedback, part 2
On 2011-11-26 05:26, Adam Barth wrote: Yes. Bid-endian is correct. The IETF draft you're reading expired on November 8. Adam ... Well, it's the last that was published. Are you saying people should stop reading it? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Define cross-origin
On 2011-11-23 13:47, Anne van Kesteren wrote: Often it is convenient to use cross-origin in a specification rather than non same origin. Can this term be added to http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 That would be most useful. Seems to be too late, it's in the publication queue: https://www.rfc-editor.org/queue2.html#draft-ietf-websec-origin. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] New draft of HTTP header-based public key pinning
On 2011-11-09 01:31, Tom Ritter wrote: My notes: I believe the BNF (pseudo-BNF?) is incorrect: Public-Key-Pins = Public-Key-Pins : LWS directives directives = max-age LWS ; LWS fingerprints / fingerprints LWS ; LWS max-age max-age = max-age LWS = LWS delta-seconds pins= pins LWS = LWS fingerprints fingerprints= fingerprint / fingerprint , fingerprints fingerprint = fp-type - base64-digits fp-type = sha1 / sha256 I believe 'directives' should replace fingerprints with pins: directives = max-age LWS ; LWS pins / pins LWS ; LWS max-age ... By all means *please* consider re-using the syntax of an existing header field. In particular, please read http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.3.1 So decide whether you want to allow multiple header fields (in which case you should use the ABNF list notation used in 2616/HTTPbis), *or* define the syntax so that a , introduced by header field recombination can be detected by recipients. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] New draft of HTTP header-based public key pinning
On 2011-11-09 21:09, Chris Palmer wrote: On Wed, Nov 9, 2011 at 12:34 AM, Julian Reschkejulian.resc...@gmx.de wrote: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.3.1 So decide whether you want to allow multiple header fields (in which case you should use the ABNF list notation used in 2616/HTTPbis), *or* define the syntax so that a , introduced by header field recombination can be detected by recipients. I'm sorry, I don't know what you mean by a ',' introduced by header field recombination. http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.2.p.5 What grammar do you prefer? I would recommend a syntax that uses a single delimiter. If you use ;, you'd be able to detect the case mentioned above. If you use ,, you could support multiple header fields (if this is desired). By using both however, you gain nothing (IHMO), and create potential problems. Let's assume it's ;. In that case I would write: directives = max-age LWS *( ; LWS [ fingerprint ] ) thus require max-age to be always first (your grammar allows it at the beginning and at the end, but not inbetween; this is likely to cause confusion. Then make fingerprint a proper name/value pair, as in other HTTP parameters, and put the name of the hash into the parameter name. So instead of Public-Key-Pins: max-age=31536000; pins=sha1-4n972HfV354KP560yw4uqe/baXc=, sha256-LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= you'd have Public-Key-Pins: max-age=31536000; pins-sha1=4n972HfV354KP560yw4uqe/baXc=; pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= Finally, allow quoted-string notation, Public-Key-Pins: max-age=31536000; pins-sha1=4n972HfV354KP560yw4uqe/baXc=; pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= so that characters not allowed (such as /) in HTTP tokens work. Best regards, Julian Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-29 04:42, =JeffH wrote: The max-age directive MUST appear once in the Strict-Transport-Security header field value. The includeSubDomains directive MAY appear once. The order of appearance of directives in the Strict-Transport-Security header field value is not significant. Additional directives extending the the semantic functionality of the Strict-Transport-Security header field may be defined in other MAY or might ? yes, a good question. I believe that there's examples in other RFCs of the use of the lower-case may in situations similar to this (I've seen it discussed many times over the years). I.e., not all instances of may in any given RFC are capitalized MAYs. In this case, MAY isn't appropriate IIRC. And yes, a way to avoid that question/issue is to use a different word such as might or can, which i can do. I just thought a may has more correct connotations (but I /knew/ it'd come up as a question :) thanks, +1 to can ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-29 05:08, Adam Barth wrote: ... Except for RFC6265, which in the algorithm for parsing Max-Age=, it algorithmically provides for ignoring a value that doesn't match the effective value ABNF of.. [-]*DIGIT ..which would catch the max-age=1 case, but doesn't seem to explicitly address.. max-age= That's handled by some more general processing rules in the spec. The net result is that it's ignored. But in any case, perhaps (additional) browser implementor folk could chime in here -- do we really need to address such detail-level issues (both of the examples above and below) in the syntax/grammar we specify in specs such as these? Or is the new ABNF proposed in the original message in this thread sufficient? Generally, we prefer to be instructed exactly how to behave for every possible input (even illegal ones). There's a long history of quoted-string not being implemented correctly by browsers. I spec this as just splitting the string on ; and then processing each substring separately, ignoring bogus/future ones. I know Julian has a dream that all HTTP headers will be parsed the same, but quoted-string is sufficiently ill-defined w.r.t. error handling that I prefer to avoid it. ... - when discussing generic parsing, we need to distinguish between legacy cases like cookies, and new headers, where we can do better - standardizing handling of broken headers is one thing (and in general I prefer not to), but that doesn't mean that when defining a new header field we shouldn't minimize the things a sender can get wrong; if we know that some recipients will accept both token and quoted-string anyway, then it seems like a good thing to simply allow them both, reducing the number of special-cases in parsing - not sure what you mean by ill-defined w.r.t. error handling; it's defined just like most other syntax elements in HTTP -- is there something *specific* to quoted-string you have in mind? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-29 10:10, Adam Barth wrote: On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschkejulian.resc...@gmx.de wrote: On 2011-10-29 05:08, Adam Barth wrote: ... Except for RFC6265, which in the algorithm for parsing Max-Age=, it algorithmically provides for ignoring a value that doesn't match the effective value ABNF of.. [-]*DIGIT ..which would catch the max-age=1 case, but doesn't seem to explicitly address.. max-age= That's handled by some more general processing rules in the spec. The net result is that it's ignored. But in any case, perhaps (additional) browser implementor folk could chime in here -- do we really need to address such detail-level issues (both of the examples above and below) in the syntax/grammar we specify in specs such as these? Or is the new ABNF proposed in the original message in this thread sufficient? Generally, we prefer to be instructed exactly how to behave for every possible input (even illegal ones). There's a long history of quoted-string not being implemented correctly by browsers. I spec this as just splitting the string on ; and then processing each substring separately, ignoring bogus/future ones. I know Julian has a dream that all HTTP headers will be parsed the same, but quoted-string is sufficiently ill-defined w.r.t. error handling that I prefer to avoid it. ... - when discussing generic parsing, we need to distinguish between legacy cases like cookies, and new headers, where we can do better - standardizing handling of broken headers is one thing (and in general I prefer not to), but that doesn't mean that when defining a new header field we shouldn't minimize the things a sender can get wrong; if we know that some recipients will accept both token and quoted-string anyway, then it seems like a good thing to simply allow them both, reducing the number of special-cases in parsing - not sure what you mean by ill-defined w.r.t. error handling; it's defined just like most other syntax elements in HTTP -- is there something *specific* to quoted-string you have in mind? Most of HTTP is ill-defined w.r.t. error handling. We muddle through with reverse engineering. ... It's not ill-defined, but undefined (by design) - see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186. What I was trying to understand whether there's something special with respect to quoted-string? Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-29 10:21, Adam Barth wrote: ... What I was trying to understand whether there's something special with respect to quoted-string? Quoted string is particularly bad because it's hard to know what to do with unbalanced quotation marks. ... So your points were about quoted-string in general, not the question of allowing them for max-age, right? I'm asking because due the possible presence of extension parameters, recipients need to deal with quoted-string anyway, no matter whether they are allowed for max-age. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-27 20:03, =JeffH wrote: I've been working with Julian on simplifying the STS header field syntax. Here's where it's presently at -- thoughts? thanks again to Julian and Ryan for their earlier feedback. =JeffH That looks much better to me. More inline. ### 5.1. Strict-Transport-Security HTTP Response Header Field The Strict-Transport-Security HTTP response header field indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this header field. Note: this specification uses the augmented BNF (ABNF) notation from Section 2 of [RFC2616], including its rules for implied linear whitespace (LWS), and case-insensitivity of quoted-string literals. The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response Header field is: Strict-Transport-Security = Strict-Transport-Security : directive *( ; [ directive ] ) STS directives: directive = max-age | includeSubDomains | STS-d-ext max-age = max-age = delta-seconds What happens with max-age=1 ? Do you expect all recipients to reject this? Depending on the parsing API they use they might not even know that the value was quoted on the wire. includeSubDomains = includeSubDomains There's a tiny risk that some implementations will handle value-less parameters the same way as parameters with empty values, such as includeSubDomains= or includeSubDomains= but maybe I'm over-engineering here. (To get this right an API will need to distinguish between parameter missing, parameter present and valueless and parameter present and having a zero-length value. Also, identifiers max-age and includeSubDomains are case-insensitive, right? This follows from the ABNF, but might be worth saying again in prose; in particular because it also needs to be the case for all future extensions. The max-age directive MUST appear once in the Strict-Transport-Security header field value. The includeSubDomains directive MAY appear once. The order of appearance of directives in the Strict-Transport-Security header field value is not significant. Additional directives extending the the semantic functionality of the Strict-Transport-Security header field may be defined in other specifications, using the STS directive extension point (STS-d-ext) syntax: STS-d-ext = token [ = ( token | quoted-string ) ] Defined in [RFC2616]: delta-seconds = 1*DIGIT, defined in [RFC2616], Section 3.3.2 token = token, defined in [RFC2616], Section 2.2 quoted-string = quoted-string, defined in [RFC2616], Section 2.2 ### Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-07 01:23, =JeffH wrote: ... Trying to summarize my concerns and proposals... (1) RFC2616-or-HTTPbis In a perfect world I could give you an exact time-of-arrival for HTTPbis. But the world is not perfect; and progress on HTTPbis mainly depends on the availability of the editors, and, more importantly, people showing up on the HTTPbis mailing list to help in closing issues and reviewing the existing text. So help *is* appreciated. - http://trac.tools.ietf.org/wg/httpbis/trac/wiki (2) Multiple header instances Header fields can occur multiple times, even when they were intended not to. Examples: Location, Content-Length. When this happens, we usually see interop problems because some consumers pick the first, some pick the second, and some combine them using a comma, as described in HTTP spec. This can be dangerous when the repetition makes the message format ambiguous (Content-Length, for instance). It also means that it allows smuggling, relying on checkers/intermediaries only seeing one of the headers. Note that Chrome and FF have become very strict in checking for this for C-L, and FF does even more checks (syntax of C-L, also checks for Location and Content-Disposition). So *if* STS doesn't allow multiple header fields (which would require switching to a comma-separated syntax), the spec should be crystal clear what to do when multiple instances are encountered; in many cases the default should be ignore the header field or even consider the message to be broken. Not sure what's best here. Also note that somebody else may be combining multiple fields into a single one, and the recipient will see those concatenated with commas as separators. Optimally the format is robust enough to detect things like that. (3) ABNF organization Any header field that is extensible needs to define the syntax for the extension point, so existing code can parse them. Don't make extensions different from the builtins with respect to syntax. It just makes the parser more complicated. So just define a single ABNF for STS directives in ABNF. For instance, using RFC 2616 ABNF and list syntax: Strict-Transport-Security = Strict-Transport-Security : 1#directive ...or when sticking to semicolon: Strict-Transport-Security = Strict-Transport-Security : directive *( ; directive ) Then directive = token( = ( token / quoted-string ) ) In prose, add additional constrains, such as MUST contain FOOBAR directive exactly once. Finally, for each builtin directive state the individual syntax of the param *value*, and do not make the ABNF vary based on the directive. Hope this helps. Also worth reading: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.creating.header.fields Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax redux
On 2011-10-08 20:22, Julian Reschke wrote: ... directive = token( = ( token / quoted-string ) ) ... And this should have been...: directive = token [ = ( token / quoted-string ) ] Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] [decade] Digest: Adventures in encoding
On 2011-10-07 10:54, Stephen Farrell wrote: Hi Phill, Oauth [1] uses application/x-www-form-urlencoded format as defined by [W3C.REC-html401-19991224] all over the place to solve basically this problem but in the context of HTTP URLs which has to be worse than for a new URI scheme. Why not do the same here? ... ...because the definition is vague with respect to non-ASCII (that *is* a problem for OAuth, but might be ok here), and because it also leaks the special-casing of SP (encoded as +) into new areas. If you like the encoding otherwise, then just refer to RFC 3986 for percent-encoding: http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.2.1. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] I-D Action: draft-ietf-websec-origin-05.txt
On 2011-09-23 09:29, Julian Reschke wrote: ... 1. NOTE: Running this algorithm multiple times for the same URI can produce different values each time. Typically, user agents compute the origin of, for example, an HTML document once and use that origin for subsequent security checks rather than recomputing the origin for each security check. It seems the NOTE shouldn't be in a numbered list (same for item 4). ... Draft -06 has another instance of this nit :-) b) null in ABNF means case-insensitive; consider replacing with octet sequence and putting the literal null into a comment. ... You now have: origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list You can make that origin-list-or-null = %x6E.75.6C.6C / origin-list and make it more readable by saying: null= %x6E.75.6C.6C ; null, case-sensitive origin-list-or-null = null / origin-list Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Digest URI scheme
On 2011-10-03 19:12, Phillip Hallam-Baker wrote: On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffmanpaul.hoff...@vpnc.org wrote: On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: URLs are used in cases where hierarchy is assumed. I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal. As Julian correctly pointed out, a generic URI will be used in situations where the application will (correctly) assume that anything in URI syntax that has a slash character in it will be hierarchical. Thus a URI scheme that does not intend to indicate hierarchy MUST NOT include a slash character in that part of the identifier. ... I wouldn't say MUST NOT. It's just it's a source of confusion that can be avoided when defining new URI schemes. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] I-D Action: draft-ietf-websec-origin-05.txt
On 2011-10-03 08:26, Martin J. Dürst wrote: On 2011/10/03 7:14, Adam Barth wrote: On Fri, Sep 23, 2011 at 12:29 AM, Julian Reschkejulian.resc...@gmx.de wrote: References: may need updates, such as WEBSOCKETS. Also consider sorting them (xml2rfc sortrefs PI). I've updated WEBSOCKETS. It will probably need to be updated again. My policy in cases like this is: Whenever I update a draft, I check the references and update them if needed. However, the RFC editor is very good at getting these things right, so there's no need to produce a new draft just because another one as increased its number. Indeed. And if you use xml2rfc, those checks can be automated: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Strict-Transport-Security syntax
On 2011-09-28 01:16, =JeffH wrote: thx for the comments Julian. On 2011-09-14 23:08, =JeffH wrote: a few questions about the header field syntax: Strict-Transport-Security = Strict-Transport-Security : OWS STS-v OWS So the header field is *not* using the RFC2616 list syntax. So you can have Strict-Transport-Security: a; b but *not* Strict-Transport-Security: a Strict-Transport-Security: b because that would be equivalent to Strict-Transport-Security: a, b (is this intentional?) well, it was not necessarily intentional as far as I recall. We either managed to overlook, or regarded as inappropriate for this header, the RFC2616 list syntax (i.e., the #rule), that defines such implicit comma-separated lists. Also, we'd noted that quite a number of header field definitions used semi-colons as a delimiter, but perhaps hadn't noted that those overall productions often are embedded within such comma-separated lists. Yes, that's the list-of-parametrized-things format. However, in thinking about it a little bit, for this particular header field, as it's presently defined, it doesn't seem appropriate to have it explicitly be comma-separated repeatable (aka #rule), because only one instance of S-T-S: max-age=n is effective in terms of established the cached Known HSTS Host in the UA. In that case, as this is security related, you may want to talk about what recipients are to do when (a) they *do* get multiple instances, that's already done in -websec-strict-transport-sec-02 in S 7.1. Indeed: If a UA receives more than one Strict-Transport-Security header field in a HTTP response message over secure transport, then the UA SHOULD process only the first such header field. I think it would be cleaner to consider the message broken in this case. and (b) when an intermediate folds multiple headers using the comma syntax. ah, so an intermediate can/might do that to multiple occurrences of any header field in a message ? Yes. Also in ; value STS-v = STS-d / STS-d *( OWS ; OWS STS-d OWS ) ; STS directive STS-d = STS-d-cur / STS-d-ext ; defined STS directives STS-d-cur = maxAge / [ includeSubDomains ] having includeSubDomains optional is a bit weird. This means that the empty string would be a valid STS-d-cur, thus an empty header field is allowed... Ah, thanks, yes -- i was unsure of how to make includeSubDomains optional while max-age is required, and that hack didn't work. I've now re-worked it as below -- how's that look? thanks again, =JeffH Strict-Transport-Security = Strict-Transport-Security : OWS STS-v OWS ; STS header field value; must have a max-age: STS-v = max-age / max-age *( OWS ; OWS STS-d OWS ) ...which makes putting max-age first required. ; additional STS directives: STS-d = STS-d-cur / STS-d-ext ; currently defined STS directives, ; delta-seconds is 1*DIGIT and is from [RFC2616]: max-age = max-age OWS = OWS delta-seconds [ OWS v-ext ] STS-d-cur = includeSubDomains includeSubDomains = includeSubDomains [ OWS v-ext ] ; extension points STS-d-ext = name ; STS extension directive v-ext = value ; STS extension value name = token value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or ; [ ! .. : ] [ lt; .. ~ ] any visible chars other than ; token = 1*tchar tchar = ! / # / $ / % / amp; / ' / * / + / - / . / ^ / _ / ` / | / ~ / DIGIT / ALPHA ; visible (printing) characters, except visible ; separators. ; DIGIT, ALPHA, separators are from [RFC2616] ; Basic rules: OWS = *( [ CRLF ] WSP ) ; Optional White Space WSP = SP / HTAB CRLF = CR LF ; CR, LF, SP, HTAB are from [RFC2616] --- end I think it would be simpler not to try to express this in the ABNF. what do you mean by this ? Essentially constraints on what directives need to be there (as opposed to their syntax). Just use the ABNF to state the core syntax (that a parser will need to understand), and then put additional requirements about what directives must be there in prose (we're doing the same in HTTPbis, but aren't done yet... :-). do you have a particular example in mind? HTTPbis, for instance, doesn't enumerate header field names in the ABNF anymore. I'm guessing that the Expect header might be a good example, from -httpbis-p2-semantics-16, yes? Not really, it still has the directive 100-continue spelled out in the ABNF. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt
On 2011-05-08 02:45, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Media Type Sniffing Author(s) : A. Barth, I. Hickson Filename: draft-ietf-websec-mime-sniff-03.txt Pages : 24 Date: 2011-05-07 ... I think it would be good if the Internet Drafts database could be updates to say that draft-ietf-websec-mime-sniff replaces draft-abarth-mime-sniff (this helps with various tools that try to check for upto-date-ness and successor documents). Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] effective request URI def, was: I-D Action: draft-ietf-websec-strict-transport-sec-02.txt
On 2011-08-06 01:34, =JeffH wrote: ... 12. Removed any and all dependencies on [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending on [RFC2616] only. Fixes issue ticket #12 http://trac.tools.ietf.org/wg/websec/trac/ticket/12. ... Not sure this is a good idea. The current text copies a known bug from draft-ietf-httpbis-p1-messaging-15 (see http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1340). Also, the ABNF claims it's based on RFC 2616's definitions, but mentions RFC 3986 in ABNF comments. This needs to be checked. Furthermore, there's a risk that HTTPbis will have to tune the definition of Effective Request URI furthermore -- see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/222. (I realize that's not your fault, but we somehow have to deal with this). Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
