Re: [TLS] Connection ID Draft

Martin Thomson <martin.thomson@gmail.com> Fri, 13 October 2017 00:07 UTC

Return-Path: <martin.thomson@gmail.com>
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 EA872132403 for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 17:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com
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 cpFKZwztGXWr for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 17:07:08 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 5DA0F13219E for <tls@ietf.org>; Thu, 12 Oct 2017 17:07:08 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id v9so11078537oif.13 for <tls@ietf.org>; Thu, 12 Oct 2017 17:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xixHViOHUmN9e0efrS+5hwxcgT/NGKHbW96/PEXDW20=; b=XpLkeNE3nZeWH4ayIG9oD609zHcZiPTuzJNOEvXwLMUkH0KbXn19yhgEqc7+gcurl4 EJI7GZqgp7xH73O76LgctMT5KHTxa50sp7kBpctNjHT57zlnG8KeYhBS29jfPR7qLS2o iglw5R+gv297Ft/3HM/Wc/ZifHf7nFynHAyqn8ePX+lXje3bcHvS0VMoa07lu0hoMAp+ bgdqNPzLOSuUhRqd9bbL6CRZp8hq6ILXiDWg0qkRSVf9bW/tULTdq3Ozh7JAsxOwib09 Fqx6cVJri8OfVluJqP7Zr8z4Q4Ik6drY5mbEhzEp1FQLpB4Geg+/qBEZOFMgDBQtYyTZ Lf5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xixHViOHUmN9e0efrS+5hwxcgT/NGKHbW96/PEXDW20=; b=XIDkX+rVrceRcczK+JWVa37aSOWTsstomxzewR1myHcaj3TrPsR7zJ85YPaFWDgpQY pRDd+xtRAqTylyjrTx6EGtSGr5tvKpdt4fsBlwHjA5l6WsC/grl+mAy0WIWTL0U3+i68 YnBVtrbRN2rbuN2BoKYk/K4Gnyx0uCzNyPt2uGQkntE9a1sOSagEJU9wzbEiaIID+ezZ dCHByR/X9NTuKsYljtfeLVj5BGNbCIpl2+Zs7xPjkw/vws0acyy+EWTrZeCEfS/rafjp 5CfYQo1LLkxuaxyAzOCcq8h/owl4nWXt282irZqGn6hkMWgGtPflD+pEgnJjGaQKXW6/ EGqQ==
X-Gm-Message-State: AMCzsaVtFo7S7NUEC2TIgO3wXZxAMfo4a25veKsnmEbDWGCxhtkLI0Vx l1as7OxlsPCOFG/oDP4Uan5Yd1pyw1Tuu9z5kao=
X-Google-Smtp-Source: ABhQp+QyQPh+g3AkwkhpHlHM6gYS4NNpNsIewoCgInBH7EsVo9KKxCIYQ2Ar1YH++hxtvxbWyQxCWmLhbE8RWLMgTQQ=
X-Received: by 10.157.52.53 with SMTP id v50mr2898371otb.35.1507853227667; Thu, 12 Oct 2017 17:07:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.72.178 with HTTP; Thu, 12 Oct 2017 17:07:07 -0700 (PDT)
In-Reply-To: <CABcZeBPP0AK5yR-sZ6mcF1epOvjCh2jfOd8TfrgCgeExk+eduA@mail.gmail.com>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <CABkgnnXsBZz5PAvQOfYBgB6HHzH0RuQgO8DuAeZ9X2+R02QP_A@mail.gmail.com> <CABcZeBPP0AK5yR-sZ6mcF1epOvjCh2jfOd8TfrgCgeExk+eduA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 13 Oct 2017 11:07:07 +1100
Message-ID: <CABkgnnVHmtU2Rw4_XxtdxVpGaWbrXR63Xa1pm+0rsgBhH=HjxA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1xjNYgkd4AmFETQM-Y4xdlMvQSU>
Subject: Re: [TLS] Connection ID Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Oct 2017 00:07:10 -0000

On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> The design for new connection IDs is clearly to handle the linkability
>> issue, but the draft doesn't propose a solution for linking based on
>> the monotonic increase of sequence numbers, or acknowledge the
>> problem.
>
> Sorry, that's a good point that somehow didn't make it from my head into the
> draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you
> don't
> need contiguous ranges except for anti-replay, so the sender can just jump
> forward and then the receiver can keep a per-connid table. I've filed
> https://github.com/ekr/dtls-conn-id/issues/2 to address this.

That only true if we don't truncate the sequence number.

>> We had comments about the length of the connection ID and the value
>> being used as a covert channel.  That issue should at least be
>> addressed in the security considerations.
>
>
> I filed:
> https://github.com/ekr/dtls-conn-id/issues/3
>
> That said, I'm not sure that any plausible length CID can avoid this.

I agree.  Anything too short is going to be useless for the use cases
we care about, but anything long enough to be useful is ripe for
abuse.  We can acknowledge the problem though; and maybe suggest that
endpoints that care about this could at least disable the extension.