Re: Packet number encryption

Martin Thomson <martin.thomson@gmail.com> Wed, 31 January 2018 10:42 UTC

Return-Path: <martin.thomson@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 52836131714 for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 02:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 bv7lyS4Gq-C9 for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 02:42:40 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 0D0BB1319E1 for <quic@ietf.org>; Wed, 31 Jan 2018 02:40:05 -0800 (PST)
Received: by mail-oi0-x234.google.com with SMTP id c189so9473078oib.12 for <quic@ietf.org>; Wed, 31 Jan 2018 02:40:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xOumLKUeIZ8TrvnwS080ut+/oEL+In1mLXPiwtyxU6A=; b=CqxJaIC2pJqkqfRPHHa/pzMsfdW1e/lxq+h7l4QUPdLgOfDCVEk4RaPmIAeCWCWoPy PB64/7cuDoDUWcFGrTtICtmL+p9duOUOpPbrCz93t4x0ix4PdeJ+xUWrPKnGi5zBUFJG ivHSXgB2qbvbBP0RcR9oa+c6UIaLtnBsX0u/JfQ/7gPqe1WDhCGRgxMxeZOJwMw0kgzg dADT+muuJA2tOjjOv6JN5IEmJpajcClx8Gepw1pQO71EdOOje6nTC2bDbwtShWEPOQEV 4J/pYN4MBsjqR9rT4uxcHYq0FFX+ugsxqWSfOVVcCvJb1hKkpfh7A8A/bemrag7YNYWl 6w6w==
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=xOumLKUeIZ8TrvnwS080ut+/oEL+In1mLXPiwtyxU6A=; b=gGlTixrNYfY6UnqVmmggA1JaYj/gaG+lCzt+MtN3HGn2vBUbire8SLQx6GZ4QgmEa2 duzERCLMj6waN2oBUwPC2sIqZ2lAy/KRCmJzvZfzQTNDY84BjDYvjs/Mi35FuV1sFnBi +QGVhSANP8HxRJLHK9jxPZ7EdrQ853Y+bboCZoniHatUp/0AfAxdDl0hjgjMpeH5pl6K lcTM8uG1mvWSJG2wJ6cGMYHvUZ2U/LigQSSHsphRyTbIy03uA4FxSWhzOIUBYgYzQGk1 I7CBnDGgYVrduax7pvZ3I2biylAP7IlXf0GltMlP/+Tji5GMQMow/mIflKlCQUQbO3tT Zb/g==
X-Gm-Message-State: AKwxytdjjW89e6MgFWzuExjM9UZMcxq0ltdKHhcQAK2x8zdIaUv9vLcg fAqgaMuslRCMnvVh2Df8TC3+YjnujF/l/lFMtUo=
X-Google-Smtp-Source: AH8x224Hw9v35y8zlqAjvGvTPBnUiM8xEkU0KjxU9Q/cM7g6YAVy0Lr/kMMhxrVQcGjDvUyZq4vcmAGv8IJVHYpTBS0=
X-Received: by 10.202.23.9 with SMTP id j9mr6344958oii.50.1517395204269; Wed, 31 Jan 2018 02:40:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 02:40:03 -0800 (PST)
In-Reply-To: <BCB3985A-74B6-4D50-9397-FF808FE5A087@trammell.ch>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <BCB3985A-74B6-4D50-9397-FF808FE5A087@trammell.ch>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 31 Jan 2018 21:40:03 +1100
Message-ID: <CABkgnnUX-JbqSAr4H7hwS8t0Ydt7npEvVajqd45E+06V9Bm+Ng@mail.gmail.com>
Subject: Re: Packet number encryption
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/r_sXVoXFDY70nH4ZyAgjcnKZhYo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Jan 2018 10:42:42 -0000

On Wed, Jan 31, 2018 at 9:14 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> Seems like it'd be simpler just to always try to 0RTT resume after being quiet for more than 30s, though that would require the application mapping to be resumption-aware.

You would lose a lot of state that way (absent some way of preserving
that state, which we don't have).  0-RTT also has a bunch of
drawbacks, including but not limited to: a pretty significant crypto
hit, a non-zero risk of not working, replay exposure, limitations on
number of bytes.