Subject: [Uta] Certificate pinning?

From: Cyrus Daboo <[email-masked]>
Date: Fri, 07 Mar 2014 10:12:36 -0500

Hi,
Has any thought been given to generalizing the certificate pinning work 
being done by the websec WG 
(<http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11>) to make it 
applicable to other protocols?

And, vice versa, what about taking the concept of security latches from 
draft-newman-email-deep-01 and making those available in HTTP?

I guess this begs the question of what, if any, relationship is there 
between UTA and WebSec WGs?

-- 
Cyrus Daboo

---

From: Tom Ritter <[email-masked]>
Date: Fri, 7 Mar 2014 17:02:07 -0500

Quite so.  http://tack.io/ is a mechanism for pinning that operates at
the TLS layer, making it usable for a wide variety of protocols,
without needing to redefine it for every application later protocol.

-tom

On 7 March 2014 10:12, Cyrus Daboo <[email-masked]> wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 9 Mar 2014 01:21:47 -0800

> > draft-newman-email-deep-01 and making those available in HTTP?

To echo Tom, TACK's approach to pinning is applicable to any TLS-using
protocol (e.g. MUA protocols like POP, IMAP, or SMTP):

http://tools.ietf.org/html/draft-perrin-tls-tack-02

Cross-domain SMTP poses challenges for pinning due to MX indirection, one
approach is here:

https://lists.riseup.net/www/arc/tack/2013-08/msg00000.html

DEEP's "latches" allow a server to pin itself so that:
 (a) the server must forever present a valid certificate from any CA in the
Web PKI, or
 (b) the server must forever maintain a valid DANE record and DNSSEC chain.

There's no option for the server to pin itself to a 3rd-party of its own
choosing, or to manage its keys itself.  The assumption is apparently that
everyone wants to delegate the power to authenticate (and thus impersonate)
their domain to one of these two systems.  That's a bad assumption.

I also question the wisdom of pinning permanently to *anything*.  Mistakes
happen.  Domains change ownership.  TACK has a more conservative approach
to pin lifetimes.

Trevor

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 11 Mar 2014 17:04:13 +0000

In my view, it would be very useful, to include a high level description of these "emerging" techniques (e.g., pinning, latching, etc.) in UTA's generic "bcp" with the pointers to application-specific works (if exist).

Echoing Stephen Farrell's words, it is not important where in IETF the work is being done, as long as our readers can find and understand the issues.

It is natural that these techniques are being introduced bottom up. It would be interesting to know, though,  whether people are actually interested in defining truly "application independent" mechanisms for these ideas.

Orit.

From: Uta [mailto:[email-masked]] On Behalf Of Trevor Perrin
Sent: Sunday, March 09, 2014 1:22 AM
To: Tom Ritter
Cc: Cyrus Daboo; [email-masked]
Subject: Re: [Uta] Certificate pinning?

On Fri, Mar 7, 2014 at 2:02 PM, Tom Ritter <[email-masked]<mailto:[email-masked]>> wrote:
Quite so.  http://tack.io/ is a mechanism for pinning that operates at
the TLS layer, making it usable for a wide variety of protocols,
without needing to redefine it for every application later protocol.

-tom

> draft-newman-email-deep-01 and making those available in HTTP?

To echo Tom, TACK's approach to pinning is applicable to any TLS-using protocol (e.g. MUA protocols like POP, IMAP, or SMTP):

Cross-domain SMTP poses challenges for pinning due to MX indirection, one approach is here:

DEEP's "latches" allow a server to pin itself so that:
 (a) the server must forever present a valid certificate from any CA in the Web PKI, or
 (b) the server must forever maintain a valid DANE record and DNSSEC chain.

There's no option for the server to pin itself to a 3rd-party of its own choosing, or to manage its keys itself.  The assumption is apparently that everyone wants to delegate the power to authenticate (and thus impersonate) their domain to one of these two systems.  That's a bad assumption.

I also question the wisdom of pinning permanently to *anything*.  Mistakes happen.  Domains change ownership.  TACK has a more conservative approach to pin lifetimes.

Trevor

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2014 16:12:14 -0400

On 03/11/2014 01:04 PM, Orit Levin (LCA) wrote:
> It is natural that these techniques are being introduced bottom up. It 
> would be interesting to know, though, whether people are actually 
> interested in defining truly "application independent" mechanisms for 
> these ideas. 
I find myself wondering if new applications need latching techniques, or 
if they're only needed for legacy applications which don't have built-in 
protection against MITM attacks.   Perhaps new applications should just 
always use TLS or a similar technology which ensures that the client 
really is talking to the server it thinks it is talking to.  Once that 
condition is met, "latching" has less value, and normal protocol 
negotiation mechanisms might be sufficient.

