Re: Packet Number Encryption outside of AEAD

Kazuho Oku <kazuhooku@gmail.com> Fri, 27 July 2018 04:14 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 85177130EA6 for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 21:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 btOF5y0NrSMw for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 21:14:17 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 2BEE1130EF4 for <quic@ietf.org>; Thu, 26 Jul 2018 21:14:17 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id n96-v6so2636475lfi.1 for <quic@ietf.org>; Thu, 26 Jul 2018 21:14:17 -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:content-transfer-encoding; bh=0Tz9p9oDrAR9prjM7I5yrENUV0rsbpVWeUGLWjQikJI=; b=Prz1Rnrbc8gOOXbuVegC5A808nDoW74xYy6MYiutoCqrKD+EV+udXpy+RCO+x2D+vE 273Dsa6jv+NgdkYSa8pGsDI1BkOUbgODOsBFnGO70zPquqg48LbQLRsrG4BgHxPWt2i0 a2BYCZ59ilU+iIZTPT20GY32kkS97T9u2TXCvPuI+/y9YTUe2YmTVPcBffk/Pj0j3BYb 09YWPYLV7GOxBKpwMm67ctiGTjsDV4ZIQrVKrKC6oTYU65hMbvrqubKQbutQDfyiPwQ5 WS3Au14RLpFtsqxsXVRGQqSESUi6wSOX/KalCcBg2ub+6RG2L/Xv49WmQTTuuWaXvuG8 ooaw==
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:content-transfer-encoding; bh=0Tz9p9oDrAR9prjM7I5yrENUV0rsbpVWeUGLWjQikJI=; b=Ol2X24C5fevmjeptwMHk6z7KXO1PeF19nc/SCkZhZG39aWG8hoa6IXtAMbQBbg4AXu QQOn8FKq3Z6xijyqkUDEuWB5kkJT916zeg2WjLrKZiF5TmyXYInfBlj/7MuRwTc2ukPR Jo7F+nV5MTOlzFkEhfB77CJHVy6Te/gLkE7nBKmQ6R2Kbq0De1fqBYgyo+tLDg5W/k29 QRP55HcfitOtimB+lVgChlQnGKPtqXHNjE+EEWFrDg4fLeBlRRRyRz6kRDf3Nthzw/Hx I1lzeK6bic7go04r66zHv++sq28k7NfmEimbZcY5AeJgn4xJImknrUZu8DfkwIhCx2/N tEQg==
X-Gm-Message-State: AOUpUlF/D2iR9m7fKnsgxqrVfxtbS4k/2Yi8ifk/gyLVsHRxswvQhV+L DJH5Id07VUbyjv/NGfE9t6k1wIAQV/ZLBYSqzYU=
X-Google-Smtp-Source: AAOMgpc91DkZHczr1TqEMq4LxdaSx//1NOnvCcPd+gQIBrw3gNWWVlKoaLU3vlBKzVM0c3vY/8T29XYrDHOlKili4Kc=
X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr2741093lfa.81.1532664855402; Thu, 26 Jul 2018 21:14:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 21:14:14 -0700 (PDT)
In-Reply-To: <CAN1APdcCdPGVEHJh4FiQBirunHUxY7HV_idYPtyQT09Fe-fSUw@mail.gmail.com>
References: <CAN1APdcCdPGVEHJh4FiQBirunHUxY7HV_idYPtyQT09Fe-fSUw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 27 Jul 2018 13:14:14 +0900
Message-ID: <CANatvzzMhYowiCCCz+_q+zT6LYRjDa9ru33G-tcs44G8r8cBjg@mail.gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/k2H_0ReSSZnDG8-i7KNfNsZqEBk>
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: Fri, 27 Jul 2018 04:14:29 -0000

2018-07-26 15:21 GMT+09:00 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>:
> I created the following issue a while ago but go no response, so perhaps it
> should have been discussed on this list:
>
> https://github.com/quicwg/base-drafts/issues/1578
>
> The issues covers the point, but in summary:
>
> If the packet format is kept as it is today, but the packet number is not
> included in the authenticated data when computing the AEAD tag, then the
> decoder need not modify the received packet buffer when decoding the packet
> number. This can lead to more efficient hardware implementations and make
> multi-processor buffer sharing more effective.

I am not sure if this is a safe change.

What makes me worried is the fact that we will now have at most three
ways of representing a packet. My understanding is that having
indeterministic encoding is considered dangerous in crypto.

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.

Then, the attacker can observe if the packet is successfully consumed
by the receiver, and use the fact to infer if the upper 6 bits of the
30-bit PN was equal to the least 6 bits.

I am not sure if this attack is interesting, but allowing multiple
representation does create these kind of attack vectors.

>
> Mikkel



-- 
Kazuho Oku