Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)

Kazuho Oku <notifications@github.com> Fri, 31 May 2019 14:17 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 AC02A1200E5 for <quic-issues@ietfa.amsl.com>; Fri, 31 May 2019 07:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.424
X-Spam-Level:
X-Spam-Status: No, score=-8.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 fLW470g-P1rr for <quic-issues@ietfa.amsl.com>; Fri, 31 May 2019 07:17:57 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA11A120052 for <quic-issues@ietf.org>; Fri, 31 May 2019 07:17:56 -0700 (PDT)
Date: Fri, 31 May 2019 07:17:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1559312275; bh=WiSBHWIQxf6xVDYUeKyAAA3M88LdrhMUQ7ryko0T2W4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OMy4d+Md1kqakrOLJnZlSjJdd7SXsj95GBl/vu71tOhtLTWMIocga3mVEyqioEn72 814Rl99jz5CK8B+jm8JO2AvVyJftcL6I/im76gzPeoXGrkvXULWIrjj9c2PcNfMq3B ymyhDy7otzliHo5a9L2JOGtsKD2dQp9s5hY58mHQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7EE7QFA24CNPHRO6N27ZVBHEVBNHHBVVRQLI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2760/497725048@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2760@github.com>
References: <quicwg/base-drafts/issues/2760@github.com>
Subject: Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf13793d86a8_72233fa53e2cd96818156d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/iOoNVWX3MoF3q0bDu_F-Q-_qHZM>
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, 31 May 2019 14:17:59 -0000

@marten-seemann 
> The token is literally just an opaque blob which is transferred on one connection and reused on another connection. All the complexity of issuing, encrypting, validating and using the tokens is born by the implementations, and if p2p isn't your use case, you don't need to do anything.

While I agree that tokens are just blobs, there are bunch of text explaining how a token is expected to be (or to not be) used, assuming that the roles between the endpoints do not change.

> There are two benefits here, that apply even if you don't do 0-RTT:
> 
> 1. You save one round-trip for address validation.

The only difference will be the amount of 0.5-RTT data that the server can send. It's either 3 packets (without token) or more (with token, like 10 packets or the CWND remembered by the token). Regardless of the availability of the token, the server cannot send data that cannot be replayed, because until it cannot be certain that the Initial packets that it received came from a legitimate client until it receives a response from the client.

So it seems to me that there'd be some difference, the benefit depending on if P2P application protocols require the server to send several packets worth of data before receiving anything from the client, before validating the client's authenticity.

> 2. You can encode additional information into the token. For example, an implementation could encode the RTT of the old connection into the token, and use that as an initial estimate when establishing a new connection.

I am not sure how much that is important, because in this scenario, the endpoint that is now acting as the client (i.e. the endpoint that offered the token) should have the knowledge of the RTT. Then, it would retransmit it's Initial at the correct moment, which would trigger the server to retransmit packets.

-- 
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/2760#issuecomment-497725048