Re:Re:Re: Fast Address Validation - about

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sat, 02 November 2019 06:51 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE34120AC0; Fri, 1 Nov 2019 23:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 n4enwwkmh8Lp; Fri, 1 Nov 2019 23:51:10 -0700 (PDT)
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 C074412089B; Fri, 1 Nov 2019 23:51:09 -0700 (PDT)
Received: by mail-ed1-x541.google.com with SMTP id b18so9128008edr.11; Fri, 01 Nov 2019 23:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SJP3OI0Rry6TWCHbW4fDpmLO2qMqLuAafIi8f6VX3qc=; b=vZKUa/i6/lQ7hlUIV91fvehqFW8SDvaF1TkmZShvBvzBLv+gbBwsxCCjrjuA/FcabK DWWKhCEGXQYQtKh+VmIcL4navfZYsOoJv3Ogmf+AHWY20+bY6qYEUamX0WucbeL9pYhl wl3QgBNo5nnq6ARPgJWseXPRz0n1asskF328Ny1fmfU98TCzTxNyFngOuANy86lVu4Br kPmiXkpfR2LACycCclyay9qODMZMd+QftusKOhDK3lzgcjwgGsmVS+fsNlT2vokvZ6bf aZSWe/F5KtDko868upPmibLWaA6h3DHJHS+AEHj/lxYWtAvXNlAK96WxCvaUgNnpwPXZ tniQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SJP3OI0Rry6TWCHbW4fDpmLO2qMqLuAafIi8f6VX3qc=; b=JMGNbOmjG7WeYhTqdE5mHcbR01Br8OUaljI+E0gBBfZCH6wEKuXvKdw5XwJxRn2+Kr 50gbwEu1BcrPLJVfMnosU9kW5uZDHLUw+EcYinwQU4ynkZcrAHc3zQSTpiuhyMvwRyVP WjsRmkyjoNzQzcH5L5I7Ls0GI3ybIM/fE+cvqjVlgJtSAn5EzSJxgyoVed93uzDV+7Jw 7v1HnvE3hfpnnDS5sJY6abRv5QyJYTD3f1Cgqiuoy4JP1lrZzHHTQOyn5sYNG1QJGACJ shuBCCFrT29R2CaOUaoKK1RbPKS9RXJXik+kRj/ZGUkDCbES0kQjpgpvo0KCipSJuPWd fmcg==
X-Gm-Message-State: APjAAAUAf86dHSeIr/8Kgjk3HHWVER2thDsRfxV0tiW4+Osm52VaZEa7 LnA2yqJw/AGYgUlyLTk7w2hqR4XZvFChY3qGhJU=
X-Google-Smtp-Source: APXvYqz2++9ragbWS8TDVmqg3WfxJA6KhOil+i8zyGAXiwEY5litdjeSAgbZ9dbzAFU2ybcpvMKCWsQg5EEsabiDWuo=
X-Received: by 2002:a50:9930:: with SMTP id k45mr17122747edb.134.1572677468314; Fri, 01 Nov 2019 23:51:08 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 1 Nov 2019 23:51:07 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <880446e2-3bd9-4c47-8d66-fd582c0ae473.anqing.aq@alibaba-inc.com>
References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> <BN6PR2201MB1700F72F3DC8F6C3CF79902CDA600@BN6PR2201MB1700.namprd22.prod.outlook.com> <bd15f357-8e7a-42af-bf28-79f7177da385@www.fastmail.com> <f55efb80-1a95-4190-84e5-b81948a7f081.anqing.aq@alibaba-inc.com> <BN6PR2201MB17005571E88F1C68769091A3DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <69d1a917-b1f9-4142-afb0-f5c67abe7334.anqing.aq@alibaba-inc.com> <CAOYVs2r0zJzbfw5L2Mck8VEJhtyfQtHwF-db5VG45HDTF0WoOQ@mail.gmail.com> <7ac8ad51-c1a2-461b-bc47-021b3875eab8.anqing.aq@alibaba-inc.com> <CAN1APddvVeqXeWCZbe9WrLrOyVOWM5-1Dg8x5B4UpNwP6YOGrA@mail.gmail.com> <8f87c3ce-d9c0-4017-be6d-4a411daeaa2d.anqing.aq@alibaba-inc.com> <CAN1APdd4WuMGAusz3EnCc4+BsT+hBfC9oMmAmhhwDc75wxMGiw@mail.gmail.com> <880446e2-3bd9-4c47-8d66-fd582c0ae473.anqing.aq@alibaba-inc.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 01 Nov 2019 23:51:07 -0700
Message-ID: <CAN1APdeo78H5cfoDOcwiS3AJ9mx2jYEJB3X0qD3LBP8xQYc3Vw@mail.gmail.com>
Subject: Re:Re:Re: Fast Address Validation - about
To: Qing An <anqing.aq@alibaba-inc.com>, Marten Seemann <martenseemann@gmail.com>
Cc: "jri.ietf" <jri.ietf@gmail.com>, QUIC <quic-bounces@ietf.org>, quic <quic@ietf.org>, mt <mt@lowentropy.net>, "刘大鹏(鹏成)" <max.ldp@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="000000000000d860b50596578180"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/J-Wzzev1njtoFV2PgFh7R7UVg18>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2019 06:51:14 -0000

