IETF Logo Mail Archive

Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)

Benjamin Kaduk <bkaduk@akamai.com> Wed, 30 September 2020 21:34 UTC

Return-Path: <bkaduk@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 C2AC93A0BB9 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 14:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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 DvNyKLJ-oNvs for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 14:34:09 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 81CAF3A0BB8 for <tls@ietf.org>; Wed, 30 Sep 2020 14:34:09 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08ULVQOY027494; Wed, 30 Sep 2020 22:34:08 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=rKK1mG+/R5zDnYkjF5+QwtrQrUEQnpRhSn54kYxyemo=; b=m+eTQLD2Z38iuQPj0ze+xks2BpCWPZdK7L6k17oXKeBWnStutg1fyE9+ObYWbe6olRbu iUc4K2HhGSvL0EDVCNRcYTEeaoPvOwm29ywJpC1z74SVnNIjHcM/LTK1drWKuFPloJt0 iDLu7LO7dc5ygcLb4VVO5eiJ4y257b319Kx3ARVtKspJdQyruQ3y8xGglUafuLMVrjY9 f4wSHZNZnCpklN2AA10Cpjfu4hYS5+er5K1Y9ePkMtrMkND/DjpKEpuVEnfrxNAbItD7 6TwI9jk+MzssV55jIXh/HpUGIHYnUWgVQWh7zyFujILSkEWuyfccfPe9UntDOXw2QYyI Yw==
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 33stqns72e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 22:34:08 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08UL5xon008856; Wed, 30 Sep 2020 17:34:07 -0400
Received: from prod-mail-relay19.dfw02.corp.akamai.com ([172.27.165.173]) by prod-mail-ppoint3.akamai.com with ESMTP id 33t0yy02w7-37; Wed, 30 Sep 2020 17:34:07 -0400
Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay19.dfw02.corp.akamai.com (Postfix) with ESMTP id 2C7C060547; Wed, 30 Sep 2020 21:34:07 +0000 (GMT)
Date: Wed, 30 Sep 2020 14:34:06 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Michael D'Errico <mike-list@pobox.com>
Cc: tls@ietf.org
Message-ID: <20200930213405.GG20623@akamai.com>
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com> <AM0PR08MB37164F2D0E0CE5FB6D62D461FA350@AM0PR08MB3716.eurprd08.prod.outlook.com> <1c7e2f31-8a9e-4bd8-9e80-ab18ebeb609f@www.fastmail.com> <CACsn0cmbDz3ML8o5moAacqfXqYQo-Hqi53XQL6UoGYcZBwy-Mg@mail.gmail.com> <5af9219e-8a61-bd3f-caf9-39c169ae4539@pobox.com> <85beb428-f72e-090f-5f5f-7067b162e19c@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <85beb428-f72e-090f-5f5f-7067b162e19c@pobox.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_13:2020-09-30, 2020-09-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=908 adultscore=0 suspectscore=0 bulkscore=0 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009300172
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_13:2020-09-30, 2020-09-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k95tF1iVSPw67gaTFuHr0mXFPuw>
Subject: Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Sep 2020 21:34:11 -0000

On Wed, Sep 30, 2020 at 05:24:21PM -0400, Michael D'Errico wrote:
> I wrote:
> 
> > Also the server can't be actually stateless since
> > it needs to know the HelloRetryRequest message
> > for the transcript hash, right?
> 
> How can you even implement stateless HRR with a
> pseudo-session-ticket in the "cookie"?  The server
> needs to know the full HRR message to calculate the
> transcript hash, but this can't be part of the ticket
> since the ticket is included within the HRR, thus
> changing it....

The HRR is presumed to be a deterministic function of the
initial ClientHello, and as I discussed in my earlier message,
the server can reconstruct the initial ClientHello from the
second ClientHello and verify it against the hash in the cookie.

-Ben

v2.29.0 | Report a Bug | By Email | System Status