Re: [websec] #54: Specify a report-only mode

[websec issue tracker]

#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: 
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

[websec issue tracker]

#57: Re-add an upper limit to max-age

Changes (by pal...@google.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The new language satisfies the rough consensus in the WG.

-- 
+
 Reporter:  pal...@google.com   |   Owner:  pal...@google.com
 Type:  defect  |  Status:  closed
 Priority:  major   |   Milestone:
Component:  key-pinning | Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:  |
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #60: Well Known URIs vs Response Headers

[websec issue tracker]

#60: Well Known URIs vs Response Headers

Changes (by y...@checkpoint.com):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Although we accept that this will be hard to change in the future, the
 browser developers on the list argued that the disadvantages would
 outweigh the advantages. Specifically:

  * Sending the HPKP header in every request is not a big deal, and
  * Having to do the fetching of the policy resource out of band is
 complicated
 With  no consensus to change, we decided to keep the current design.

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-key-
  y...@checkpoint.com|  pinn...@tools.ietf.org
 Type:  enhancement  |  Status:  closed
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  In WG Last   |  Resolution:  wontfix
  Call   |
 Keywords:  HPKP |
  RFC5785|
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #58: Should we pin only SPKI, or also names

[websec issue tracker]

#58: Should we pin only SPKI, or also names

Changes (by y...@checkpoint.com):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 In the end we decided to leave this for a future extension, as we don't
 currently have a good framework for mapping names to keys

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-key-
  y...@checkpoint.com|  pinn...@tools.ietf.org
 Type:  enhancement  |  Status:  closed
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  In WG Last   |  Resolution:  wontfix
  Call   |
 Keywords:  HPKP |
-+-

Ticket URL: 
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

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors

Changes (by pal...@google.com):

 * status:  assigned => closed
 * resolution:   => fixed


-- 
---+
 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: 
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

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors


Comment (by pal...@google.com):

 The current draft has this text:

  578 If 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 ), then the UA MUST perform Pin
 Validation.

 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #56: Specify includeSubdomains directive for HPKP

[websec issue tracker]

#56: Specify includeSubdomains directive for HPKP

Changes (by pal...@google.com):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 There seems to be consensus that this is done.

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  closed
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:  fixed
 Keywords:  includeSubdomains  |
---+

Ticket URL: 
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

[websec issue tracker]

#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=svnfc4bef2ce138d467182832a362831b6d63ea9cdc&r=fc4bef2ce138d467182832a362831b6d63ea9cdc&format=side&path
 =/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: 
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

[websec issue tracker]

#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=svn4f697cf66f747c18a5389922f484d9a1dbe85968&r=83bad3527ede8bb6ef52a8c220990ccd8762d9e7&format=side&path
 =/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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #56: Specify includeSubdomains directive for HPKP

[websec issue tracker]

#56: Specify includeSubdomains directive for HPKP


Comment (by pal...@google.com):

 I have added language to the working copy of the draft
 (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-
 websec-key-pinning.xml) in the Security Considerations section.

-- 
---+
 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #56: Specify includeSubdomains directive for HPKP

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #57: Re-add an upper limit to max-age

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #52: Clarification of section 2.3.1

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #56: Specify includeSubdomains directive for HPKP

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #56: Specify includeSubdomains directive for HPKP

[websec issue tracker]

#56: Specify includeSubdomains directive for HPKP

 Example:

 Google.com PKP = key A, key B, includesubdomains
 WWW.Google.com PKP = key C

 Effective PKP?

 1) A, B, C (union)
 2) C (most specific)
 3) none (intersection)

 We think (2) is best.

-- 
-+---
 Reporter:  palmer@… |  Owner:  palmer@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:
Component:  key-pinning  |Version:
 Severity:  -|   Keywords:  includeSubdomains
-+---

Ticket URL: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #55: Clarify that the newest pinning information takes precedence

[websec issue tracker]

