Re: [TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data

Martin Thomson <mt@lowentropy.net> Fri, 24 April 2020 10:10 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 675863A11D7 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 03:10:11 -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=e5GQjfHP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jFz2z/p3
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 rkn9CMMzkMsU for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 03:10:09 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E5C3A11D5 for <tls@ietf.org>; Fri, 24 Apr 2020 03:10:09 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E10D85C0966; Fri, 24 Apr 2020 06:10:08 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 24 Apr 2020 06:10:08 -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=p9sU1+u7R4pC+O1ELShhtnZ6luzLgWi /2GUx/vGjaMU=; b=e5GQjfHP+32RDVH4w0QlvhU+gbUur7gvB/TnNXz+Oc7C+UF ODCy5AJbXFCfKNRW6BIyQauWrw7dUQ/c5un+59VsGqEA8qnZvT5lI/tu9ebYGaOz M6iDAYIKI+/onkQI6ql/150biDz3VOZLCyMqcK0kYlqTFGD/x3lFihijQYAIyN6d DOw/A2CNOKEMQBrY/46T40fAqOHKa/kS55/U3KU4YhymSromPunvZrTnu3v8xuCZ TH0C/bp+as3EANVFL1xAtgtGDTw0+vtRZrAALY5dzsL+haDf8JKB+doCrC1UYqyJ iVybX+pZPV1f2wKGQSLYgNA6KXCtUYiIuDdQUdg==
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=p9sU1+ u7R4pC+O1ELShhtnZ6luzLgWi/2GUx/vGjaMU=; b=jFz2z/p3S1/+EUhyxf47xs TNSUnl+UTAN5rwhzDMmTWyRvew1Aa4u9cO/eHpZ50vrH+bBEmmgcq94kXK0qGjur WrfkjqtkmcHpCGWGv5ZK8MCAij0jV3jDGVCD3sAADCTMFFUjYkAuFFAsTlOBulhT lxjrD/cX0hcxIFF94wJqH1PSY8gL2N/SG03Q7mN7c49MPK+WFwJyBh0G/tn+qjaV bk2+VcrT3ZC1Z5A2QIHhMds1KrUwTDQnPtt9cQuZHrer5HOjE6SUvA1C+NOnM5Ak E6b+aAP8i9l329gShChr0d01tcR03fvmL3XOlaxrd/qnXQHX56WiVn48sLn/LwwQ ==
X-ME-Sender: <xms:ALuiXj2HReKe_ZL9vBA_-Km55SUIv8KvhpJ68qev0PbDF-DdGxjU-w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedugddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:ALuiXvwbw9yunSVFcgP2GpvN_EXzOqxcKe9DniQ7JF6yUG3k3ndhlg> <xmx:ALuiXuXo4l7oyyat5oKRfWr6jjafqS5wztKqE_K3Xof9IBXtsi3cwQ> <xmx:ALuiXhAJwZaDD4TwV7Bu9wiR_fwPs9ZoqyN_uE68Q2lTJA0JyY5-tw> <xmx:ALuiXm4dEdFXDntb5cssPi5i8vMVPN9FXCkStyxtd_fxJZPQExU3zA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90FBAE0157; Fri, 24 Apr 2020 06:10:08 -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: <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com>
In-Reply-To: <AM0PR08MB3716173B73ABE156C5E22B08FAD00@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <AM0PR08MB3716173B73ABE156C5E22B08FAD00@AM0PR08MB3716.eurprd08.prod.outlook.com>
Date: Fri, 24 Apr 2020 20:09:49 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ApMKz-gpBKbKNi7mOfCq01Qm10Q>
Subject: Re: [TLS] Attack description ... was RE: 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: Fri, 24 Apr 2020 10:10:12 -0000

Hi Hannes,

Let me see if I can clarify then :)

On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote:
> > Say that a connection spans two network paths.  CID A is used on path 
> A; CID B is used on path B.
> I guess you are considering a scenario where a device, of the lifetime 
> of the communication with another peer, changes from CID A to CID B.
> Is this correct?

I don't think that DTLS really says what the CID is for, but this particular attack depends on being able to shift records from a datagram containing a record that has CID A to a datagram containing a record with CID B.  So this depends on either concurrent use of the two CIDs, or moving a record from before a change in CID to after a change.

Imagine that you have record 1 and 2 in the same datagram, with record 1 having CID A and record 2 having no explicit CID (but for the same connection, as required).  Then record 3 is sent with CID B (maybe on a different path).  The attacker can remove record 2 from the first datagram and add it to the second.  If the attacker can determine whether record 2 was consumed, it can confirm that CID A and CID B are for the same connection.

> > 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.
> What do you mean by "route" here? The CID was primarily introduced to 
> allow the receiving party to correctly find the correct security 
> context to verify and decrypt the packet.

by "route" I am trying to be generic.  In QUIC, the CID is used by cooperating middleboxes to select server instances.  But as you say, it is also used to identify which connection (and the right keys) to pick from potentially many choices, without necessarily using addressing information (which might have changed).  To me, that's all just routing, whether between boxes, or threads, or connections.
 
> > 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.
> 
> If you copy the record that does not contain the CID and send it to the 
> peer independently then with the current text in the spec the packet 
> will be dropped.

Probably, yeah.  That's why you need to find a record with the other CID to pair it with.  Besides, the "attack" is trying to link CID A and CID B, and having the record consumed without linking to either doesn't tell the attacker much (except perhaps that the CID wasn't needed for routing purposes).