Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Sun, 11 Oct 2015 22:57:38 +0300

We have a standard for certificate pinning (RFC 7469), but it is rather 
hard to use and as a result is rarely deployed. This draft proposes a 
lightweight alternative that allows TLS clients to authenticate the 
server they're connecting to, even if a rogue CA can generate fake 
certificates for that server.

The draft is currently TLS 1.3-only, and is based on the previous draft 
of 1.3 so some minor details may have changed.

Comments are of course most welcome.

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for 
draft-sheffer-tls-pinning-ticket-00.txt
Date: Sun, 11 Oct 2015 12:35:17 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>

A new version of I-D, draft-sheffer-tls-pinning-ticket-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-sheffer-tls-pinning-ticket
Revision:	00
Title:		TLS Server Identity Pinning with Tickets
Document date:	2015-10-11
Group:		Individual Submission
Pages:		14
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
Htmlized: 
https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00

Abstract:
    Fake public-key certificates are an ongoing problem for users of TLS.
    Several solutions have been proposed, but none is currently in wide
    use.  This document proposes to extend TLS with opaque tickets,
    similar to those being used for TLS session resumption, as a way to
    pin the server's identity.  That is, to ensure the client that it is
    connecting to the right server even in the presence of corrupt
    certificate authorities and fake certificates.  The main advantage of
    this solution is that no manual management actions are required.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 16:21:32 -0400

https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00#section-3

Your notation is incorrect. Please read the section on vectors carefully, as it *is* confusing and the notation is not what is usually assumed. I'll cite the TLS 1.2 spec as it has not changed:
https://tools.ietf.org/html/rfc5246#section-4.3

For "type name<n..m>;", the range [n,m] is always in _bytes_, not entry count. In particular, note the second example at the end of the vectors section:
      uint16 longer<0..800>;
            /* zero to 400 16-bit unsigned integers */

All 3 of your arrays of strings are listed with "<0..1>", which actually notates zero or one byte, not zero or one element. There is no way to explicitly state a range of allowed sizes by entry count with variable length entries, within this notation. Yes, this is not great and yes, this is often misunderstood. You'll have to mandate entry count with a "MUST" in the body of the text.

No, it's probably not going to be changed any time soon, as that would contradict past specifications' notation. Maybe something like "type name<min_bytes..max_bytes>[min_count..max_count];" could work, but that's probably not worth the confusion of introducing a new and more complex notation.

On the actual topic of the proposal, I haven't looked into it in detail yet, but I am glad to see pinning being worked on at the TLS level.

Dave

On Sunday, October 11, 2015 03:57:38 pm Yaron Sheffer wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 11 Oct 2015 16:48:06 -0400

Hi Yaron--

> of 1.3 so some minor details may have changed.

I've only just skimmed thus far, but i'm happy to see this proposal.  A
few comments below:

TACK
----

As you note in the draft, it addresses a similar problem as TACK, which
never made it through the standards process:

  http://tack.io/draft-tack.html

perhaps it would be useful to have a section next to the Comparison:
HPKP that included a Comparison: TACK ?

(dis)similarity to session tickets
----------------------------------

In the session-ticket case, most servers (clustered or otherwise) can
afford to treat their session ticket master keys as ephemeral keys -- if
the server is restarted or dies and is re-installed, the worst that
happens is that a client doesn't get to resume their session -- they
have to open a new connection.

If the session ticket resumption master keys are used as recommended
here, it seems like the risk of master key loss is bricking the server,
so the master key becomes necessary to store non-ephemerally.

Writing the master key to disk or storing it off-site someplace can
present a risk to the forward-secrecy of ticket-resumed sessions.

tracking the master key itself seems like it also adds specific
operational overhead for server maintainers that doesn't currently
exist.  Does this reduce the advantage of the scheme over TACK or HPKP?
if not, can you explain why not?

Client Privacy
--------------

section 6.6 says "TODO", and page 5 says:

