Re: [saag] [websec] Pinning

[Tobias Gondrom <[e-mail]>]

On 17/08/12 13:58, Alexey Melnikov wrote:
> On 10/08/2012 23:20, Chris Palmer wrote:
>> 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.
> I am surely hoping there would be no IMAP, POP or SMTP extensions to 
> address this. IMHO, judging from past experiences of any new 
> functionality being adopted by IMAP/POP/SMTP, chances of such 
> extensions being deployed in any reasonable number of email clients 
> any time soon are close to 0. I think some more generic facility (like 
> a TLS extension) has much better chance of success.
>
> Having said that, I think it is Ok if an HTTP facility is deployed now 
> before the TLS extension is finalized.

<hat="individual">
I agree with Alexey on both: chances of deployment in email clients is 
unclear and that it is ok to get an HTTP facility deployed.

>> * 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.
>>
>