Ben Campbell | 2 Aug 19:46 2012

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

Hi, thanks for the response.  Comments inline:

On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
> 
> > -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
> > should be explicitly flagged and mentioned in the abstract.
> 
> Good question, I don't believe we've discussed this possibility directly in the websec wg. In looking at
the RFCs that do update RFC2616, it doesn't look like draft-ietf-websec-strict-transport-sec (HSTS)
is of that ilk.
> 
> However, it nominally appears that an argument could be made that it'd be appropriate to update RFC2818
via draft-ietf-websec-strict-transport-sec, specifically with regards to Section 2.1.  Connection Initiation.
> 
> Though, RFC2818 is Informational, which may be an issue (?). Also, perhaps this is something to more
appropriately do via a standards-track rfc2818bis, i.e., have the latter reference the HSTS spec.
> 
> this is something to discuss this coming week  <at> IETF-84 Vancouver it seems.
> 
> 

I will comment on this in response to your post-meeting email.

> > -- I did not find any guidance on how to handle UAs that do not understand
> > this extension. I don't know if this needs to be normative, but the draft
> > should at least mention the possibility and implications.
> 
> Agreed. My -12 working copy now contains these new subsections..
> 
> ###
(Continue reading)

Yoav Nir | 2 Aug 20:18 2012
Picon

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11


On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote:

> Hi, thanks for the response.  Comments inline:
> 
> On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
> 
>>> -- I did not find any guidance on how to handle UAs that do not understand
>>> this extension. I don't know if this needs to be normative, but the draft
>>> should at least mention the possibility and implications.
>> 
>> Agreed. My -12 working copy now contains these new subsections..
>> 
>> ###
>> 10.  Server Implementation and Deployment Advice
>> 
>>  This section is non-normative.
>> 
>> 10.1.  Non-Conformant User Agent Considerations
>> 
>>  Non-conformant UAs ignore the Strict-Transport-Security header field,
>>  thus non-conformant user agents do not address the threats described
>>  in Section 2.3.1 "Threats Addressed".  Please refer to Section 14.1
>>  "Non-Conformant User Agent Implications" for further discussion.
>> 
>>                      .
>>                      .
>> 
>> 14.  Security Considerations
>>                      .
(Continue reading)

Yoav Nir | 2 Aug 20:40 2012
Picon

Fwd: [saag] WebSec status

Sorry. forgot to CC this list.

Begin forwarded message:

From: Yoav Nir <ynir <at> checkpoint.com>
Subject: [saag] WebSec status
Date: August 2, 2012 9:15:07 AM PDT

WebSec met at 9:00 AM on Tuesday morning.

HSTS is at IETF LC. All issues are resolved, and a new revision should go to the IESG soon.
Cert Pinning is coming along, with several issues to be discussed on the list
Still no editor for Mime-sniffing. If none is found soon, we may consider dropping this item, but there are issues with HTML5 spec referencing it.
The Frame-Options drafts (X- and non-X-) are coming along OK, but the non-X may become part of CSP and move to W3C

Yoav

<div>Sorry. forgot to CC this list.<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<span>From: </span><span>Yoav Nir &lt;<a href="mailto:ynir <at> checkpoint.com">ynir <at> checkpoint.com</a>&gt;<br></span>
</div>
<div>
<span>Subject: </span><span>[saag] WebSec status<br></span>
</div>
<div>
<span>Date: </span><span>August 2, 2012 9:15:07 AM PDT<br></span>
</div>
<div>
<span>To: </span><span>"<a href="mailto:saag <at> ietf.org">saag <at> ietf.org</a>" &lt;<a href="mailto:saag <at> ietf.org">saag <at> ietf.org</a>&gt;<br></span>
</div>
<br><div>WebSec met at 9:00 AM on Tuesday morning.<br><br>HSTS is at IETF LC. All issues are resolved, and a new revision should go to the IESG soon.<br>Cert Pinning is coming along, with several issues to be discussed on the list<br>Still no editor for Mime-sniffing. If none is found soon, we may consider dropping this item, but there are issues with HTML5 spec referencing it.<br>The Frame-Options drafts (X- and non-X-) are coming along OK, but the non-X may become part of CSP and move to W3C<br><br>Yoav<br>
</div>
</blockquote>
</div>
<br>
</div>
Ben Campbell | 3 Aug 00:54 2012

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

