Re: [TLS] DTLS 1.3 AEAD additional data
Martin Thomson <mt@lowentropy.net> Thu, 23 April 2020 07:40 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 B47B83A1652 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2020 00:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=Sa02MuPa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z3LCO5ZZ
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 8_9oWxcwbJj9 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2020 00:40:30 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70323A1651 for <tls@ietf.org>; Thu, 23 Apr 2020 00:40:30 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1E8325C01A8; Thu, 23 Apr 2020 03:40:30 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 23 Apr 2020 03:40:30 -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 :cc:subject:content-type; s=fm2; bh=C8Ud/FHTGIoMN0l033vfZx3G7gMs k3kHUzOiwMCYl2c=; b=Sa02MuPaTjn37MMx9xslqToQ88VzuZ1ulxvGtF47UGOE DOfBcgPKdtAzRAhOFzeHFELXnLWESx12rOSzQZwZhVnS1vsQV4WU0mo2HEcDOqTC 1ZNx4jMKNrsv4smPOG5jncvNgtn2qNnl79aG3Dt/xqk4106q2INcPhNprmjcvqap 96qzHzwTOv2Qk/Yg0SqxbGC4OCiyxPq7nyUTDnQVYGlk5586CBhmi43/5zGn7JVj WonUF/8HdVCUTyXmhq7gD2w+GbpUNITXIlAjSQCNoMFEG8vzyDUwz4ywm1Iz/kn3 o6pkPHPI8tPvT5i55oxjG2rwYT+w0BRN6QNgmGXwEA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=C8Ud/F HTGIoMN0l033vfZx3G7gMsk3kHUzOiwMCYl2c=; b=z3LCO5ZZBs+tGE7wcRJ6GX ATY7EixLPmUdbEBze7lNJ/qNB3UvTizA/s77kQH9Q/I5prYgFzcTG7IL3YkZvCao cjpa4BQkaopeXvhMe/a2+sZXqUFNJ4S8Lg1mF7qOI7adw51bHFq/0ZebrtiSNKT3 cdWnd6/CaHyix/4obawsVfyZjd2RAYyrqc/IFbRjgi5ESz7aL5tSko251Mm6rMgt h+Pu/2vpuNqP3bVTLm6gEgov4yFvtStjhfVFL8eb49HA/yw5AF+Cn9LMDczA7kIN dn790Cdrxr6HU8q57Hr5FkaaAL1cIUwist9RMZSUz7Ek2TFFj9W8QaFpnXtNwzQQ ==
X-ME-Sender: <xms:bUahXsGj9T1cQ465NYjzfUx-cOInmzlCcavo9gV3pjk34aCkuNI3xw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:bUahXkg6bTZCiVwwbnM6wO1hcLLPcC-azTN1tdlajWdfAE5eEdeBtA> <xmx:bUahXo3rbzYh6Gxw79ny6XOXTsDVFEhGQJJ2RTWGZRiwMhChq63yhQ> <xmx:bUahXncyle--gHNJhqBRWeWcOVN8RVdsx7o5QorDWF2GbJtUqnNo3Q> <xmx:bkahXtJK3cM55-aVnD_3vwhmahfD2HwU5YQ02deWgxGnRL6M8uO9iw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8A5C7180091; Thu, 23 Apr 2020 03:40:29 -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: <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com>
In-Reply-To: <AM6PR08MB3318D5881B8D2BEFF938F2B79BD30@AM6PR08MB3318.eurprd08.prod.outlook.com>
References: <AM6PR08MB3318911C71C0DDB90480694A9BD50@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBMs+o4BU5VhqJKmQvnkEe9RkQXRv7Ej6pVD1-e1vdMoyA@mail.gmail.com> <CABcZeBM9Ri=Rz5kbWn08Vk-Y14MVSALwB1Bd9QV=HfWoq3XqSA@mail.gmail.com> <AM6PR08MB33184161239B6383EA7D776C9BD20@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBM4wVkH_pdTZMakyV9Y=tk8PNDknHTFhjwX-sw3GOOaZw@mail.gmail.com> <AM6PR08MB3318D6A11587449627F6EA679BD20@AM6PR08MB3318.eurprd08.prod.outlook.com> <CABcZeBNcODKehe217nr2jSedy6N6Gun+QYcksFp2Oqv6gLrzzw@mail.gmail.com> <AM6PR08MB3318717D21E69A2373AC1ACE9BD20@AM6PR08MB3318.eurprd08.prod.outlook.com> <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <CABcZeBNbehkW8FO29DS00m19+b=dH8V8esscu8OU-mmaJf6etQ@mail.gmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <CABcZeBOvm-nx6hKR79ChN=A4RFzWgt=-BzjORc=N7_A79tO6Ng@mail.gmail.com> <AM6PR08MB3318D5881B8D2BEFF938F2B79BD30@AM6PR08MB3318.eurprd08.prod.outlook.com>
Date: Thu, 23 Apr 2020 17:40:09 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Hanno Becker <Hanno.Becker@arm.com>, 'Eric Rescorla' <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gQ0hea3_90FBanj4H9Ie7A6lw00>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
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 07:40:33 -0000
On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > OK but we would expect the peer to process CID-less records if they are > coalesced? I guess so. If we allowed them to drop them, then we're close to saying MUST NOT omit. On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be a > fairly bad complication. Separately, I hope that no one would be > contemplating trial decryption for this, which would be terrible. > > Yes that's a fair point and also applies to Ekr's proposal > https://github.com/tlswg/dtls13-spec/pull/143. I don't see how. If you are talking about marshaling costs, that's a constant problem, but we haven't found that to be an issue in practice. From my perspective, it's the old DTLS records with a pseudo-header that are hard to construct; the new format is far easier to construct for sending (assuming that you don't try to shave the sequence number length down dynamically, but that's a new option our stack doesn't try to use). Yours is a sending-side concern, and that seems to be subjective, because I think that sending is easier without a pseudo-header. My concerns were about receiving. > The CID maintenance for incoming records can be avoided when forbidding > CID elision, as suggested by Ekr. > Comparing the state maintenance complications this avoids to the > increase in header size it introduces, maybe > that's the way to go, as the state maintenance indeed seems to be the > bigger pain. > However, even if CID elision is removed, I maintain the proposal to > always use the logical presentation of the header > for AAD, for all the mentioned reasons: (a) No interleaving of record > and datagram layer, (b) conceptual clarity and > independence of [header] compression methods from cryptographic > computations, as e.g. in cTLS, (c) dynamic > choice of header depending on network paths. All those issues persist > when sticking to the on-the-wire AAD. > What are your reservations towards this? I'm sorry, I don't follow your argument. The authenticated logical header being different than what is sent on the wire is a bug in my opinion. Authenticating all the bytes you send makes the protocol simpler and less error prone.
- [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Martin Thomson
- Re: [TLS] DTLS 1.3 AEAD additional data Christopher Wood
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Martin Thomson
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Martin Thomson
- Re: [TLS] DTLS 1.3 AEAD additional data Hanno Becker
- Re: [TLS] DTLS 1.3 AEAD additional data Martin Thomson
- Re: [TLS] DTLS 1.3 AEAD additional data Thomas Fossati
- Re: [TLS] DTLS 1.3 AEAD additional data Eric Rescorla
- Re: [TLS] DTLS 1.3 AEAD additional data Christopher Wood
- Re: [TLS] DTLS 1.3 AEAD additional data Thomas Fossati
- Re: [TLS] DTLS 1.3 AEAD additional data Thomas Fossati
- Re: [TLS] DTLS 1.3 AEAD additional data Thomas Fossati
- Re: [TLS] DTLS 1.3 AEAD additional data Christopher Wood
- Re: [TLS] DTLS 1.3 AEAD additional data Thomas Fossati