Subject: [websec] Next rev of HSTS certificate pinning draft

From: Chris Palmer <[email-masked]>
Date: Tue, 20 Sep 2011 11:08:16 -0700

Is attached, now in XML. The main change is that I got rid of widely
and rightly reviled pin revocation business, and replaced it with a
better idea from Trevor Perrin. Big thanks to everyone who reviewed
and commented on the previous draft. Precisely how to generate
fingerprints is answered with working code from Adam Langley. The
gross errors that surely remain are my fault alone. :)

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Sep 2011 21:36:26 +0300

> gross errors that surely remain are my fault alone. :)

So this is when we get to make fun of the newbie, as promised in http://www.ietf.org/mail-archive/web/websec/current/msg00521.html ?

Cool!  So add a reference to RFC 2119 (see for example any draft or RFC). Otherwise you're not allowed to say "MUST". Also have a "Security Considerations" section, even if initially it will also say "to be added", or the classic cop-out, "security considerations are interspersed throughout this document". One more issue, Go code (as opposed to pseudo code, although I would bet your pseudocode compiles) should go in an appendix - it's just a section within the "back" tag.

And one comment as to substance. Section 3.1 says "Have a safety net.  Generate a backup key pair, get it signed..."  I agree that this is a good idea for e-commerce site that lose sales on any outage. But what if I generate a backup key pair for my personal website (www.yoavnir.com is not it!), and not get it signed at all?  Then if my regular private key gets compromised, I then get it signed by some other CA (or the same CA). With DV certificates this takes minutes.

Just as some institutions like banks or Google have hot standby server farms that switch over in milliseconds, while the IETF is fine with hour-long outages (as long as they're rare), websites can make a trade=off of expense vs availability of the website certificate.  I don't think the draft should mandate the hot-standby datacenter approach.

Yoav

---

From: SM <[email-masked]>
Date: Tue, 20 Sep 2011 13:30:39 -0700

Hi Chris,
>gross errors that surely remain are my fault alone. :)

These comments are editorial.

Under Status of this Memo:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

Section 10 of RFC 2026 has been updated by newer RFCs.

The Copyright Notice should be according to the IETF Trust legal 
provisions.  This can be generated automatically ( see 
www.rfc-editor.org/rfc-editor/intro_xml2rfc.pdf ).

As an example, in Section 3.3.3:

  "You SHOULD attempt to get the certificate revoked by whatever means"

In terms of style, the requirement (SHOULD) should not be directed to 
the reader.  You could rewrite that as:

  The certificate SHOULD be revoked by whatever means

In Section 3.7.4:

  "CDNs MAY, and SHOULD, also use certificate pinning independently of
   any of their customers."

There is always some long discussion in the IETF about RFC 2119.  To 
keep it simple, don't say MAY and SHOULD do X.  The MAY is not needed 
in this case.

Think about the Security Considerations section.  Some of the 
existing text could go under there.

As you are defining a new HTTP header field, add an IANA 
Considerations section for it to be registered.  You can deal with 
that as the work on the I-D progresses.

Don't read any of the above as gross errors. :-)

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Sep 2011 16:48:58 -0400

I can't follow the link to the Perrin draft, it says 'you lose'

On the hashing:

1) Please eliminate SHA1 completely. At this point it is an ex-algorithm so
far as new protocols go.

2) Algorithm identifiers need to be managed using either an IANA registry or
some existing crypto-registry. At present adding support for a new algorithm
would change the protocol syntax.

The usual solution is either to use ASN.1 OIDs for algorithm IDs or re-use
the identifiers originally defined for PEM. Since we are dealing with SSL
and hence PKIX here implementations will already need code to manage
algorithms by OID (and by SSL cipher suite ID but that is another ball of
wax).

3) It is not at all clear how the digest is calculated and in particular
whether that includes the algorithm identifier for the public key type. It
is essential to prevent an algorithm substitution attack.

Could we break off the section that defines the digest identifier from the
rest of the document? I can send text for this as I am currently working on
doing just that.

The need to have a strong reference to some object comes up time and again.
It really calls for having a URI.

On Tue, Sep 20, 2011 at 2:08 PM, Chris Palmer <[email-masked]> wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

-- 
Website: http://hallambaker.com/

---

From: Chris Palmer <[email-masked]>
Date: Tue, 20 Sep 2011 17:57:56 -0700

> So this is when we get to make fun of the newbie, as promised in http://www.ietf.org/mail-archive/web/websec/current/msg00521.html ?

Woo hoo!

> Cool!  So add a reference to RFC 2119 (see for example any draft or RFC). Otherwise you're not allowed to say "MUST".

Done.

>Also have a "Security Considerations" section, even if initially it will also say "to be added", or the classic cop-out, "security

I did this by re-naming our security considerations section to
"Security Considerations". :)

> One more issue, Go code (as opposed to pseudo code, although I would bet your pseudocode compiles) should go in an appendix - it's just a section within the "back" tag.

Done.

> And one comment as to substance. Section 3.1 says "Have a safety net.  Generate a backup key pair, get it signed..."  I agree that this is a good idea for e-commerce site that lose sales on any out…

That part is not MUST, and is in a section called "guidance". So it's
not a mandate. Also later on we acknowledge the last-minute signing
case.

Also, we say at the outset that HSTS certificate pinning is for sites
with high operational maturity — if an operator is not prepared to
plan for disaster, that's a sign they might not need or want HSTS
certificate pinning. At least not now, in this early stage. I don't
want for this feature to get a bad reputation when unprepared
operators get burned.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 20 Sep 2011 18:06:21 -0700

On Tue, Sep 20, 2011 at 1:30 PM, SM <[email-masked]> wrote:

> The Copyright Notice should be according to the IETF Trust legal provisions.
>  This can be generated automatically ( see

I didn't write that text, it was auto-generated by the xml2rfc tool
itself. If that tool does the wrong thing, we should poke its
maintainer...

> In terms of style, the requirement (SHOULD) should not be directed to the
> reader.  You could rewrite that as:
>

Ok.

> There is always some long discussion in the IETF about RFC 2119.  To keep it
> simple, don't say MAY and SHOULD do X.  The MAY is not needed in this case.

Done.

> As you are defining a new HTTP header field, add an IANA Considerations
> section for it to be registered.  You can deal with that as the work on the
> I-D progresses.

Well, it's an extension to the HSTS header field, not a whole new field.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 20 Sep 2011 19:04:33 -0700

Incorporating people's suggestions. Thanks again all!

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Sep 2011 07:53:55 +0300

> want for this feature to get a bad reputation when unprepared

HSTS (with or without pinning) is a security feature. It prevents certain kinds of attacks. Yes, it requires operational maturity in the sense that you can't let your certificate expire or introduce new keys at a moment's notice. Organizations like the IETF or power utilities should have that kind of operational maturity and need for security.

A requirement for 5 nines or uptime is a different thing. Many websites can live with some downtime. So if you have a serious compromise, you take down the server, get the certificate signed, and bring the server back up. This can all be done in under an hour, and that's acceptable to many. Obviously not the likes of Paypal, Amazon, or Google. But allnaturalpet.com ?  The lost sales from that 1 hour downtime after a rare key compromise may not be worth the hassle of getting a second certificate.

---

From: SM <[email-masked]>
Date: Wed, 21 Sep 2011 22:46:45 -0700

Hi Chris,
>itself. If that tool does the wrong thing, we should poke its

The I-D which you submitted has the correct text.  BTW, even though 
the text is auto-generated, it is still considered as an assertion by 
the author.

Regards,
-sm