Subject: Re: [saag] [websec] Pinning

From: Chris Palmer <[email-masked]>
Date: Fri, 10 Aug 2012 15:20:22 -0700

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
<[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/saag
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Aug 2012 10:57:42 -0700

On Aug 10, 2012, at 3:20 PM, Chris Palmer wrote:

> HTTP.

I am one of those people who expressed that criticism in the past. Having said that:

> I currently don't consider that a huge problem — even though I

Fully agree to both. TACK is more general, but HPKP's specificity is an advantage for deployability and interoperability, and other TLS-using application protocols can copy what they need from it when it is deployed.

> using pin validation failure as a spam signal.

Even if you could, the SMTP community hasn't spent much effort and thinking about the value of TLS failure as spam signals. Until they do, it is not wise for us to gate our work on them. If they deal with it, they can then deal with things like pinning issues.

> * SSH already has PKP. :)

And we can learn from that. And from the smiley.

> HPKP, "IPKP", and "PPKP".

Yes.

> TACK) are a good, quick fix — as long as they are quick and simple.

"Here is what I say about them" proposals are orthogonal to "here is what I say about myself" proposals and should not be confused with each other.

--Paul Hoffman

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 11 Aug 2012 11:16:02 -0700

Hi Chris, all,

> deployment experience with both (or, sadly, real-world non-deployment

My 2c: We should keep exploring both TACK and HPKP.  I'd like to see
both proposals fleshed out, so we can do an in-depth comparison.
We'll try to send a draft-01 in a couple weeks.

> and expiration ideas, for example.

Awesome, looking forward to it.

There's some things you'll have to grapple with (is pin activation
performed for each key individually, or for the keys as a set?  when
is it performed?  etc.)

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

Agreed: TACK's TLS-generic-ness is a nice benefit, but a good solution
for HTTPS is more important than reusability.

> regular old X.509 failure).

Pinning for MTA-to-MTA SMTP seems useful.  Since receiving MTAs often
have invalid certificates, they're hard to authenticate any other way.
 If a sending MTA doesn't want to reject connections on pin failure,
it could run in "warn-only" mode.

> * SSH already has PKP. :)

Not proposing to change that.  But a TACK_Extension *could*,
theoretically, be embedded in non-TLS, non-X.509 protocols...  And
TACK *does* have some nice lifecycle features (activation, break sigs,
generations)...

> TACK) are a good, quick fix — as long as they are quick and simple.

I think pinning is likely to coexist or integrate with future trust systems.

For example, Cert Transparency is cool and would help detect bad
certs, but pinning would prevent their use.  I think sites would want
to deploy pinning even in a CT world.

Also, self-asserted pins like TACK and HPKP can be detected by trust
infrastructure (think Convergence or Google Cert Catalog) which
publishes them for auditors to review and for client apps to download.
 So, in a broad sense (pinning, CT, Convergence) are all "public
knowledge" systems which have some similar benefits.

Anyways, quick and simple is always good, but we shouldn't view
pinning as a disposable technology.  (Not that you're saying that, but
just don't want it to be misconstrued).

Trevor

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 11 Aug 2012 18:18:18 -0400

> regular old X.509 failure).

That depends.  Key pinning may not be very interesting for accepting
coming mail from unknown sources, but it may be very interesting when
TLS is used for communication between cooperating components of an
enterprise mail system, or with an outsourced anti-smap or anti-virus or
backup MX service.  And of course, it's also interesting when TLS is
used to protect authenticated mail submission services -- a user sending
outgoing mail via his ISP probably doesn't want to tell his username and
password to just anyone.

> * SSH already has PKP.

Well, no.  Certainly, SSH clients making a leap-of-faith connection to a
previously unknown host will generally remember that host's public key.
And yes, once a host's public key is known, clients will generally
reject a host that presents a public key other than the one known for
that host.  But then, web browsers do the same thing for leap-of-faith
connections to web servers, when a server has a self-signed certificate
or one signed by an unknown CA.  But while this behavior is common, it
is not required by any standard, not something I'd expect an SSH client
to do when an X.509 certificate is used, and not the same thing as key
pinning.

So in fact, if this gets done at the application layer, it likely will
eventually have to happen for SSH, too.

I would really rather not see a proliferation of application-layer
extensions to handle pinning of the long-term keys used for TLS.  While
I haven't participated in previous discussion on this question, I think
that in the long run this is much better handled at the TLS layer.

That said, there may be a benefit to solving the problem for HTTP at the
HTTP layer, _if_ doing so allows us to get something deployed more
quickly than a TLS-layer solution.

-- Jeff

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Aug 2012 15:08:31 +0100

Chris Palmer <[email-masked]> wrote:
>
> * It's not clear that SMTP over TLS is very beneficial,

It is not beneficial at the moment because it is underspecified - there is
no specification that says which identity to check against the
certificate (mail domain vs. host name), and there are significant
problems with either choice. In practice this has led to most SMTP server
certificates being unvalidatable or containing the wrong name.

See also draft-fanf-dane-smtp for a possible way to sort out this mess.

> because you can't stop delivery due to pin validation failure (or really
> even regular old X.509 failure).

I disagree. You can (and usually have to) stop delivery for DNS failures;
there is no reason why you can't do the same for authentication errors.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest FitzRoy, Sole, Lundy, Fastnet: Southwesterly backing southerly 4 or
5. Moderate, occasionally rough in northwest Fitzroy and west Sole. Rain or
thundery showers. Moderate or good.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Aug 2012 13:58:03 +0100

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

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 18 Aug 2012 13:03:43 +0100

On 17/08/12 13:58, Alexey Melnikov wrote:
> 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.
>

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