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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 24 May 2012 23:35:49 +0300

Hi,

this draft looks too complex to be implementable in its current form, 
however I'd like to offer too early comments.

First, pinning is a useful idea. To make it even more useful, we might 
want to extend TACK itself by pinning additional properties of the 
server, not just the server cert. For example, pinning the property 
"this server supports the Encrypted Handshake extension" would go a long 
way towards resolving the EH downgrade attack that EKR described.

In addition, going through this exercise and then subjecting it to the 
user's "just press OK" mentality is kind of useless. So I would remove 
the following sentence:

"An example policy would be to accept the connection only if it passes 
certificate verification and is not rejected by a pin, or if the user 
elects to "connect anyway" despite certificate and/or pin failures."

Thanks,
	Yaron

>
> Trevor Perrin<[email-masked]>  writes:
>
>> 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!
>
> 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.
>
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 94, Issue 22
> ***********************************

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 24 May 2012 15:17:00 -0700

Hi Yaron,

> however I'd like to offer too early comments.

Which part?  We've implemented much of it (admin tool, TLS support,
OpenSSL/Apache patches):

https://github.com/tack

> First, pinning is a useful idea. To make it even more useful, we might want
> to extend TACK itself by pinning additional properties of the server, not
> just the server cert. For example, pinning the property "this server
> supports the Encrypted Handshake extension" would go a long way towards
> resolving the EH downgrade attack that EKR described.

If you are thinking of pinning some other property to the domain name
(besides a TACK key) then TACK may not be involved.  However, you
could consider re-using pin activation.

If you are thinking of pinning some additional property to the TACK
key, then check out section 6.2 on "Application-specific pinning",
http://tack.io/draft.html#anchor17

A possible use-case for that is MTA-to-MTA SMTP, where instead of
pinning the receiving MTA's domain name (to a TACK key), you'd like to
pin the email recipient's domain name.

> user's "just press OK" mentality is kind of useless. So I would remove the
> following sentence:
>
> certificate verification and is not rejected by a pin, or if the user elects
> to "connect anyway" despite certificate and/or pin failures."

We could maybe remove the "connect anyway" clause.  Personally, I
think it's reasonable to provide a user recourse in the case of
security errors, as long as the user is suitably warned.  Anyways,
this sentence is just an example (non-normative), and client
implementors are going to provide whatever UI makes sense for their
app and user base, so I don't think what we say here is critical.

Trevor