IETF Logo Mail Archive

Re: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)

Martin Thomson <notifications@github.com> Fri, 11 October 2019 02:58 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFBC1200F4 for <quic-issues@ietfa.amsl.com>; Thu, 10 Oct 2019 19:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 ebAnZFPwwWLS for <quic-issues@ietfa.amsl.com>; Thu, 10 Oct 2019 19:58:28 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B901200CC for <quic-issues@ietf.org>; Thu, 10 Oct 2019 19:58:27 -0700 (PDT)
Date: Thu, 10 Oct 2019 19:58:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570762707; bh=L3Fi5oHhmGN2iKWU6v8FcC1KKTcHy3GGulZViIc92ms=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xPp4o2I+TSmmqIY+TzQcs2r7MAexNI7wzOC8arSMzwb7PlxUXA2G0n0R7O//sH/t2 91KaIpqurZJOTWbMC55GLiQ4vZngMJ890hoTmClenaq8H+cJdnhD852bIlUb5TP6nk 3QJupOwVVbS0ZwWOeLqYLO5PMks/+zBhaBr1UkM0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2AM4FG7DHO4K7ROIN3VURFHEVBNHHB4IOF7M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3086/540879423@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3086@github.com>
References: <quicwg/base-drafts/issues/3086@github.com>
Subject: Re: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9fefd3192c5_48553ff2eb4cd95c105125"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/n7WiyJ3qoxMyN1lMC0jSvVU9wb4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Oct 2019 02:58:30 -0000

I think that Ian's assessment is broadly correct.  The downsides of the move, are that it increases the complexity of the transport by about the same, if not more, than it helps h3.  And it's not clear that a simple pair of declarations (this doesn't work as a negotiation when you are generically useful for other protocols.

The limitations of the mechanism - specifically regarding confidentiality - of a mechanism that uses transport parameters or similar aren't nice for a generic mechanism.  If I was inclined toward a fix, then I would prefer something along the lines of what @kazuho suggested elsewhere, which could involve more encryption, but also more complexity with no real guarantee of the resulting mechanism being generically useful.

That's why I'm firmly in the `v2` camp here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-540879423

v2.23.0 | Report a Bug | By Email