I can see how a token in the initial packet can speed up a second
connection because you can drop the handshake if you do not like the token.

But isn’t that exactly what 0-RTT connections / tokens are supposed to do?

And for delivering new tokens for future use it does not really matter if
it is delivered in the handshake from a performance perspective because 1)
you are likely to continue doing more work anyway, and 2) if not, you still
need to confirm the handshake before trusting the connection, and 3)
coalescing 1-RTT packets are not usually slower than sending in handshake.

>From a security perspective there are other concerns as Christian has
discussed.

Delivering Retry tokens for future use (as you mention your next mail) may
be problematic due to life time concerns. 0-RTT tokens are expected to live
longer than Retry and Retry tokens and the Connection ID associated with
it, reflects the current server farms load such that new connections can
redirect immediately, not sometime later.

On 1 November 2019 at 23.28.03, Qing An (anqing.aq@alibaba-inc.com) wrote:


Based on discussion, the proposal is for first connection establishment,
server chooses to eliminate Retry and rely on handshake. But server can
also use New_Token frame via Handshake or Initial to deliver token for
future connection.


------------------Original Mail ------------------
Sender:Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Send Date:Fri Nov 1 23:19:30 2019
Recipients:Qing An <anqing.aq@alibaba-inc.com>, Marten Seemann <
martenseemann@gmail.com>
CC:jri.ietf <jri.ietf@gmail.com>, QUIC <quic-bounces@ietf.org>, quic <
quic@ietf.org>, mt <mt@lowentropy.net>, 刘大鹏(鹏成) <max.ldp@alibaba-inc.com>
Subject:Re:Re: Fast Address Validation - about

