Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Martin Thomson <mt@lowentropy.net> Wed, 05 May 2021 06:51 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 0CF6C3A1209 for <tls@ietfa.amsl.com>; Tue, 4 May 2021 23:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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_DNSWL_LOW=-0.7, 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=AV0s5vhk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i73tx1df
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 kIKxaOcWu3cB for <tls@ietfa.amsl.com>; Tue, 4 May 2021 23:51:34 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051F13A1207 for <tls@ietf.org>; Tue, 4 May 2021 23:51:33 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A00CA120B; Wed, 5 May 2021 02:51:30 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 05 May 2021 02:51: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=1NbHjy4G9dXZaxO409nRcl3uv8xb MZtoMDjAWOxNFs4=; b=AV0s5vhkAKy/4NlPjkszt0Rbuxx8hNM6/dQ9wn7e+DZM u8eAwzNjZxQ/JmgW53J49AkfiAJDOCVpU/g+eNCmwWPwAjLfJELKg65Vw+AU4PLD 8L+JW68CAtWVVFWWuKGmngQrwW8PG0bd2ECTkgNxvUZ5LBx7GJfOAw6wpxN7Qntd BqzHRLmABRmJf5NXomUNY0mw5a9UWqIMvBHZRylbEDWiIbzIZOut1Nv99Bw5NRw8 fBUGBhRg+KJrS2TjhAugQAOsdOkaGmUeX1un4MZO5zCukvvO8B2UAD5CoVKVxML9 6lh35lvov7OrOkd18eLKGsrBCrBN2gjpm1J9GDGy2g==
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=1NbHjy 4G9dXZaxO409nRcl3uv8xbMZtoMDjAWOxNFs4=; b=i73tx1dfRiO2iQnBsIfZ25 Igs2vHroBLXYv6pmfAZ1GyZq4K/xo0WLMD2BhLBsnLp94lzgzGSTU1AglYjWjE7U wjnc8G/mLjZQHfJcj0qN9bps7Yw/DX+oVPOluTEPXawEtLGKap+xRB1YZmUNTR28 UVe3CD9tXd8kIsnb6YN6ULCgkAPdAVRh+gRHN0nRVlPVIiDQB7Blb37AMThVfnSe 5quC/dDzL9W61rUWMPGK5tXsRbvHn59U5jlfTGhUhndLBsL5MRKV8b2VDMPIJn3F VLPTw7L1e33HlNneWClyTu2Mw7dS1kaHgLlpF11lerZKrYJSDfDb3WTdW2Z1JVyA ==
X-ME-Sender: <xms:cUCSYJIMmO_0h7_yigiK0W0ziAcyEI0x8B21WnxHYwFMEazUYYZlFg> <xme:cUCSYFKilhmQJ0EXSFoEjdOqxW4Kt4mazQjqMvPZDu-08gvUQaiLEVkednxYS6FX2 XN7D80N9e0FNNibktk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeehfeetudduudehtdekhfdvhfetleffudejgeejffehffevkedu iefgueevkeefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:cUCSYBsh8fFja29r8aduYDHsGQLcgnY8K4BDKYMrXpEIMGjk_fpTyg> <xmx:cUCSYKbGMNvdk81i8Bdb2d44qfkqCiZ6PLolfBAGbntrIHhQUaYR-Q> <xmx:cUCSYAZ9iXd8L6Zz6mz3fGe6wniAwvG-DDa7SdJhxVzFQhvZhCILMQ> <xmx:ckCSYG0N2q5QNn7-rWEEGURfYEjShjMgN26KzSc9u-vrvXEAyuYPaQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id F06074E0095; Wed, 5 May 2021 02:51:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-442-g5daca166b9-fm-20210428.001-g5daca166
Mime-Version: 1.0
Message-Id: <b2aa0fb2-c17b-4868-8b5a-252562c407cf@www.fastmail.com>
In-Reply-To: <f67218d9-5cd0-397e-a1f7-23a8411d9411@gmx.net>
References: <161894801377.8373.6532898944771346676@ietfa.amsl.com> <VI1PR08MB2639A557022756B119EAB4EAFA5A9@VI1PR08MB2639.eurprd08.prod.outlook.com> <CAM4esxQaGhv8p3U7pa3JTyLFOvicZ4fM14p8-J5zpyOdBWNw9Q@mail.gmail.com> <72c410c0-f164-4428-9dda-ca62a9c0b419@www.fastmail.com> <f67218d9-5cd0-397e-a1f7-23a8411d9411@gmx.net>
Date: Wed, 05 May 2021 16:51:01 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "Achim Kraus" <achimkraus@gmx.net>
Cc: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ktkllvmQ0E6OJG8vRaw45opmvRI>
Subject: Re: [TLS] =?utf-8?q?Martin_Duke=27s_No_Objection_on_draft-ietf-tls-d?= =?utf-8?q?tls-connection-id-11=3A_=28with_COMMENT=29?=
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, 05 May 2021 06:51:39 -0000


On Wed, May 5, 2021, at 15:51, Achim Kraus wrote:
> For me, this requires, that cid is used in both directions. If not, the
> "elicits" doesn't work, or? If both parties are using CID in order to
> signal, that the addresses are changing, my feeling is, this scenario is
> not that common. (Even more, it will have anyway troubles, with or
> without CID.)

Nothing here depends on using a CID, except perhaps to the extent that the endpoint that observes the "migration" needs to be able to match incoming records with connection state.  If they need a CID for that, then this needs a CID.  

The attacker can ensure that the other endpoint receives all records from the same address, so whether it uses a CID doesn't matter.

> I see, that in cases, where both sides uses cid and dynamic addresse,
> there maybe that manipulation. But, I can't see the attack. Maybe I
> oversee something. If the "on path attacker" is installed and that
> attacker changes the source of the traffic again in order to attack an
> other victim peer, the probe will again protect the victim's new source
> from being DDoS'ed.
> So, please be more explizit, what the resulting attack would look like?

0. Connection is setup between a victim and its peer on a certain network path.
1. Attacker causes victim to believe it has received (valid) packet from a new address.
2. Victim probes toward that address.
3. Attacker captures the probe and forwards it to the victim's peer, spoofing the source address so that it follows the original path (from Step 0).
4. Attacker captures the response to the probe and forwards it to the victim, spoofing the source address to match the address the attacker chose in Step 1.
5. Victim believes that the connection has migrated and stops sending on the old path.

If the new address is attacker controlled, the attacker is now on-path.  The attacker can stop forwarding and deny service at its discretion.