Subject: [TLS] draft-perrin-tls-tack-00

From: Trevor Perrin <[email-masked]>
Date: Wed, 23 May 2012 06:57:29 -0700

Hi,

I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd
like to propose to help with pinning.

Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/
Website: http://tack.io

The main idea is to allow a site operator to sign their TLS public key
with a separate "TACK" key which can be pinned.  A pin based on a TACK
key isn't tied to any CA or certificate chain, which has benefits in
security and operational flexibility compared to pinning certificate
chains more directly.

There's also mechanisms for activating and de-activating pins, and
handling compromises.

Anyways, we'd greatly appreciate any feedback!

At the website you can find some code (including a command-line tool
and test server), and a dev mailing list.

Thanks,

Trevor

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 May 2012 12:10:04 -0400 (EDT)

> There's also mechanisms for activating and de-activating pins, and

A first read seems to suggest you are embedding a self-signed CA into a
new TLS extension without a trust model, requiring leaps of faith or
an external undefind PKI model.

It does not protect new sites you visit, unless you share TACK keys.
Sharing tack keys means you just moved the problem without solving
anything. How are you going to trust other people's TACK keys? You might
as well share either the TLS cert pubkey directly, or the CA that signed
it.

It seems very hard to be an alternative to DANE/TLSA and PKIX/CAbforum
without actually specifying an alternative trust model. But there has to
be one. This isn't really different from CertPatrol without a central
place to exchange certificate information. Which would require no
protocol change. Why not add th TACK information into the X.509
certificate itself, so it would not require a new TLS extension?

It only specified ECC, which is a problem for some people due to patents. It's
lack of crypto agility is a generic problem.

How will this work with CDNs and TLS load balancers using different
certs and keys per location?

If you want to notify the server owner of someone else faking them, you
might want to consider adding something like this into the protocol:

http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00

It seems plugins like CertPatrol already do exactly this, without
requiring a TLS protocol change - and with the same problems of a lack
of trusted repository to look up TLS server public keys.

Paul

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 23 May 2012 09:44:42 -0700

Hi Paul,

Thanks for feedback, responses inline -

> an external undefind PKI model.

The "pin activation" algorithm is somewhat different from the typical
"leap-of-faith" / "trust-on-first-use" model.

Yes, pins could also be distributed from external sources, such as a
browser preload list, etc.

> as well share either the TLS cert pubkey directly, or the CA that signed

Disagree with the "might as well" part.  Sharing the cert pubkey or a
CA key does not work as well, since sites can have mutliple of these
things deployed simultaneously, and can change these things at any
time.  It is difficult to distinguish - without something like TACK -
whether the presence of multiple such things, or such changes, are
attacks or not.

> certificate itself, so it would not require a new TLS extension?

We would not want to add it into a CA-signed certificate, since we
would like a site to be able to deploy TACK without needing to rely on
CAs.

But, you're right that it may be reasonable, and a quicker route to
deployment for some sites, to add a "superfluous" certificate to a TLS
certificate chain, containing a TACK_Extension.  In fact, we've
implemented this as well, but figured that was somewhat an abuse of
the TLS handshake, so we did not document it here.

> lack of crypto agility is a generic problem.

ECDSA/P-256 is pretty widely used, and covered in RFC6090.  See
section 9.3 for agility: http://tack.io/draft.html#future

> certs and keys per location?

Hopefully well, since the TACK key can sign different TLS keys.

> It seems plugins like CertPatrol already do exactly this

Disagree per above - plugins like CertPatrol can't know whether the
observation of a different cert from one seen previously is legitimate
or an attack.  A site rejected provided by a TACK pin provides a much
stronger basis for rejecting the connection on security grounds.

Trevor

---

From: Moxie Marlinspike <[email-masked]>
Date: Wed, 23 May 2012 10:31:42 -0700

> certificate itself, so it would not require a new TLS extension?

To add a few comments to Trevor's, I don't think we see TACK (by itself)
as a replacement for DANE or CAs.  We hope that it's a smaller, simple
to deploy solution that takes a bite out of the larger problem, and can
work in conjunction with other trust systems.

If we look at the history of CA compromises, the CA pins in Chrome are
the only technology that I know of which has thus far been documented as
effective in mitigating a real-time attack.  They're the reason we even
know about the DigiNotar compromise.  The Chrome team has been very
generous about allowing other sites to add their own CA pins to Chrome,
but there are two limitations that I see:

1) Chrome pins CA SPKIs.  Many sites have several certificates signed by
multiple CAs, and don't know what root certificate their CAs will use to
sign future renewals, so while the pins end up narrowing the risk, it
still ends up being a pretty big list for major websites (look at
Twitter's pins in Chrome, for instance).

2) Scalability.  This requires actually embedding lists into the Chrome
source, which is hard to imagine scaling extremely far.  It adds
friction for the site operator, because future CA changes or even
certificate renewals with an existing CA might require Chrome to update
its list.  That means waiting for the change to get committed and
distributed, then waiting another 10 weeks for the pinning window of
users who might not have upgraded yet to phase out.  And, of course,
this is all limited to Chrome and doesn't extend to other browsers.  If
the DigiNotar attackers had been smart enough to fingerprint the
browsers they were attacking, we might never have known about it.

TACK is an attempt to extend this mechanism so that it's easy to deploy,
pins site keys rather than CA keys, offers the agility site operators
are used to, and can be easily supported in multiple browsers.

While I see a project like Convergence as an attempt to provide
increased 'trust agility,' I see TACK as an attempt to reduce the
surface for which third party trust is even required.  The two types of
projects are not incompatible, and in fact the latter simply reduces the
amount of work the former needs to do.

> of trusted repository to look up TLS server public keys.

I think addons like CertPatrol are pretty nice, but there's a reason
they have not been incorporated directly into browsers for the benefit
of all users: TLS certificates change under completely normal
circumstances.  Browser vendors would have difficulty incorporating
CertPatrol type logic into their browsers today, because it would
probably either end up a) asking a lot of users or b) completely
desensitizing them to whatever warnings they display.

TACK provides a layer of indirection that allows a browser to
distinguish between an attack and a normal certificate change.

- moxie

-- 
http://www.thoughtcrime.org

---

From: Geoffrey Keating <[email-masked]>
Date: 23 May 2012 13:38:40 -0700

> Anyways, we'd greatly appreciate any feedback!

I like this part:

   When a
   client sees a new hostname and TACK key combination, an inactive pin
   is created.  Every subsequent time the client sees the same pin, the
   pin is "activated" for a period equal to the timespan between the
   first time the pin was seen and the most recent time, up to a maximum
   period of 30 days.

However, I would suggest 32 days not 30, so that a web site which is
used at the same local time on the same day each month can always be
pinned.  Some months have 31 days, and you need a little more time
to allow for DST or time zone changes which I rounded up to 1 extra
day making 32.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 24 May 2012 16:56:35 -0700

> to allow for DST or time zone changes which I rounded up to 1 extra

Hmm, maybe... but 30 days has a nice ring to it, it's a sort of
"standard" time interval that you encounter often.  If we go with 32
we are going to have to explain your logic to people frequently.

Leaning againt this, but noting it as an open issue.

(We've received suggestions that the max period should be even longer.
 Moxie has a good post on the issues involved here:)

https://lists.riseup.net/www/arc/tack/2012-05/msg00006.html

Trevor

---

From: Max Pritikin <[email-masked]>
Date: Thu, 24 May 2012 23:19:13 -0600

I think 32 has a nice ring to it, its sort of a a "standard" number what with it being 2^5th. :)

On May 24, 2012, at 5:56 PM, Trevor Perrin wrote:

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 May 2012 11:26:38 +0200

> Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/

Hello,
 May I ask what are the advantages compared to:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01

As I see it the key-pinning is simpler, does not require dependence on
any signing algorithm (only hash). I can see that you try to have a
discussion in the introduction, but it seems to be wrong:
   "Unfortunately, a number of problems arise when attempting to pin
   certificate chains: the TLS servers at a given hostname may have
   different certificate chains simultaneously deployed and may change
   their chains at any time, the "more constant" elements of a chain
   (the CAs) may not be trustworthy, and the client may be oblivious to
   key compromise events which render the pinned data untrustworthy."

My understanding of the key-pinning draft is that pinning occurs on
the hosts public key, so changing certificate chains does not have the
effect you describe.

regards,
Nikos

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 29 May 2012 08:53:07 -0700

> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01

Hey Nikos,

Good question.  We think "PKP" is good work, but TACK has several advantages:

(1) TACK works at the TLS layer, so it can be used by any application
built on TLS.

(2) TACK uses signing keys which are not CA keys.  Thus, TACK allows
for TLS key changes without needing trust in CAs.

(3) TACK has additional safeguards to reduce the risk of bad pins
affecting site availability.  In particular, the "pin activation"
algorithm places a limit on pin activation periods, and scales up
slowly so that brief exposure to a bad pin cannot cause long-lived
problems.

(4) TACK's "break signatures" lets a server publish an emergency
signal that a pin is compromised and should not be trusted.  TACK's
"min_generation" lets a server publish an emergency signal that a TLS
key is compromised.  These signals can be cryptographically verified
using the pin, and could be gathered and distributed by 3rd-party
trust infrastructure.

(5) The TACK "expiration" field allows use of short-lived TACKs as an
alternative way to mitigate the risk of TLS key compromise without
relying on revocation messages.

(6) TACK pins are small and contain embedded revocation info
(min_generation), so they are a compact form for distributing trust
information (e.g. via DNS, browser preload lists, Convergence, etc).

(7) TACK supports 3rd-party-assisted pinning, where a 3rd-party (which
could be a CA or any other entity) provides TACKs.

> As I see it the key-pinning is simpler,

TACK is a bit complicated to evaluate, but it's easier to implement,
and even easier to deploy, since:
 (a) The deployer can ignore revocation features like break signatures
and generations until they're needed.
 (b) The most complex part of TACK (pin activation) actually
simplifies deployment, by automatically scaling up the activation
period.

To get a sense of the deployment process, see the tackpy README (or
try the tool):

https://raw.github.com/tack/tackpy/master/README
https://github.com/tack/tackpy/downloads

Trevor

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 May 2012 12:41:20 -0400 (EDT)

> for TLS key changes without needing trust in CAs.

Which is also the *problem* of TACK. Since the TACK pins are signed by
entities for which no trust anchors are distributed, I do not see
much value of TACK pins over the TLS public key. Both are obtained
inside the TLS connection and come with no one backing them up to
ensure you're not MITM'ed. You might think TACK keys can be handled
better by larger SSL farms, but then you have to consider why those
large SSL farms are not able to use the same SSL pubkeys everywhere
either and why the same issue would not affect TACK keys.

I'd say using a TLSA record, without any kind of trust anchor, would
have benefits over TACK, as you can get DNS answers from unexpected
sources that are not as easy to MITM. With DNS records, you already
have a flexible caching system in place without the need for new code,
or hardcoded timing values in an RFC.

> slowly so that brief exposure to a bad pin cannot cause long-lived

I'm not sure how that gains you anything compared to TLSA records with
TTL values? How long any key has been used in the past is never any
guarantee for its correctness of today's use. With TLSA records, you can
only get exposed to a "bad pin" if the administrator makes a mistake,
which is something that is still widely discussed on the dane list with
respect to hard vs soft fail errors and how to actually convey "bad TLS"
to the enduser.

> using the pin, and could be gathered and distributed by 3rd-party

Then use rbl whitelists to store these pins in 3rd party DNS trees?

> relying on revocation messages.

Short TTLs on TLSA records?

> information (e.g. via DNS, browser preload lists, Convergence, etc).

Ugh. so you figured out this DNS distribution method too. Then why do
still think a TLS server/client modification is needed along with a new
cryptographic identifier when we already have a way of storing TLS pubkeys
in DNS (even if you ignore DNSSEC). How is storing a TACK pubkey any
different? You could write the draft using TLSA records with the same
initial timing constraints if you deem those better then trusting ICANN
and Verisign without inventing any TLS extensions and without adding
another level of trust indirection using a new keying scheme.

> could be a CA or any other entity) provides TACKs.

Like DNSSEC? Or DLV?

> simplifies deployment, by automatically scaling up the activation

But DNSSEC allows the publisher of the TLS pubkey, the only entity
which has absolute knowledge over their intentions with the key, to
announce these intentions to everyone, without third party delays,
agreements, redistribution, or "x out of y" trust requirements. Anyone
else making assumptions about its key use runs the rsk of being wrong,
and is delayed in making any such risky statements about the keys.