>       The main reason for refreshing the ticket on each connection is
>       privacy: to avoid the ticket serving as a fixed client
>       identifier.  It is RECOMMENDED to include a fresh ticket with
>       each response.

If the participating client wants privacy from the server (to avoid the
server using this to track the client) but also wants defense against
broken CAs, how does recomending this behavior from the server actually
allow the client to enforce privacy?

The server is trivially capable of tying together a history of
pinning_ticket objects to track specific clients, right?  it just
remembers the two tickets involved every time it generates a
PinningTicket extension.  If the pinning tickets returned by the server
are different each time, the client cannot know whether the server is
doing this tracking or not.

public key vs. certificate
--------------------------

In your introduction (and in the mail above), you refer to "certificate
pinning" -- but i don't think there is anything out there that is
"certificate pinning" -- HPKP is public key pinning, and it ignores the
certificates that wrap any given public key.  So your tables should
really refer to "main public key" and "backup public key", not "main
certificate" or "backup certificate".

HPKP example workflow
---------------------

Your HPKP timeline seems to assume that your "old backup certificate"
can't be used as your "new main certificate" -- what makes you say this?

I agree with you that HPKP end-entity pinning generally makes more sense
(and is more useful at defending against malicious/incompetent CAs) than
authority pinning.  But I'd expect an HPKP timeline using end-entity
pinning to be more like:

lower-case letters are public keys.  we presume that the site
administrator has the corresponding secret keys backed up
offsite/offline somewhere, and the associated certs and secret keys
needed to operate the web site get deployed as needed.

Initial deployment:

 HPKP: { a, b }  Cert: A = X.509-wrapped(a)  

as A approaches expiry, we generate a new key c (storing its secret key
offline), get a new cert made over b, and switch to:

 HPKP: { b, c }  Cert: B = X.509-wrapped(b)

As B approaches expiry, we do the same dance, generating d and making a
cert over c:

 HPKP: { c, d }  Cert: C = X.509-wrapped(c)

and so on.

Does this simpler cycle change your analysis of HPKP?

I tend to think HPKP deployment has been slow because:

 (a) the risk of bricking the site makes admins (justifiably) nervous

 (b) having to have an additional offsite store (of your HPKP backup
     secret key) to avoid site-bricking is a workflow that most admins
     don't already have in place.

But i don't think your proposal addresses these issues either (though
the data stored offsite for (b) is slightly different between your
proposal and HPKP).  Does it address them in some way that i'm missing?

Regards,

     --dkg

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 Oct 2015 00:17:07 +0300

Hi Dave,

Thanks for correcting my notation. The text in TLS 1.2 and 1.3 is 
confusing and I misunderstood it. This sentence is absolutely opaque to 
me: "The length will be in the form of a number consuming as many bytes 
as required to hold the vector's specified maximum (ceiling) length."

Regards,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 Oct 2015 16:18:17 +0300

Hi Daniel,

Thanks for your review. Please see my comments inline.

	Yaron

> HPKP that included a Comparison: TACK ?

I'm not familiar enough with TACK at the moment. I can write something 
up, or if you'd like to contribute text, that'll be awesome.

> (dis)similarity to session tickets

IMO persisting the master key to disk is less of a problem than 
distributing it across cluster members, and this is something that needs 
to happen or session resumption will fail regularly. Regular  rotation 
of the master key means that persisting it to disk is not such a risk. 
You are right that a session resumption master key needs not be backed 
up, whereas the pinning secret may need to be backed up securely for 
disaster recovery.

> Client Privacy

Yes, I was thinking of privacy in the face of passive attackers who 
listen in to the TLS handshake. Not when the server itself is out to get 
you. I suspect that there is little you can do to protect your privacy 
when the server itself is malicious, but I'm sure you are more 
knowledgeable about these issues.

> public key vs. certificate

You are right. "Certificate pinning" is the more common term, but is it 
less precise.

> HPKP example workflow

