IETF Logo Mail Archive

Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

Mike Bishop <notifications@github.com> Tue, 20 August 2019 23:03 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 691381200F9 for <quic-issues@ietfa.amsl.com>; Tue, 20 Aug 2019 16:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 TuRRwdLWfBJi for <quic-issues@ietfa.amsl.com>; Tue, 20 Aug 2019 16:03:18 -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 7E6971200D8 for <quic-issues@ietf.org>; Tue, 20 Aug 2019 16:03:18 -0700 (PDT)
Date: Tue, 20 Aug 2019 16:03:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1566342197; bh=jeeCw81wxGdL/kvShKmvTI1ujUed5XRQz76WoYEwcO4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BTOSfm4FjrFR9ryxZSEcPU/gAQBtifmCaFWYW5S8YCsSt0DC9kCT5DXUesdQ97qeZ wjD+zRn2wg5jo+FYyZM9Fehj3UEAwUuCfd/6Z9LAz8SeZpCdE4kMhg5jKVPntsAfC3 PrnvFVsnMuLBundhzYUKPTJsdbdVBQGikWwPk82s=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5PKBSOFCTLVWUJRG53NGXLLEVBNHHBYVUFKY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2945/523228236@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2945@github.com>
References: <quicwg/base-drafts/issues/2945@github.com>
Subject: Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d5c7c359d471_12943fc5ce2cd96c212672"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/euIA8qA9BizDMjG0XhcdJNzcWZE>
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: Tue, 20 Aug 2019 23:03:20 -0000

> You do raise a good point about the ALPN dependency, however. That's a further complication to the QUIC/TLS interface: [...] The only way to avoid that complexity is to stop remembering the SETTINGS frame across 0-RTT.

I agree with you about the complexity of that, but I doubt giving up remembered settings in 0-RTT is a price we're willing to pay.  I feel like it's marginally better to have something post-handshake (NST) depend on the application (even if you get it during the handshake processing) than to have the transport parameters depend on application data.  We've currently been able to toe the line that nothing in the server's transport parameters depends on processing the client's transport parameters; ideally I'd consider that to include the rest of the Client Hello.

-- 
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/2945#issuecomment-523228236

v2.23.0 | Report a Bug | By Email