It's a novell idea, but if you just want to avoid trusting ICANN or
Verisign, you are better of setting up a third-party trust group that
takes TLS pubkeys (or TLSA records) and verifies/distributes those,
whether it is submitting to the EFF observatory, rbl lists, trust
ambassadors or otherwise. But using TACK to pretend there is no need
for the user to consult anyone else is pretty dangerous, especially
with hardcoded algos and timings all over the place, and no trust
model that scales, and corner cases with never before visited sites.

Paul

---

From: Marsh Ray <[email-masked]>
Date: Tue, 29 May 2012 13:02:06 -0500

Disclaimer: I haven't had a chance to read TACK in detail yet, so this 
not so much a comment on TACK as a response to the response.

On 05/29/2012 11:41 AM, Paul Wouters wrote:
> sources that are not as easy to MITM.

I don't understand. It sounds to me like on one hand you're criticizing 
TACK because it involves asymmetric keys without the "security of a 
trusted CA" and on the other you're saying unauthenticated DNS replies 
are somehow more secure because they are harder to MITM?

> With DNS records, you already
> guarantee for its correctness of today's use.

I apologize for bringing up the cliche' "perfect is the enemy of the 
good enough". Personally I don't want "good enough" security, I want 
"best practical" security, which is a somewhat higher standard. But the 
saying still applies.

What we've been learning in recent years is that such absolute 
guarantees (which look great on paper) are probably impossible in 
practice and we need to look at strategies that augment the status quo 
of PKI with a combination of less-than-airtight measures which make the 
attacker's job far more difficult.

One of the only large scale real-world MitMs case studies comes to us 
from Iran and Diginotar. The attacker in this case was able to subvert 
PKI, subvert unauthenticated DNS, and could have easily blocked DNSSEC 
had there been any. However he was ultimately defeated by a (non-IETF) 
pinning technique.

> With TLSA records, you can

There's no rule that says browsers, websites, and IETF can use only one 
new technique to secure the web. Therefore, an advantage of one proposal 
is not an argument against another.

> Then why do

It's unclear when, if ever, client browsers will begin to refuse to 
access sites for which DNSSEC records are unavailable but it's probably 
on the same timescale as websites going IPv6-only. Until that day, a 
malicious ISP is able to completely disable any protections provided by 
DNSSEC.

In the meantime it appears that in practice TLS handshakes are far more 
difficult to MitM successfully, particularly if the attacker has only 
one chance to intercept the browser's first contact with a regularly 
visited website such as Gmail.

> ambassadors or otherwise.

I suspect Moxie is familiar with these concepts as he is the guy who 
built Convergence. http://convergence.io/

> But using TACK to pretend there is no need
> for the user to consult anyone else is pretty dangerous,

Does TACK actually propose not consulting anyone else? I don't see it in 
the I-D.

> especially with hardcoded algos and timings all over the place,

This sounds like a valid criticism.

> and no trust model that scales,

I don't understand that. I see no scalability bottleneck here.

> and corner cases with never before visited sites.

Yes, it does not solve everything. But neither does anything else.

- Marsh

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 30 May 2012 09:00:41 -0700

Hi Paul,

So, you're arguing that since TACKs are not signed by an authority,
there is "no one backing them up", and we are "pretend[ing] there is
no need for the user to consult anyone else".

Not true!  TACK pins can be encoded into small identifiers and
distributed through 3rd-party trust infrastructures.  This is a
different, more flexible approach to 3rd-party trust than using
signatures.

-

You're also arguing that instead of TACK pins, it would be better to
distribute "DANE pins" (aka TLSA records) via DNS.

If DNS was secure, we would be interested in distributing TACK pins
through it.  TACK pins have the advantage (compared to DANE pins) of
allowing TLS key changes without needing CA trust or DNS updates.

Unfortunately, DNS is not secure at present.  So you're proposing that
instead of key-continuity via a TACK TLS handshake, it would be better
to do key-continuity via DANE pins retrieved over unsecure DNS.

There are several problems with that:
 - DANE usages 2 and 3 can actually disable a client's default path
validation, which would be a security hole in this case (and seems
risky in general?).
 - If the pin is delivered outside the protection of the TLS handshake
it is easier for an attacker to set a bad pin.
 - TLSA record retrieval could fail due to DNS middleboxes.
 - DANE pins do not have the same flexibility as TACK pins.

So, we think that TACK is a better approach for supporting both
key-continuity pinning as well as 3rd-party trust infrastructure.

Trevor