The longer you keep a keypair, the more likely it is to be compromised. 
So you may not want to keep a keypair in "cold storage" for a year, and 
then use it as a production cert for another year.

Depending on your setup, the risk may be much larger on the production 
server than on some offline storage, and then your proposed process 
makes perfect sense.

> proposal and HPKP).  Does it address them in some way that i'm missing?

One difference is that in HPKP, the data stored in (b) is 
security-critical, in that its compromise is just as bad as compromise 
of the site's regular secret key (you can use it to MITM all connections 
to the server). In my proposal the pinning secret is truly a "second 
factor". Its compromise is an issue only if you can *also* generate a 
fake certificate.

Another major difference is that my proposal avoids the manual 
management steps of HPKP (at least until we have ACME widely deployed). 
The pinning secret can be generated automatically when the server is 
started and rolled over periodically, with no human in the loop.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 15 Oct 2015 19:54:49 -0400

> up, or if you'd like to contribute text, that'll be awesome.

i'm not up-to-speed yet either, and am unlikely to be able to get to
this soon, sorry!

> distributing it across cluster members, and this is something that
> needs to happen or session resumption will fail regularly. Regular
> rotation of the master key means that persisting it to disk is not
> such a risk.  You are right that a session resumption master key needs
> not be backed up, whereas the pinning secret may need to be backed up
> securely for disaster recovery.

hm, i'm not convinced of this tradeoff in general -- in today's
"cloud-y" age, backing up to disk rather than keeping in RAM might
trigger writes to data storage that's owned by yet another entity.  This
means you have the potential for traffic decryption not only to those
who can access your CPU and RAM, but those who run your storage backend.

Even worse, if the pinning secret is derived from the session resumption
master secret as recommended in section 4.2, then the temptation will be
to store the session resumption master secret to disk, which puts the
forward secrecy of resumed sessions at risk.  If admins don't persist
the resumption master secret, but persist only the derived secret, then
there are two modes of operation: one running from the derived secret,
and one running from the backup secret, which sounds messy.

Perhaps some implementation guidance is warranted here?  

> knowledgeable about these issues.

TLS servers themselves should not be able to track a TLS client in the
event that the client decides to not be tracked.  For example, a client
could refuse to initiate session resumption, and could offer a
standardized, common TLS Client Hello.

Maybe privacy from a pinned-ticket server can be achieved by a client by
simply never sending the ticket pinning extension, or by never sending
it on subsequent connections?  this would come at the cost of losing the
ability to detect when a server's identity gets swapped out, of course.
It's not a particularly satisfying tradeoff.

> You are right. "Certificate pinning" is the more common term, but is it 

fwiw, "certificate pinning" is also used in
https://tools.ietf.org/html/rfc6125#page-11 to describe what browsers
often call a "security exception" -- a non-validating certificate that
the user explicitly decides to allow for a given site.  this kind of
additional grant is the *opposite* of the additional restriction you're
describing.  better to stick to "public key pinning", which has no such
connotations.

> server than on some offline storage, and then your proposed process 

yes, i intended the proposal to be for an admin who has access to
offline storage (though even an encrypted thumb drive locked in a drawer
would do).

> of the site's regular secret key (you can use it to MITM all
> connections to the server). In my proposal the pinning secret is truly
> a "second factor". Its compromise is an issue only if you can *also*
> generate a fake certificate.

I'm not sure about this distinction.  No certificate has been issued for
the HPKP backup key until just before it is deployed.  So the attacker
has to get a certificate issued for that secret key anyway, right?

> management steps of HPKP (at least until we have ACME widely
> deployed).  The pinning secret can be generated automatically when the
> server is started and rolled over periodically, with no human in the
> loop.

Since you'd still need to persist the secret to disk in some reliable
way that handles rotation, backup, etc. safely if you don't want to risk
bricking the site, I think you're saying that hypothetical software
stack X has a better chance at successful implementation and deployment
than hypothetical software stack Y.  ;)

Thanks for proposing this, Yaron.

       --dkg