Re: [Uta] Certificate pinning?

[Trevor Perrin <[e-mail]>]

On Tue, Mar 11, 2014 at 1:37 PM, Salz, Rich <[e-mail]> 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?


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