Jeff and I spoke f2f. Pending actual text, I believe we have resolutions to all of my comments save those
about an extension registry, which Jeff will discuss with other interested parties.

Thanks!

Ben.

On Aug 2, 2012, at 10:46 AM, Ben Campbell <ben <at> nostrum.com> wrote:

> Hi, thanks for the response.  Comments inline:
> 
> On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
>> 
>>> -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
>>> should be explicitly flagged and mentioned in the abstract.
>> 
>> Good question, I don't believe we've discussed this possibility directly in the websec wg. In looking at
the RFCs that do update RFC2616, it doesn't look like draft-ietf-websec-strict-transport-sec (HSTS)
is of that ilk.
>> 
>> However, it nominally appears that an argument could be made that it'd be appropriate to update RFC2818
via draft-ietf-websec-strict-transport-sec, specifically with regards to Section 2.1.  Connection Initiation.
>> 
>> Though, RFC2818 is Informational, which may be an issue (?). Also, perhaps this is something to more
appropriately do via a standards-track rfc2818bis, i.e., have the latter reference the HSTS spec.
>> 
>> this is something to discuss this coming week  <at> IETF-84 Vancouver it seems.
>> 
>> 
> 
> I will comment on this in response to your post-meeting email.
> 
> 
>>> -- I did not find any guidance on how to handle UAs that do not understand
>>> this extension. I don't know if this needs to be normative, but the draft
>>> should at least mention the possibility and implications.
>> 
>> Agreed. My -12 working copy now contains these new subsections..
>> 
>> ###
>> 10.  Server Implementation and Deployment Advice
>> 
>>  This section is non-normative.
>> 
>> 10.1.  Non-Conformant User Agent Considerations
>> 
>>  Non-conformant UAs ignore the Strict-Transport-Security header field,
>>  thus non-conformant user agents do not address the threats described
>>  in Section 2.3.1 "Threats Addressed".  Please refer to Section 14.1
>>  "Non-Conformant User Agent Implications" for further discussion.
>> 
>>                      .
>>                      .
>> 
>> 14.  Security Considerations
>>                      .
>>                      .
>> 14.1.  Non-Conformant User Agent Implications
>> 
>>  Non-conformant UAs ignore the Strict-Transport-Security header field,
>>  thus non-conformant user agents do not address the threats described
>>  in Section 2.3.1 "Threats Addressed".
>> 
>>  This means that the web application and its users wielding non-
>>  conformant user agents will be vulnerable to both:
>> 
>>     Passive network attacks due to web site development and deployment
>>     bugs: For example, if the web application contains any insecure,
>>     non-"https", references to the web application server, and if not
>>     all of its cookies are flagged as "Secure", then its cookies will
>>     be vulnerable to passive network sniffing, and potentially
>>     subsequent misuse of user credentials.
>> 
>>     Active network attacks: If an attacker is able to place a man-in-
>>     the-middle, secure transport connection attempts will likely yield
>>     warnings to the user, but without HSTS Policy being enforced, the
>>     present common practice is to allow the user to "click-through"
>>     and proceed.  This renders the user and possibly the web
>>     application open to abuse by such an attacker.
>> 
>>  This is essentially the status-quo for all web applications and their
>>  users in the absence of HSTS Policy.
>> ###
> 
> That's all good text, but I'm not sure it actually captures my concern.
> 
> From the server's perspective, the fact that non-conformant UAs may exist, the server cannot assume that
UAs will honor the extension. This means that a UA might attempt unprotected access to some resource
assumed to be protected by this extension. That is, the server can't merely select the extension and
forget about things--it still needs to to take the same care to avoid leaking resources over unprotected
connections that it would need to do if this extension did not exist in the first place.
> 
> I think this is implied by your last sentence above, but it would be better to say it explicitly.
> 
> 
>> 
>>> 
>>> -- How should a UA handle potential conflicts between a the policy record
>>> that includes the includeSubdomain, and any records for subdomains that might
>>> have different parameters?
>> 
>> this is in the draft. the short answer is that at policy enforcement time, "superdomain matches win".
>> 
>> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) is noted regardless of whether there
are superdomain HSTS hosts asserting "includeSubDomains".
>> 
>> perhaps this needs to be made more clear?
> 
> Maybe I'm missing something, but I'm not getting that answer from the text. Can you point out the specific language?
> 
>> 
>> 
>>> 
>>> -- section 6.1:
>>> 
>>> The draft mentions that directives may be extended, but defers creation of an
>>> IANA registry to the time of first extension. IANA registries are not
>>> expensive; I suggest it be created now. If there's a good reason not to, then
>>> the draft should still address the specification policy for extensions.
>>> 
>>> Also, do you expect that some future directive might need to have a
>>> "required-to-understand" status? Given that this is a security-affecting
>>> extension, it seems likely. If so, then the mechanism for expressing that
>>> needs to be defined in this draft.
>> 
>> 
>> These are good questions, and they beg the overall question of how complex this simple solution really
needs to be and whether we really think we'll need any extensions. Something for us to discuss in the
working group meeting on Tue morning I think.
> 
> I will comment on this in the post-meeting mail.
> 
>> 
>>> 
>>> -- section 7.2:
>>> 
>>> Am I correct to assume that the server must never just serve the content over
>>> a non-secure connection? If so, it would be helpful to mention that, maybe
>>> even normatively.
>> 
>> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one
needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple
statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?
>> 
> 
> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the
content unprotected would improve the text. That's probably already implied, and a reasonable
implementor wouldn't due it anyway. But my experience is that some readers will find strange
interpretations whenever you give them the wiggle room to do so, so it's better to be explicit.
> 
>> 
>>> 
>>> -- section 8.4:
>>> 
>>> Does this imply a duty for compliant UAs to check for revocation one way or
>>> another?
>> 
>> yes. though, per other relevant specifications, as duly cited. AFAIK the HSTS spec doesn't need to get
into the details because the underlying security transport specs, namely TLS, already do this.
> 
> If that duty already exists, then I see no reason to add it here. But do the cited specs unambiguously
_require_ revocation checks? I admit to not being an expert here, but on a quick scan it seems more like they
say how you can do it, but do they say you have to? 
> 
> [...]
> 
>> 
>>> -- section 1.2:
>>> 
>>> The description of indented notes is almost precisely the opposite of how
>>> they are described in the RFC editor's style guide. It describes them as
>>> "parenthetical" notes, which is how experienced RFC readers are likely to
>>> perceive them. While it doesn't say so explicitly, I think putting normative
>>> text in parenthetical notes should be avoided. If these are intended to be
>>> taken more strongly than that (and by the description, I take it they should
>>> be taken more strongly than the surrounding text), then I suggest choosing a
>>> stronger prefix than "NOTE:"
>> 
>> As it turns out, almost all the Notes are parenthetical.
>> 
>> I'll render the one(s) that are normative as a regular paragraph(s) and leave the others as-is. Will that
address your concern?
>> 
> 
> Yes, thanks.
> 
>> 
>>> 
>>> -- section 7:
>>> 
>>> Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for
>>> SSL3?
>> 
>> no, it's just that SSLv3 remains a fact of life and is referenced for completeness' sake.
>> 
>> 
> 
> Okay.
> 
>> 
>>> 
>>> -- section 8.2, paragraph 5 (first non-numbered paragraph after numbered
>>> list)
>>> 
>>> To be pedantic, this could be taken to mean a congruent match only applies if
>>> the includeSubdomains flag is not present. I assume it's intended to apply
>>> whether or not the flag is present.
>> 
>> [ I am assuming you actually are referring to section 8.3, as section 8.2 doesn't mention the
includeSubdomains flag and does not contain a numbered list. ]
>> 
>> yes, a congruent match is intended to apply whether or not the flag is present.
>> 
>> 
> 
> yes, I meant 8.3. And on re-reading, I think the text is fine.
> 
>> 
>>> -- section 12 and subsections:
>>> 
>>> I was surprised to see more apparently normative material after the
>>> non-normative guidance sections. I think it would improve the organization to
>>> put this closer to the normative rules for UAs.
>> 
>> We can move section 12 up ahead of the non-normative guidance sections.
> 
> I think that would help, thanks.
> 
>> 
>> 
>>> 
>>> -- section 14.1, 4th paragraph (first non-bulleted paragraph following bullet
>>> list)
>>> 
>>> This issue is only true for proxies that act as a TLS MiTM, right?
>> 
>> yes.
>> 
>> 
>>> Would
>>> proxies that tunnel TLS via the CONNECT method have this issue?
>> 
>> I don't think so in the general case.
>> 
>> I'm not sure what terminology to use to differentiate such proxies if this is a detail worth addressing.
>> 
> 
> Okay
> 
>> 
>> thanks again,
>> 
>> =JeffH
>> 
>> 
>> 
>> 
>> 
>> 
> 

