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.
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
