Re: [Uta] Certificate pinning?

[Trevor Perrin <[e-mail]>]

On Fri, Mar 7, 2014 at 2:02 PM, Tom Ritter <[e-mail]> 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
>
> On 7 March 2014 10:12, Cyrus Daboo <[e-mail]> wrote:
> > 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?
>


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