Re: [websec] #54: Specify a report-only mode
#54: Specify a report-only mode Changes (by pal...@google.com): * status: assigned = closed * resolution: = fixed Comment: Draft -08 specifies a report-uri directive and a JSON format to be POSTed to the given URI. -- ---+ Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: fixed Keywords: | ---+ Ticket URL: http://tools.ietf.org/wg/websec/trac/ticket/54#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #55: Clarify that the newest pinning information takes precedence
#55: Clarify that the newest pinning information takes precedence Changes (by pal...@google.com): * status: assigned = closed * resolution: = fixed Comment: Per discussion on the list, adopted Sleevi's text but changed evict to ignore. https://code.google.com/p/key-pinning- draft/source/diff?spec=svnfc4bef2ce138d467182832a362831b6d63ea9cdcr=fc4bef2ce138d467182832a362831b6d63ea9cdcformat=sidepath =/draft-ietf-websec-key-pinning.xml -- ---+ Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: fixed Keywords: | ---+ Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:3 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #53: Clarify status of pin validation when used with private trust anchors
#53: Clarify status of pin validation when used with private trust anchors Comment (by pal...@google.com): The current draft has this text: 578 tIf the connection has no errors, then the UA will determine whether to 579 apply a new, additional correctness check: Pin Validation. A UA SHOULD 580 perform Pin Validation whenever connecting to a Known Pinned Host, but MAY 581 allow Pin Validation to be disabled for Hosts according to local policy. For 582 example, a UA may disable Pin Validation for Pinned Hosts whose validated 583 certificate chain terminates at a user-defined trust anchor, rather than a 584 trust anchor built-in to the UA. However, if the Pinned Host Metadata 585 indicates that the Pinned Host is operating in strict mode (see 586 xref target=strict/), then the UA MUST perform Pin Validation./t I believe this is the result of previous consensus. Is that correct, and can I therefore close this issue? -- ---+ Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: Keywords: | ---+ Ticket URL: http://tools.ietf.org/wg/websec/trac/ticket/53#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #55: Clarify that the newest pinning information takes precedence
#55: Clarify that the newest pinning information takes precedence Comment (by pal...@google.com): Ryan Sleevi has added text to the working copy that I believe resolves this ticket. Comments? https://code.google.com/p/key-pinning- draft/source/diff?spec=svn4f697cf66f747c18a5389922f484d9a1dbe85968r=83bad3527ede8bb6ef52a8c220990ccd8762d9e7format=sidepath =/draft-ietf-websec-key-pinning.xml -- ---+ Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: Keywords: | ---+ Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #57: Re-add an upper limit to max-age
#57: Re-add an upper limit to max-age At IETF 86, it was decided that there should be an upper limit to the max- age directive -- +--- Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning |Version: Severity: Active WG Document | Keywords: +--- Ticket URL: http://tools.ietf.org/wg/websec/trac/ticket/57 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #57: Re-add an upper limit to max-age
#57: Re-add an upper limit to max-age Comment (by pal...@google.com): Rather, it was decided that there should be implementation guidance for setting an upper limit, including discussing the security considerations /trade-offs of high vs. low maximum max-age values. -- + Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Resolution: Keywords: | + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/57#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #57: Re-add an upper limit to max-age
#57: Re-add an upper limit to max-age Comment (by pal...@google.com): I have added language discussing the issue to the latest working copy of the draft at https://code.google.com/p/key-pinning-draft/source/browse /draft-ietf-websec-key-pinning.xml. -- + Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Resolution: Keywords: | + Ticket URL: http://tools.ietf.org/wg/websec/trac/ticket/57#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #56: Specify includeSubdomains directive for HPKP
#56: Specify includeSubdomains directive for HPKP Comment (by pal...@google.com): TODO: Discuss the problem that, given that we prefer (2), Pinned Host operators will have a problem if UAs by chance happen to visit Google.com first, and then second try to visit WWW.Google.com. Due to includeSubdomains, the pins A and B will take effect, and Pin Validation will fail, *before the UA has a chance to note the pin C for WWW.Google.com*. Host operators SHOULD take this problem into account when deploying Pinned Hosts. -- ---+ Reporter: pal...@google.com | Owner: pal...@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: Keywords: includeSubdomains | ---+ Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/56#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #52: Clarification of section 2.3.1
#52: Clarification of section 2.3.1 Changes (by y...@checkpoint.com): * status: assigned = closed * resolution: = fixed Comment: Solved in -04 -- -+ Reporter: Tom Ritter | Owner: pal...@google.com Type: defect | Status: closed Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: fixed Keywords: | -+ Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #56: Specify includeSubdomains directive for HPKP
#56: Specify includeSubdomains directive for HPKP Changes (by palmer@…): * status: new = assigned -- ---+--- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning| Version: Severity: - | Resolution: Keywords: includeSubdomains | ---+--- Ticket URL: http://tools.ietf.org/wg/websec/trac/ticket/56#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #55: Clarify that the newest pinning information takes precedence
#55: Clarify that the newest pinning information takes precedence Changes (by palmer@…): * status: new = assigned -- -+--- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: Keywords: | -+--- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #54: Specify a report-only mode
#54: Specify a report-only mode Should there be a report-only mode, allowing site operators to see how using HPKP would affect their site's operation in browsers supporting HPKP? (Probably.) If so, specify how that mode would work. -- -+-- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+-- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/54 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #54: Specify a report-only mode
#54: Specify a report-only mode Changes (by palmer@…): * status: new = assigned -- -+--- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: Keywords: | -+--- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/54#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #52: Clarification of section 2.3.1
#52: Clarification of section 2.3.1 Changes (by palmer@…): * owner: draft-ietf-websec-key-pinning@… = palmer@… * status: new = assigned -- -+--- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: assigned Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: Keywords: | -+--- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #50: Handing of pinning DSA public keys
#50: Handing of pinning DSA public keys Changes (by palmer@…): * owner: draft-ietf-websec-key-pinning@… = palmer@… * status: new = assigned -- -+--- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: assigned Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: Keywords: | -+--- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #53: Clarify status of pin validation when used with private trust anchors
#53: Clarify status of pin validation when used with private trust anchors Clarify in the I-D whether and how, when a the server's certificate chain chains up to a private trust anchor (as opposed to a publicly-trusted one such as in Mozilla's or Microsoft's root CA programs), the UA should perform pin validation. Options: * If anchor is private, do not perform pin validation * Always perform pin validation, presumably always failing when trust anchor is private * If anchor is private, validate against a database of private pins; ** If there is no DB of private pins, do not perform pin validation ** If there is no DB of private pins, perform pin validation anyway (presumably always failing) * Other options? Currently, Google Chrome opts to not perform pin validation when the trust anchor is private. -- -+-- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+-- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/53 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #53: Clarify status of pin validation when used with private trust anchors
#53: Clarify status of pin validation when used with private trust anchors Changes (by palmer@…): * status: new = assigned -- -+--- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major| Milestone: Component: key-pinning | Version: Severity: -| Resolution: Keywords: | -+--- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/53#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #50: Handing of pinning DSA public keys
#50: Handing of pinning DSA public keys http://www.ietf.org/mail-archive/web/websec/current/msg01027.html To close up the hole with inherited parameters, in 2.2, prior to the We pin public keys note, add: If the SubjectPublicKeyInfo of a certificate is incomplete when taken in isolation, such as when holding a DSA key without domain parameters, a public key pin cannot be formed. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #51: Clarification of section 2.4
#51: Clarification of section 2.4 In 2.4, adding a phrase to the parenthetical comment in the big paragraph : If the connection has no errors, the UA will then apply a new correctness check: Pin Validation. To perform Pin Validation, the UA will compute the fingerprints of the SPKI structures in each certificate in the host's validated certificate chain. (The UA ignores certificates whose SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain.) The UA will then check that the set of these fingerprints intersects the set of fingerprints in that host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Failure as a non-recoverable error. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/51 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #52: Clarification of section 2.3.1
#52: Clarification of section 2.3.1 I'd suggest the following change to 2.3.1, clarifying it's required-ness and a max-age of 0. 2.3.1. max-age max-age specifies the number of seconds, after the reception of the Public-Key-Pins HTTP Response Header, during which the UA regards the host as a Pinned Host. The delta-seconds production is specified in [rfc-2616]. max-age is a required attribute. If omitted, the UA MUST NOT note the host as a Pinned Host, and MUST discard any previously set Pinning Metadata for that host in its non-volatile store. If max-age is set to 0, the UA MUST likewise discard any previsouly set Pinning Metadata. -- -+- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major| Milestone: Component: key-pinning |Version: Severity: -| Keywords: -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #41: add parameter indicating whether to hardfail or not
#41: add parameter indicating whether to hardfail or not Changes (by jeff.hodges@…): * status: new = closed * resolution: = wontfix -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: wontfix Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/41#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #42: STS exception for CRL fetching
#42: STS exception for CRL fetching Changes (by jeff.hodges@…): * status: new = closed * resolution: = wontfix -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: wontfix Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/42#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #47: HSTS: explicitly note that HSTS applies when following redirects
#47: HSTS: explicitly note that HSTS applies when following redirects Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: jeff.hodges@…| Owner: draft-ietf-websec- Type: enhancement | strict-transport-sec@… Priority: minor| Status: closed Component: strict-transport-sec | Milestone: Severity: Waiting for Shepherd | Version: Writeup| Resolution: fixed Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/47#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #48: HSTS: max-age value in section 10.1 is incorrect
#48: HSTS: max-age value in section 10.1 is incorrect Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: jeff.hodges@…| Owner: draft-ietf-websec- Type: defect | strict-transport-sec@… Priority: minor| Status: closed Component: strict-transport-sec | Milestone: Severity: Waiting for Shepherd | Version: Writeup| Resolution: fixed Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/48#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #47: HSTS: explicitly note that HSTS applies when following redirects
#47: HSTS: explicitly note that HSTS applies when following redirects explicitly note that HSTS applies when following redirects -- section 8.3 URI Loading and Port Mapping doesn't call this out explicitly. It should perhaps say something like.. Whenever the UA prepares to load, also known as dereference, any http URI [RFC3986] (including when following HTTP redirects [RFC2616]), -- -+- Reporter: jeff.hodges@…| Owner: draft-ietf-websec- Type: enhancement | strict-transport-sec@… Priority: minor| Status: new Component: strict-transport-sec | Milestone: Severity: Waiting for Shepherd |Version: Writeup| Keywords: -+- Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/47 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #48: HSTS: max-age value in section 10.1 is incorrect
#48: HSTS: max-age value in section 10.1 is incorrect A statement in Section 10.1.' HSTS Policy expiration time considerations' reads: 'For example, a max-age value of 778000 is 90 days: Strict-Transport-Security: max-age=778000' This is miscalculated, 778000 is about 9 days. 90 days is actually 7776000 seconds. -- -+- Reporter: jeff.hodges@…| Owner: draft-ietf-websec- Type: defect | strict-transport-sec@… Priority: minor| Status: new Component: strict-transport-sec | Milestone: Severity: Waiting for Shepherd |Version: Writeup| Keywords: -+- Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/48 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? #choose ticket.new #when True (extension) directives are defined having this grammar.. token [ = ( token | quoted-string ) ] There is an argument against having quoted-string as part of the grammar. Justification is presented primarily in these messages.. https://www.ietf.org/mail-archive/web/websec/current/msg00781.html (Adam Barth) https://www.ietf.org/mail-archive/web/websec/current/msg00920.html (Adam Barth) ..but also in other messages in the same thread. Nominal summary of argument against inclusion of quoted-string is.. * presently-defined STS header directives don't employ quoted-string syntax * supporting use of quoted-string syntax raises questions of handling error conditions such as unbalanced quotation marks. * present HSTS implementations don't parse quoted-string STS directive values (e.g. max-age=13425) Argument for having quoted-string as a part of the grammar is.. * centered around HTTP header field consistency -- the generic header field syntax in RFC2616 (as well as in the in-progress httpbis update) incorporates quoted-string syntax as a part of header field value components. * because the HSTS header field grammar is extensible, and new directives can be defined in the future which may (need to) use quoted-string syntax. ..as noted here.. https://www.ietf.org/mail-archive/web/websec/current/msg00774.html (Julian Reschke) https://www.ietf.org/mail-archive/web/websec/current/msg00933.html (Julian Reschke) #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: reopened = closed * resolution: = fixed * severity: Active WG Document = In WG Last Call #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in =07 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:6 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #39: appropriately acknowlege and accommodate DANE
#39: appropriately acknowlege and accommodate DANE #choose ticket.new #when True see.. Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9 (paul hoffman) https://www.ietf.org/mail-archive/web/websec/current/msg01092.html This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST- compliant browsers to fail, even if those certificates cause matching when used with TLSA. Proposed replacements: 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a web application presenting a certificate that does chain to a trusted root or match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol]. . . . If a web site/organization/enterprise is generating their own secure transport public-key certificates for web sites, and that organization's root certification authority (CA) certificate is not typically embedded by default in browser CA certificate stores, and if HSTS Policy is enabled on a site identifying itself using a self- signed certificate, and the certificate presented by the TLS server does not match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol], then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above. However, if said organization strongly wishes to employ self-signed certificates, and their own CA in concert with HSTS, they can do so by deploying their root CA certificate to their users' browsers. They can also, in addition or instead, distribute to their users' browsers the end-entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once their root CA certificate is installed in the browsers, they may employ HSTS Policy on their site(s). Alternately, that organization can deploy the TLSA protocol; all browsers that also use TLSA will then be able to trust the self-signed certificates if it announced through TLSA. Note: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack, see Section 14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/39#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ?
#43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? #choose ticket.new #when True [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter snip/ Section 7.2 Does is make sense to mention that status code 308 might be appropriate in certain circumstances? See draft-reschke-http-status-308. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/43#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels
#44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels #choose ticket.new #when True [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter Section 9 The phrase valid Unicode-encoded string-serialized domain name seems a bit strange, because we don't typically refer to Unicode as an encoding scheme. See RFC 6365 regarding such terminology. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/44#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #45: HSTS: Alexey's editorial comments on -06
#45: HSTS: Alexey's editorial comments on -06 #choose ticket.new #when True See.. Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt https://www.ietf.org/mail-archive/web/websec/current/msg01173.html #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -08 -09 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/45#comment:3 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #46: HSTS: AppsDir Editorial comments
#46: HSTS: AppsDir Editorial comments #choose ticket.new #when True Editorial (minor issues) noted in Murray Kucherawy's AppsDir review.. [websec] AppsDir review of draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01147.html #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -09 #end #end #end -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/46#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels
#44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter Section 9 The phrase valid Unicode-encoded string-serialized domain name seems a bit strange, because we don't typically refer to Unicode as an encoding scheme. See RFC 6365 regarding such terminology. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: In WG Last | Call | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/44 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? Changes (by jeff.hodges@…): * status: closed = reopened * resolution: fixed = Comment: Need to re-fix STS grammar that appears in -06 (see entire thread rooted here)... https://www.ietf.org/mail-archive/web/websec/current/msg01096.html Also, the quoted-string debate continues... https://www.ietf.org/mail-archive/web/websec/current/msg01107.html -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: reopened Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:5 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #39: appropriately acknowlege and accommodate DANE
#39: appropriately acknowlege and accommodate DANE see.. Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9 (paul hoffman) https://www.ietf.org/mail-archive/web/websec/current/msg01092.html This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST- compliant browsers to fail, even if those certificates cause matching when used with TLSA. Proposed replacements: 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a web application presenting a certificate that does chain to a trusted root or match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol]. . . . If a web site/organization/enterprise is generating their own secure transport public-key certificates for web sites, and that organization's root certification authority (CA) certificate is not typically embedded by default in browser CA certificate stores, and if HSTS Policy is enabled on a site identifying itself using a self- signed certificate, and the certificate presented by the TLS server does not match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol], then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above. However, if said organization strongly wishes to employ self-signed certificates, and their own CA in concert with HSTS, they can do so by deploying their root CA certificate to their users' browsers. They can also, in addition or instead, distribute to their users' browsers the end-entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once their root CA certificate is installed in the browsers, they may employ HSTS Policy on their site(s). Alternately, that organization can deploy the TLSA protocol; all browsers that also use TLSA will then be able to trust the self-signed certificates if it announced through TLSA. Note: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack, see Section 14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: In WG Last | Call | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/39 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #40: Various editorial comments on -06
#40: Various editorial comments on -06 https://www.ietf.org/mail-archive/web/websec/current/msg01092.html - paul hoffman Editorial: annunciate (used a few times) is a fancy word for announce. Maybe use the far more common word instead. In section 3.1, suboptimal downside is unclear. Is there an optimal downside? I suggest replacing it with negative. The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are used in 11.1 and 11.3. This should be an easy fix. https://www.ietf.org/mail-archive/web/websec/current/msg01093.html - yoav nir Editorial: In the introduction 2nd paragraph it says (although modulo other rules). s/modulo/subject to/. Also, replace annunciate with announce or indicate. Both the introduction and section 8.2 say the policy applies to all TCP ports. Hosts have multiple TCP ports: for SSH as an example. I suggest we change to all HTTP(S) ports In the title of section 8.5, I think we can do without the word Interstitially. Section 10.1 begins with Server implementations and deploying web sites need to consider whether they are setting…. Searching for the alternative (because an implied or not doesn't work for this sentence) took me to the 4th paragraph of this section, and the top of page 21, which begins with Or, whether they are setting. This won't make it past the RFC editor, but I think it should be rephrased earlier. Section 14.1 discusses a UA behind an SSL proxy and implies that such a connection will cause warning screens (without HSTS) or hard failures. Such a deployment would be considered a wrong deployment of an SSL proxy. Administrators usually configure the UAs that are managed, and give detailed instructions to the owners of UAs that are not managed, so that the CA used by the proxy is trusted. There should be no warnings and no hard failures. https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter Section 1: This specification also incorporates notions from [JacksonBarth2008] in that policy is applied on an entire-host basis: it applies to all TCP ports of the issuing host. Please make it clear that all TCP ports does not mean all application protocols, only HTTP on all ports where it might be offered (not only the ports registered with the IANA). Section 7.2 Does is make sense to mention that status code 308 might be appropriate in certain circumstances? See draft-reschke-http-status-308. Section 8.4 The HTTP-Equiv Meta Element Attribute is defined in the HTML specification, so a reference would be helpful. Section 9 The phrase valid Unicode-encoded string-serialized domain name seems a bit strange, because we don't typically refer to Unicode as an encoding scheme. See RFC 6365 regarding such terminology. Section 11.1 I think the text about no user recourse conflates two things: showing a warning, and allowing the user to click through: the user should not be presented with an explanatory dialog giving her the option to proceed. Would it be OK for a user agent to show an explanatory dialog but not provide an option to proceed? Is there a security reason to fail the connection without any explanation? Section 11.5 The note it worded a bit oddly (e.g., it shouldn't be possible for an attacker to inject script... might be better worded along the lines of implementations need to guard against alowing an attacker to inject script...). -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: In WG Last | Call | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/40 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #37: Clarify that superdomain HSTS flag does not update max-age of subdomain's HSTS max-age and vice versa
#37: Clarify that superdomain HSTS flag does not update max-age of subdomain's HSTS max-age and vice versa The case is the following: A UA notes a superdomain e.g. example.com as a Known HSTS Host, with includeSubDomains. Then after that the UA also receives a HSTS header from subdomain foo.example.com (with or without includeSubDomains) and new max-age (longer or shorter time). The point is in that case the HSTS timer of the superdomain (example.com) MUST NOT be changed (extended or shortened) to the timer used in the subdomain. In fact the UA MUST keep both timers in cache independently and if at some point either one of them is removed (be due to expiry or because of an update setting max-age=0), the second remaining HSTS value MUST still be kept intact and applied. This is mainly to prevent that a subdomain can invalidate the HSTS flag of the superdomain or make it expire and vice versa. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- tobias.gondrom@… | sec@… Type: enhancement | Status: new Priority: major| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: -| -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/37 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? Comment (by jeff.hodges@…): Further nits wrt STS header ABNF are in the thread rooted here.. [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 https://www.ietf.org/mail-archive/web/websec/current/msg01020.html the crux being.. STS: foo ; parses, but STS: ; foo does not. This could be fixed by saying: Strict-Transport-Security = Strict-Transport-Security : *( ; [ directive ] ) -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:3 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #2: Effective Request URI definition dependency on HTTPbis spec ?
#2: Effective Request URI definition dependency on HTTPbis spec ? Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- --+- Reporter: jeff.hodges@… | Owner: =JeffH Type: task | Status: closed Priority: minor | Milestone: Component: strict-transport-sec | Version: Severity: Active WG Document| Resolution: fixed Keywords:| --+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/2#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #4: Clarify that HSTS policy applies to entire host (all ports)
#4: Clarify that HSTS policy applies to entire host (all ports) Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- --+- Reporter: jeff.hodges@… | Owner: =JeffH Type: defect| Status: closed Priority: major | Milestone: Component: strict-transport-sec | Version: Severity: Active WG Document| Resolution: fixed Keywords:| --+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/4#comment:3 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #8: clarify/explain behavior when STS header not returned by known HSTS Host
#8: clarify/explain behavior when STS header not returned by known HSTS Host Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- --+- Reporter: jeff.hodges@… | Owner: =JeffH Type: defect| Status: closed Priority: major | Milestone: Component: strict-transport-sec | Version: Severity: Active WG Document| Resolution: fixed Keywords:| --+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/8#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #36: HSTS: fixup references
#36: HSTS: fixup references Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/36#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
#34: HSTS cache manipulation and misuse by server enabled by wildcard cert Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:4 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #31: HSTS: mention case insesitivity in prose for max-age and includeSubDomains
#31: HSTS: mention case insesitivity in prose for max-age and includeSubDomains Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/31#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #29: HSTS: dismbiguate mixed content term provide reference
#29: HSTS: dismbiguate mixed content term provide reference Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/29#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #28: HSTS spec unclear about the denotation of HSTS policy
#28: HSTS spec unclear about the denotation of HSTS policy Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/28#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken
#27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:3 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #14: Effective Request URI definition issues
#14: Effective Request URI definition issues Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor| Milestone: Component: strict- | Version: 2.0 transport-sec | Resolution: fixed Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/14#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #12: Remove dependencies on HTTPbis and depend on RFC2616 only
#12: Remove dependencies on HTTPbis and depend on RFC2616 only Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/12#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #11: failing insecure connections and user recourse
#11: failing insecure connections and user recourse Changes (by jeff.hodges@…): * status: new = closed * resolution: = fixed -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/11#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #36: HSTS: fixup references
#36: HSTS: fixup references Comment (by jeff.hodges@…): Alexey notes that I too-ruthlessly moved refs from Normative to Informative. See https://www.ietf.org/mail- archive/web/websec/current/msg01023.html. -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/36#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? Comment (by jeff.hodges@…): Subsequent additional discussion is in thread rooted here.. [websec] of quoted-string header field param value syntax (was: Strict- Transport-Security syntax redux) https://www.ietf.org/mail-archive/web/websec/current/msg00975.html -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #36: HSTS: fixup references
#36: HSTS: fixup references see.. [websec] draft-ietf-websec-strict-transport-sec-03 reference nits, Julian Reschke https://www.ietf.org/mail-archive/web/websec/current/msg00919.html -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: Active WG| Document | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/36 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #33: HSTS: quoted-string grammar in (extension) directives ?
#33: HSTS: quoted-string grammar in (extension) directives ? (extension) directives are defined having this grammar.. token [ = ( token | quoted-string ) ] There is an argument against having quoted-string as part of the grammar. Justification is presented primarily in these messages.. https://www.ietf.org/mail-archive/web/websec/current/msg00781.html (Adam Barth) https://www.ietf.org/mail-archive/web/websec/current/msg00920.html (Adam Barth) ..but also in other messages in the same thread. Nominal summary of argument against inclusion of quoted-string is.. * presently-defined STS header directives don't employ quoted-string syntax * supporting use of quoted-string syntax raises questions of handling error conditions such as unbalanced quotation marks. * present HSTS implementations don't parse quoted-string STS directive values (e.g. max-age=13425) Argument for having quoted-string as a part of the grammar is.. * centered around HTTP header field consistency -- the generic header field syntax in RFC2616 (as well as in the in-progress httpbis update) incorporates quoted-string syntax as a part of header field value components. * because the HSTS header field grammar is extensible, and new directives can be defined in the future which may (need to) use quoted-string syntax. ..as noted here.. https://www.ietf.org/mail-archive/web/websec/current/msg00774.html (Julian Reschke) https://www.ietf.org/mail-archive/web/websec/current/msg00933.html (Julian Reschke) -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: Active WG| Document | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken
#27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken Comment (by jeff.hodges@…): The portion of Julian's feedback, as identified in http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:1 (above) that pertains to quoted-string grammar, is now forked off into this separate issue ticket #33.. http://trac.tools.ietf.org/wg/websec/trac/ticket/33 The other portions of his comments are still under this ticket at this time (see any comments below for any changes) -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken
#27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken Comment (by jeff.hodges@…): draft-ietf-websec-strict-transport-sec-03 contains fixes for the issues described in this ticket. Julian Reschke has reviewed -03, and provides feedback in this message.. Strict-Transport-Security syntax redux [Julian Reschke] https://www.ietf.org/mail-archive/web/websec/current/msg00918.html ..see also subsequent discussion in that email thread. -- -+- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: -| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #32: HSTS: explain some practical implications of includeSubDomains directive
#32: HSTS: explain some practical implications of includeSubDomains directive the includeSubDomains directive has some practical implications -- for example, if a HSTS host offers http-based services on various ports, then they will all have to be TLS/SSL-based in order to work properly. For example, certification authorities often offer their CRL distribution and OCSP services over plain HTTP, and sometimes at a subdomain of a publicly-available web application which may be secured by TLS/SSL. E.g. https://example-ca.com/ is a publicly-available web application for Example CA, a certification authority. Customers use this web application to register their public keys and obtain certificates. Example CA generates certificates for customers containing http://crl-and-ocsp .example-ca.com/ as the value for the CRL Distribution Points and Authority Information Access:OCSP certificate fields. If example-ca.com were to issue an HSTS Policy with the includeSubDomains directive, then HTTP-based user agents implementing HSTS, and that have interacted with the example-ca.com web application, would fail to retrieve CRLs and fail to check OCSP for certificates because these services are offered over plain HTTP. In this case, Example CA can either.. * not use the includeSubDomains directive, or, * ensure HTTP-based services offered at subdomains of example-ca.com are uniformly offered over TLS/SSL, or, * offer plain HTTP-based services at a different domain name, e.g. example-ca-services.net. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: Active WG| Document | -+- Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/32 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken
#27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken HSTS header ABNF in -02 HSTS spec revision is a hybrid of RFC2616 and httpbis and is overly complex and broken See these messages for details Strict-Transport-Security syntax redux [Ryan Sleevi] https://www.ietf.org/mail-archive/web/websec/current/msg00614.html Strict-Transport-Security syntax redux [Julian Reschke] https://www.ietf.org/mail-archive/web/websec/current/msg00673.html -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: -| -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #28: HSTS spec unclear about the denotation of HSTS policy
#28: HSTS spec unclear about the denotation of HSTS policy Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html The document is a bit unclear about the denotation of HSTS policy. Sometimes it refers to the site's policy and sometimes to the overall recommendations defined in the spec. This specification also incorporates notions from [JacksonBarth2008] in that the HSTS policy is applied on an entire-host basis: it applies to all TCP ports on the host. Additionally, HSTS policy can be applied to the entire domain name subtree rooted at a given host name. This enables HSTS to protect so-called domain cookies, which are applied to all subdomains of a given domain. Perhaps it would be helpful to contrast the all ports and entire subtree principles with the same origin policy also being worked on in this WG, with an informational reference to the appropriate spec. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: -| -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/28 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #30: HSTS: add an informational reference to RFC 4732: Denial-of-Service Considerations
#30: HSTS: add an informational reference to RFC 4732: Denial-of-Service Considerations Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html SECTION 12.2 Let's add an informational reference to RFC 4732. Can we add some more details to the description of the denial of service attack? IMHO it's a bit thin. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: -| -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/30 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #31: HSTS: mention case insesitivity in prose for max-age and includeSubDomains
#31: HSTS: mention case insesitivity in prose for max-age and includeSubDomains Re: [websec] Strict-Transport-Security syntax redux [JulianR] https://www.ietf.org/mail-archive/web/websec/current/msg00765.html 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. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor| Milestone: Component: strict- |Version: transport-sec | Keywords: Severity: -| -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/31 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #25: what, if any, sniffing for fonts is required?
#25: what, if any, sniffing for fonts is required? The current spec has a stub for sniffing fonts. The use case for this was @font-face, CSS' font linking feature. The request came in http://www.ietf.org/mail- archive/web/websec/current/msg00235.html However, That seems very anecdotal. Do you have data to back up these claims? (in this case, data = significant use cases where sniffing is necessary). http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0005.html http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0012.html Reading those, it looks like there was some disagreement about what types ought to be registered. This seems like a case where there are multiple type definitions which can be distinguished by magic number or other usage patterns, and the question is whether to register them as separate types or to use a single type and disambiguate later in the process at the receiver. In any case, we need to resolve what font sniffing is necessary, what should be sniffed, etc. -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: https://trac.tools.ietf.org/wg/websec/trac/ticket/25 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #17: Use the magic numbers in the media type IANA registry instead of an explicit table
#17: Use the magic numbers in the media type IANA registry instead of an explicit table The Internet Media Type IANA registry contains a field for Magic Number which is intended to represent how the type can be sniffed. The tables in this document and the IANA registry should be aligned, although perhaps the IANA registry should be expanded to annotate whether the Magic Number information in the IANA registry is suitable for sniffing. Otherwise, how could one ever sniff a new MIME type ? -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/17 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #18: Describe use of file extension in sniffing from file: and ftp: URIs
#18: Describe use of file extension in sniffing from file: and ftp: URIs while file extensions should not be used in sniffing data over http:, this isn't the case for ftp and file system access, I don't believe. -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/18 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #19: Do not sniff PDF
#19: Do not sniff PDF There should be a strong advice not to sniff PDF -- if the data is mislabeled as something else, then sending it to a PDF interpreter is likely just an error. -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: minor | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/19 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #20: Sniffing should be opt in on a case-by-case basis
#20: Sniffing should be opt in on a case-by-case basis The way the document is written as a normative algorithm makes it hard to say this, but: Every implementation should be free to opt out of sniffing based on other information it has (previous experience with the site, information based on whether a correct MIME type was given vs. misconfigured, etc.) From the point of view of a web site, there's no additional security or danger from opting out on a case-by-case basis; it's the same as, on a case-by-case basis, choosing between two implementations, one of which always sniffs and the other never sniffs. -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/20 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml
#21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml (I have to double check that this is true): In general, sniffing is dangerous in polyglot cases where the same content CAN be served with different media types, where the meaning is the same or related. For example, there are types for packaged formats that use ZIP and thus have the ZIP magic number but aren't served as ZIP, text/plain is sometimes used to deliver examples of otherwise mal-formed XML, etc. It would seem better to discourage sniffing in cases where the content is valid for the type that it's actually labeled, and to treat that as a special case. (One still might want to sniff text/html when the type is labeled text/plain, for example, but not for other polyglot cases.) -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/21 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #22: content-type sniffing should include charset sniffing
#22: content-type sniffing should include charset sniffing the HTML5 spec contains some algorithms for sniffing charset, overriding labeled charset, etc. MIME parameters like charset are as much a part of the content-type as the base internet media type, and any sniffing of parameters and other metadata (overriding content-type or guessing where it is not supplied or wrong) should be included in this document, since the sniffing will happen at the same time. -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/22 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #24: ensure XML packaging is in scope
#24: ensure XML packaging is in scope http://www.w3.org/TR/widgets/ Widget Packaging and XML Configuration makes normative reference to (some version) of this document, as: [SNIFF]Media Type Sniffing. A. Barth and I. Hickson. IETF (Work in Progress). Make sure it is clear that the use case for XML packaging in ZIP files is in scope, and that the use case is justified (since misconfigured HTTP servers don't come into play at all.) -- + Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: minor | Milestone: Component: mime-sniff |Version: Severity: - | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/24 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #15: Clarify scope of MIME sniffing
#15: Clarify scope of MIME sniffing Comment (by ietf@…): However, the document itself covers many situations beyond misconfigured web content. In my view, bullets 1 through 3 arise from misconfigured web servers. For bullet 1, there's lots of examples of servers supplying a syntactically correct but erroneous MIME type, where I judge the supplied MIME type to be erroneous because obeying the MIME type causes the site to behave in undesirable ways, e.g., having broken images because the site uses a resource as an image but the resource has a Content-Type that says text/plain. For bullet 2, a syntacticly invalid Content-Type header is manifestly caused by a misconfigured server. For bullet 3, a correctly configured web server will always supply the correct MIME type with a response, but that's just a matter of semantics. I'll agree that bullet 4 is a distinct use case and might be valuable to point out in the introduction. -- -+- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major| Milestone: Component: mime-sniff | Version: Severity: Active WG| Resolution: Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/15#comment:2 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #16: lack of explanatory text and no justifications for the normative language
#16: lack of explanatory text and no justifications for the normative language Comment (by ietf@…): There's a lot of discussion of the rationale in this document: http://www.adambarth.com/papers/2009/barth-caballero-song.pdf I'm not opposed to importing that information into this document. -- -+- Reporter: | Owner: draft-ietf-websec-mime-sniff@… tobias.gondrom@… | Status: new Type: defect | Milestone: Priority: major| Version: Component: mime-sniff | Resolution: Severity: Active WG| Document | Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/16#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #16: lack of explanatory text and no justifications for the normative language
#16: lack of explanatory text and no justifications for the normative language Filing this issue on behalf, as submitted by Pete Resnik: (no objection to progressing *a* MIME sniffing draft in the IETF as an RFC.) He does have an objection to progressing this MIME sniffing draft in its current form. It has an algorithm with no explanatory text and no justifications for any of the normative language it gives. That's not a protocol. Surely the author and other folks who think this work is important know *why* the algorithm is written the way it is. All that I am asking is for that knowledge be written in the document to explain. Then, if someone is in an environment that is different from the one anticipated by the draft, be it more restrictive or less, they can figure out what the right thing to do is and the draft can be updated appropriately. The current form simply doesn't allow that. [Tobias] To discuss or to do: add some more justification and explanation text at RFC2119 statements? -- --+ Reporter: tobias.gondrom@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect| Status: new Priority: major | Milestone: Component: mime-sniff|Version: Severity: Active WG | Keywords: Document| --+ Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/16 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #15: Clarify scope of web sniffing
#15: Clarify scope of web sniffing This issue may be broken down into several (is X in scope?) but this issue is meant to cover the overall question to start with. The introduction to the document cites the existence of mis-configured web content served via HTTP as the primary justification for sniffing. However, the document itself covers many situations beyond misconfigured web content. * web sites where content-type values are syntactically correct but believed to be different from what was intended (because the content itself doesn't match) * situations where HTTP protocol content-type is syntactically incorrect, duplicate, malformed. * situations where no content-type is supplied at all via HTTP. * situations where the content is not being delivered via HTTP at all, but via other protocols. There are a number of these situations, including web accesible material delivered via ftp:, file: (on thumb drives?). The internet-draft is currently normatively required by a W3C recommendation on zip packaging, for example. So the basic question is: what is the scope? The bug in the specification is that the introduction and justification don't match the apparent intent of the scope of the body. -- --+ Reporter: masinter@…| Owner: draft-ietf-websec-mime-sniff@… Type: defect| Status: new Priority: major | Milestone: Component: mime-sniff|Version: Severity: Active WG | Keywords: Document| --+ Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/15 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #15: Clarify scope of MIME sniffing (was: Clarify scope of web sniffing)
#15: Clarify scope of MIME sniffing -- -+- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major| Milestone: Component: mime-sniff | Version: Severity: Active WG| Resolution: Document | Keywords: | -+- Ticket URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/15#comment:1 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] #6: cite FireSheep as real-life threat HSTS addresses
#6: cite FireSheep as real-life threat HSTS addresses cite FireSheep as real-life threat HSTS addresses, in response to this query: http://www.ietf.org/mail-archive/web/hasmat/current/msg00074.html Subject: [HASMAT] HSTS Threat prevalence From: Devdatta Akhawe dev.akh...@gmail.com Date: Fri, 6 Aug 2010 11:36:12 -0700 To: IETF HASMAT list has...@ietf.org Hi all The HSTS specification talks about possible attacks that could be prevented by the use of HSTS. Do we have any data that suggests these attacks are actually a concern / being used by attackers anywhere ? I couldn't find any citation to this effect in the specification. -- ---+ Reporter: jeff.hodges@… | Owner: =JeffH Type: defect | Status: new Priority: major | Milestone: Component: strict-transport-sec | Version: Severity: - |Keywords: ---+ Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/6 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
