Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

Achim Kraus <achimkraus@gmx.net> Fri, 18 September 2020 08:00 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 8076B3A0EFF; Fri, 18 Sep 2020 01:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SKC8UqCELhVF; Fri, 18 Sep 2020 01:00:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADAB3A080C; Fri, 18 Sep 2020 01:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600415996; bh=cUKZFRO4fOsAv/0zRZ5goaW+B9q+x954Az9SXr5czD8=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=cYRP5nRrB4d6WlFUUbBGq6VHUSgcKtIcls+zUBJkysTCY14QYrOdwsH+YyU9RqlEw lC4DMbr023dM3w8tB/FdjW7F5DPb3+kfzOGxDAmjfyhAFvx5JfblWiLjTHDEqIfKJy 1t/oyTu3Rcimzon6fUic7DumYAbKbxwyipJgYyxM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.2.213.78]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MPokN-1k6l5j2TvX-00MvOs; Fri, 18 Sep 2020 09:59:56 +0200
From: Achim Kraus <achimkraus@gmx.net>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, tls@ietf.org
References: <20200903230228.GQ16914@kduck.mit.edu> <0723ab09-7c47-400b-6e93-1b0ae34242fd@gmx.net> <20200915192644.GV89563@kduck.mit.edu> <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
Message-ID: <06e2f9db-7c7c-f594-b236-e307d52bc07b@gmx.net>
Date: Fri, 18 Sep 2020 09:59:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:93Uxlw7kl0YF3M3vrFlJ0LMxzd8Un7gnnxGFnAOwdF+wZYUi7km 5e6rGpNBAH/IYVi3t/6Je8OQ0NRQoFuuc0IMWOuOgOWb9GLMa14prHYwrGVK7JRlGyTDQNN K2sT8u7eTFzajxNeKQ5JaNtQeWW0Z5uvh+VyKaCZ16izBbYl1b1XBkx8BqL6PuBFBcCXv59 Y36Z0uQyikQzycLU4qshQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Q2rqA5CE8Ac=:m4BKzJm6pTPzTstfo+XY+l zyokiWLBPq2yq7YhKKgbnppSrQxZcBMTq+1hE0Q3x9sdDbboSEHy466D03TPogUnVzUVRxJ11 /u5RwcrK/RCJ+ELPaB3ORDTCVq4686T/dMx24zOHBCfu4jCslFxDWpElQuZ0O6ohvxBb8v6va T+iAx6aBL9PybmHhICNiHU0sV8Kw2lcVpuW+//xVs4OXYKXYP9w+hoR5WGw5McW1s+Jnr+Jrg 5cXxFcptYrSD+IPBgxwGwHcBw2BvhnkkA4cvCI0vcUg9HRRDoER+5nB0P0joQaL0nCWCjqbR9 Z6pN4Db1Dv8gx09E7cehtSEN9M/Ns4WoeVoaAJLmPIEKxUwHVN2Em+6m14xcehL/a6ChfpeXe VvBoX7TSZKj18S2qOrAKRgpdeNiGP1tq/Xe9KNxuUVCC0Y8oB/tufjGOdHizDILlXvBCyG/1D Or/sxNFZc+VON+M/ZAb3z2pgToBrZilmIN79yHRB7MNsZdy3KGdYnp5uD9OwME+hsPEb58Wkc xAymhvKB8i8H6eME3YdRf4Dr9fFPNj3XXj17h/O+5vPj+47IRT5oDOX/nEClr9ZX5r9kKCCGO aXp16ze0Fy4Wlez8oeT/sVHwlebpNeyB1ZcuQI8RX9tbrLL/D9qLf/aJTlV9cH7cKWMC5n6Zs ASsfVsLYYnwFvkS+3yPBHhLgzRkDP/h05MlljexvNP2kdPIlJ0Os9ZySFT0IjZui0aBq0wYQR /Qpoy8ErjsxWyKzrYulYroKmr0Nh2tg6z2f/R5j7AmoqzhUGhdyWzviBMpLaqkHLl/UIcq9l+ sjxxefyUnVF7iMBe3c9kOa12odEgxI5XdyuKofszRKT7h0Q8HoZx+MRCx444MRAkT0N6SNOWe DuIVru8N73VIvoyTsQLa40/5Ytuprv5hIi+eApsITXbam8+BhWVsHSJDF0o2BgT0herHSsceg o9Kl5FWxB/WgvqMdxAhtuQALXcdmx1aNB92X7LA5/lt/mwh1ftVgKOZnZcL54EaLktSVau+Sy 8wIOqnAde0m9mPfvw8ZLiUvA5Iy+Ys0o4XiD2b5+flLISPowcwpp8kS2YIPKDpEeybhiexxRe 07/B6Ojsrb9sc+wJW2hsR8Rq89TolouQ0Nusv0e9pd2GOVhcNbg4yx1xDNY1hFTESfybc6Cqi Ab+rSObElel6u0HcEZow/OSb5htoB9+vbkz/9vt92OBFXCNZ0VsOk73Z47m+0FNm9hyn09Y6u MHth0Gu2h4Z79/+I5tHmwrjNRXRrYJgd3bUt04A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GvSd_e2XdcygGjb_8_bnU-lqD_0>
Subject: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
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, 18 Sep 2020 08:00:07 -0000

Hi Ben,


Am 16.09.20 um 08:31 schrieb Achim Kraus:
> Hi Ben,
>
>>>
>>> If I did't get it, it may be easier to discus this as issue in the
>>> github repo.
>>
>> I think you got it; I am just failing to remember where the "MUST anyway
>> use new handshakes" requirement comes in from.  And I guess that also
>> raises the question of what the expected behavior is when a server
>> expects
>> CID-ful traffic on a given 5-tuple and receives an (unencrypted)
>> ClientHello on that 5-tuple.
>>
>
> "when a server expects CID-ful traffic on a given 5-tuple"
>
> I'm not sure, why that should happen. If CID is used, the server should
> not expect a given 5-tuple (at least not longer than a few seconds).
> If a new CLIENT_HELLO arrives, it's first challenge it with a
> HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
> of a previous CID message" is hit, then just mark/remove the 5-tuple of
> that CID association. That mainly means, you will not be able to reach
> the CID peer with that 5-tuple. That's anyway extremely common to lose
> the ip-route to such CID peers, otherwise CID would not be required.
>

Let me add:

- If the scenario uses "dynamic 5-tuples, with CID or without" and
"static 5-tuples without CID",
- then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
pool) and CID (described in
https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
communication to such a static-5-tuple without CID.

Even then, that "static-5-tuple" peers must be anyway aware, that
sometimes new handshakes are required. So that scenario may also depend
more on the volume of such attacks, than just on the pure possibility.
In my experience, such "static-5-tuples" are rare and I would guess,
they will benefit from different handling also for other reasons.
Therefore I would just spend them an separate endpoint to separate their
traffic.

best regards
Achim