Re: [TLS] Connection ID Draft

Matt Caswell <matt@openssl.org> Fri, 03 November 2017 09:15 UTC

Return-Path: <matt@openssl.org>
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 876A813FD20 for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 02:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 pjPCrnxPd4yX for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 02:15:17 -0700 (PDT)
Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD30913FA91 for <tls@ietf.org>; Fri, 3 Nov 2017 02:15:16 -0700 (PDT)
Received: from [10.35.10.6] (unknown [104.238.169.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 6420CE6665; Fri, 3 Nov 2017 09:15:13 +0000 (UTC)
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <CABkgnnXT7nv9aNQh12deeitF1CurENpxgUicn9GHjMbojcEvJg@mail.gmail.com> <D0524862-083C-4576-98B8-6D8A4825D458@nokia.com> <CABkgnnW4d=H5RZ0E+Hwo4jQptDpshVVuFtD-xQudJzxLXyReAQ@mail.gmail.com> <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> <CABkgnnUSBQ3+YG4BkGPAqmMt3YLiDVcivp_vYcdeOHrsD0ca4A@mail.gmail.com>
From: Matt Caswell <matt@openssl.org>
Message-ID: <f128b6ea-4d2f-5aa3-9289-2439e71ee21a@openssl.org>
Date: Fri, 03 Nov 2017 09:15:12 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnUSBQ3+YG4BkGPAqmMt3YLiDVcivp_vYcdeOHrsD0ca4A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XN3mp5ubifftFy1qnGuaU41Yqe4>
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, 03 Nov 2017 09:15:20 -0000


On 02/11/17 23:34, Martin Thomson wrote:
> On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell <matt@openssl.org> wrote:
>> Just skimming this old thread...doesn't this fail in the case where the
>> five tuple has been reused? In that case five_tuples.lookup will return
>> an old stale connection which the server thinks is still valid so we
>> never get to lookup the connection id. With an explicit marking we would
>> not fail in this scenario.
> 
> I'm assuming that once a connection is closed (or moved), the entry is
> removed.  There's some fudging needed there for migrations (it might
> be in two places at once for a while), but I don't see a significant
> problem.  (Note that I didn't include the update parts of this code -
> when a packet decrypts successfully, you need to update the
> five_tuples list.)
>

Imagine the scenario where you have a large number of clients sitting
behind a NAT middlebox talking to a server. If the NAT crashes/reboots
then all of the associations are lost and the server will not know to
remove any of them from its table. It then seems highly likely that a
tuple will get reused with stale connections in the server's table.

It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.

Matt