Yoav Nir | 7 Aug 14:27 2012
Picon

Meeting Minutes

Hi all

I have uploaded the minutes from last week's meeting. The URL is http://www.ietf.org/proceedings/84/minutes/minutes-84-websec
Please send corrections to Alexey, Tobias, or me.

Thanks again to Ted Hardie for taking the notes.

Yoav

=JeffH | 10 Aug 00:09 2012

handling STS header field extendability

Hi, here's a write-up on the background of, and proposed resolution to the 
question of handling STS header field extendability more properly in the spec.

I also pose the question of which IANA policy to declare, down at the very end.

thanks,

=JeffH

Background:
----------

We've defined the Strict-Transport-Security (STS) header field like so..

      Strict-Transport-Security = "Strict-Transport-Security" ":"
                                  [ directive ]  *( ";" [ directive ] )

      directive                 = directive-name [ "=" directive-value ]
      directive-name            = token
      directive-value           = token | quoted-string

..such that the definition of new directives is open-ended, i.e., the STS header
field is extendable.

draft-ietf-websec-strict-transport-sec-11 presently states at the end of section 
6.1..

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications, with a registry
    defined for them at such time.

The only extensions we'd discussed in the past were the CertPinning, LockCA,
LockEV.  We've decided that cert pinning is an intersecting but orthogonal
policy to HSTS, and thus best handled at this point via a separate header field.
Also, the various LockFoo notions should be addressed in a cert pinning policy
context (i mentioned this in the WG session at IETF-82 Taipei).