(Note that I didn't say that latching had zero value - some users might 
indeed want to know, for instance, that their mail server is now no 
longer offering a ciphersuite with PFS - but this is probably also in 
the realm of conditions for which a warning message to the user is of 
dubious value since most users will just click OK anyway.)

As for existing applications, I suspect that latching is going to need 
to be tailored, at least somewhat, to each application, because 
different applications operate under different conditions and/or have 
different authentication methods with different degrees of 
vulnerability.   But we won't know for sure unless/until we try to adapt 
latches to several different applications and see what we have in 
common.   And I'd prefer to not block attempts to secure any of those 
applications while we wait to see what commonality there is.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 11 Mar 2014 16:32:05 -0400

Hi Keith,

> negotiation mechanisms might be sufficient.

I think one of the key goals for the websec work was to prevent attacks in 
which a root certificate authority is compromised, potentially allowing an 
attacker to create certificates that trick the client into thinking it is 
talking to the real server when in fact it is being MITM'd.

-- 
Cyrus Daboo

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Mar 2014 16:37:51 -0400

> I think one of the key goals for the websec work was to prevent attacks in which a root certificate authority is compromised, potentially allowing an attacker to create certificates that trick the client into thinking it is talking to the real server when in fact it is being MITM'd.

Did they come up with any thoughts on how to do this?  So far, our best hope in this area is certificate transparency, which is in its infancy.

If a CA you trust has been compromised, there's not much you can do except un-trust the CA and somehow 'pin' the certificates you've already seen.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2014 16:37:39 -0400

On 03/11/2014 04:32 PM, Cyrus Daboo wrote:
> I think one of the key goals for the websec work was to prevent 
> attacks in which a root certificate authority is compromised, 
> potentially allowing an attacker to create certificates that trick the 
> client into thinking it is talking to the real server when in fact it 
> is being MITM'd.
>
I'm familiar with the threat, but not familiar with that work.  Does it 
somehow use latches or something else?

(I've been assuming that TLSA records would be useful as additional 
trust anchors to deal with cases like compromised or untrustworthy CAs.)

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 11 Mar 2014 16:38:17 -0400

Hi Rich,

--On March 11, 2014 at 4:37:51 PM -0400 "Salz, Rich" <[email-masked]> 
wrote:

>> I think one of the key goals for the websec work was to prevent attacks
>> in which a root certificate authority is compromised, potentially
>> allowing an attacker to create certificates that trick the client into
>> thinking it is talking to the real server when in fact it is being
>> MITM'd.
>
> Did they come up with any thoughts on how to do this?  So far, our best
> hope in this area is certificate transparency, which is in its infancy.
>
> If a CA you trust has been compromised, there's not much you can do
> except un-trust the CA and somehow 'pin' the certificates you've already
> seen.

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

-- 
Cyrus Daboo

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2014 16:47:06 -0400

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

Interesting.  Offhand, it seems unfortunate that (for this particular 
mechanism) the indication provided by the server is in the HTTP protocol 
rather than the TLS protocol.   If the indication were in the TLS 
protocol it would presumably be easier to get it incorporated into TLS 
stacks and automatically checked by client applications.

Then again, as far as I can tell, the real trick with all of these 
latching mechanisms seems to be to make operators aware of the latches 
and how to enable them, make them aware that enabling the latches will 
cause their customers' service to fail en masse if the latched condition 
fails to be met without adequate advance notice, and convincing the 
operators to enable the latches anyway.

Keith

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 11 Mar 2014 15:24:15 -0700

On Tue, Mar 11, 2014 at 1:37 PM, Salz, Rich <[email-masked]> wrote:

> in which a root certificate authority is compromised, potentially allowing
> an attacker to create certificates that trick the client into thinking it
> is talking to the real server when in fact it is being MITM'd.
>
> Did they come up with any thoughts on how to do this?

Yes, the idea behind HPKP and TACK is for servers to assert that their key
should be "pinned" for some period of time:

http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/
https://tools.ietf.org/html/draft-perrin-tls-tack-02

This generalizes the hard-coded ("preloaded") pinning which Google has
deployed in Chrome in the last few years, and which has detected several CA
failures.

>  So far, our best hope in this area is certificate transparency, which is
> in its infancy.
>

Maybe.  But pinning is a good idea too.  And it deserves more attention,
IMO, since it doesn't have the readymade constituency of PKI or DNSSEC
solutions, and Google's not pushing it like they're pushing CT.

Note also that CT is particularly suited to https.

