Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)

Nick Harper <notifications@github.com> Fri, 25 October 2019 03:22 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 18E0612006A for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 20:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xbb1wRdcEt8C for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 20:22:32 -0700 (PDT)
Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0FA120110 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 20:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=rNWz+hp4QP2Mj3DskmYOhE/NNLw=; b=YdJhomyxOu40I++Q xJD/AQ5NRD447OD6fPNlVSnAsCxWrTX8r/0PvCCOAzIbHCKQolJW5dtEa2/7zNSg zmAqN+oQEW/pwROwt083mPAKCIGs8xOqa75sS15o8W5VkHFGxr9C2eInsfDRFHM9 zkHonSyN1lcxCPNGMKrpPTeCPsw=
Received: by filter2071p1mdw1.sendgrid.net with SMTP id filter2071p1mdw1-27500-5DB267DA-18 2019-10-25 03:11:22.5178188 +0000 UTC m=+616621.353039197
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) by ismtpd0036p1mdw1.sendgrid.net (SG) with ESMTP id VsuP4BVuRHuewJutrgjUIw for <quic-issues@ietf.org>; Fri, 25 Oct 2019 03:11:22.442 +0000 (UTC)
Date: Fri, 25 Oct 2019 03:11:22 +0000 (UTC)
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYATRK5AIECZGEO4PN3X6UGLEVBNHHB5B4MBE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3150/c546182450@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3150@github.com>
References: <quicwg/base-drafts/pull/3150@github.com>
Subject: Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db267d5cfc8_61233fdefc4cd96410948a"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3EohbUI9MFOXzC20TjdGjqlHV0aXkiJ50KwU ided0vnqxE0T07WMBmSxLxbT341+k5DmVBY8REGMxbyR5TqGnuSaHiuONoQoIeEntY+BrxhCwcsUpD wpMLa6jamT3sjpdyiyWYfQbI/EY2jFmile88Cz6MF77lzdUxlDWnjT9wvwhMofcjs8lGB4jlctfGap w=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/JwGQ0VZkCXZ9m1HQFI7Y1ewu9Mo>
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, 25 Oct 2019 03:22:37 -0000

> If I handed out a session ticket for 0-RTT, but I wouldn't accept 0-RTT without a token, would it be reasonable for me to put additional information about 0-RTT in the token?

The token is used for deciding whether the server believes the packet it's receiving actually comes from the address it says it's coming from. I could believe a server might trust a client only if it's doing a 1-RTT handshake, but not trust it if it's doing a 0-RTT handshake, so might encode that bit in the token. I don't think the server should be putting more specific bits like "this is the NST that should be used" or "here are the SETTINGS from the previous connection" in the token.

If the server doesn't like a token it receives with a 0-RTT handshake, it can send a Retry packet but still continue with the 0-RTT crypto handshake (even though it's now 1-RTT from a transport perspective). I don't see the need for there to be fate sharing between accepting a token and accepting 0-RTT - a server can reject one without rejecting the other.

I've created #3152 to express the problem statement as an issue.

-- 
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/3150#issuecomment-546182450