IETF Logo Mail Archive

Re: Packet number encryption

Christian Huitema <huitema@huitema.net> Thu, 01 February 2018 02:25 UTC

Return-Path: <huitema@huitema.net>
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 B1D8B13175F for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 18:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 gFKhCyw3RqOK for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 18:25:10 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA8712EC91 for <quic@ietf.org>; Wed, 31 Jan 2018 18:25:10 -0800 (PST)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eh4Yl-0004X0-3P for quic@ietf.org; Thu, 01 Feb 2018 03:25:08 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eh4Yi-0007ay-1p for quic@ietf.org; Wed, 31 Jan 2018 21:25:04 -0500
Received: (qmail 6973 invoked from network); 1 Feb 2018 02:25:01 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 1 Feb 2018 02:25:01 -0000
To: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <fenix@fb.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <CA+9kkMDvp64NspznEuVy2tu8Eh1xmFkXu5S0AtDwbZKQ9Kq2fA@mail.gmail.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <CABkgnnVsx9ohKO95bsDbYpM+bgWb-HQiVW2Yn=XWG458uzNgtg@mail.gmail.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <218b5005-4fb5-1577-2699-87a8ab93a90c@huitema.net>
Date: Wed, 31 Jan 2018 16:25:01 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnVsx9ohKO95bsDbYpM+bgWb-HQiVW2Yn=XWG458uzNgtg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: Packet number encryption
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5j90Qwll3RzAYIAmbX3Q8kIXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKeGm+GYYqNLYaw38DBWInB98yDTitFWvbHwz9vKZpm+Fv CFr9jpJ2kLwf6AsfyQqZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLuoPnCd8zMEGMjWpPpP6Z uS+Gz+dPt+p2eC3ntkP+IrLh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Gd20T8xFITcF1bVYFM5+Dh5nHEeB4hpRrmo/duzUUp/Lr cNWSa56tlMgWLlKqQLVzuG+lKlmR7zmDjulXtu9Kl3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+AqMI8XB32z4L/a53NbOeOoj2lB9TLiDMfXuvSrucRXrlnGtGdG3g+ozMfeTuFOSvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ctn5BThjYlsIJio6g1Ta_SKiFTg>
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: Thu, 01 Feb 2018 02:25:11 -0000


On 1/31/2018 4:00 PM, Martin Thomson wrote:
> Of course, that likely only makes sense if the server is creating
> explicit mappings for each, which - as discussed at the interim -
> isn't super practical in many deployments.  Right now, I think that
> the assumption is an assumption only, and that relying on strictly
> linear use of connection IDs would be unwise.
Then maybe we need a way for the client to signal that it won't use a
particular ID in the future.

For privacy reasons, IDs should only be used on single paths. If a
client tries to use a path and then gives up, the ID won't be used
anymore. So maybe the client needs to have a way to tell that to the
server. Something like an "OLD_CONNECTION_ID" frame.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email