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

Benjamin Kaduk <kaduk@mit.edu> Thu, 08 October 2020 23:41 UTC

Return-Path: <kaduk@mit.edu>
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 925363A101A; Thu, 8 Oct 2020 16:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Fhbpez7wPuLw; Thu, 8 Oct 2020 16:41:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C73303A1018; Thu, 8 Oct 2020 16:41:16 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 098NfBY0022059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Oct 2020 19:41:13 -0400
Date: Thu, 8 Oct 2020 16:41:10 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Achim Kraus <achimkraus@gmx.net>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, tls@ietf.org
Message-ID: <20201008234110.GG89563@kduck.mit.edu>
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> <06e2f9db-7c7c-f594-b236-e307d52bc07b@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <06e2f9db-7c7c-f594-b236-e307d52bc07b@gmx.net>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pAb-auIN9c6997w8UvbEZl3M_v4>
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: Thu, 08 Oct 2020 23:41:19 -0000

Hi Achim,

Sorry again for the delayed response.  (Inline.)

On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote:
> 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.

Yes, I think this is the disruption I was pondering.

> 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.

It does seem like a pretty rare/difficult attack, unlikely to be worth the
trouble.  But perhaps it is still worht documenting as a property of the
protocol ...

> 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.

... especially when we can give this recommendation as a workaround.
(Actually, is it generally a good idea to try to steer CID-ful and CID-less
traffic to different endpoints?)

Thanks,

Ben