IETF Logo Mail Archive

Re: Packet number encryption

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 02 February 2018 12:24 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 D4EEB12D7E4 for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 04:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 XZ-a8YfX_kRl for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 04:24:20 -0800 (PST)
Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F43129C6B for <quic@ietf.org>; Fri, 2 Feb 2018 04:24:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zXx4K2tGrz15N3y; Fri, 2 Feb 2018 13:24:17 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch
Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnAzGJLl8zRn; Fri, 2 Feb 2018 13:24:16 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.178.33] (i577BCE83.versanet.de [87.123.206.131]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 2 Feb 2018 13:24:15 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Packet number encryption
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CANatvzwoih1zXo6iG3XL=xM3xmN-QX_fiSb5wBBUdmdr926URw@mail.gmail.com>
Date: Fri, 02 Feb 2018 13:24:14 +0100
Cc: "Eggert, Lars" <lars@netapp.com>, Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9586DED-4A7B-4C7C-98BB-711610530A73@tik.ee.ethz.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> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <CANatvzwoih1zXo6iG3XL=xM3xmN-QX_fiSb5wBBUdmdr926URw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LkSuDRyGvr279AF9nTM0D1_Imv0>
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, 02 Feb 2018 12:24:23 -0000

Please see below.

> Am 02.02.2018 um 01:56 schrieb Kazuho Oku <kazuhooku@gmail.com>:
> 
> 2018-01-31 19:00 GMT+09:00 Eggert, Lars <lars@netapp.com>:
>> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>>> +1 - Simply: This *is* complicated and seems to add little.
>> 
>> So as an implementor (chair hat off), this adds very little to the overall complexity of the protocol.
> 
> +1
> 
> The algorithm defined in the PR is easy to implement.

I didn’t say that it is too complex (I actually explicitly said in my original mail  it is not very complex) but it adds additional complexity to a protocol that is already complex and doesn’t provide much benefit from my point of view but can be an additional source for errors. After all it must also be possible to implement QUIC if you just read the final specs and have not participated in the wg design discussion or can easy ask a clarifying question on the list.

> 
> When using OpenSSL what you need to do is:

If you don’t want to use OpenSSL or are in an environment where you can use such a library, it is definitely more complex than this.

> 
> * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a
> CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key
> passed as the argument.
> 
> * for each packet, call EVP_EncryptInit_ex to set the IV to the 16
> bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain
> the encrypted packet number
> 
> Decryption is exactly the same as encryption, since it is CTR mode.
> 
> To me it seems that using packet number encryption actually simplifies
> the implementation, since we no longer need to care about randomizing
> the initial packet number or implement special measures to avoid
> linkability when switching to a new CID.

Choosing a random number is definitely less complex than encrypting something. It might simply your current code because you are using a library that implements the complexity already. And special measures when switch to a new path are needed anyway for the CID.

Mirja




> 
>> Lars
> 
> 
> 
> -- 
> Kazuho Oku

v2.23.0 | Report a Bug | By Email