Re: [TLS] Implicit ACKs in post-handshake

Martin Thomson <mt@lowentropy.net> Thu, 23 April 2020 23:58 UTC

Return-Path: <mt@lowentropy.net>
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 BD2C33A0AA8 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2020 16:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=FIko5nEq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VL1f7Hzj
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 mqZxl-hIezjJ for <tls@ietfa.amsl.com>; Thu, 23 Apr 2020 16:58:16 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737CE3A0A98 for <tls@ietf.org>; Thu, 23 Apr 2020 16:57:59 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E5E374B1 for <tls@ietf.org>; Thu, 23 Apr 2020 19:57:57 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 23 Apr 2020 19:57:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=8ATzOMyO/Q0XmKsUCXfRiiSBzZWXoud g31FMtLzp/VI=; b=FIko5nEqGy5D0/kKABAUFyq19tDJzZKCykhGI77TouFm/g5 THVvl4ojYFM562if9QHPEZfBpBwOc0jbbRcMQVUj4JBRYmxKAlPjtxkVp8+7qQ2S +YAQCA2lJ36h1APiC9e7PanrHrCPemNQoD0Cg47oaKBNqZN+TnRDpIiryaSWrtPc r8Ic3tJV+eQobqRabb05qdO3TogOrKqt0TjEcxD7Vjgnaj7E69hVKDXAEhHeqmiy uy0b+LeEMRVuKuz7SvJ3V/RzhtZpsR3A9pwmD78TqTqFTRAXnkUPSwjyR6AKYJfJ t1+BGtfS07Z/PhYNFBcVR3H0ltH8gN0FpFk8h0w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8ATzOM yO/Q0XmKsUCXfRiiSBzZWXoudg31FMtLzp/VI=; b=VL1f7HzjOOpUsK3xROtRN7 +f0SeD4Jdo1NVSriZ4dph/rxFmqolwUnJ0VnxfccdLMrLjpEO6ViRISHslJNkdz+ xPs14Y2p64VvdAGNyPRUwgl03svalFJDK+OYejPcgfM9x4OyCiXzeNFSi4qIaQfR 7+aWK76/l/gzls/6HBR+iU0nUxjswM+WHdq1XdWfRXAucjhtAUXDiAIldWgrXobN WcmvhmGCdIeE54ASNi875ttTq36VxVcSvhN8K9LH4/M+VIvuvrVUNDkGbhs6rlj2 KR7c7aTWjGHszUCmpED/hNGdY+g/EHbMlsYRL5KfTwBA+EBNd2pT7u/ilUd3TNSw ==
X-ME-Sender: <xms:hSuiXsKagN0A93nH7m3dEaN1P3aDVRWAf5oRv7yuItzoVfIJmx9ytQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedtgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght
X-ME-Proxy: <xmx:hSuiXu_bZE0xHqOgFotVuWaZsTueOmkTL3BnIRZ7G-a7-aVZBb-F1w> <xmx:hSuiXvdnUdVUxRaXMMKe0dcaVj6gHW_s4_9fRsFGCP40SikuCyf5KQ> <xmx:hSuiXs5dii7LwLnWVn5bFkYUrP0xIOJC5bkyVt4O9Fg1Xto73b4Ecg> <xmx:hSuiXtV9BUcLPXQ-ZY7INqmJCOeEHA9TLnRymw30wABGYHptjvK23A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3601E180091; Thu, 23 Apr 2020 19:57:57 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <04c48f22-4475-42fc-bbc9-980523875319@www.fastmail.com>
In-Reply-To: <CABcZeBNcQm3Vr=6QexvXH=RxS+s-wFGJHLg0x3BiaDYKbtCn0w@mail.gmail.com>
References: <CABcZeBOjajk44mASbVZ1O-gYyh54B-TsHxV2iVaAXdqUgmB5kQ@mail.gmail.com> <AM6PR08MB331828BC62552C177CEE4D369BD30@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBNcQm3Vr=6QexvXH=RxS+s-wFGJHLg0x3BiaDYKbtCn0w@mail.gmail.com>
Date: Fri, 24 Apr 2020 09:57:36 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Mib_pwWb4HRkcBAGt6qGCrWEAg>
Subject: Re: [TLS] Implicit ACKs in post-handshake
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: Thu, 23 Apr 2020 23:58:18 -0000

What makes this case interesting is the non-machine time that might exist between receiving CertificateRequest and sending Certificate.

In most of the exchanges, we expect there to be an answer that is immediately available, so that the implicit ACK works.  Here we have to recognize that ACK might need to be sent anyway if the Certificate message is going to take time to source.

If we don't have something already, it might pay to at least mention that if there are significant delays involved in preparing a response, an ACK SHOULD be sent rather than relying on implicit acknowledgment.

On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote:
> I don't feel strongly about it, and not changing anything is certainly 
> easier. It just felt out of place and I wanted to flag it.
> 
> -Ekr
> 
> 
> 
> On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker <Hanno.Becker@arm.com> wrote:
> >  Hi Ekr,
> > 
> >  Do you see some simplifications resulting from this? 
> > 
> >  On first thought I'd think that since implementations are already able to handle implicit
> >  ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth, too.
> > 
> >  In contrast, it seems that if the client's Certificate message no longer
> >  implicitly acknowledges the CertificateRequest, there's need to explicitly
> >  explain the state machine transition upon receipt of the Certificate message
> > prior to receiving an ACK for the CertificateRequest.
> > 
> >  Overall I feel that there is no need for change here, but I might miss something.
> > 
> >  Best,
> >  Hanno
> > 
> > *From:* TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
> > *Sent:* Thursday, April 23, 2020 9:48 PM
> > *To:* <tls@ietf.org> <tls@ietf.org>
> > *Subject:* [TLS] Implicit ACKs in post-handshake 
> > Hi folks,
> > 
> >  As I was going through the ACK clarifications, I noticed that we were
> >  requiring explicit ACKs for everything other than post-handshake
> >  client auth, where we allow implicit ACK. This obviously works,
> >  but given that (1) we expect explicit ACK from the client if there
> >  is a user-consent delay and (2) it's the only one, what would people
> >  think of using implicit ACKs only for the handshake itself.
> > 
> >  -Ekr
> > 
> > 
> >  IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>