#55: Clarify that the newest pinning information takes precedence

 In section "Interactions With Preloaded Pin Lists", we need to specify
 that the newest information, even "stop pinning", must take precedence. I
 propose this text:

 UAs MUST use the newest information — built-in or set via Valid Pinning
 Header — when performing Pin Validation for the host. If the result of
 noting a Valid Pinning Header is to disable pinning for the host (such as
 because the host set a max-age directive with a value of 0), UAs MUST
 allow this new  nformation to override any built-in pins. That is, a host
 must be able to un-pin itself even from built-in pins.

-- 
-+--
 Reporter:  palmer@… |  Owner:  palmer@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:
Component:  key-pinning  |Version:
 Severity:  -|   Keywords:
-+--

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #54: Specify a report-only mode

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #54: Specify a report-only mode

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #52: Clarification of section 2.3.1

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #51: Clarification of section 2.4 (ignore pins where SPKI is insufficient) (was: Clarification of section 2.4)

[websec issue tracker]

#51: Clarification of section 2.4 (ignore pins where SPKI is insufficient)

Changes (by palmer@…):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 I have fixed this in the draft that will go out later today.

-- 
-+---
 Reporter:  Tom Ritter   |   Owner:  palmer@…
 Type:  defect   |  Status:  closed
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:  fixed
 Keywords:   |
-+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #51: Clarification of section 2.4

[websec issue tracker]

#51: Clarification of section 2.4

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #50: Handling of pinning DSA public keys (was: Handing of pinning DSA public keys)

[websec issue tracker]

#50: Handling of pinning DSA public keys


-- 
-+---
 Reporter:  Tom Ritter   |   Owner:  palmer@…
 Type:  defect   |  Status:  closed
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:  fixed
 Keywords:   |
-+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #50: Handing of pinning DSA public keys

[websec issue tracker]

#50: Handing of pinning DSA public keys

Changes (by palmer@…):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Added this note to the draft. I'll send out a new version of the draft
 later on today.

-- 
-+---
 Reporter:  Tom Ritter   |   Owner:  palmer@…
 Type:  defect   |  Status:  closed
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:  fixed
 Keywords:   |
-+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #50: Handing of pinning DSA public keys

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #52: Clarification of section 2.3.1

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #51: Clarification of section 2.4

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #50: Handing of pinning DSA public keys

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #49: HSTS: mention OCSP stapling aka "Certificate Status Request" TLS extension

[websec issue tracker]

#49: HSTS: mention OCSP stapling aka "Certificate Status Request" TLS extension

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: 
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

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #42: STS exception for CRL fetching

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #49: HSTS: mention OCSP stapling aka "Certificate Status Request" TLS extension

[websec issue tracker]

#49: HSTS: mention OCSP stapling aka "Certificate Status Request" TLS extension

 OCSP stapling aka "Certificate Status Request" TLS extension is yet
 another means for a CA to address the issues illustrated in the example in
 section "10.3.  Implications of includeSubDomains".

 Should at least mention that and informatively reference RFC6066.

-- 
-+-
 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: 
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

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #46: HSTS: AppsDir Editorial comments

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #45: HSTS: Alexey's editorial comments on -06

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
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 ?

[websec issue tracker]

#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
 
 >
 > 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #40: Various editorial comments on -06

[websec issue tracker]

#40: Various editorial comments on -06

#choose ticket.new
  #when True
 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  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...").
  #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:  minor|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:  fixed
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #37: Clarify that superdomain HSTS flag does not update max-age of subdomain's HSTS max-age and vice versa

[websec issue tracker]

#37: Clarify that superdomain HSTS flag does not update max-age of subdomain's
HSTS max-age and vice versa

#choose ticket.new
  #when True
 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.
  #end
  #otherwise
#if changes_body
Changes (by jeff.hodges@…):

 * status:  new => closed
 * resolution:   => fixed
 * severity:  - => 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-
  tobias.gondrom@…   |  transport-sec@…
 Type:  enhancement  |  Status:  closed
 Priority:  major|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:  fixed
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #39: appropriately acknowlege and accommodate DANE

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #46: HSTS: AppsDir Editorial comments

[websec issue tracker]

#46: HSTS: AppsDir Editorial comments

 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

-- 
-+-
 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #45: HSTS: Alexey's editorial comments on -06

