Re: Implicit ACK and Client Finished

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 06 June 2018 07:01 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 219C4130EBA for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 00:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fg3StuaTLWSq for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 00:01:43 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 E5B74130EB7 for <quic@ietf.org>; Wed, 6 Jun 2018 00:01:42 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id r24-v6so6409543ioh.9 for <quic@ietf.org>; Wed, 06 Jun 2018 00:01:42 -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; bh=kCC1KSjpwY8f9lXzYBHo9QpXCdhNLZ93pRvhbgGOLdw=; b=DrtOoOWPUZlGLv1WLaAnnyGqlSe9NqkiPr2+WVk+fzYS5XaLqxxP8zGO36z8y/v1m6 ZW+TCBdksfDuS3/6fBlomRdy/mS1n/xPw6OtlYzfPiGVp5HuJvYLM8cRi6lGgD1NFJUx VBDOIewCMK6sSHwvEjO5rM+Nu1/HozyAYdrJ8VYQ0iHLR7qONjTmcZVF/fgRhKvBDkU7 88dEhkH2KEgSYK5wvdqO7AQZPFfI5TJyEzlZC+ZLQ1ELqh+T+u4RDAlOj3Jtqw/i2jDZ +NGi9V4rFF8qUg+r+EfMLBKE3eSvZzMhgkVBu8PTk43i1mQxVwCFfGCDuvcWA63zC/1c EmUQ==
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; bh=kCC1KSjpwY8f9lXzYBHo9QpXCdhNLZ93pRvhbgGOLdw=; b=fj/3biSvcbwH2gR5zFMxGrgDcG5gvQwYfkqiFF811PbAX8PH1+2pJuHcTDKtjcFNIh dKCITJruvrR1pdlP9LziSdtn+uUp1fG8NH319tmIFWbGNFZgTheWNfohaXBnVRvC3bAw 8ruJZgAvygEqU87GABTpRIQETgPe62ecU9dwWS+9cDyqEFuwONlgpmyo5OuqmLNCToKC nCq9XnIYUYbITlI37/F7Rg8sfOwluuKoDmELzhkVKgiwuR1ECrSXWAK82BaY820onqZB +31GuEpnYXQJfCKdBmFrPR3+/qDI1zhFbw9fT5yCFQ75x4XFNyrnfbTKx53bfHwHy/au roNA==
X-Gm-Message-State: APt69E2T0QXeVwvbhTF7N9u00Rhp1h0gYwqFP4fqiJS2XCPmKLFk6BZz tWjxsIaVur9LVgUYVBXFfeYCZ0m7EclfkfU9p9+8qg==
X-Google-Smtp-Source: ADUXVKIxcdkzoa7yQpKw1d9n8WssD75NkyBRvEP326PRvPTwbd/qmg5SkCYpiccrBNz8alWRIBkBHatcshD2OvN4MeA=
X-Received: by 2002:a6b:93c6:: with SMTP id v189-v6mr1686486iod.274.1528268500784; Wed, 06 Jun 2018 00:01:40 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 03:01:40 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net>
References: <25a3676e-459e-808f-c055-f023b7b11dcc@huitema.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 6 Jun 2018 03:01:40 -0400
Message-ID: <CAN1APddu+gOfVKk-Dv8TufXUXTGsKt46-GOcatzk_ipyGpMXHw@mail.gmail.com>
Subject: Re: Implicit ACK and Client Finished
To: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c5fe1056df3bd7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cAsn9GbkcTcvz-pFCZNOEXtHxNc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 06 Jun 2018 07:01:48 -0000

I had the same thought while reading through the assertions, before
arriving at your concerns.

This question also needs some motivation for the implicit ACK - what is
gained by doing so?
I guess it could avoid a packet when one part has nothing else to send, but
I’d like to see that detailed.

I also prefer an explicit client finished signal. Especially because
implicit ACK’s ties the handshake close to TLS and especially with the new
stream 0 proposal TLS is fairly decoupled, opening for protocol variants
with other handshakes (e.g. IoT devices).

Thus, even if it could be assumed that the assertion 2 and 3 holds, they
might not hold in other variants, so there should be a good reason to rely
on them.



On 6 June 2018 at 08.40.29, Christian Huitema (huitema@huitema.net) wrote:

During the QUIC interop yesterday, there was a discussion of the
proposed implicit ACK of the "client finished" message, during the
transition from handshake to 1rtt protection. The sequence that we
envisage goes like that:

<--- Server sends last message in server flight (server finished),
protected with Handshake key, sequence number A

<--- Server sends first 1-RTT protected message (really, 0.5RTT),
protected with 1 RTT key, sequence number B

---> Client sends last message in client second flight (client
finished), protected with Handshake Key, sequence number C

---> Client sends 1-RTT protected message, carrying ACK(C), sequence
number D

<---Server sends 1-RTT protected message, carrying ACK(D), sequence
number E.

---> Client sends ACK(E) in 1RTT protected packet.

The implicit ACK proposal would state the following:

1) When the server receives ACK(B), the ack of its first 1RTT message,
it knows that the whole server first flight had been received.

2) When the client receives ACK(D), the ack of its first 1RTT message,
it knows that the whole client flight has been received, and that the
server will not send any more "handshake" packet.

3) When the server receives ACK(E), it knows that the client knows that
all handshake packets have been received, and the clientwill not send
any more handshake packets.

I believe that the 1st assertion is correct, because if the server
flight up to server finished was not properly received, the client would
not have been able to validate the session, compute the 1RTT key, and
receive a packet encrypted.with 1RTT key. But I believe that the 2nd and
possibly the 3rd assumptions are not correct.

The problem with the second assumption is that the server does not
really need to receive the TLS client finished message before
acknowledging 1RTT protected packets. Even if we wrote in the spec that
the server MUST wait for the final validation of the TLS handshake
before acking any 1RTT protected packet, since there is no actual
mechanism to enforce that, we know it will be one of those "MUST (BUT WE
KNOW YOU WILL NOT)" recommendations.

Personally, I would rather see some kind of explicit acknowledgement of
the client finished message. But we need an open discussion.

-- Christian Huitema