Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
Hi, thanks again for your review of draft-ietf-websec-strict-transport-sec-06, Murray. I've interpreted and applied your comments [1] to -08, yielding an -09 working copy. In the below, "done in -09" means done in my working copy of -09 -- which I haven't published quite yet. I'm trying to resolve the unrecognized directives language thing being discussed on websec@ before doing so. thanks again, =JeffH [1] HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 > MINOR ISSUES: > > Section 2.3.2: Your Security Considerations section should probably include > a pointer to this section. very good point. done in -09. > Section 3: Are the latter two paragraphs really necessary? I only find such > statements useful when minimum conformance is not the same thing as full > conformance. It's apparently helpful for readers with a strong W3C-style spec background. I'll leave them in. > Section 4, HTTP Strict Transport Security Host: Should this say "for all > web pages it serves" or similar? That sort of detailed requirements are given in Section 7 Server Processing Model. I'd rather keep the term definition to be high-level. Plus, the statement isn't strictly true -- an HSTS Host doesn't have to return the STS header field for all resources on all requests. (again see S7) > Section 4: Expand ABNF on first use, and include a reference to RFC5234. > (The reference could instead go in Section 6.) > > Section 6.1: The ABNF you have there requires a leading semi-colon. Based > on your examples, I think instead you want: > > Strict-Transport-Security = "Strict-Transport-Security" ":" > directive *( ";" [directive] ) > > Note that this also allows: > > Strict-Transport-Security: foobar > > Is that okay? > > Section 6.1: What's "the STS directive extension point"? > > Section 6.1.1: I think the "delta-seconds" should be: > > delta-seconds = 1*DIGIT > ; defined in Section 3.3.2 of [RFC2616] > > The angle-bracket notation you have there doesn't seem to be normal. > > Section 6.2: The second example isn't strictly correct because no space is > allowed around the semi-colon in the ABNF in Section 6.1. It looks like you'll > need to add optional whitespace at various points in the ABNF, or correct the > example. the above issues were discussed on list, the spec is based on RFC2616 ABNF (not RFC5234), as well as there having been changes to aspects of the above quoted text from -06 to -08. please refer to at least -08. thx. > Section 8.1: The "Note:" includes stuff that should be normative, and thus > is not appropriate for a side discussion note. It doesn't quite jive with > how you've defined use of "Note:" as a document convention. "Note:" removed. done in -09. > Section 8.2: The "Note that..." at the end threw me for a loop. How does > what's said in 8.2 imply what's stated here? For example, what does it say > about SMTP or FTP? sec 8.2 (now 8.3) was heavily re-written in rev -07 -- I believe this comment no longer applies. > Section 10.1: This discussion got me wondering why an absolute time for > HSTS Policy expiration isn't used instead of a delta. Perhaps that could be > explained somewhere like Appendix A. (Yes, I know about time synchronization, > but this text gave me pause.) as I recall (this was early in the HSTS work), there were the time sync issues plus the whole mess with cookies having both "expires" and "max-age" and other non-trivial stuff such as needing to parse various date formats because server implementors got it wrong but its incumbent on UA implementors to try to be a lenient as possible, etc. Without rummaging back through all those discussions, I've added this note to Appendix A "Design Decision Notes" in -09, and hope it's sufficient... The max-age approch of having the HSTS Host provide a simple integer number of seconds for a cached HSTS Policy time-to-live value, as opposed to an approach of stating an expiration time in the future was chosen for various reasons. Amongst the reasons are no need for clock syncronization, no need to define date and time value syntaxes (specification simplicity), and implementation simplicity. > Section 10.3: "example-ca.com" is not a reserved domain name for use in > examples. Suggest "ca.example.com" or "ca.example". Same issue with > "example-ca-services.net". done in -09. > Section 14.2: The "but the attacker has established somewhere" clause > doesn't parse for me. What's it trying to say? clarified in -09: "...but that the attacker has managed to register in the DNS and point at an HTTP server under the attacker's control.." # Ok, so amongst the below "NITS" comments was the "a HSTS" vs "an HSTS", as well as "a STS" vs "an STS". I did some research (e.g. Chicago Manual of Style) and will change 'em all to the "an" form. Those various commen
Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
Hi, thanks for your review Murray, apologies for latency. Nice to see you didn't find any major issues. The most major obvious item in this review, concerning ABNF in section 6, was discussed on the list -- and then I neglected to submit a bug for the overall review feedback (sorry). that's now done: HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 ..and I'm working on -09 to incorporate your feedback and will reply to your msg on-list. =JeffH ___ 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
> -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. -MSK ___ 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
> -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. > > 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". RFC5234 also says it should be used as a "last resort". This is such a simple definition that it doesn't seem to qualify. -MSK ___ 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
[websec] AppsDir review of draft-ietf-websec-strict-transport-sec
I have been selected as the Applications Area Directorate reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). [NOTE: This is a pre-Last Call review requested by the Applications Area Directors. Please disregard any boilerplate indicating otherwise.] Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-websec-strict-transport-sec-06 Title: HTTP Strict Transport Security (HSTS) Reviewer: Murray S. Kucherawy Review Date: April 28, 2012 IETF Last Call Date: n/a IESG Telechat Date: n/a Summary: This draft is almost ready for publication as a Standards Track RFC, but has a few issues that should be fixed before publication. Reviewer Synopsis: The document specifies methods by which providers of web-based services can signal to users (and their web clients) that their services should only be accessed via secure mechanisms. It also gives a detailed treatment of the threat model leading to the proposal it contains. This is one of the more well-written drafts I've reviewed in some time. It's clear and very complete in terms of presenting the background, which is very helpful to readers (and reviewers!) not expert in this area. MAJOR ISSUES: None. MINOR ISSUES: Section 2.3.2: Your Security Considerations section should probably include a pointer to this section. Section 3: Are the latter two paragraphs really necessary? I only find such statements useful when minimum conformance is not the same thing as full conformance. Section 4, HTTP Strict Transport Security Host: Should this say "for all web pages it serves" or similar? Section 4: Expand ABNF on first use, and include a reference to RFC5234. (The reference could instead go in Section 6.) Section 6.1: The ABNF you have there requires a leading semi-colon. Based on your examples, I think instead you want: Strict-Transport-Security = "Strict-Transport-Security" ":" directive *( ";" [directive] ) Note that this also allows: Strict-Transport-Security: foobar Is that okay? Section 6.1: What's "the STS directive extension point"? Section 6.1.1: I think the "delta-seconds" should be: delta-seconds = 1*DIGIT ; defined in Section 3.3.2 of [RFC2616] The angle-bracket notation you have there doesn't seem to be normal. Section 6.2: The second example isn't strictly correct because no space is allowed around the semi-colon in the ABNF in Section 6.1. It looks like you'll need to add optional whitespace at various points in the ABNF, or correct the example. Section 8.1: The "Note:" includes stuff that should be normative, and thus is not appropriate for a side discussion note. It doesn't quite jive with how you've defined use of "Note:" as a document convention. Section 8.2: The "Note that..." at the end threw me for a loop. How does what's said in 8.2 imply what's stated here? For example, what does it say about SMTP or FTP? Section 10.1: This discussion got me wondering why an absolute time for HSTS Policy expiration isn't used instead of a delta. Perhaps that could be explained somewhere like Appendix A. (Yes, I know about time synchronization, but this text gave me pause.) Section 10.3: "example-ca.com" is not a reserved domain name for use in examples. Suggest "ca.example.com" or "ca.example". Same issue with "example-ca-services.net". Section 14.2: The "but the attacker has established somewhere" clause doesn't parse for me. What's it trying to say? NITS (mostly trying to save the RFC Editor some work here): There are so many important references to [ForceHTTPS] that I think it might be helpful to include page or section numbers for those. Section 1: The Abstract uses "Web" as a proper noun, but this section includes uses of it that are all lowercase. I believe it should be used one way or the other throughout the document. Section 1: "Section", when referring to a section of a document, should be capitalized. (Also occurs in a few other places.) Section 2.2: s/known as a HSTS Host/known as an HSTS Host/ Section 2.2, bullet 1: s/to be/such that they are replaced by/ Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/ Section 2.3.1.1: Define or provide a reference for what Firefox is, in case it's somehow not in common use at the time some future reader gets this. Section 2.3.1.2: Define or expand "CA" on first use. For that matter, would it be possible to reference something that talks about the difference between self-signed and CA-signed certificates, and why they get different treatment? Section 2.3.1.3: Define or expand "SWF" on first use. Section 2.3.1.3: s/by injecting script/by injecting a script/ Section 2.4.1.1, bullet 1: s/inte
