Mechanism for negotiating extensions

Victor Vasiliev <vasilvv@google.com> Thu, 25 January 2018 16:34 UTC

Return-Path: <vasilvv@google.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 1FE2F12DA51 for <quic@ietfa.amsl.com>; Thu, 25 Jan 2018 08:34:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uiOR46zDunVV for <quic@ietfa.amsl.com>; Thu, 25 Jan 2018 08:34:31 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 81F1712DA73 for <quic@ietf.org>; Thu, 25 Jan 2018 08:34:26 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id f71so15738954wmf.0 for <quic@ietf.org>; Thu, 25 Jan 2018 08:34:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pzofMFc2BWU5tQdCS7znte5lNj2GLC8YmJZc1/stilQ=; b=llF20rGFskalxrnjNDXLxpuDtVaEhmOYAf2lMPn+28nsbPbRQ0M2w/A++OQmvu6xwz YZ2j72F8fZIjC4b1bvm+5ZkceuHeebLTuYBkjRCjItRRpteUvIlkV3IorCvKrAK00YYd K0vsPE7hTAcKJav9sbtBHn4F6AXnJL1QuogtgZmFhw79a5xmCRjZqS9JMt0bbRrs33T1 wkWO73Z2jDLSRZj5o5HFD1XWo0xd0KPVf/9wNyJE6icSFZnalqL+19B8dyJi6sTR+JoN Z4RwnDVeHXNp8Dq3RacRrkMIlW0hEnAxnNn3bgjjcGkEMApaHkSvlv4yHMjO3ZbqrpVT G7JA==
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=pzofMFc2BWU5tQdCS7znte5lNj2GLC8YmJZc1/stilQ=; b=nyvrZaLzDT1LRjoOJNAOzfIWXRfhHecCrr1EQyfSkpY0C7lzJyb2FlyFS5+ZsKpBwO 4xAP/Sd20eBt0xVRocBt4gVphl2yaS5On1tJ/jlffK6EGRZvVj9GKLDDfwrKLcwEOJa2 ytDtg138Nr6KkMeivDEbXio6KOK+i5c88H3wTkURQamL2vYOWkXO3d+YVal6EqRkvzZq weOtN0B/9nlX26L3b47D6fMk91GCBH5nP4rSDTJfj/FAjsC98hCU9LR2PrQEBCIB64OW YV5xun5pp68pzIw5yX6dYO4FcNJMAlmqLrwuBPHjKQSS41xZHNFSitdIUEbPClT6TXKZ Zr5A==
X-Gm-Message-State: AKwxytcKr7O4DPr6YLRFdV2DZHJYY9N6lrtNn9FguOqcJfcp1McdAWRQ Mb2PYCKXzI5jSwgyN4b61rEuqV5Azzt36kX/UBx+HFQs
X-Google-Smtp-Source: AH8x227Oby1lq/vjvOBoMvnUJm1CZW8DjsBSOdHKpGAZsGV7BsO3NIvymbfwqn5tGBUXK3B0FRVmNHFFY27ADxFTHX4=
X-Received: by 10.80.129.225 with SMTP id 88mr29900782ede.19.1516898064616; Thu, 25 Jan 2018 08:34:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.134.182 with HTTP; Thu, 25 Jan 2018 08:34:24 -0800 (PST)
From: Victor Vasiliev <vasilvv@google.com>
Date: Thu, 25 Jan 2018 11:34:24 -0500
Message-ID: <CAAZdMaddvjUj4=9_RKm8oeET0G-tQ4w4WVyzr81KP=eEPN+orw@mail.gmail.com>
Subject: Mechanism for negotiating extensions
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05da824e074905639c5a4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/U3DM8pZ48osCIyn1VhR0D7a36JE>
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, 25 Jan 2018 16:34:34 -0000

I've been thinking about extension negotiation, and I'm not entirely sure
that "just put a transport parameter per extension" is a sufficiently
complete answer.  There are at least two problems in extending QUIC that we
ought to address.

The first problem is that the frame type field is only one byte long.
While this is enough for any single QUIC connection, if we try to allocate
those globally in a non-conflicting manner, we might exhaust it sooner than
we think (also, this would require coordinating two extensions to be
compatible).  Thus, I believe we should to add a general mechanism where
every extension, when negotiated, would specify which frame type numbers
it's using on the wire for each frame, so that this number allocation can
be performed on per-connection basis.  I believe there are mechanisms
similar to that in other protocols (e.g. RTP does something like that in
RFC 8285).

The second problem is that the client list of offered extensions is not
protected by secure keys.  I am not sure how much of an issue this is in
terms of ossification -- I don't remember off the top of my head where it
caused problems in TLS *per se*, and inventing a completely new mechanism
for it will surely run into a set of issues.  Still, it's worth discussing.

If people believe that the mapping proposal is valuable, I can write up a
PR for this.