For a protocol like MTA-to-MTA SMTP, MTAs aren't already expected to have
certs (or valid certs), so *some* sort of pinning or policy assertion from
a server about how it should be authenticated seems necessary.

Also, browsers are reluctant to perform online lookups to verify servers
(due to latency / reliability).  This is why CT needs central log
authorities, trusted by all browsers, issuing signed statements.  But MTAs
are probably more willing to do online lookups, so trust-agile solutions
become possible.  This is where self-asserted pinning shines, since a
site's assertion of a TACK or HPKP pin could be observed by various
monitors (think Converge/Perspectives/Vantages/etc), then queried by
relying parties, without a centralized infrastructure like CT.

Trevor

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Mar 2014 18:28:20 -0400

Pinning is nice and simple and I like it because of that.  It seems to me that the main problem is that if you don't speak to the server before the badguy gets to you, then you end up pinning a the wrong data.

/r$

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 11 Mar 2014 15:29:37 -0700

On Tue, Mar 11, 2014 at 1:47 PM, Keith Moore <[email-masked]>wrote:

> rather than the TLS protocol.   If the indication were in the TLS protocol
> it would presumably be easier to get it incorporated into TLS stacks and
> automatically checked by client applications.
>

Yep, that's one of the rationales behind TACK:

http://tack.io

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 11 Mar 2014 15:40:12 -0700

On Tue, Mar 11, 2014 at 3:28 PM, Salz, Rich <[email-masked]> wrote:

> Pinning is nice and simple and I like it because of that.  It seems to me
> that the main problem is that if you don't speak to the server before the
> badguy gets to you, then you end up pinning a the wrong data.
>

That is a problem, but there's things that can be done:

* On first contacting a new TLS server, clients could lookup its pin from
an online source.  Or clients could be populated with pins lists for
popular servers, similar to how browsers are currently preloaded with HSTS
and key pins.

 * TACK has a "pin activation" algorithm, so the client only forms pins
with lifetimes equal to the amount of time the pin has been observed.  So
if an attacker only has brief control of your network connection, she can't
set long-lived pins.

Trevor

---

From: Yan Zhu <[email-masked]>
Date: Thu, 13 Mar 2014 12:45:39 -0700

On 03/11/2014 03:24 PM, Trevor Perrin wrote:

> authorities, trusted by all browsers, issuing signed statements.  But
> MTAs are probably more willing to do online lookups, so trust-agile
> solutions become possible.  This is where self-asserted pinning shines,
> since a site's assertion of a TACK or HPKP pin could be observed by
> various monitors (think Converge/Perspectives/Vantages/etc), then
> queried by relying parties, without a centralized infrastructure like CT.
> 
> 

Google has announced plans to enforce CT in Chrome for EV certificates,
starting at some date in the near future (possibly this year).
https://www.digicert.com/certificate-transparency.htm

EFF had a similar proposal called "Sovereign Keys"
(https://www.eff.org/sovereign-keys), but it seems like CT has the right
momentum at this point.

-Yan

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 Mar 2014 09:47:53 -0400

> (https://www.eff.org/sovereign-keys), but it seems like CT has the right

I don't think CT and key pinning or TACK are necessarily in conflict, fwiw.

HPKP and TACK are ways of asserting "these are the only keys i'm willing
to allow for use with my site".  They attempt to prevent the use of
misissued certificates.

CT asserts "this certificate is known to be publicly logged and is
therefore auditable"; it does not attempt to prevent the use of
misissued certificates; rather, it helps the domain owner detect
misissuance, but only if the browsers require verifiable SCTs and check
inclusion proofs (thereby holding the logs to account), and the logs
hold the CAs to account (e.g. by refusing SCTs to CAs proven to have
mis-issued certs).

We can have both! :)

	--dkg

---

From: Yan Zhu <[email-masked]>
Date: Fri, 14 Mar 2014 09:16:04 -0700

> hold the CAs to account (e.g. by refusing SCTs to CAs proven to have

I agree with you and didn't mean to suggest that they aren't
complementary. In fact, Google Chrome already supports both HPKP (sans
the reporting mechanism in the later versions of the spec, which needs
more work, IMO) and CT. :)

1. HPKP for Chrome/Chromium:
https://code.google.com/p/chromium/issues/detail?id=78369. Ongoing work
for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=744204. I
haven't checked whether the Chrome implementation supports features
added to the spec after
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 (such as
includeSubdomains).

2. CT in Chrome/Chromium:
https://code.google.com/p/certificate-transparency/wiki/CertTransparencyInChrome

-Yan

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 14 Mar 2014 09:30:14 -0700

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

Hi Yan,

I don't think the Chromium implementation of HPKP is complete, based on
code review I would not encourage sites to use it.

Trevor