[websec issue tracker]

#45: HSTS: Alexey's editorial comments on -06


Comment (by jeff.hodges@…):

 alexey's feedback referred to above is here:

   https://www.ietf.org/mail-archive/web/websec/current/msg01185.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:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #45: HSTS: Alexey's editorial comments on -06

[websec issue tracker]

#45: HSTS: Alexey's editorial comments on -06


Comment (by jeff.hodges@…):

 Alexey notes that all his issues were addressed in rev -08 except for
 needing to explicitly state that "unrecognized directives are to
 be ignored" where they are defined as "syntactically valid but undefined
 in the specfication" (my interpretation of how to state what he means).

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-strict-
  jeff.hodges@…  |  transport-sec@…
 Type:  defect   |  Status:  new
 Priority:  minor|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #45: HSTS: Alexey's editorial comments on -06

[websec issue tracker]

#45: HSTS: Alexey's editorial comments on -06

 See..

 Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt
 https://www.ietf.org/mail-archive/web/websec/current/msg01173.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:  In WG Last   |
  Call   |
-+-

Ticket URL: 
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 ?

[websec issue tracker]

#43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ?


Comment (by julian.reschke@…):

 In a perfect world yes :-) But 308 is new, experimental, not well
 supported, and introduces an indirect dependency on HTTPbis.

 Proposal: rephrase the normative requirement so that sending 308 instead
 of 301 is *possible* (say "permanent redirect", and list 301 as example).

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-strict-
  jeff.hodges@…  |  transport-sec@…
 Type:  enhancement  |  Status:  new
 Priority:  minor|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #40: Various editorial comments on -06

[websec issue tracker]

#40: Various editorial comments on -06


Comment (by jeff.hodges@…):

 forked two items to their own tickets...


 > 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.

 forked to Ticket #43
 http://trac.tools.ietf.org/wg/websec/trac/ticket/43

 > 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.

 forked to ticket #44
 http://trac.tools.ietf.org/wg/websec/trac/ticket/44

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-strict-
  jeff.hodges@…  |  transport-sec@…
 Type:  defect   |  Status:  new
 Priority:  minor|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ?

[websec issue tracker]

