Re: [TLS] Cookie reuse subsequent connections

Jānis Čoders <janis.coders@gmail.com> Mon, 30 October 2017 14:00 UTC

Return-Path: <janis.coders@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF513F9D8 for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 07:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZQy3NOJ9L4b for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 07:00:43 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26AC13F950 for <tls@ietf.org>; Mon, 30 Oct 2017 07:00:42 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id v132so22101582oie.1 for <tls@ietf.org>; Mon, 30 Oct 2017 07:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lQq7tClrPr5NbEcmX/qUoL+aEr7NYLNgQlyX3hvmLa8=; b=Lh4pB70paSNlCBeiviYSsqICXIFtzqCTvpVuzQ5MkQru0+STOyvbdXP8S7rvS/ysH0 iNZkofbS5FPmz43klwQ3i7I7b1fxMoctqlvoiZXRHOWFJZtQm4I38O/yQZcQKRkRPoPH eePNjFt1nLt6NoXNw3CeNBm/Ibz3jKmSd4GvsHUtvL3TPH1y/m5/yOiVI9S6w/9x/Xw+ 20mixCxAwFefbO/mVm8mPZILM4b3pLiP7YbGHIF8Bd+ile0EKrgXF1zsDQFk5CWZxwDE UccTE/kKnmxIF5IqBzxRTH+2wsUedB1bRqk5ReOl4NHs9Qw7CISX0hNPd0VbSZZomkBO jeKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lQq7tClrPr5NbEcmX/qUoL+aEr7NYLNgQlyX3hvmLa8=; b=mNxkILK90J7mUbkdsaHJK9N8MzxqQPQPq29spA6U2Y5c3n+cDPtL3fO6vZmwIEMgVQ ejH4ErrU8ervhV64i0oq6MxnTvXyAo6gwqQiVYlTxj0hcRA4NTeCd2VOW1FA81ASd3g3 ivPcIKkhPLBW7OrWHrcJnbm4ic/4AqMyXYh8i/Ng6zUe62CE44tQBR4Gm9i2EawYluNJ cuGJ6DBJr/LLSW2uSTd7f9yCAIh2UnLfdZ/KZ9f64W8vpftS7o7eJAud0s5Qp0hse3/w eg+iK6+0fvLL1yZOkWRDe/OWJ59ROpmFfTIY8D6vCsfVmlJU9k0+N131sm95/rM+8vMQ 2gBQ==
X-Gm-Message-State: AMCzsaW/1Un/2ylXojykljx00/Jds6wMaENwadGFM0HGOPSjrYl2+uy3 B/XxR/DIceei0KjzCUZYMWeb5W4uG9QdOW4ey5GTuQ==
X-Google-Smtp-Source: ABhQp+S+CDTzxVHpOhjDfaImy8fulTKMsAScVnuvlF+w7KxeRt992QikR0V+dT5UnxDpj6GXMlLVE91WI5FBvHWxLbQ=
X-Received: by 10.202.166.15 with SMTP id p15mr4699681oie.51.1509372040300; Mon, 30 Oct 2017 07:00:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.88.141 with HTTP; Mon, 30 Oct 2017 07:00:39 -0700 (PDT)
In-Reply-To: <d488f6e9-ca7f-0c30-1d37-11deaa8f54e2@akamai.com>
References: <CA+tEvRTBGj0JwQVh66DiFQhrYXdV2h0zOTzAE5MS-yykHe3dLw@mail.gmail.com> <CABkgnnWPGomdhb8+t1P5jhR5XV+4CKFRRHHExZ=FcHPieM-WkA@mail.gmail.com> <CA+tEvRQovU=4NHwbm17Wubo1My5vdbH5hG-jjVMCZWPDUMEp7Q@mail.gmail.com> <d488f6e9-ca7f-0c30-1d37-11deaa8f54e2@akamai.com>
From: Jānis Čoders <janis.coders@gmail.com>
Date: Mon, 30 Oct 2017 16:00:39 +0200
Message-ID: <CA+tEvRQ=3MV=k2KdK2yeuMjfs2Vt-fPaswXiyCFj7nVbiG4q-A@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/H2JMImBISGfwVT8cMuLQ7CfMTIc>
Subject: Re: [TLS] Cookie reuse subsequent connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 14:00:45 -0000

Thank you all for you answers.

On 30 October 2017 at 15:52, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> On 10/30/2017 04:51 AM, Jānis Čoders wrote:
>> 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?
>>
>>
>
> 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



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