Re: Packet number encryption

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 09 February 2018 21:27 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 022221242F7 for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 13:27:44 -0800 (PST)
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 ZEYLjBsDF_La for <quic@ietfa.amsl.com>; Fri, 9 Feb 2018 13:27:42 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 616B81272E1 for <quic@ietf.org>; Fri, 9 Feb 2018 13:27:39 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id f89so11154329ioj.4 for <quic@ietf.org>; Fri, 09 Feb 2018 13:27:39 -0800 (PST)
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=Cyk6TVoPbikO0Rm7c3Ni6R4nqsHDu7OayY+0D2jqehM=; b=BN/64F/NfC3/PshDGoA4Dled5JsSJujq/E6bZBPNQH+tKjeLarIF5w4//PRyWpiIrm PueRTgtKw9k/RTXyZyMZuhAS5PPhz3yIIa4Q+RD1kkr2yhcMidSQkdm29QYj6J6f1VrA XVdvysy5nHB8ZGCTLmWUy/m6IKcA3OI5CTjqhAKPG4nA0dVkrW0l1ANL06QgWijuvELT X7nPN6bfN0X6v3s43LvwNarYwa47afb2/2n+GRzokVrS57vlWQG6rwModSLLbZT1Tfs9 IP7qGetuurgJk1ZCnZIqvBVO3v7MBmIjso8IFsXMArqz6ehmfywZN4xFN2Dguo0OQvq6 sukQ==
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=Cyk6TVoPbikO0Rm7c3Ni6R4nqsHDu7OayY+0D2jqehM=; b=rrTolTLREmuptKL1IuHt3o7B8/QVUG9lFSmoTtomWR4BgKAvwPXBfd9gqM4YTaBG71 EkH35HnoncqhjdJiauP2MhLrubeouJXMHWzMxJ0wEZAtH07V9ap8gcehgynhX+WBtAwI 7BXLTyNiveFH7zLW3jCwsrpLfmd6zWjLVebX31Dsw50chhLlKwB70IunHqv9GCB2Nr0V LlrqXgVgACaYNakQ4q33GZzOq2f53LFctd+RakxUL3mJI8JBcLrv6mS4UeM6XrAPOKBO VQTetbYoshX+dPg8ZMLPdrToTyH+8yqOgACZcI3M41LzEvi7oa/lbVmt1W9FfDCAZ7om Z7Vg==
X-Gm-Message-State: APf1xPAsaXfnYc2KiwANQae98tARCkVuhpmoqmAWCSHg5FGtbfQ8mfrO x185ZgEzN9Ln2UaZNapdV7dPvvtpcmseXT4Rgxg=
X-Google-Smtp-Source: AH8x225KieAX7rsPgbS7rvR7O0kLRHa/oPKU9fvHFevHvK7xE2fkdIWL+ANCS8YbaaY6JKEHAeFAYgJecUNHz0yJ1eQ=
X-Received: by 10.107.34.199 with SMTP id i190mr5079118ioi.297.1518211658747; Fri, 09 Feb 2018 13:27:38 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 13:27:38 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAAZdMaf_okyh1FHemPK90=RQp2Tb-p34SA_C77RLp68bwWSE2Q@mail.gmail.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <CAN1APde6o6=aCXuWajPFSU=jXv-ERdVHk=uyjM71uQ_uU-oMTg@mail.gmail.com> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <MWHPR08MB2432D0216BC8FE1B0D9E3690DAFD0@MWHPR08MB2432.namprd08.prod.outlook.com> <CAGD1bZauKbucs_5n7RQbK8H2HiyfiqpGVEcKreGA6umhMBSFgg@mail.gmail.com> <CABcZeBPNrc-9vANSH02r++p53s6gN4pVB8DMd80nUxOhKTp3dA@mail.gmail.com> <CAKcm_gMvHSBhpUvsQCCkV2_o+d_wchF3R3L6H8mp6nKNaaRmSw@mail.gmail.com> <CY4PR21MB0133CCAA6807469BA983D00BB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <CABkgnnW4xr_YzpsvCxaJJgcQdBTuX=Yv735_sdd4VoMfji8mbA@mail.gmail.com> <CY4PR21MB0133C759D4A08A4988B641B2B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <bdf88936-8edc-d56e-ee59-c9d597058edd@huitema.net> <CY4PR21MB01337C8A700E58B49D90B712B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <CAOYVs2pi8-NVuS+crNMfjsP-n5upK3=5tPeQ8OSGpOvL6RTrjA@mail.gmail.com> <CY4PR21MB0133A1117B2733BBCF049C5FB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <CAAZdMad-vEBj4Zw-9=bM8hfSui68YBPTi88ZB434giYMXA1viQ@mail.gmail.com> <MWHPR21MB0144A36781B9AB9BEC7B99A8B6F30@MWHPR21MB0144.namprd21.prod.outlook.com> <CAAZdMaf_okyh1FHemPK90=RQp2Tb-p34SA_C77RLp68bwWSE2Q@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 09 Feb 2018 13:27:38 -0800
Message-ID: <CAN1APdchpj++3K5AcYZk-SMPBRDi3jvo7gjSMQwdYY_NuLNkgQ@mail.gmail.com>
Subject: Re: Packet number encryption
To: Victor Vasiliev <vasilvv@google.com>, Praveen Balasubramanian <pravb@microsoft.com>
Cc: "quic@ietf.org" <quic@ietf.org>, huitema <huitema@huitema.net>, Marten Seemann <martenseemann@gmail.com>
Content-Type: multipart/alternative; boundary="001a1140d9449d126c0564ce3224"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HsthfPRBArg6MGi8dnFIrPnqHnw>
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: Fri, 09 Feb 2018 21:27:44 -0000

I am very confused about the 1.25% number.  1280 bytes is about 80 AES
blocks, and one extra block is 1.25% on top of total *encryption* costs
(you don't have to MAC the PN, so that's even cheaper).  And the encryption
itself is fairly cheap compared to almost any other part of the QUIC stack
(sent packet tracking, ack processing, I/O, timers, etc).

This is for the large file upload case. It does not consider low latency
applications with small messages and separate cores for different
responsibilities. It also does not consider that that a single block costs
the same as 4 blocks on Intel, nor does it consider that the packet cannot
be decoded in-place. But yes, in the common large file download case, the
cost is not very significant. But it can be significant enough to choose
another protocol in other scenarios. So there needs to be a really good
reason to add this extra latency step. Linkability might be an argument,
and ossification might be too, and the complexity of alternatives might as
well. However, I’m not convinced. I’m also not completely dismissing it,
but I would like to see alternatives explored more thoroughly before
throwing in a cost for no good reason.