> But what do you need to the token for in this case? The token is to prove
> that you previously spoken to the server. But the TLS handshake provides
> the same proof (but cannot redirect and must carry state). Any additional
> information the token might carry is only interesting in Initial packets
> where the connection can be stopped early or (in ongoing work) to encrypt
> the initial packet. That is not relevant during handshake. The Diffie
> Helman key exchange takes care of all this. Since you proposal also cannot
> redirect and must carry state, I don’t see the purpose. I do agree you can
> deliver that token, but since it is not obvious what the token is needed
> for, the purpose is unclear.
>
> You appear to assume that address validation only happens if you have a
> Retry token, bu that is not correct, it just happens with less server
> resources.
>
> On 1 November 2019 at 15.55.09, Qing An (anqing.aq@alibaba-inc.com) wrote:
>
>
> Again, the fast address validation is to provide another option for
> server, not to drop the Retry approach.
>
> I think if choose not to send a Retry, it is necessary to define how to
> deliver token from server to client. In this case,  via new_token frame in
> handshake can be an approach.
>
>
> ------------------Original Mail ------------------
> Sender:Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
> Send Date:Fri Nov 1 21:37:42 2019
> Recipients:Qing An <anqing.aq@alibaba-inc.com>, Marten Seemann <
> martenseemann@gmail.com>
> CC:jri.ietf <jri.ietf@gmail.com>, QUIC <quic-bounces@ietf.org>, quic <
> quic@ietf.org>, mt <mt@lowentropy.net>, 刘大鹏(鹏成) <max.ldp@alibaba-inc.com>
> Subject:Re: Fast Address Validation - about
>
>> You only save a roundtrip because you do not send a Retry.
>>
>> If you choose not to send a Retry, the client eventually gets validated
>> anyway because otherwise the handshake could not complete. Therefore a
>> Retry token is not needed if you go down that path. In this case the RTT
>> overhead with fast address validation is the same as ordinary QUIC 1-RTT
>> handshake.
>>
>> On the other hand, in the case where Retry is needed, the fast address
>> validation approach does not solve the problem which is one of 1) defer
>> handshake processing and server state until after the address is verified,
>> or 2) redirect the client to another server through a change in
>> ConnectionID.
>>
>>
>>
>> On 1 November 2019 at 14.26.24, Qing An (anqing.aq@alibaba-inc.com)
>> wrote:
>>
>>
>> I believe this can save 1-RTT.
>>
>> As for the privacy risk, new_token frame can be delivered via handshake
>>
>>
>> ------------------------------------------------------------------
>> From:Marten Seemann <martenseemann@gmail.com>
>> Send Time:2019年11月1日(星期五) 20:54
>> To:安勍(莳逸) <anqing.aq@alibaba-inc.com>
>> Cc:QUIC <quic-bounces@ietf.org>; quic <quic@ietf.org>; jri.ietf <
>> jri.ietf@gmail.com>; mt <mt@lowentropy.net>; mikkelfj <mikkelfj@gmail.com>;
>> 刘大鹏(鹏成) <max.ldp@alibaba-inc.com>
>> Subject:Re: Fast Address Validation - about
>>
>> I don't see any enhanced client experience, since the handshake takes
>> exactly the same number of round trips with your proposal as with the
>> current version of the QUIC draft.
>> Sending NEW_TOKEN in Initial packets provides no benefit over sending it
>> in 1-RTT packets, but comes with worse privacy properties, since Initial
>> packets are not encrypted and can therefore be read by on-path observers.
>>
>> On Fri, Nov 1, 2019 at 7:37 PM Qing An <anqing.aq@alibaba-inc.com> wrote:
>>
>> If so, for the first connection between client and server, server can
>> choose to eliminate the use of Retry packet for token delivery, and
>> rely on handshake encryption layer to prove return routability.
>> In addition, New_Token frame is used by
>> server, via i.e. the Initial packet, to provide the client with an
>> address validation token that can be used to validate future connections.
>>
>> It can enhance the experience in client side for the first connection
>> establishment.
>>
>> I submitted the draft,
>> https://datatracker.ietf.org/doc/draft-an-fast-address-validation/
>>
>> Qing
>>
>>
>>
>> ------------------------------------------------------------------
>> From:Mike Bishop <mbishop@evequefou.be>
>> Send Time:2019年11月1日(星期五) 00:06
>> To:安勍(莳逸) <anqing.aq@alibaba-inc.com>; quic <quic@ietf.org>; jri.ietf <
>> jri.ietf@gmail.com>; mt <mt@lowentropy.net>; mikkelfj <mikkelfj@gmail.com
>> >
>> Subject:RE: Fast Address Validation - about
>>
>> As Martin pointed out in the e-mail you replied to, if the server is
>> willing to maintain state, any packet at the Handshake encryption layer
>> proves return routability.  There seems to be no need for a separate
>> address validation mechanism if the server is willing to proceed with the
>> handshake.
>>
>>
>>
>> *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of* Qing An
>> *Sent:* Thursday, October 31, 2019 8:56 AM
>> *To:* quic <quic@ietf.org>; jri.ietf <jri.ietf@gmail.com>; mt <
>> mt@lowentropy.net>; mikkelfj <mikkelfj@gmail.com>
>> *Subject:* Re: Fast Address Validation - about
>>
>>
>>
>>
>>
>>
>>
>> To clarify, the proposal is not to replace the existing Retry-based
>> validation, but to provide another option for server to do the client
>> validation.
>>
>>
>>
>> I understand that in server side, exchanging the token at the Handshake encryption level
>> will make the server start to maintain handshake states. But in client
>> side, it can accelerate the connection establishment from client to server.
>>
>>
>>
>> And it is the server's decision whether to exchange token in Retry or in
>> Handshake. If server chooses to accept the cost brought by token exchanging
>> in Handshake, it will bring more enhanced experience in client side.
>>
>>
>>
>>
>>
>> BR,
>>
>> Qing
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------
>>
>> From:Martin Thomson <mt@lowentropy.net>
>>
>> Send Time:2019年10月31日(星期四) 06:07
>>
>> To:quic <quic@ietf.org>
>>
>> Subject:Re: Fast Address Validation - about
>>
>>
>>
>>
>> Also note that exchange of Handshake packets provides proof of return routeability via the use of the encryption keys, so there is no need to exchange tokens at that level.
>>
>> On Thu, Oct 31, 2019, at 03:29, Mike Bishop wrote:
>> >
>> > The advantage of using Retry, however, is that the server is able to
>> > keep minimal (if any) state about the client. Exchanging the token at
>> > the Handshake encryption level means the server is already doing work
>> > and maintaining state in order to process the handshake, which is
>> > exactly what the server is trying to avoid.
>> >
>> >
>> > *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of * Qing An
>> > *Sent:* Wednesday, October 30, 2019 9:41 AM
>> > *To:* quic <quic@ietf.org>; jri.ietf <jri.ietf@gmail.com>; mt
>> > <mt@lowentropy.net>
>> > *Cc:* 刘大鹏(鹏成) <max.ldp@alibaba-inc.com>
>> > *Subject:* Fast Address Validation - about
>> >
>> >
>> >
>> >
>> > Hi Martin, Jana,
>> >
>> > I read through https://www.ietf.org/id/draft-ietf-quic-transport-23.txt
>>
>> > and have a few comments and ideas to discuss.
>> >
>> >
>> > [QUIC-Trans] defines a token based scheme to facilitate address
>> > validation of a client. The token MUST be covered by integrity
>> > protection against modification or falsification by clients. The server
>> > remembers the value it sends to clients and validates the token sent
>> > back from a client. In its design, Retry packet is used to deliver the
>> > token to a client which address has not yet been validated. It voids
>> > the first transmission of the Initial packet sent by the client, and
>> > triggers a second Initial packet to be sent with the token. The
>> > exchange of token will cause longer connection establishment delay for
>> > a client.
>> >
>> >
>> > To improve the efficiency of address validation during handshake, one
>> > idea is that the same token can be exchanged via a different container
>> > i.e. the Handshake packet, that eliminates the use of Retry packet for
>> > token delivery.
>> >
>> >
>> > I am working on the complete draft and will submit it by Friday. Before
>> > that, hope this can be discussed in email first.
>> >
>> >
>> > BR,
>> >
>> > Qing An
>> >
>>
>>
>>
>>
>>