#43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ?

 [ 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 7.2
 >
 > Does is make sense to mention that status code 308 might be
 > appropriate in certain circumstances? See draft-reschke-http-status-308.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…  |  sec@…
 Type:  enhancement  | Status:  new
 Priority:  minor|  Milestone:
Component:  strict-  |Version:
  transport-sec  |   Keywords:
 Severity:  In WG Last   |
  Call   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #42: STS exception for CRL fetching

[websec issue tracker]

#42: STS exception for CRL fetching


Comment (by tobias.gondrom@…):

 just a personal comment:
 Just to be complete: CRL fetching does not necessarily mean a complete
 break of HSTS if CRLs come from the same server. A server could still use
 HSTS without the subdomain directive and publish the CRLs/OCSP on a
 different subdomain. Though I admit that would be a significant limitation
 of HSTS. :-(

-- 
-+-
 Reporter:   |   Owner:  draft-ietf-websec-strict-
  jeff.hodges@…  |  transport-sec@…
 Type:  enhancement  |  Status:  new
 Priority:  major|   Milestone:
Component:  strict-  | Version:
  transport-sec  |  Resolution:
 Severity:  In WG Last   |
  Call   |
 Keywords:   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #38: HSTS : Editorial Comments

[websec issue tracker]

#38: HSTS : Editorial Comments

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #42: STS exception for CRL fetching

[websec issue tracker]

#42: STS exception for CRL fetching

 https://www.ietf.org/mail-archive/web/websec/current/msg01093.html - yoav
 nir

 Section 10.3 discusses the case where the server or some subdomain also
 hosts CRLs or OCSP and suggests some work-around to the "all TCP" port
 requirement. Fetching CRLs is a different context than rendering a web
 page. I think the suggestions should be removed and a sentence added that
 says that the STS policy does not apply to fetching of revocation
 information by the browser. I think this would be far easier to implement.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…  |  sec@…
 Type:  enhancement  | Status:  new
 Priority:  major|  Milestone:
Component:  strict-  |Version:
  transport-sec  |   Keywords:
 Severity:  In WG Last   |
  Call   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #41: add parameter indicating whether to hardfail or not

[websec issue tracker]

#41: add parameter indicating whether to hardfail or not

 https://www.ietf.org/mail-archive/web/websec/current/msg01093.html - yoav
 nir

 The significant:

 I have said this before, and was rejected by the group, so I'll raise this
 one last time here.
 Section 8.3 makes it a MUST-level requirement that any failure of the
 underlying secure transport. Section 11.1 clarifies that there should be
 no user recourse for this. This makes the cost of implementing
 unreasonably high, and significantly discourages trial roll-outs. Adding
 an HSTS header to your web site takes about 2 lines of configuration file
 in Apache. But doing so makes small errors like letting the certificate
 lapse or using links with a different FQDN cause hard failures. Both these
 sections do now state specifically what constitutes a failure, so it might
 be that the intention was not to include expirations. I think this should
 be clarified, but mismatched names obviously apply.
 I suggest that either we remove the no user recourse advice, or else add a
 "hardfail" directive. Roll out with "hardfail=no", and if people don't
 complain, change to "hardfail=yes"

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…  |  sec@…
 Type:  enhancement  | Status:  new
 Priority:  major|  Milestone:
Component:  strict-  |Version:
  transport-sec  |   Keywords:
 Severity:  In WG Last   |
  Call   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #40: Various editorial comments on -06

[websec issue tracker]

#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  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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #39: appropriately acknowlege and accommodate DANE

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #38: HSTS : Editorial Comments

[websec issue tracker]

#38: HSTS : Editorial Comments

 Tobias wrote up various editorial comments on rev -05 here..

 https://www.ietf.org/mail-archive/web/websec/current/msg01076.html

 Note: the technical comment at the very end is represented separately by
 ticket #37.

-- 
-+-
 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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #10: note that end-entity certs can be dristrib'd to http clients ?

[websec issue tracker]

#10: note that end-entity certs can be dristrib'd to http clients ?

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #11: failing insecure connections and user recourse

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #13: clarify that max-age=0 will cause UA to forget a known HSTS host

[websec issue tracker]

#13: clarify that max-age=0 will cause UA to forget a known HSTS host

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #14: Effective Request URI definition issues

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
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"

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #29: HSTS: dismbiguate "mixed content" term & provide reference

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #30: HSTS: add an informational reference to RFC 4732: Denial-of-Service Considerations

[websec issue tracker]

#30: HSTS: add an informational reference to RFC 4732: Denial-of-Service
Considerations

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: 
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"

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #32: HSTS: explain some practical implications of includeSubDomains directive

[websec issue tracker]

#32: HSTS: explain some practical implications of includeSubDomains directive

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #35: HSTS spec could be more clear about UA behavior behind proxies

[websec issue tracker]

#35: HSTS spec could be more clear about UA behavior behind proxies

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #36: HSTS: fixup references

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #26: reference IDNA2008 as well as IDNA2003

[websec issue tracker]

#26: reference IDNA2008 as well as IDNA2003

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #9: explicitly note revocation check failures as errors causing connection termination?

[websec issue tracker]

#9: explicitly note revocation check failures as errors causing connection
termination?

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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #7: clarify and add examples/justification wrt connection termination due to tls warnings/errors

[websec issue tracker]

#7: clarify and add examples/justification wrt connection termination due to
tls warnings/errors

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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #6: cite FireSheep as real-life threat HSTS addresses

[websec issue tracker]

#6: cite FireSheep as real-life threat HSTS addresses

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:  - |  Resolution:  fixed
 Keywords:|
--+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #5: Clarify need for IncludeSubDomains

[websec issue tracker]

#5: Clarify need for IncludeSubDomains

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:  - |  Resolution:  fixed
 Keywords:|
--+-

Ticket URL: 
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)

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #3: Better Effective Request URI definition

[websec issue tracker]

#3: Better Effective Request URI definition

Changes (by jeff.hodges@…):

 * status:  new => closed
 * resolution:   => fixed


-- 
--+-
 Reporter:  jeff.hodges@… |   Owner:  =JeffH
 Type:  defect|  Status:  closed
 Priority:  minor |   Milestone:
Component:  strict-transport-sec  | Version:
 Severity:  - |  Resolution:  fixed
 Keywords:|
--+-

Ticket URL: 
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 ?

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #1: port mapping should be explicit about case where URI does not contain explicit port

[websec issue tracker]

#1: port mapping should be explicit about case where URI does not contain
explicit port

Changes (by jeff.hodges@…):

 * status:  new => closed
 * resolution:   => fixed


-- 
--+-
 Reporter:  jeff.hodges@… |   Owner:  =JeffH
 Type:  defect|  Status:  closed
 Priority:  minor |   Milestone:
Component:  strict-transport-sec  | Version:
 Severity:  Active WG Document|  Resolution:  fixed
 Keywords:|
--+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #36: HSTS: fixup references

[websec issue tracker]

#36: HSTS: fixup references


Comment (by jeff.hodges@…):

 Alexey notes that I too-ruthlessly moved refs from Normative to
 Informative. See .

-- 
-+-
 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#33: HSTS: quoted-string grammar in (extension) directives ?


Comment (by julian.reschke@…):

 Related Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=718409

-- 
-+-
 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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #36: HSTS: fixup references

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #35: HSTS spec could be more clear about UA behavior behind proxies

[websec issue tracker]

#35: HSTS spec could be more clear about UA behavior behind proxies

 UA won't note a well-behaving but unknown HSTS Host as an HSTS Host if the
 UA is behind a proxy such that secure transport warnings/errors exist.
 overall behavior and design rationale could be better explained in 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:  Active WG|
  Document   |
-+-

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert

[websec issue tracker]

#34: HSTS cache manipulation and misuse by server enabled by wildcard cert

 See..

 The Double-Edged Sword of HSTS Persistence and Privacy --  by Mikhail
 Davidov
 http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-
 privacy/

 summary:

 This technique allows a web app on one domain to surreptitiously send a
 message to another web app on another domain via manipulation of the HSTS
 cache...

 If server wields a wildcard cert, eg for "*.example.com", then example.com
 can create any number of subdomains of example.com, with any subdomain
 name, and then direct user agents to fetch resources from these
 subdomains. If HSTS Policy is returned for each of these subdomains, and
 includeSubDomains is not used, then any number of entries will be created
 in in the user agent's HSTS store. E.g., an web page like the below would
 accomplish this..

   [img]https://charcount-5.example.com/setbit.png[/img]  -- this
 stores the char count of the msg

   [img]https://0-H.example.com/setbit.png[/img]
   [img]https://1-E.example.com/setbit.png[/img]
   [img]https://2-L.example.com/setbit.png[/img]
   [img]https://3-L.example.com/setbit.png[/img]
   [img]https://4-O.example.com/setbit.png[/img]


 These entries can be read back by some other web application under some
 other domain name by causing the user agent to send HTTP requests to
 example.com in order to brute-force the character count subdomain name --
 the server responds whether the name is available over just http -- which
 means it is a miss, or over HTTPS, which is a hit..

   http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS!
 ]   -- msg char count is 5

 Then the web app can brute force each character of the message in a
 similar fashion.

 the original message-sending domain web app can clear the cached message
 by causing the user agent to re-request resources from the same dubdomains
 and returning a HSTS header for each with max-age=0.

 For a resolution, Mikhail suggests..

 "My proposal is to amend the draft to force the includeSubDomains flag on
 wildcard certificates. This would limit them to only one entry in the
 browsers HSTS database and make the technique above prohibitively
 expensive to non-CA owners as a separate signed SSL certificate would be
 needed for every bit of information stored and limit encoding options."

-- 
-+-
 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: 
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

[websec issue tracker]

#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
  (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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #33: HSTS: quoted-string grammar in (extension) directives ?

[websec issue tracker]

#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: 
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

[websec issue tracker]

#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: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec