Read-out on offline connection ID discussion

Eric Rescorla <ekr@rtfm.com> Wed, 24 January 2018 22:37 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6988612D779 for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 14:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 QO0x2qpx_obZ for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 14:37:23 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C155512AF84 for <quic@ietf.org>; Wed, 24 Jan 2018 14:37:23 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id u17so2123217ywg.9 for <quic@ietf.org>; Wed, 24 Jan 2018 14:37:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=U6ad7fcyKDDeL6W/W6aha/qlLY6v2Wc21tqouOCVpy0=; b=bjZt1uPfzQ+YLYJIKRW22XeCmEEWJJoSnvW88Eroo1NV+T0rkhSWGqv2h4dc7+bq8z 5XQhJSvYUSP3+gCf1SNGl+wSKuqEb14NdM68CdZLdB6aw2kPCcoyAFrX6Q1tFx2ceX16 TxxCnBegn6hj+QVBpm4P8ueMR4RreIhuhAh7zCokPQGSxSeUlNmkSDLyYYDKUtNEeKIM wqghwcWjWW62boRk1it2Inb8JpVRfC9g9+yU9xYPUFJD35wTal5XFVy+rJEv7vcUHiL4 pw8XkAtkeQTTfYtkMPnZKEa9/P/zUsIaCdKRDd8En7o7kjjXtlbVtIfbxljh9RL3SNqS Zi4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U6ad7fcyKDDeL6W/W6aha/qlLY6v2Wc21tqouOCVpy0=; b=SQKT8JGFeBz5LyqU7UmZF87x7QarjNl430Rw0qp8LI4dYZnSxaLLNRKb55vN9zj1UQ nvbzkh7snZF4D6srOt6VGc/BcHFL+/IutE/aB0pZ9iVPwcz6uaTukbKvHnsakCuzSkJc LCu16/o6UkVngBf6sKXoVaeykU9FCOFiXiU/N04Y0U7YvOJxCcTdnnH6vJQowO0uacK1 +Y3f5mo8fmNYMPUnWe1g6/QlqEo8ZM2xcvBxmAh3wOPj/PB7XQIcEOUi0Rba784ejL3o c4igxGbSIQXO4cqx2o+QdXaCOI/DPQohZaQDFZLDOMyA/+pTq+n04A7+ZCMoqfLJDZx9 M87A==
X-Gm-Message-State: AKwxytfQSA3zB6rz1uW6fptB1D/YYgStFAjODuKk538Usc0s/b10Gux/ frxBk5lw2X/m7mLOYsmOFpqBLVcpeloyScLsUBbujYVN+g8=
X-Google-Smtp-Source: AH8x2270UjkXavFFXqGhdyTvTElFZCkrX785QGc/2uJJUYUq539PccgZIIx6E7qvUiyUwKNIu5MQah6O5wdChyAoZjw=
X-Received: by 10.129.39.84 with SMTP id n81mr6755563ywn.5.1516833442818; Wed, 24 Jan 2018 14:37:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.201 with HTTP; Wed, 24 Jan 2018 14:36:42 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 24 Jan 2018 14:36:42 -0800
Message-ID: <CABcZeBO8UcdsPPp7D-3gZW8tuDqNhP-z+O1+WH=68KjbfYMr5A@mail.gmail.com>
Subject: Read-out on offline connection ID discussion
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114097248b06a205638d4e8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eHPIEy-z4y4z3seykuUTq7tJM_s>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 22:37:25 -0000

Hi folks,

We didn't really reach a conclusion, but here's, I think what there
was at least some support for:

- The long header has a variable length connection ID which has an
  explicit length field on the wire, with a max length (strawman: 32
  bytes). The exact wire encoding to be designed by the editor.
  Similarly, NEW_CONNECTION_ID would have a variable length
  encoding.

- The short header has a variable length connection ID which has
  an implicit length (i.e., it cannot be decoded unambiguously
  by an observer who is not part of the connection). However,
  the CID may be self-describing, so that the server may include
  a length field if it so chooses.

There was rough consensus on the second point, but some disagreement
about the first point. The major alternative proposal was to have
a fixed-length CID field in the long header and NEW_CONNECTION_ID
and then truncate it to an amount carried in transport_parameters.
This would have the benefit that the length of the CID would be
throughout the connection whereas if we wanted that rule for the
other design we would need a rule.

One thing that makes this second approach unattractive is that we want
the server to be able to use a 16 byte connection ID (thus allowing it
to be AES-encrypted) but it also needs to be able to include
meta-data, such as a key-id for rotation or potentially a length. This
tells us that you need to have a maximum connection ID larger than 16
bytes, and having a fixed 17-20 byte CID seems odd.

-Ekr