Re: Packet number encryption

Christian Huitema <huitema@huitema.net> Fri, 02 February 2018 02:49 UTC

Return-Path: <huitema@huitema.net>
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 2EC5A12EBCB for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 18:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 DNwQ5oTHQA4R for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 18:49:22 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AA712EB91 for <quic@ietf.org>; Thu, 1 Feb 2018 18:49:21 -0800 (PST)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ehRPh-0003gT-UI for quic@ietf.org; Fri, 02 Feb 2018 03:49:19 +0100
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ehRPb-000814-Dg for quic@ietf.org; Thu, 01 Feb 2018 21:49:15 -0500
Received: (qmail 14316 invoked from network); 2 Feb 2018 02:49:09 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <martin.thomson@gmail.com>; 2 Feb 2018 02:49:08 -0000
To: Kazuho Oku <kazuhooku@gmail.com>, "Eggert, Lars" <lars@netapp.com>
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>
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <e8cb7288-2d32-2677-e1ca-bf05a3f1968e@huitema.net>
Date: Thu, 01 Feb 2018 16:49:08 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CANatvzwoih1zXo6iG3XL=xM3xmN-QX_fiSb5wBBUdmdr926URw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: Packet number encryption
X-Originating-IP: 168.144.250.234
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: ham
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.07)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5jpcmxYcSIkO6d0SRLt7mL0Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvdNbTVhHPV9J4dajz1aY/nB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS+C+me6dA6yBk+me OMe0W22n/kFi61SvDQh5XsjlapMvoZNAifNUgo2DcM4YtKVx9MMCOkgYBX58rqmjkeHDbS4kHaox hC4vjXqQZhHVp33bdA4PSvr8BodmIS11My0yWMx0Hcdm1lHSqdVK8QtbVazR2PDNKbWhLn7g2aSz CwEE5YE5enyccp7RH4WQio3uGTAwyjhRzXq9E3eaUXDCvLdWBb39uS1TjWG2Inx+Ts2Q6HPPLuOV zXiNlBYhGfdaOhRAKfWK48mqxd1pWN6R4o2HeieqAXh0r0nzc7RP95mM7ZWatoIKNF2f2G/5/Amz e6+9leQc+iFUvWoHPKlvO6wHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFNWyKkmH5fSq8aOwg6myHV8ibYT4C2qF2lnc18bVJn66R tTJ2QXCFHiUb4d5gX2qGZlKV//LDlCDTFxiJUKFQqDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTlW6glWwcZMx8scB+2xXkSFjI1dRH6f16eQCtvwPkeoyZ+pdPqFUnGuNg304AKeRgl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/97x-5rjKQ_y_9QN2DixpBrrJDDM>
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 02:49:24 -0000


On 2/1/2018 2:56 PM, Kazuho Oku wrote:
> 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.
>
> When using OpenSSL what you need to do is:
>
> * 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.

+1.

By the way, I wrote a small test vector for the PN encryption using AES,
at
https://github.com/quicwg/base-drafts/wiki/Test-vector-for-AES-packet-number-encryption.

-- Christian Huitema