Re: Go Back to Single Packet Number Space

Eric Rescorla <ekr@rtfm.com> Thu, 26 July 2018 15:44 UTC

Return-Path: <ekr@rtfm.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 842E113119C for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 08:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 5gk2SkOtC2zz for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 08:44:50 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 01587131157 for <quic@ietf.org>; Thu, 26 Jul 2018 08:44:50 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id g6-v6so1513370lfb.11 for <quic@ietf.org>; Thu, 26 Jul 2018 08:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iVwK5MejFnZougPZYJiJJMzCgmprkkqYrCp//lpEL8M=; b=x3oXImOV1z0Zwna+0gXW5GrLTIOxxWX9nv0Vu36D+uImBkM8B3GoKZdscG17d31Jv+ 9qBvWLkzTwSgh9byKlD8/liex7t4XTGNDeIGDrlt8WdUOYFY2cWgjEUdbeG0nPSoGHbz e3dRfC5wPGS0N6HsxVrG7T8xR/zgmo86opxVzL3tbYDLMawui3q+PM88ILcHOm/Vwk61 1ZT1qiScvSEDwt6DjaHtKqCwOpcimGtefihwt1bYEIDh6qrClogBaefvsz5SxUlJf1SV mlm/EanZ8lFt4IZ35MmGeV2yrP2QZPSwNNIX74l0IbRP0xJN3WBwdD+H5nI4qN/rA5Av gIUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iVwK5MejFnZougPZYJiJJMzCgmprkkqYrCp//lpEL8M=; b=qjXO7cNQL69CnQoupq8NKFJDXTSMU/K1Ev+OcWGQxQ8r6DjHalm4PFNHUTL6BwxVsk FzIwxteosq6wYaGUI30cgFGO3n21qzhWD13Thl+Acq4YUFD+06eeQQ/kYGRyur5URKLl oMFqQGEvIlLq6OpZ/gnrCW4P175l3KZfGMV+NEWf8JvwSGr1Pei2CnTGvpbmxRg+/i6H SZmPCbv9zYrBid2pFzSJKd0DtbjnIi7mmfuWUWd/Yv1xOf4GssXntcDPPu3TpztymbtZ zYr4/mPiAgerCrSWwPCLRDXBpshsLkhk0CA1/VK1AUjhXL/tqndilTaquJwhcbo7NH1U L+KA==
X-Gm-Message-State: AOUpUlHO2bLRqS2n4r+Y/mP4SophORXi6HOZC4o/VlEzK99qJjcSNnT+ m9hsYCZCcyn9H9dYsU2prcBE/tHz/KjXwUsZzV3E2w==
X-Google-Smtp-Source: AAOMgpd9dtduJM7eGdYyJuPrQY+SX5OcrerfnJflfpsgLzywKL85h8BdTTk9LRRE3YfVDBq+Y9efW6bwAe1D8wa4KMg=
X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr1698187lfc.59.1532619888136; Thu, 26 Jul 2018 08:44:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 08:44:07 -0700 (PDT)
In-Reply-To: <DM5PR2101MB0901581E982F410F31E42E2AB32B0@DM5PR2101MB0901.namprd21.prod.outlook.com>
References: <DM5PR2101MB09016D44959E5796570F3CB7B3540@DM5PR2101MB0901.namprd21.prod.outlook.com> <CABkgnnUTPvrVALX0Xr9xGpJnTHq=yWN48NRqtcQSZ4bzGFjAYA@mail.gmail.com> <CANatvzwP9czJSVzLWYj1+0-rGMkeX0UAE9T+11Zd2ygip4K29A@mail.gmail.com> <CAOdDvNqzecNOX9hPrMqpTWTFh3yrqFjdmxtm1e+_sC6y+xxZsA@mail.gmail.com> <DM5PR2101MB0901581E982F410F31E42E2AB32B0@DM5PR2101MB0901.namprd21.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 26 Jul 2018 08:44:07 -0700
Message-ID: <CABcZeBPUe+0i8OkriJG4GyjrmLd+y4vwsCTcQYb7_vVGvp_goA@mail.gmail.com>
Subject: Re: Go Back to Single Packet Number Space
To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Kazuho Oku <kazuhooku@gmail.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000002310e0571e8e0b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jogH4FZFvhP18EreqJJqOc-23nI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 26 Jul 2018 15:44:54 -0000

On Thu, Jul 26, 2018 at 7:04 AM, Nick Banks <
nibanks=40microsoft.com@dmarc.ietf.org> wrote:

> First, I think we should limit the discussion to what actually is in V1.
> Things like post quantum crypto and possible future TLS changes are
> interesting to reason about, but should have no immediate bearing on the
> design right now. If things change in the future that might cause
> additional issues, we should handle them in a future version.
>
>
>
> Second, on the topic of only acknowledging packets at a greater than or
> equal encryption level being even harder or less efficient to implement,
> while I whole-heartedly disagree, I was thinking about this, and feel we
> could actually go one step further. Already I have proposed disallowing
> ACKs in Initial packets and allowing 0-RTT packets to be acknowledged in
> Handshake packets. We could instead just say no ACKs in Initial packets,
> but all other packets can acknowledge any other packet.
>

This seems like a lot of special casing.


No encryption level requirements at all. The obvious possible point of
> contention with this, is that it would allow Handshake packets to
> acknowledge 1-RTT packets. While it is a ‘lower’ encryption level (I don’t
> really know what that means) both Handshake and 1-RTT keys are keys only
> the endpoints know. I don’t see any harm in temporarily (as long as you
> accept Handshake packets) allowing Handshake packets to acknowledge 1-RTT
> packets. With this design, an implementation that needs to acknowledge
> something can then do whatever it likes, so long as it doesn’t use an
> Initial packets.
>

This does not match the analytic framework established for TLS 1.3, which
explicitly includes key separation between handshake and traffic keys. This
was very important when we did the protocol analysis, so I would not be in
favor of this change.

-Ekr




> Next, for not explicitly sending ACK frames in Initial packets, I
> personally don’t see the explicit event of TLS changing read encryption
> keys from initial to handshake as an implicit signal. To me, it seems very
> reasonable to call that out as the explicit signal to treat your initial
> packet(s?) as acknowledged.
>



>
> - Nick
>
>
>
> *From:* Patrick McManus <pmcmanus@mozilla.com>
> *Sent:* Thursday, July 26, 2018 5:15 AM
> *To:* Kazuho Oku <kazuhooku@gmail.com>
> *Cc:* Martin Thomson <martin.thomson@gmail.com>; Nick Banks <
> nibanks@microsoft.com>; QUIC WG <quic@ietf.org>
> *Subject:* Re: Go Back to Single Packet Number Space
>
>
>
>
>
>
>
> On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> I prefer having split packet number spaces, because in addition to
> what Martin says, I feel uneasy about allowing a receiver to
> acknowledge a packet "in a greater than or equal encryption level."
>
> My understanding is that this the key of the proposal. Use of a
> unified packet number space makes sense only when an endpoint can send
> an acknowledgement for all packets that it has received in one
> encryption level.
>
>
>
> This sums up my feelings as well - I really like the explicitness of the
> separate spaces.
>