Re: [Uta] Certificate pinning?

["Orit Levin (LCA)" <[e-mail]>]

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:[e-mail]] On Behalf Of Trevor Perrin
Sent: Sunday, March 09, 2014 1:22 AM
To: Tom Ritter
Cc: Cyrus Daboo; [e-mail]
Subject: Re: [Uta] Certificate pinning?


On Fri, Mar 7, 2014 at 2:02 PM, Tom Ritter <[e-mail]<mailto:[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]<mailto:[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