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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Yaron--

On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
> 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.

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