Re: [websec] [saag] Pinning

Hi all,

Resurrecting this ancient thread, and explicitly including Moxie and
Trevor in case they aren't already on any of the relevant mailing
lists.

So ultimately I do think we should decide on either HPKP or TACK, but
that we should make that decision after there has been some real-world
deployment experience with both (or, sadly, real-world non-deployment
of one or both).

Additionally, HPKP and TACK might converge, more or less. I have plans
to publish a new HPKP I-D that borrows some of TACK's pin activation
and expiration ideas, for example.

Additionally, one of the main criticisms of HPKP is that it is tied to
HTTP. I currently don't consider that a huge problem — even though I
consider TACK's TLS-generic-ness a nice benefit — for several reasons:

* HTTPS is the big, important application that we need to secure right now.

* IMAPS and POPS are surely on the list too, right after HTTPS; but
specifying "IPKP" and "PPKP" is likely to be relatively
straightforward once we get HPKP working.

* It's not clear that SMTP over TLS is very beneficial, because you
can't stop delivery due to pin validation failure (or really even
regular old X.509 failure). You could use certificate errors as
soft-fail spam signals, but you can in principle do that now, too,
without explicit pinning. I don't know how much benefit you'd get from
using pin validation failure as a spam signal.

* SSH already has PKP. :)

* The other common application protocols, like SIP, XMPP, and friends,
are likely to also be pretty easy to extend in a manner similar to
HPKP, "IPKP", and "PPKP".

And finally, as Ben Laurie pointed out, there is also Certificate
Transparency. I personally consider the "public log" class of
solutions (of which CT is a leading member, along with Sovereign Keys)
to be The Real Solution. Pinning-like solutions (including HPKP and
TACK) are a good, quick fix — as long as they are quick and simple.

On Wed, Jun 6, 2012 at 9:46 AM, Tobias Gondrom
<tobias.gondrom@gondrom.org> wrote:
> Sean et al.,
>
> <hat="individual">
> I agree with Paul and Yoav and think the coordination between dane and
> websec on HSTS and key-pinning is ok. Both WGs are aware of potential
> coordination issues when mechanisms in both (DNSSEC and HTTP header) will be
> implemented eventually. I don't think we need an operations statement yet.
> Maybe at some point in the future an informational Best Practice or if you
> wish a Std Track can help.
>
> With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, I
> am not so sure about potential conflicts here and whether we need or want
> both.
> </hat>
>
> Best regards, Tobias
>
>
> Ps.:
> <hat="WG chair">
> And on a personal note, one thing I am not so happy about is that I can see
> from the tls-tack draft, that the authors are aware of key-pinning (which is
> nice) and perceive that there would be flaws, yet they chose to not post
> their comments on it to websec nor inform the WG about their new draft.
>
> To make it easier in the future to coordinate the two drafts and possibly
> discuss and decide whether to boil down to one, it might make sense to
> inform websec about draft-perrin-tls-tack and have a discussion about it at
> some point there.
> Just my 5cents.
> </hat>
>
>
>
>
> On 05/06/12 23:01, Paul Hoffman wrote:
>>
>> On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote:
>>
>>>> The similarity of pinning and DANE has been discussed before. DANE
>>>> relies on DNSSEC being deployed, which key-pinning does not.
>>
>> Correct. Further, key-pinning in HTTP only applies to HTTP and relies on
>> the client being able to establish a TLS session using non-key-pinning
>> semantics. Key-pinning in TLS relies works with any lower-layer protocol and
>> relies on the client being able to establish a TLS session using
>> non-key-pinning semantics.
>>
>>>> Come to think of it, the draft needs a section comparing with DANE, but
>>>> that's for another thread.
>>>>
>>>> draft-perrin-tls-tack seems to tackle the same problem as key-pinning.
>>>> Instead of the pins getting attested to in HTTP headers, you have a special
>>>> public/private key pair, that you use to sign the SPKI from the server
>>>> certificate within the a TLS extension. Like key-pinning there's a TOFU
>>>> element here, because the client only learns about the special key when it
>>>> encounters it in a TLS handshake.
>>>>
>>>> The obvious question is why would we need both key-pinning and tack.
>>
>> It would be clearer if you said "both key-pinning in HTTP and key-pinning
>> in TLS (tack)".
>>
>> --Paul Hoffman
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag