Re: Packet Number Encryption outside of AEAD

Kazuho Oku <kazuhooku@gmail.com> Sat, 28 July 2018 12:35 UTC

Return-Path: <kazuhooku@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 DCB8D130F36 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 05:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 tejOVzKDQ-0O for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 3E952130EDB for <quic@ietf.org>; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id j19-v6so6661584ljc.7 for <quic@ietf.org>; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
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=a19U3jSemwzpgCupG/UnP8G1PEvi0LfhxTbPA3Uqu3A=; b=Z7pFEoXhANgl+yYhTmMlyJyFr/gVA4t7MVBq+25SMp6N6ct0RxoECrWTbFPCIaGqKq istvxhFahmq9YtNqfWVa0aSJ07ETr3yIoi9WiBjrP8p3e3CzrL9sC5xE0IJi4d38EcNs hcRbONKz49cj0LRfCu4WRjuVfFnvB3LP6YVX7IOryVoCvhUHZvCoGRZ9NzIRIV0vymmH ndDYzeS20rIZceaFLjjbPJx1tvsb6gKKEvObaHuRKc7CqJOzJcBnGfVz5C24zEMWzX94 4yu9hh1HVxU3WL99gutf9Bb7bhcThEo1nB8QtIKf/YAeegFDKj07eKXvS7HuG/p2NtOM or+Q==
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=a19U3jSemwzpgCupG/UnP8G1PEvi0LfhxTbPA3Uqu3A=; b=qaHD03i/7xXImGZVohvSuqi8bO/Y9SzBrToTtFARZJU2Yz5gPh/bt0mvFshNHFD56h SnV1QtcgJ9NEUsFJb3nhQ9VHk5a3YKvtqihr4xF7GEySvFrEeB8ctdeb9IoMS0F3F3r1 093d8dtFfYr71PeXDaGulYl0fwN1O/SNlRkht2UHYrIFFJVR5rby11kvIP05n7D6qtno d82/04XGDSzd6ucDCRtToGk3kOGqJv/sGtfOpqlvDOcQfsl43hm7V0wKHQ/F1egVow91 f70VOE2pl0WVtaeHlwwH/Yx9INRSGpXMLRLrojSxFJtXE0CgAjxgsYh96R1rSxziotQF +c3A==
X-Gm-Message-State: AOUpUlGkEKTsHqFiqTnTnbUQww4vXNdkCWuk6HBYxugnwabexkueWZyj 9mAUzYmcqg/JmQFN5Q6fkSbLvSBMGgNibuDjsJ4=
X-Google-Smtp-Source: AAOMgpcyLGCA3KXq5Uf882ZvjPn1QUvbT/c1WmcH3nSTVhHV2XMofFHgFC+rNiPGWfRTZ1o5Qy3ND3eKEfi8OIhdh9I=
X-Received: by 2002:a2e:4e02:: with SMTP id c2-v6mr7471931ljb.108.1532781307469; Sat, 28 Jul 2018 05:35:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 05:35:06 -0700 (PDT)
In-Reply-To: <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
References: <CAN1APdcCdPGVEHJh4FiQBirunHUxY7HV_idYPtyQT09Fe-fSUw@mail.gmail.com> <CANatvzzMhYowiCCCz+_q+zT6LYRjDa9ru33G-tcs44G8r8cBjg@mail.gmail.com> <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 28 Jul 2018 21:35:06 +0900
Message-ID: <CANatvzwRG4i7XDtqOgwLYT+DiwLjXsvDOeSQxQiNHAyXRY8V-A@mail.gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
To: Christian Huitema <huitema@huitema.net>
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/e3eXw1W2Ul_GmQapEAfpua5mcRY>
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: Sat, 28 Jul 2018 12:35:11 -0000

2018-07-27 22:43 GMT+09:00 Christian Huitema <huitema@huitema.net>:
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.

I do not see how the issue relates to the endianness.

Consider the following case.

encrypted PN + payload: 46 5f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f 10 11
AES-CTR mask for PN: c5 5c

The PN field after decryption is 83 03. IV used for PNE is 02 03 .. 11.

Attacker applies XOR 0x80 (to change the PN field length from 2 to 1)
and removes the second octet.

The modified encrypted PN + payload becomes: c6 00 01 02 03 04 05 06
07 08 09 0a 0b 0c 0d 0e 0f 10 11.

The PN field after decryption is 03, and IV used for PNE is 02 03 .. 11.

In such case, the receiver will successfully process the modified
input if the PN was expressible using one octet, thereby leaking the
fact that the first 6 bits of the 16-bit PN was equal to the least
significant 6 bits of the PN and that the 7th and 8th bits were zero.

Admittedly, this attack relies on the fact that the frames contained
in the packet are 2 octets. But I am not sure if this is the _only_
attack that is possible.

Am I missing something?


Besides, note also that the proposed change will prevent us from using
the PNE key to encrypt other information. For example, in #1322, we
have been discussing about how to protect the key-phase bit. It seemed
to me that we were leaning towards encrypting the key-phase bit using
the PNE key. That would no longer be possible (or lead to other
security concerns) if we adopt this proposal.

>
> -- Christian Huitema



-- 
Kazuho Oku