IETF Logo Mail Archive

Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

MikkelFJ <notifications@github.com> Fri, 15 November 2019 08:56 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 A8B8612013F for <quic-issues@ietfa.amsl.com>; Fri, 15 Nov 2019 00:56:02 -0800 (PST)
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 3eMGeHoKuBqo for <quic-issues@ietfa.amsl.com>; Fri, 15 Nov 2019 00:55:56 -0800 (PST)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BBE120119 for <quic-issues@ietf.org>; Fri, 15 Nov 2019 00:55:55 -0800 (PST)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 507981204F9 for <quic-issues@ietf.org>; Fri, 15 Nov 2019 00:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573808155; bh=8aTm+gYtoega+wBnSVlXptoXvy/C+0602D289IhVKBk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YzIuSLRHBvksPRkC1qD6d67NafCjwZrJ+/bbuOas8Xh+IWo8MoN/30Q7nOZvsOnlA q0ZT5Z1cOK5mibPs4dOMyLKBF1/o98CfvWPpJeiPvl+fxFs4Dk1uSHa1dXwEkKHUn7 N8GkW9r1Uu7ZpNK1g/LERBxss8flWK6qL/L7MLJ4=
Date: Fri, 15 Nov 2019 00:55:55 -0800
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5HGC3JTNMYFOEUWUN33ONJXEVBNHHB5FNSNM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3156/c554271435@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3156@github.com>
References: <quicwg/base-drafts/pull/3156@github.com>
Subject: Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dce681bc7f8_17663fb3ee8cd96c150721c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/C4EJ3zgpuEqI3GpuYxV_H7kKSdU>
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, 15 Nov 2019 08:56:03 -0000

> I'm not sure that this is the right scoping. Consider that NST is explicitly tied just to the server you connected to, not to any server found in the certificate. Why isn't this "same server name"?

Retry is a server controlled method that can be used for various things including client address validation, but also load balancing or redirects to a more local or somehow better service. Requiring these alternative locations to be tightly coupled to the original connection would work against this.

-- 
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/pull/3156#issuecomment-554271435

v2.20.0 | Report a Bug | By Email