Subject: [saag] Pinning

From: Sean Turner <[email-masked]>
Date: Tue, 05 Jun 2012 15:55:29 -0400

All,

There are many proposals for how to say which key or certificate or 
trust anchor should be used by the client in a TLS session that it is 
about to open. These proposals include making that decision in the DNS 
(https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the 
application after TLS has happened once, to be remembered in the future 
(https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and 
in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin 
tls-tack/). If more than one of these protocols are deployed, 
operational mistakes could lead to a client getting conflicting information.

Similarly, there are also proposals on how to say whether or not a 
client should expect to see a particular service running under TLS. 
These proposals include making that indication in the DNS (draft 
hoffman-server-has-tls, expired but might be revived) and in the 
application after TLS has happened once, to be remembered in the future 
(https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport 
sec/). If more than one of these protocols are deployed, operational 
mistakes could lead to a client getting conflicting information.

Is a standards-track operations statement needed to describe the choices 
that a TLS server administrator has, and to deal with conflicts between 
the proposals?

spt

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 5 Jun 2012 13:16:29 -0700

On Jun 5, 2012, at 12:55 PM, Sean Turner wrote:

> Is a standards-track operations statement needed to describe the choices that a TLS server administrator has, and to deal with conflicts between the proposals?

IMO, ultimately, absolutely.  I doubt we have sufficient understanding and consensus to do it yet (but I hope I'm wrong).
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Steven Bellovin <[email-masked]>
Date: Tue, 5 Jun 2012 22:41:13 -0400

On Jun 5, 2012, at 3:55 PM, Sean Turner wrote:

> All,
> 
> There are many proposals for how to say which key or certificate or trust anchor should be used by the client in a TLS session that it is about to open. These proposals include making that decision in the DNS (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information.
> 
> Similarly, there are also proposals on how to say whether or not a client should expect to see a particular service running under TLS. These proposals include making that indication in the DNS (draft hoffman-server-has-tls, expired but might be revived) and in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information.
> 

It strikes me more as BCP material.  If there are multiple standards,
what's needed is advice on how to choose amongst them, rather than a
standards track document that says "ignore these other standards track
RFCs and use this other one instead."

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 6 Jun 2012 14:17:18 +0200

On Tue, Jun 5, 2012 at 11:17 PM, Paul Hoffman <[email-masked]> wrote:
> From the SAAG mailing list, but appropriate here. I bet that Sean would appreciate all discussion to go on on the SAAG mailing list...
> Begin forwarded message:
>> From: Sean Turner <[email-masked]>
>> Subject: [saag] Pinning

The fact that more than one protocols can be deployed is an advantage.
In that case an attacker needs to control more infrastructure in order
to perform an attack on a TLS session. If you compare to the current
situation where the attacker only needs to control a random CA, it
looks like an improvement. Of course the situation can be improved by
restricting to few of these approaches rather than all (more peer
verification paths is better, but also increases the probability of
something going wrong unintentionally and thus false alarms).

regards,
Nikos

---

From: Ben Laurie <[email-masked]>
Date: Thu, 7 Jun 2012 11:22:46 +0100

On Tue, Jun 5, 2012 at 8:55 PM, Sean Turner <[email-masked]> wrote:
> All,
>
> There are many proposals for how to say which key or certificate or trust
> anchor should be used by the client in a TLS session that it is about to
> open. These proposals include making that decision in the DNS
> (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in
> the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/).
> If more than one of these protocols are deployed, operational mistakes could
> lead to a client getting conflicting information.

You forgot Certificate Transparency :-)

http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf

> Similarly, there are also proposals on how to say whether or not a client
> should expect to see a particular service running under TLS. These proposals
> include making that indication in the DNS (draft hoffman-server-has-tls,
> expired but might be revived) and in the application after TLS has happened
> once, to be remembered in the future
> (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/).
> If more than one of these protocols are deployed, operational mistakes could
> lead to a client getting conflicting information.
>
> that a TLS server administrator has, and to deal with conflicts between the
> proposals?
>
> spt
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag