IETF Logo Mail Archive

Re: Asymmetric CIDs

Kazuho Oku <kazuhooku@gmail.com> Tue, 20 February 2018 06:56 UTC

Return-Path: <kazuhooku@gmail.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 2E24B126DC2 for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 22:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-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 weczR3E9qZrm for <quic@ietfa.amsl.com>; Mon, 19 Feb 2018 22:56:29 -0800 (PST)
Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (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 03909124235 for <quic@ietf.org>; Mon, 19 Feb 2018 22:56:29 -0800 (PST)
Received: by mail-pl0-x22f.google.com with SMTP id p5so6963431plo.12 for <quic@ietf.org>; Mon, 19 Feb 2018 22:56:28 -0800 (PST)
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=AZ9GXsl7M3zKTpZlgOzUBtWJ/d5YpTTDaAVyjtwReCI=; b=n91ALvRozBebyDKSzoXgN6ZGJNIjelH2cVzDs/kuY01FpG046pSORklzzf/ks7sAgJ WLHP95GU1ebnWFe89KlgExYhkmKdKehAdmuiqkK+JFoWuHYr1qc1PPvL84A1MBHwQe3M KN/qyZARxXDRV6mrnSt1WIw4RBBQU9l3vlPYMr6tUL82+1op4sVD4y9iiWoggHUDeQJs pawUQoUkkO4Lqpx2ARZPyj776IRhFAC57ULDqu7b2D8T8P0cXNBojmKB+0ZMPIf7QxHl N0rlSZKCQ3RwPoCGp6bHWBcCxJkT5FVkV5jTm867ERPcdm6vo4oRynZJQZ83LUu466Cr VLPw==
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=AZ9GXsl7M3zKTpZlgOzUBtWJ/d5YpTTDaAVyjtwReCI=; b=URVxtr2LX7zaBzSCih0iI3kKf/8CBpFpdnRgV+yZXbKYxIBA3Ms1hAn5pPLmpdvIug Mn4PDfKO2TrQRiUBEBoAYoaKVBp0X9Nv71zX7NFZg0YSvhTxbtI1EDwU7yWy5Pql9+VH aiMxZ5B+gswXbviTLUBjKj8d1g7u//GLfiOrpaGPp1zNwDE9xS9bbuYv6Y69nrzxryi/ rEbfXt/FZDlabQ7eqpTlaNnYfWniJne/MQDniNWmLBGghOdO1kRthhx+zhP49ffjlGMt 4/8/02htXCmRxhXTNYSHtfLeQAXEUBieKl6GDPqEn8PcTItpOu6k+bZdDACC5oFZYPcL OYZw==
X-Gm-Message-State: APf1xPC4mrOKcp02IJXabe2idS/h3t4xG6OfSw1IZPaGGLRjKGOlkcym 52pAonJXXUzpe+PSsr6/Gjhrj4yjVXL0yGK79QY=
X-Google-Smtp-Source: AH8x224g+CpyVNwT39qfdlTc02tx8XMAUV1oQ53ep7Dt4V8eiWnxMde5VczXEJItUNewdw0Y2o6jdVMYWHicYy48V8Y=
X-Received: by 2002:a17:902:6e8c:: with SMTP id v12-v6mr16474230plk.424.1519109788521; Mon, 19 Feb 2018 22:56:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.189.151 with HTTP; Mon, 19 Feb 2018 22:56:28 -0800 (PST)
In-Reply-To: <CAKcm_gNeFJUP_1VFxSri=V+iDJR9RxvTwmca45bLM0m0BHo-Hw@mail.gmail.com>
References: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com> <CAKcm_gOvf0N7sq2so38sQaD+2jHGnDpsSQHEwU8HPgSpMJRfzA@mail.gmail.com> <CAM4esxQW1-dVfJSi4zoURNV-7u0EP6h-Xdyx5Wbo0QMdrkLk=w@mail.gmail.com> <AA0705E2-7A79-47DD-846A-C0B74A8A4B24@huitema.net> <D7E469CD-B9D8-41ED-8F5C-9933DCBA90E6@fb.com> <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> <BN6PR21MB0178395DC04C19D991436525B3CB0@BN6PR21MB0178.namprd21.prod.outlook.com> <CAKcm_gNeFJUP_1VFxSri=V+iDJR9RxvTwmca45bLM0m0BHo-Hw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 20 Feb 2018 15:56:28 +0900
Message-ID: <CANatvzzxydfXHvZ1ABka4y1L5GZychGm7hTkAEmBJjt_ndP24Q@mail.gmail.com>
Subject: Re: Asymmetric CIDs
To: Ian Swett <ianswett@google.com>
Cc: Nick Banks <nibanks@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>, huitema <huitema@huitema.net>, Roberto Peon <fenix@fb.com>, Martin Duke <martin.h.duke@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jT4GleZMSZtQdD81vv8gxgJc17A>
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: Tue, 20 Feb 2018 06:56:30 -0000

2018-02-17 7:45 GMT+09:00 Ian Swett <ianswett@google.com>:
> I agree that could be a concern, but I think it's no more difficult to solve
> than the status quo.  It just means both sides need to have more connection
> IDs, not just one side.
>
> Nick's solution is a good suggestion, but one can also imagine cases when
> other connection IDs have previously been made available.

Another approach will be to use the first N octets of the stateless
reset token (provided by the server) as the connection ID.

For example, if the stateless reset token is 00 01 02 03 04 ... 7f,
and if the length of the CID is 4 octets, the server will use 00 01 02
03 as the CID and 04..7f as the payload of a stateless reset.

> In practice, for most of the cases we're discussing, I'm expecting the
> connection ID from server to client will be 0 bytes in length, making this a
> non-issue.

Agreed.

-- 
Kazuho Oku

v2.23.0 | Report a Bug | By Email