Thus we don't have any presently anticipated extensions for the STS header field.

However, I don't believe we wish to change the (implicitly extensible) maner in 
which the ABNF is specified, nor necessarily close the door to defining some 
extension if we happen to come up with an appropriate need.

The IETF-84 Vancouver, WebSec WG meeting minutes [1] state on this topic..

   The group then discussed the registry management, particularly around
   “mandatory to understand” extensions. The sense of the room was that the
   group did not want to create mandatory to understand extensions ever. If
   such extensions are needed, they will need a new header. Where the draft
   says other specifications can update this one, say that any necessary
   registries may be created when such an update comes around.

Note that -11 already states that a registry should be created at that time. Ben 
indicated in his review that it isn't sufficient in his view (below).

Ben replied directly to me regarding the meeting minutes...
 >
 > I think we may be conflating two mostly orthangonal comments:
 >
(a)
 > -- If the working group doesn't expect "mandatory to understand" extensions,
 > then I'm fine with it, other than thinking it might be worth noting that any
 > such extensions must be safe to ignore.
 >
(b)
 > -- My questions about a registry don't depend on the mandatory to understand.
 > I'm skeptical of any draft that says "you can extend this, but we will leave
 > the creation of a registry until someone actually does it." In particular,
 > this defers making decisions about the documentation policy for extensions
 > (rfc5226 section 4.1), which is rarely a good idea. The only situation where
 > it seems to make sense to defer the registry would be if you really didn't
 > expect any extensions--in which case the draft probably shouldn't mention
 > extending it.
 >
 > That all being said, please keep in mind that I, as a gen-art reviewer, am
 > only offering my opinion like anyone else. It's up to the work group and the
 > ADs to decide if they agree with me or not. So it's okay to say "We disagree
 > with Ben here, and choose to leave it as is".

Proposed Resolution:
-------------------

For (a)

The spec already notes that UAs must ignore unrecognized directives. in any case 
I've composed a note regarding furture-defined directives being ignored by 
(legacy) UAs.

For (b)

Alter the spec text to include a reference of the required IANA Policy for any 
defined registry.

NOTE: we need to decide the type of IANA Policy (more below)

