Subject: [TLS] Cookie reuse subsequent connections

From: Jānis Čoders <[email-masked]>
Date: Mon, 30 Oct 2017 09:07:42 +0200

Hi, is there ANY security issue with reusing Cookie from previous TLS
connection? In current draft there is text: "Clients MUST NOT use
cookies in their initial ClientHello in subsequent connections." I
can't think of any security implication, but can think of situations
where it could be useful.

-- 
Ar cieņu,
Jānis Čoders

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Oct 2017 20:31:46 +1100

What is most likely to happen is that the cookie will be invalid and
the connection will be rejected.

Many TLS servers assume that presence of a cookie means that they
previously sent a HelloRetryRequest on that connection.  For instance,
NSS packs a hash of the original ClientHello into the cookie so that
it can restore the handshake transcript.  Reusing the cookie will just
lead to the server restoring the handshake transcript from the wrong
handshake.  And that's even assuming that it accepts the cookie in the
first place.

On Mon, Oct 30, 2017 at 6:07 PM, Jānis Čoders <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Jānis Čoders <[email-masked]>
Date: Mon, 30 Oct 2017 11:51:56 +0200

Thank you. Ok, I understand that some servers could not allow reuse of
cookie, but why is it FORBIDDEN by standard? It could be suggested to
not reuse in general cases, but if I wanted to use TLS 1.3 with my
custom server, which uses cookies to only prevent spoofing attacks (in
UDP (DTLS) case). And clients know that they can reuse previous
cookies for fast handshake, then why would it be prohibited?

-- 
Ar cieņu,
Jānis Čoders

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Oct 2017 04:41:39 -0700

It's a privacy leak.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Oct 2017 08:52:22 -0500

> cookies for fast handshake, then why would it be prohibited?

The standard must ensure that compliant clients interoperate with
compliant servers.  Compliant servers are permitted (expected, even, for
DTLS!) to offload state such as the handshake hash into the cookie.  A
client that reused a cookie from an old connection on a new connection
to such a server would fail to interoperate, as the server would use the
wrong handshake transcript.  Ergo, the spec strictly forbids clients
from implementing this behavior in order to preserve interoperability.

There is "nothing" to stop some actor from deploying a noncompliant
implementation on their own private network where interoperability with
compliant implementations is not needed, but of course then that actor
must take responsibility for any changes to the security and privacy
properties as a result of those noncompliant modifications. In this
case, for example, the routability proof embedded in the cookie could
become stale with time (in case of readdressing), and the repeated
cookie provides linkability between ClientHellos from the same client
(to an adversary observing at some point in the middle of the network),
for a start.  No one could guarantee that there are not more changes to
the security and privacy properties than those already listed, of course.

-Ben

---

From: Jānis Čoders <[email-masked]>
Date: Mon, 30 Oct 2017 16:00:39 +0200

Thank you all for you answers.

-- 
Ar cieņu,
Jānis Čoders