IETF Logo Mail Archive

Re: [TLS] DTLS 1.3 AEAD additional data

Eric Rescorla <ekr@rtfm.com> Thu, 23 April 2020 01:49 UTC

Return-Path: <ekr@rtfm.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 DF1D33A1084 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2020 18:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 emPLFKYsP6Lj for <tls@ietfa.amsl.com>; Wed, 22 Apr 2020 18:49:43 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AF13A1083 for <tls@ietf.org>; Wed, 22 Apr 2020 18:49:43 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id u6so4507526ljl.6 for <tls@ietf.org>; Wed, 22 Apr 2020 18:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6dFdxugSmM7DeCZeizSXFRhU1/6/Nads1aJYN/LB9+w=; b=hwlx8IopBBQQ9C+GDn/ejDdFTUJNIik51GPnFKeEP6wrDCvegpVEwpISP1pXyD2WKj oJBnmlRxhRCmOB2a3e1E9VkkvDfo61MzqeXaX/YtSP08gXqmwdB3nt37KFq9INmMoWtg p+LqxdV24klxLzra9L4RBtOlFhV8Qvc1fc4W/Pv3kVEH269lCrw5O/mKhBWL3pK3Qw/+ YAxZ4EOqKO19bCs5VhmyHmzpJydz6u9SsDMDAaXf3scuazel1iibnSxMMowsay7gVV7w nLwHNMdQufrOZ3vZEwyz1BOUiMUGhfXmYXpAheofuDEDoC5wXAjmA8tE2q4oKr9tpBS9 WTeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6dFdxugSmM7DeCZeizSXFRhU1/6/Nads1aJYN/LB9+w=; b=gHUpLwIbd/iwLR8EHozq383OFCkkrXk8Alz9pme0V4kqAAQnNLuZJD2oWLkmJck8dp GN8VCoooEWNvYdWBuvRpto6NLZDEmy4G5Gn/mcnYspjEysCQ9zxLiTKePCog3J90L9/1 3qVkk4eysDsGC6sfXXpcs3ViMvGBNzX39VfmJQkGjnJ+4cN3jLDeIa2p1K4imzAGrhs9 oybTMlg9EzUm1Ckxxctk6D3AzJrWku8KCWkGemfLI0TfsdkKvtw2RzVByJsgjN/8oule Y+ZYRDGEZbqEcnGjYoEP1ehY7MfzaDzCV73cYq92iE6pYL4glPeS9FNeaGePr/YlZG/u YeAw==
X-Gm-Message-State: AGi0PuZy8u+fgMvR7f5Phc5PmBUAcnql9eCtlfW4w/tWg0ZdoNHLRFNP c6brye+hkg/BzXHos9n0CYyzrXFuo5IqsDvgtmWpRQ==
X-Google-Smtp-Source: APiQypJPMastLXeatO71uPaf/mDsm/IZ4N0ngXuN1mCI13pLrYot5VZ/yLzLkYD1jxVdFD6zyHtvpgNI9wMRUnip/HE=
X-Received: by 2002:a2e:2414:: with SMTP id k20mr907590ljk.162.1587606581376; Wed, 22 Apr 2020 18:49:41 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 22 Apr 2020 18:49:05 -0700
Message-ID: <CABcZeBOvm-nx6hKR79ChN=A4RFzWgt=-BzjORc=N7_A79tO6Ng@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000053ae2e05a3eb76b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CGnQ_eFDmtIteFNY0e6XoMksILs>
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 01:49:45 -0000

OK but we would expect the peer to process CID-less records if they are
coalesced?

-Ekr


On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson <mt@lowentropy.net> wrote:

>
>
> On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <mt@lowentropy.net>
> wrote:
> > > I prefer Ekr's solution, but I would go with that being a
> recommendation (SHOULD) as opposed to a requirement (MUST).
> >
> > Can you clarify where you think we should say SHOULD?
>
> The security considerations seems right.  After the list of improvements
> over DTLS 1.2 CID.  You would say that an endpoint that is asked to provide
> a CID SHOULD provide one in every record (with the compact header,
> etc...).  If it does not, then it might be possible for an attacker to use
> that record to confirm guesses about linkability between two paths.  Also,
> omitting the CID might make it hard to route datagrams.
>
> With all of this, you might want a section heading for all the CID stuff.
>

v2.23.0 | Report a Bug | By Email