Re: [TLS] Record-level ACKs in DTLS 1.3

Christopher Wood <caw@heapingbits.net> Wed, 11 March 2020 13:37 UTC

Return-Path: <caw@heapingbits.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 F04BF3A136F for <tls@ietfa.amsl.com>; Wed, 11 Mar 2020 06:37:31 -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=heapingbits.net header.b=i/aNVYr7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Je+r2tVj
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 jKNktqLFjAjZ for <tls@ietfa.amsl.com>; Wed, 11 Mar 2020 06:37:30 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AED3A136E for <tls@ietf.org>; Wed, 11 Mar 2020 06:37:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2D3845DE for <tls@ietf.org>; Wed, 11 Mar 2020 09:37:28 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 11 Mar 2020 09:37:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=QNmnRNLnn68R/6qyiJ/oj5XaMQvLzf0 oUQNjhrOa5RI=; b=i/aNVYr7G9deKeBRGdGqt5k5guMwOSv08+uJ6RDgKnKHWTV GlVUUrkb5yHPzkXxdBBGx4HKSABFWm9BJspDbosZ9fbQI9LBkzJ1DdBVeQOxd0iy jWWmF+RBMqfcg8MFiWANX4f843BEiB6y+gzm8ekHQfn6U6UmHJ4oRDgLn2VPoxV6 l98OYYIdr3ywbXDX5nbSU8U0UrE9Uvr/MNa6plpL01Y3GpXBzQEm0/uSEaWSvMVz vIO+g3JqVYH5PKpaIKUuoJVntr4QpPczHWrB6HqTr5ylnIQyvBQ8a/cXcKaxubPo qexLIoQzJaNJylFUnlQRdEMSBAAFrKUbBkbAWkw==
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=QNmnRN Lnn68R/6qyiJ/oj5XaMQvLzf0oUQNjhrOa5RI=; b=Je+r2tVjF/fiWtAmGuD6Ww b4DYNw1vMlQwQTpw9CRWOKeZg3zGHaRiSNNG9n6LbqT46dHiSbQMITYqnFfvwMm6 Xrjeua/D5ZOK/wo4S2nEnkZjWXwFDlZnqmH+U2Dae2c7VKdx7/sLhiGn4cZZ5YMk lK28Z7d53Ghhz2RQsUTAdJ26H3qezC8/MxTyz83x4om2IP/syarTXvMzNuY1z5aj MN5sEMckEaLph/zPX7ijl8MVJ2PcCDJF9NzqLtuBKqEifAm9Licdca8zZ2PA3EFd 7haNd5uAlN+lZ+D+MdFc6MZ1z8r62StkNF6TS/9sD6tK3vCRSR4Cn7C/jH/mF23Q ==
X-ME-Sender: <xms:l-loXq4Mk66ePSjX04URAlUS-UpOe3pY7G7m6JVulm02ioNDhdCMyA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvvddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:l-loXghCD7-sgEhziEkmeJ-OlpNddJSm5za8J6U3HbepvQubW1Ry3Q> <xmx:l-loXtGndyrKwUmz3FGH9umNFVJ2OYAYIYoIRxKo7iZonshFTRm45A> <xmx:l-loXtTQY7j6qQ0JlC_VrBlkDHLCNvpCrNBRZKnU6kLs5PcyI0GFfw> <xmx:l-loXmKVE47LVKR3FRO2usBNUoZxoghVJkfy_d7n8xnqzItYp1ObYg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 716193C00A1; Wed, 11 Mar 2020 09:37:27 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3
Mime-Version: 1.0
Message-Id: <6b59e9d4-027c-4639-ab04-06ae6222d773@www.fastmail.com>
In-Reply-To: =?utf-8?q?=3CAM6PR08MB33185DF8F4B8BDE6254F0D5F9BE20=40AM6PR08MB?= =?utf-8?q?3318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?=
References: =?utf-8?q?=3CAM6PR08MB3318E5A347314EB509AC91759BE80=40AM6PR08MB3?= =?utf-8?q?318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCABcZeBNZ4SZzdAs64a4H3g8ato=3D-zTJv=3D0ACgCLDcAn5gnSOkQ=40mail?= =?utf-8?q?=2Egmail=2Ecom=3E_=3CAM6PR08MB3318B0F99E60EE48B6DC34449BE50=40AM6?= =?utf-8?q?PR08MB3318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCABcZeBPeW=3DMrH01Li-j=5FbgOBr3VuT=3DErxEL-Sn0FzKVbKA4YrQ=40ma?= =?utf-8?q?il=2Egmail=2Ecom=3E_=3CAM6PR08MB33185DF8F4B8BDE6254F0D5F9BE20=40A?= =?utf-8?q?M6PR08MB3318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Wed, 11 Mar 2020 06:37:07 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vX4TPoTN4C8KY3hPxPkyhgWPimI>
Subject: Re: [TLS] Record-level ACKs in DTLS 1.3
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, 11 Mar 2020 13:37:32 -0000

On Thu, Mar 5, 2020, at 7:28 AM, Hanno Becker wrote:
>  Hi Ekr,
> 
> > I don't really agree with (b) for the reasons above. It introduces new
> > complications. As for (a) I believe that in practice the state that
> > must be kept is quite small (in general, there will only be no
> > retransmission at all and so you will only need one or slightly more
> > extant flight). The TLS handshake already requires you to store quite
> > a bit of state (hashes, etc.) so I'm not persuaded by this argument.
> 
> DTLS 1.3 should suit the case of IoT devices and lossy IoT networks, 
> together with the long-term prospect of post-quantum cryptography 
> and the large cryptographic material that goes along with it. In such 
> context, it is / will be important to be able to deal with excessive 
> fragmentation and retransmission efficiently.
> 
> Moreover, note that in the face of a PMTU change, retransmission on the
> basis of buffered opaque record content without knowledge of the 
> underlying
> handshake structure doesn't work, and will require retransmission of 
> the entire flight. 
> This is avoided with ACKing at the handshake level, which makes 
> retransmissions
> agnostic to PMTU changes.
> 
> > I think we're down to a difference of technical judgement now, so
> > I'll leave it to the chairs to determine how to address this comment.
> 
> It would be nice to hear some more opinions on this here, too.
> 
> Thanks for the discussion,

There are two primary issues raised in this thread:

1. Lack of clarification regarding when ACKs should be sent.
2. Record-level ACKs make efficient implementations for IoT devices 
harder. (draft

The latest version of the specification addresses (1) with the following 
text:

~~~
record_numbers:  a list of the records containing handshake messages
       in the current flight which the endpoint has received and either
       processed or buffered, in numerically increasing order.

    Implementations MUST NOT acknowledge records containing non-
    duplicative handshake messages or fragments which have not been
    processed or buffered.  Otherwise, deadlock can ensue.

    During the handshake, ACKs only cover the current outstanding flight
    (this is possible because DTLS is generally a lockstep protocol).
    Thus, an ACK from the server would not cover both the ClientHello 
and
    the client's Certificate.  Implementations can accomplish this by
    clearing their ACK list upon receiving the start of the next flight.

    After the handshake, ACKs SHOULD be sent once for each received and
    processed record (potentially subject to some delay) and MAY cover
    more than one flight.
~~~

Regarding (2), given that record-level ACKs align with QUIC and also do 
not seem to be insurmountable implementation obstacles (e.g., stacks can 
re-generate large handshake messages on-demand instead of buffering 
them), the chairs do not think any change here is required.

Thanks,
Chris, on behalf of the chairs