IETF Logo Mail Archive

Re: [TLS] TLSv1.3 Cookies

"Short, Todd" <tshort@akamai.com> Wed, 13 September 2017 15:11 UTC

Return-Path: <tshort@akamai.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 98539132DFB for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 08:11:39 -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, HTML_MESSAGE=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=akamai.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 xjsGIaRj6QnN for <tls@ietfa.amsl.com>; Wed, 13 Sep 2017 08:11:37 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87998132949 for <tls@ietf.org>; Wed, 13 Sep 2017 08:11:37 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8DF2WOA016758; Wed, 13 Sep 2017 16:11:33 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=vibaGZPvmGYKvRyrF9fGNDn5rLDqQFTIY5t0rmXnRcE=; b=SlkglG/lLLOuHEQFZ6bKX9DshAPXBwIw3j24o4O3sbAmvobzlbJjOrQ2nj8opTwqRTwm hgq3drEShb5zrcS6mwS4f8OzUcDEPGySK6B/3eM5fFB44nYf3fG+vU3lctRamNzbACDI cx+eH0JvGjd2Ozfe5W27RnVENhOIavFOvv9Mv35GldxfC8Spv9P0521EmKXnfiG0Kdo/ GeYm1TzBYXmDbxpaDgPAFu/8Q17ZNZ2sjH8m2rh9nwJs8Y73/tbrKTCGNrowvEE7fGAR pSS0SZNmmCIokmI+B2FvmQxnG834lTiIPzXMZv15HMs8B+3lzWOgWiCj8vm91jealFCB Xg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2cxfy7xj8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 16:11:33 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8DFB06V019447; Wed, 13 Sep 2017 11:11:32 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cwwqk89a7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 11:11:31 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 10:11:30 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 10:11:30 -0500
From: "Short, Todd" <tshort@akamai.com>
To: Matt Caswell <frodo@baggins.org>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLSv1.3 Cookies
Thread-Index: AQHTLKAh101Rz2qXXkCbj/g9m1ELb6KzP7YA
Date: Wed, 13 Sep 2017 15:11:29 +0000
Message-ID: <C27E03E9-1957-48E2-B9BB-9CFC1B0CA621@akamai.com>
References: <CAMoSCWYXWJMkFAdrcy033_bjMZjRUiU-V5f8MkoTXyvDfw+z6A@mail.gmail.com>
In-Reply-To: <CAMoSCWYXWJMkFAdrcy033_bjMZjRUiU-V5f8MkoTXyvDfw+z6A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.69]
Content-Type: multipart/alternative; boundary="_000_C27E03E9195748E2B9BB9CFC1B0CA621akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130238
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130235
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zjGtE6rtoTNHONCdgnBtL2lC-U8>
Subject: Re: [TLS] TLSv1.3 Cookies
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: Wed, 13 Sep 2017 15:11:39 -0000

One comment below.
--
-Todd Short
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Sep 13, 2017, at 10:53 AM, Matt Caswell <frodo@baggins.org<mailto:frodo@baggins.org>> wrote:

I am looking at trying to implement the TLSv1.3 stateless cookie
mechanism (in order to be able to support QUIC stateless retries).

I am not clear how cookies are supposed to interact with early_data.
Consider the scenario where a server is operating statelessly. Because
there is no state each ClientHello looks like the first one it ever
saw. The server only knows that a particular ClientHello is actually a
ClientHello2 following an HRR because of the state held in the cookie.

What happens when a client attempts to send early data to such a
server? The server will process the ClientHello and determine that
there is no cookie, sends back an HRR and then forgets all of its
state and waits for the next ClientHello. However what it actually
gets next is early_data. It does not know that that early data
followed an earlier ClientHello (because it is stateless) so it does
not know to skip the records. It just looks like illegal records so,
presumably, it will respond with an alert.

In this case, the client must have previously connected to the server, so it knows what parameters the server supports, and should only use those, preventing an HRR from being generated.

If the client were to send a ClientHello with unsupported server parameters and early data, I would consider this a client error, and an alert should be generated.


Should a stateless server silently drop any records that it doesn't understand?

I am also unclear what protects against cookies being replayed. If an
attacker wishes to perform an amplification attack on a particular IP
it awaits a legitimate ClientHello with a cookie coming from that IP
and records it. It then replays that ClientHello with cookie to the
server many times. The cookie looks valid to the server and it
responds with its ServerHello, full Certificate chain etc back to the
original IP. What have I missed here?

Thanks

Matt

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email