Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)

Igor Lubashev <notifications@github.com> Thu, 14 November 2019 02:08 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 2B38D1200F5 for <quic-issues@ietfa.amsl.com>; Wed, 13 Nov 2019 18:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 bSAEwJLIHUop for <quic-issues@ietfa.amsl.com>; Wed, 13 Nov 2019 18:08:56 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7F91200E3 for <quic-issues@ietf.org>; Wed, 13 Nov 2019 18:08:56 -0800 (PST)
Date: Wed, 13 Nov 2019 18:08:55 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573697335; bh=gnAwjjQT/tg24v1JJQxfUiv7elLY9VmyZdooOJuCQyo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TOEcpp/EvIk5xvGdnewe2yJVuoB6BqOJ6EzFsi3wrfqdspQumHwQHo0S0B8Agi5qU yy5saYL5f6JTE8NrEWyVv60rOACAWL0NRDEPxREIJ4URbtsw2K29wTTdio6w9B4VvE vbPSJtlddm3M2llfwlunVcmBT+Wdj9TRlxMOa6E4=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZAKVUH7OZV2TSJA4F33HU3PEVBNHHB5FITQM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3155/553690770@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3155@github.com>
References: <quicwg/base-drafts/issues/3155@github.com>
Subject: Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dccb7376bd58_3083fd54e8cd96870065"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/QVXPX8FC4Ts0pGmqs8FZI9buGRQ>
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, 14 Nov 2019 02:08:58 -0000

@kazuho 
> There is no requirement for the client to check it's address (or the network).

@martinthomson 
> As @kazuho says, a client might choose to constrain token use to particular networks, but it doesn't have to. 

Indeed, that's correct, no requirement to check address/network on first use. There is language about reuse that does require the check (but the reuse itself is not required / actually discouraged): "A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface." 

I think I can live with the new language, since it gives clients enough flexibility in case they believe that the server that issued the token and the new server cooperate in managing the tokens (including a belief that they are the same server).  So no objection to the current language in #3156 on my part.

-- 
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/3155#issuecomment-553690770