IETF Logo Mail Archive

Re: Version Ossification: Intended Scope for QUICv1

Jana Iyengar <jri.ietf@gmail.com> Tue, 05 November 2019 02:22 UTC

Return-Path: <jri.ietf@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 94C63120033 for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 18:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UWLzWWAgrf8V for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 18:22:17 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 7716412000F for <quic@ietf.org>; Mon, 4 Nov 2019 18:22:17 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id r7so11242963ljg.2 for <quic@ietf.org>; Mon, 04 Nov 2019 18:22:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=25Iefp8JlE4JxPk7FXWGE7TBegF9tDIBYOj9ZCct98M=; b=EwirZIGySl5wWnZ6lBz8g32NiMSU1ur2no9g34fHO+EoYuFt+wPHjlT7R7d2hs2vpv Cifjp5d/bKAggrVYTfBppIdeQmZgz761g2EHTinHPO1+SErqZoW6Knuw9VuIUWSO0DU0 j+pFMZTl5r4vN5NTwhTf9wsQVRkoqWVhVoN6XBmx1v+irGQuI027mGPzQtoUEtG/LqiV L6e7xcjV283SYBr5B2KL3zm+ndFDxrMQWtfuR8CY4S1tyNa4uiV8WdtVUOu+sMoVPqOo tBsw2UwTf5d88xnht6u57i1jNRxX4HkyiPVfnlRYWDFQGTNiBAKmFlt0qZuP7GrcYm8/ vMOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=25Iefp8JlE4JxPk7FXWGE7TBegF9tDIBYOj9ZCct98M=; b=eSrJqv+np/7G7wMCT8UeYkiyAhtitZdR2a4wlm2K3pjhUXCURF07C81++xatt5udNH Ahbm94iqFTTfzHyWqQ9s1FzeRO79F7A7D8hIjEe4K5ME4eHFJQ0LnXACje4sYJUlINcN M6hREmd71JcZ6Lsh0RtNLkpnL+G+A4pRgCtKUkmDLf06qCHxlBrOerTrWiUcOA8JaMKO SY4xny82vjCuRyNH37WtV0eeel7oJKWPKB/VgvMMI7o3s+AnZNbgIb11hFPlLcc4o4iG Zo5smnopub/SD/N8igDkf4DWPC4+nBiVpEfOTpOs9QeaOV5/8PszNR3bJkgQ/K/K4G6J w0uA==
X-Gm-Message-State: APjAAAUbvxAlOVfUxyyC6wP/vrBFdaYUCrJR4ncfgQmZDwM90RtJSXIK pHE/jLPf8n+G810F/0kADwhpqopaniNVZ/SvJUNy+Q==
X-Google-Smtp-Source: APXvYqw82Nre5IEchZNhe7NNP28E+dQcdeAJNwHdR7jJTmQNRxtLlpmfvBqgooWobbTTpW//f6qyPCSSwiQuswAES4Y=
X-Received: by 2002:a2e:b0f6:: with SMTP id h22mr10421517ljl.171.1572920535615; Mon, 04 Nov 2019 18:22:15 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6E79OySoOLbJ8eWp0J-+3yeB5iGvj6sW19bEDn_V7-NA@mail.gmail.com> <CANatvzzaWFgrvnaV=VeZRAVvxqSBeMSZT5aMUu7-Vh9raeZJFw@mail.gmail.com> <BN6PR2201MB1700184D81061E2CBFD77BFBDA620@BN6PR2201MB1700.namprd22.prod.outlook.com> <e24ecddd-139d-4669-be96-b3de57557c4e@www.fastmail.com> <CACpbDcci5R7Szti7LbpH7GEm9jT2fP_Jz99Mx-bBcSe8RT43cQ@mail.gmail.com> <d5c3b4d3-2202-41d7-9ebe-3541ceec1b78@www.fastmail.com>
In-Reply-To: <d5c3b4d3-2202-41d7-9ebe-3541ceec1b78@www.fastmail.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Mon, 04 Nov 2019 18:22:04 -0800
Message-ID: <CACpbDcetR7e01oDZ7_hihB2mpbKbOuydp6mHd474bduaMA5rbA@mail.gmail.com>
Subject: Re: Version Ossification: Intended Scope for QUICv1
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c90abb05969019d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gAqsNsXyKZj_T9i18m7KQvEMW9M>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Nov 2019 02:22:20 -0000

On Mon, Nov 4, 2019 at 5:58 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Tue, Nov 5, 2019, at 12:23, Jana Iyengar wrote:
> > On Sun, Nov 3, 2019 at 1:46 PM Martin Thomson <mt@lowentropy.net> wrote:
> > > Why can't servers just bake the "keys" into binaries? I mean, that's
> not something that is likely to get lost. And it isn't really the case that
> keys need to be secret, they just have to change often enough to frustrate
> attempts to fixate on them.
> >
> > This is a fine idea, but how does it change anything? Whenever the keys
> > are rotated at the server, you would still have to deal with old
> > versions appearing at the server, no?
>
> I'm assuming that you can a) limit the time over which a token could
> appear, b) use a key identifier so that keys can be changed, and c) keep
> old keys in the code until the associated tokens are all expired.
>

Right, that makes sense. I think your point about not requiring this to be
rotated frequently is a good one, and we might even want to suggest your
idea of baking the key into the binary.

v2.23.0 | Report a Bug | By Email