Re: [TLS] DTLS 1.3 AEAD additional data
Martin Thomson <mt@lowentropy.net> Wed, 22 April 2020 23:54 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 CBCA73A0E50 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2020 16:54:26 -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=d54M5ZI6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YHElL7j8
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 Rb3g9slb1mGf for <tls@ietfa.amsl.com>; Wed, 22 Apr 2020 16:54:24 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F713A0E54 for <tls@ietf.org>; Wed, 22 Apr 2020 16:54:23 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4ADD8424 for <tls@ietf.org>; Wed, 22 Apr 2020 19:54:23 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 22 Apr 2020 19:54:23 -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=fHVF2Awzv4lzi2inUfDmbs5dfh4P6E+ 1ORFt8vuKpjg=; b=d54M5ZI6/moyJI33pnNZaetcSSvVXNao0NZW+2NUX6hNP+L OypQebhTCnxDLYfR5FThAfn/PJd71UmPRKdDKZqGQ4uJ4gp3Ybqlykoc5jSDfiCo ebUBW/bKSu1+H3nVk3y0tBFCozf6UGPE2FT7VK0U1qlRUvixt0WElgtK5w+1HVr8 TMZnVkloEccLdUUaAJQJiBw9xATDRPp9xg34YSnZrAxx1stqrU5utXz9sLu6VH8K Vn2gaV2uWWtNsGfJb2+7/Yghuhz4Kltl+iRv7Fpmk+CM8vetq/0KD/UjlmGcA8fe B3C2Iu1m4gxzgeT3yIUqrK8CXr2k+MsN2JjAJMA==
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=fHVF2A wzv4lzi2inUfDmbs5dfh4P6E+1ORFt8vuKpjg=; b=YHElL7j81eM75CCpqpwqLz 56w5uoeEviwVvn0WlrmRvOXQWVxhJj+rLu+SZblHGMVInyXQZ8w7hAEql+MDCfBv M/MGA0CnLUCTYallhQcccpXWZ+PMw7MZ7dS3tJBZ75D4DvCaNemayfpJ77EN9d0T Ps1jOJMEDi8BEQQ0bGL261h4riJju5JyGgEQ41n8p51Oc/z0ESmugDZ6XPOXawzf kUwhK7lKK2TZ0L6k0kpC55GhsMqCtrJlLJYfzCRD8+lAhge9ZUX3yB/MzAwJrVSi m6feoUVb/4yFQ8vbMnfsfeNbx7CIravo/s4ctLq1OJymukLr62BO19Sk23WOKlCA ==
X-ME-Sender: <xms:LtmgXroePwkJ-p4eIPeTGx6AJheFQn_SREZaO1ST4X8HZ50QGGIk3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhith hhuhgsrddrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:LtmgXtF-yYHVkKffivtKKuWzRvlOKB1nsZZ2KR-QvTw_WceAwRsBIA> <xmx:LtmgXlsZav7f07LFS7RUI3fhqIE4gm6K2cpLI2H2WyuYRixB8X3G4A> <xmx:LtmgXqag3yBhtbT7xm1ubXI2qHP-BIotLv0ss5YbMBIoYqEBEDi3jw> <xmx:LtmgXrD2q9DfENKnjb_VQFCz_ZumRj5qPvnF2HWWnl6bzmX_fPm3Mg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68F72180091; Wed, 22 Apr 2020 19:54:22 -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: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com>
In-Reply-To: <AM6PR08MB3318717D21E69A2373AC1ACE9BD20@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>
Date: Thu, 23 Apr 2020 09:53:59 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DW7zbCrrssx5mu5g72nulV60_N0>
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: Wed, 22 Apr 2020 23:54:27 -0000
I prefer Ekr's solution, but I would go with that being a recommendation (SHOULD) as opposed to a requirement (MUST). I was initially inclined toward doing nothing at all, but there is an attack of sorts that is worth avoiding here. Say that a connection spans two network paths. CID A is used on path A; CID B is used on path B. Let's assume that you need a connection ID to route (otherwise, why bother), but that the first record in each datagram is all that is needed for that purpose. The linkabliity confirmation attack allows an attacker that hypothesizes a correlation between CID A and CID Bto confirm that hypothesis. It relies on side channel leakage from endpoints, but as this only involves measuring application reactions, I'm going to assume that it is feasible to extract some signal. If an endpoint sends a datagram on path A that contains two records where the second record omits the connection ID, then an attacker can strip that second record out and copy it into a datagram sent on path B. With the current design, the receiver accepts that packet and maybe leaks some signal to the attacker that CID A and CID B really are the same connection. With Hanno's proposed fix, the receiver of that record will guess incorrectly that the datagram is bad and drop it, providing no signal about the relationship between the two CIDs. 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. So I'm inclined toward cautioning against omitting the connection ID when one is used. DTLS 1.3 already has fairly lightweight requirements around how linkability is avoided. Activity on new paths does not strictly require the use of a different CID, it's just a recommendation. Allowing endpoints to omit a CID is consistent with that, even if we don't recommend that. However, we do need to be careful to explain this risk so that people are aware of the consequences of omission. I would also point out that we attempt to avoid creating correlators so that attackers can't create hypotheses about linkability. Allowing confirmation of a hypothesis is not that bad when the existence of the hypothesis is itself what we are trying to avoid. Given the relative cost of performing this attack to other means of confirming the hypothesis - dropping packets and observing the response would be much easier in many cases - I don't think that this warrants a strong response. Cheers, Martin On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > Hi Ekr, > > I still don't yet understand which concrete problems you see with > the proposed solution. In particular, as mentioned in the last mail, I > don't think there > is a contradiction with any design choice for TLS 1.3 - in contrast, > decoupling > record header compression from record protection aligns with how cTLS > proposes to compress TLS 1.3 without affecting any cryptographic > computations > and hence hopefully easing carrying over the security analysis of TLS > 1.3. This decoupling > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > in the case of CIDs, > it has already led to one missing cryptographic binding. > > Anyway, let's wait for more opinions. > > Best, > Hanno > > *From:* Eric Rescorla <ekr@rtfm.com> > *Sent:* Wednesday, April 22, 2020 3:47 PM > *To:* Hanno Becker <Hanno.Becker@arm.com> > *Cc:* tls@ietf.org <tls@ietf.org> > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker <Hanno.Becker@arm.com> wrote: > > > >>> Considering the effort spent on shaving off bytes in the DTLS header, > >>> I think re-introducing the explicit CID should be avoided. It seems > >>> perfectly acceptable to me to have implicit header data which is > >>> protected via AAD. > >> > >> This is only relevant if there is a common useful case in which you would need to put multiple > >> DTLS records in the same datagram. Are you aware of such a case? > > > > I can see the following uses: > > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestConnectionID with Ack;;NewConnectionId > > 2) Sending multiple (short) app records if the application protocol doesn't provide its own framing. > > Neither of these seem particularly compelling to me. The first happens > very infrequently, and I'm not really aware of a lot of cases of the > second. > > > > > >>> > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > >>> > >>> This seems to be a mixture of logical and on-the-wire representation, which > >>> moreover duplicates the CID in case it is explicitly present in the header. > >> > >> Yes, so? > > > > Isn't this less efficient > > Trivially. > > > > and undoes the arguable benefit of the current solution that there's > > no need to piece together an AAD buffer manually, because now you'd have to? > > I don't recall making that argument. > > -Ekr > > > > > Best, > > Hanno > > > > > >> Looking forward to hearing other WG member's views, > >> Hanno > >> *From:* Eric Rescorla <ekr@rtfm.com> > >> *Sent:* Wednesday, April 22, 2020 2:23 AM > >> *To:* Hanno Becker <Hanno.Becker@arm.com> > >> *Cc:* tls@ietf.org <tls@ietf.org> > >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > >> I think there are two potential resolutions to your CID issue: > >> > >> 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > >> 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144 <https://github..com/tlswg/dtls13-spec/issues/144> > >> > >> Would like to hear what others in the WG think. > >> > >> -Ekr > >> > >> > >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote: > >>> > >>> > >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com> wrote: > >>>> Hi all, > >>>> > >>>> To my understanding, DTLS 1.3 defines AEAD additional data for record protection > >>>> as the record header as seen on the wire. Quoting Draft 37, Section 4: > >>>> > >>>> ``` > >>>> The entire header value shown in Figure 4 (but prior to record number > >>>> encryption) is used as as the additional data value for the AEAD > >>>> function. For instance, if the minimal variant is used, the AAD is 2 > >>>> octets long.. Note that this design is different from the additional > >>>> data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > >>>> ``` > >>>> > >>>> I would like to suggest that DTLS 1.3 uses a structured representation > >>>> of the record header instead, as do all other versions of [D]TLS as > >>>> far as I understand. > >>> > >>> I am not in favor of this change as proposed. I think it is better to protect the data that is actually on the wire than to allow for changes in the on-the-wire representation that are not reflected in the integrity check. > >>> > >>> > >>>> The reasons for this are as follows, in decreasing order of > >>>> my perception of importance: > >>>> > >>>> - Omission of Connection ID > >>>> > >>>> Regarding the presence of Connection IDs in multiple records within > >>>> a single datagram, Draft 37 says: > >>>> > >>>> ``` > >>>> Implementations which send multiple records in the same datagram > >>>> SHOULD omit the connection id from all but the first record; > >>>> receiving implementations MUST assume that any subsequent records > >>>> without connection IDs belong to the same assocatiation. > >>>> ``` > >>>> > >>>> This means that the Connection ID for non-initial records in a > >>>> datagram containing multiple records is _not_ part of the AEAD > >>>> additional data for those records, which seems wrong. Concretely, > >>>> one could inject such non-initial records into other datagrams > >>>> using different CIDs, and the record protection wouldn't notice it. > >>> > >>> This seems like a reasonable point, though it's not clear to me that there is an actual problem here. I'd be in favor of explicitly including the CID in the AD as well as the header. > >>>> > >>>> > >>>> One might argue that CID shouldn't be part of the AEAD in the first > >>>> place, but in any case, I believe the treatment should be uniform > >>>> and not distinguish between initial and non-initial records in > >>>> a datagram. > >>> > >>> We're not distinguishing it. The AD is protecting the record on the wire. > >>> > >>> > >>>> - Modularity > >>>> > >>>> Decoupling the wire-presentation of the record header from > >>>> record protection allows to implement record protection and > >>>> the choice of record header independently: One piece of > >>>> the implementation can take care of record protection - > >>>> using the structured presentation of the record header - while > >>>> another takes care of the wire-encoding. It is even possible > >>>> to change the record header format in transit. > >>> > >>> This seems like a defect, not a feature. > >>> > >>> > >>>> - Simplicity > >>>> > >>>> At first it seems that using the record header as an > >>>> unstructured binary blob for AEAD makes things simpler, > >>>> but I don't think this is the case: Prior to record > >>>> decryption, the record sequence number needs to be > >>>> decrypted, and for that purpose, the record header already > >>>> has to be parsed. Hence, at the time of record decryption, > >>>> the record header is already be present a modified, structured > >>>> form, and retaining the corresponding modified binary form > >>>> appears to create additional complexity which would be > >>>> avoided if record protection would use the structured > >>>> header presentation. > >>> > >>> I've implemented this for QUIC (I can't remember who at Mozilla did it for DTLS) and it's not particularly difficult. > >>> > >>> > >>>> - Uniformity with other [D]TLS versions > >>> > >>> I don't find this argument at all persuasive. To the contrary: we should break with DTLS 1.2 in any case where it's an improvement and not too onerous. > >>> > >>> -Ekr > >>> > >>>> > >>>> > >>>> > >>>> Let me know what you think, > >>>> > >>>> Best, > >>>> Hanno > >>>> > >>>> 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 > >> 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. > > 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. > 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 >
- [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