Re: [TLS] Connection ID Draft

Eric Rescorla <ekr@rtfm.com> Thu, 12 October 2017 23:50 UTC

Return-Path: <ekr@rtfm.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 8730D1326DF for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 16:50:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 AB8fddi0TQwO for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 16:50:02 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 3FCFB13219E for <tls@ietf.org>; Thu, 12 Oct 2017 16:50:02 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id q4so16704360qtq.8 for <tls@ietf.org>; Thu, 12 Oct 2017 16:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2ZBhGLZk6bMK6mD2nLjQ6W7GdsqicTfV3HSNVFAvO98=; b=VG4DXH9OFUfggtay0P3dzvPERywmt73iGxugVi7t64n3cTHG+kgfvVHq0/BqxzxYHY 9NhwzNWf1UkCpNh0BRExtbtqjUHX6TgywT9PNOy/jc9KZvmWnpXUKdnD9s7BIzsHpRmH R4O6Qq45MMkN0l8sWNRwStjoV3FUVxESxFOTCWzjINpzePd3uRrbtAn8tycjH7XFIJuA xBDr2V1V1OlkEYyj7nU48AUoPIMBu7+8cBgyy7S8C8DagcVIcO0XY8XApbRcVufQww7Q HrYLnmahwWJGzKhDjZaYGblpzdON4NcCvSWlk16/hp6tCoxtv8iOYzP0jVPaXo4D4ym0 YXeQ==
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=2ZBhGLZk6bMK6mD2nLjQ6W7GdsqicTfV3HSNVFAvO98=; b=OCaJxRKHAZS5ocKA0pFCJUjcezT+ryuXyAIUmxPC4Sybv7NlwYvXJLxtHI2fbWp3ti 4n5y6jXGYagpw1ncshicr8eSyqtVnvxaA1QwdU6DatVvMMiv/GbrJ4Ihd1NKtkNBiJhj MfQm7qk6dae3iMIu0oj2vHITl8uNRd1/pNPsEzUmdQUHEiw6M8SrypNjHc3FsCMa6ONS q90EwHW9e4DR4Eq67tfDu0Bxn3te47zyYTS9cG87dN1SIN7ZzG2VCwHitMRKylbdS4Bo JIt1rjPl3Cte36/8HjuqXknavZ8bhIMFrEMjWAmA+XzKrP+K0/YHIJfwoP8B6M22sQrG JhuQ==
X-Gm-Message-State: AMCzsaV4GOOQyQra7IcccrRORsTIri3daoEfEaPDos6O9BxEoH+tl58j fr2MNK7zT2/p8uxd5O4OyGxprSk4HdPIIA8FmgUZ2iPxHQs=
X-Google-Smtp-Source: AOwi7QDPiYln+XaJfDQZ6XMvmc99uvp3wsRynKNDqHw+eQKbZshW+iXMgeYVzy1dbSY7KXBGjyUjv4o5mDbU+evL0ko=
X-Received: by 10.37.1.7 with SMTP id 7mr2828451ybb.419.1507852201302; Thu, 12 Oct 2017 16:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Thu, 12 Oct 2017 16:49:20 -0700 (PDT)
In-Reply-To: <CABkgnnXsBZz5PAvQOfYBgB6HHzH0RuQgO8DuAeZ9X2+R02QP_A@mail.gmail.com>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <CABkgnnXsBZz5PAvQOfYBgB6HHzH0RuQgO8DuAeZ9X2+R02QP_A@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 12 Oct 2017 16:49:20 -0700
Message-ID: <CABcZeBPP0AK5yR-sZ6mcF1epOvjCh2jfOd8TfrgCgeExk+eduA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cfcacd55433055b623281"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fWJEIWvxBpfw41rJq2e7-jL7VVk>
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: Thu, 12 Oct 2017 23:50:04 -0000

On Thu, Oct 12, 2017 at 4:33 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
>
> The example shows the connection ID only being used after the
> handshake completes (that is, on epoch=3), but handshake records
> (epoch=2) use the same record format and we already know the
> preference of the peer when sending them.  I can see why you opted for
> this design (there is no way for the server to signal that it intends
> to use the connection ID before it starts to send it), but that could
> be addressed by moving the extension to the ServerHello.  The value is
> sent on every subsequent record, so there is no real gain in having
> the extension in EncryptedExtensions.  There is value in having record
> construction be consistent.
>

Oops. It *is* in the ServerHello. This is an inconsistency because an early
draft
had it in EncryptedExtensions and I just didn't update the example right.

"enables encryption early in the handshake phase the connection ID will
be enabled earlier. For this reason, the connection ID needs to go in
the DTLS 1.3 ServerHello.
"

It's fixed in the draft.


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.

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.

-Ekr


>
>
> On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> > Hi folks,
> >
> > I have just posted a first cut at a connection ID draft.
> > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> >
> > Comments welcome.
> >
> > -Ekr
> >
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>