The spec text I now have in my -12 working copy at the end of section 6.1 is..

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications, with a registry
    (having an IANA policy definition of FOO [RFC5226]) defined for them
    at such time.

    NOTE:  Such future directives will be ignored by UAs implementing
           only this specification, as well as by generally non-
           conforming UAs.  See Section 14.1 "Non-Conformant User Agent
           Implications" for further discussion.

We need to decide what IANA policy definition [RFC5226] we wish to declare for 
FOO in the above text.

Since HSTS is a security policy, I lean towards wanting to have relatively 
rigorous review applied to any registry and its contents created for HSTS 
directives and thus am thinking a policy of "IETF Review" is what we ought to 
state here.

thoughts?

[1] https://www.ietf.org/proceedings/84/minutes/minutes-84-websec

---
end

Alexey Melnikov | 10 Aug 01:03 2012

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

On 02/08/2012 10:46, Ben Campbell wrote:
> Hi, thanks for the response.  Comments inline:
>
> On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
  [...]
>>> -- section 7.2:
>>>
>>> Am I correct to assume that the server must never just serve the content over
>>> a non-secure connection? If so, it would be helpful to mention that, maybe
>>> even normatively.
>> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one
needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple
statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?
>>
> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the
content unprotected would improve the text.

Sounds good to me. (And yes, this is implied, but it doesn't hurt to 
state explicitly.)

> That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience
is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so
it's better to be explicit.
Tobias Gondrom | 10 Aug 12:03 2012

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

On 10/08/12 00:03, Alexey Melnikov wrote:
On 02/08/2012 10:46, Ben Campbell wrote:
Hi, thanks for the response.  Comments inline:

On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
 [...]
-- section 7.2:

Am I correct to assume that the server must never just serve the content over
a non-secure connection? If so, it would be helpful to mention that, maybe
even normatively.
It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?

I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the content unprotected would improve the text.

Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.)

That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so it's better to be explicit.


<hat="individual">
Agree with Alexey and Ben. Tobias


Ben Campbell | 10 Aug 16:16 2012
Picon

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase (and I assume he will correct me
if if I mischaracterize anything), Jeff indicated that this really wasn't a MUST level requirement due to
the variation and vagaries in application behavior and abilities. Rather, it's more of a "do the best you
can" sort of thing. Specifically, he indicated that an implementation that chose to go ahead and serve
unprotected content due to the listed caveats on redirecting to HTTPS would necessarily be out-of-compliance.

If the requirement really that you SHOULD NOT (rather than MUST NOT) serve unprotected content, then I
think the original language is okay.

Thanks!

Ben.

On Aug 9, 2012, at 6:03 PM, Alexey Melnikov <alexey.melnikov <at> isode.com> wrote:

> On 02/08/2012 10:46, Ben Campbell wrote:
>> Hi, thanks for the response.  Comments inline:
>> 
>> On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
> [...]
>>>> -- section 7.2:
>>>> 
>>>> Am I correct to assume that the server must never just serve the content over
>>>> a non-secure connection? If so, it would be helpful to mention that, maybe
>>>> even normatively.
>>> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one
needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple
statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?
>>> 
>> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the
content unprotected would improve the text.
> 
> Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.)
> 
>> That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my
experience is that some readers will find strange interpretations whenever you give them the wiggle room
to do so, so it's better to be explicit.
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art <at> ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
=JeffH | 10 Aug 23:33 2012

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

Thanks Ben.

 > Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase
 > (and I assume he will correct me if if I mischaracterize anything), Jeff
 > indicated that this really wasn't a MUST level requirement due to the
 > variation and vagaries in application behavior and abilities.

Yes, see the NOTE in section 7.2.

 > Rather, it's
 > more of a "do the best you can" sort of thing. Specifically, he indicated
 > that an implementation that chose to go ahead and serve unprotected content
 > due to the listed caveats on redirecting to HTTPS would necessarily be
 > out-of-compliance.

I presume you actually mean "not necessarily", which would then be correct, 
unless I'm misunderstanding something.

 > If the requirement really that you SHOULD NOT (rather than MUST NOT) serve
 > unprotected content, then I think the original language is okay.

agreed.

thanks,

=JeffH


Gmane