Re: [quicwg/base-drafts] Does a client need to remember SETTINGS it doesn't understand when doing 0-RTT resumption? (#3110)

Nick Harper <notifications@github.com> Thu, 17 October 2019 17:02 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 2C5EE120802 for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 10:02:41 -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 V6mMuvwUnZDW for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 10:02:38 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60829120145 for <quic-issues@ietf.org>; Thu, 17 Oct 2019 10:02:38 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net [10.52.16.66]) by smtp.github.com (Postfix) with ESMTP id 729496A1228 for <quic-issues@ietf.org>; Thu, 17 Oct 2019 10:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571331757; bh=HK5lvImlQ5BfrwFw34sigFEcPjulTYA1aVwzsCEuFT0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Azty71Ufq8IUB4DAUCrlqxq5gcoTqURuo5K5tM2N8xUW6/iJTB3L5CgK0UbGfTmy2 BYjuC4lbNRZP1+V0YL7otkmxzAR6t1t8kZiQBizCH0DgrsQDQQTAaefaFTg8+vIXsd l1ADxpmnnkCvYw9u6r9s7RmbAz4+Zcd2+u+qFoG8=
Date: Thu, 17 Oct 2019 10:02:37 -0700
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZCFIDXTWBD2IP4FXF3WXPT3EVBNHHB4UEZZA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3110/543269545@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3110@github.com>
References: <quicwg/base-drafts/issues/3110@github.com>
Subject: Re: [quicwg/base-drafts] Does a client need to remember SETTINGS it doesn't understand when doing 0-RTT resumption? (#3110)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da89ead61ce9_72fc3fdd702cd96c1104af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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/ZUx2K_RiKJAehiJCnkOAh6eau88>
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: Thu, 17 Oct 2019 17:02:41 -0000

You're right that for the client to know whether or not it's the default value it needs to support the setting (or at least know about it).

Suppose the server sends SETTING BLORP (which the client knows nothing about) with value X in the original SETTINGS, but omits it on the 0-RTT resumed connection. As currently specified, if value X is not the default value, the client MUST close the connection, but if it is the default value, then that's fine. (Meaning the client needs to know all possible default values for all possible settings.)

I think this needs an editorial fix to apply something like "a setting the client understands" to the bit about omitting a value as well.

-- 
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/3110#issuecomment-543269545