Re: [TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data
Achim Kraus <achimkraus@gmx.net> Fri, 24 April 2020 13:47 UTC
Return-Path: <achimkraus@gmx.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 78FFB3A00C9 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 06:47:23 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 x72plOAvXGY5 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2020 06:47:21 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4E2E23A00D4 for <tls@ietf.org>; Fri, 24 Apr 2020 06:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587736032; bh=qcZU/UA9aWzmAoLbxpJG5uUAKN2Qfosyxh1P+ltyIzc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=cx+xVhp1Au0Tmk14IAyY9RYFItqdxyBmZH4EUwxApaOX2C//eTD2iE0aNuv+siCXk b1zztQvwSirh8HV5SrnftiWZuxcAuFev1aAzmHqMTYyJiojCHT6cAu7SKBg0Y6tFQQ Cg/F3g5Ll+gs1lLEBX9HMMBx9h0UFz02LgaIRhv0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.10.206.187]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1ML9uK-1jixYb419m-00IBke; Fri, 24 Apr 2020 15:47:12 +0200
To: Martin Thomson <mt@lowentropy.net>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
References: <AM0PR08MB3716173B73ABE156C5E22B08FAD00@AM0PR08MB3716.eurprd08.prod.outlook.com> <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <a13e27d6-ade3-f760-6d36-d58347f967de@gmx.net>
Date: Fri, 24 Apr 2020 15:47:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:dUEAb4C19fngelYJuiDW35lhRUajCAT1KOJRGvZoLx7sSbnIaVM HUKy37EgWhQFCeTrU08z0sinUrIcw/OwUPGC6sTnsAaedBXKE+hxCEH4Zh0qWNNnmaAaAOd t8DkUq+twxOo0ogEIXJfzEphORBTT5eXV/UzPiBdXaMVC41bGdUiHFxzKd5Gw2JxZzse2fw 4aseJR9l3bz5qWMwCSNcA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:FBk8inDdNps=:LQeSXvKpMDDRDWlrLLkuqA BzxoxsLjESVQhblCihcMOcu3RGMVb2tnfKoaFXXWaUiubyRMzXqSYtcg0JliiNSKadpgPxIrC OEUAOcSwCzLeQArrxEmyrMcerhj/hN37WzQyWK5BRSyLaWBamLhQu0so8rW625/zScj74YR1O u4/qVHZyuIsLuWqoNy1YybpYjiPvLsu+slODJvI38j/cfxaLZ1BhtcA41xqrhK4QR5uT7dDjs yOr1kO/tN4FH9+tTg+ALkI743gBe9RruNAIaxQf5Hm7LyyQXHNKeV33SuX00pGuJ6880iVSsl eMqjh60xc9D8f0fOEhozAk14qD4EIdP9+I5aNEltkCVY5L/mBDxIL7Y/ll5dU7qqjS/L1lXSD +EuaXR4uZAkTiSTK2Upc9ZPIoVJME1BwmRkCDsiZ49AHv9jR80y/AayUS0M1+cWj/7I2tI7/z 5ytSgu70SdfPyu3RL0SGYwGS0HmgKhbs/Prc0oO/tXq0VRviYEStjH0ssqQ3RcTmT990NJ9BL w9UV7+TDNtQvLl0IGmIQckbFhewISESW2g8sk7lQ2Cp+CC58v+hnGFUapa6IPopx5FYZk/Mrn bv6elUycHVsKsTEz3XAzrGaYcmynM0d8ifBQlQAAUcNiN8XVORgY4+LcIfZgkY8azQS1O6/At dnDo2w8DIbxtnP0DV3p8emE6CzQ9zgSRUe1o2QB31ZyQ4UQOd/GX2MBZcAqR0ERdSPr9P8xRU SxmoGahuG5FZlKnLH3YhOt/1cMKPuO++Tk3b1t/E7VLGbHHTWsbx/A96dQ49WbUXEaNkk8GS5 OHAVjBiikffM9YbotFS1LhnTu21tbpc+KpK9I3XNQTMVbP7qLm49YmMVys7x7feM7GBDMlnbe Q8Ddr/9HQHR0/ZaNmsWr0ozKh55W4LhwyiZ3ZCFVIYTx7cv4nWgd8jIlLCMWpIn4pY9TrC2/V MASelZmlcEPfrB27OjrLim8F3FssSvbTIKqtZuLzRvbTTuNwPt7BDcS1Whhaszn5UdCwksf4v HhhAYmq9m4HKxSjqfN34nnYAezrIkUfJwiG6bzYGH8wNekQN/dy2mI55wPe4MtH6WiGqUzYua HkUFfq620/rDyWc/whgwMIW5RRyq+aeSnOPabKfjKoZ7WA83BOR7DeEMsbbJ8oGTNIAneXepH UVKGtdcpsI90Dq8KtTAeYE6cS2aWSmFNHYx3PFKcm+gzP5ihKVM7uGG4o0Xcxsq/XAXTb7gQ7 3PdtrJXl6XRbaVdf0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wMtsnd6M61viIDxugZlMEI2n0Go>
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 13:47:24 -0000
Hi Martin, > So this depends on either concurrent use of the two CIDs, with that and the "routing based on cid", I would raise the question, if the usage of the cid turns into a swiss-army-knife? Therefore it may get larger, and so it gets attractive, to use it only on the first record, but leave it out on follow up records. So, is that the idea? Use a large CID to include more information? > or moving a record from before a change in CID to after a change. I'm still not common to DTLS 1.3. With DTLS 1.2 a resumption- or full-handshake will result in a new context. So for me moving the record will fail. best regards Achim Am 24.04.20 um 12:09 schrieb Martin Thomson: > 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). > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Attack description ... was RE: DTLS 1.3 AEA… Hannes Tschofenig
- Re: [TLS] Attack description ... was RE: DTLS 1.3… Martin Thomson
- Re: [TLS] Attack description ... was RE: DTLS 1.3… Achim Kraus