Re: Packet Number Encryption outside of AEAD

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 27 July 2018 07:02 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 977D5130E21 for <quic@ietfa.amsl.com>; Fri, 27 Jul 2018 00:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 6e6Z70Mqn7dF for <quic@ietfa.amsl.com>; Fri, 27 Jul 2018 00:02:48 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 5B037130DEC for <quic@ietf.org>; Fri, 27 Jul 2018 00:02:48 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id s7-v6so6249030itb.4 for <quic@ietf.org>; Fri, 27 Jul 2018 00:02:48 -0700 (PDT)
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=p60NrcnjN9R3PE0JOM6Zo6lbGOyPOtdbkPJwBf3m3fs=; b=gYilaMEJIrekeXVR1z7IW4emyaP2vDeCTTW++1Bcs2dkDzCsxMyQhNy0lHMXiFCjxe mr/Fadhi6yJ1X5R3fXvsyCxP6ZyPf0yZHX5l4rtvzkvyejZLvfQ2v0N67Mx7WasLyRO+ M4oe7WD/R2rFUoUTKVxRt0w1spdUIUmUM6MrZPP2ceHj/CAWxxjtkyTab5BVTOH6WPUh hKjeeZHNUiHvobcHquOg/aGlqa5eZ7rayNY+y9ErlnniHg5mK/nQuZcJvvd5pqzJRPM1 nxd76V+ZzPNHEtslmJTN2aR9zseu6Nu/hHFvglld2o97mGG6/p+fdSYQeX9+3xPoH6bk j8Fw==
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=p60NrcnjN9R3PE0JOM6Zo6lbGOyPOtdbkPJwBf3m3fs=; b=eSgYSam5uLsvz/4HCu5FLMbBhxF+/xsU60YPg1y/mIjWrxksTso14SI9JNgbmWSQRe pa9ne5XrT382r0Xh3SimgMpLbl8uDNWNGGGB3OPVFx95L1fj5511vz9KocQcW8xsfxgt dLWS/Z6IKDuiKp0DuSbS9g2ssJ6eHsiIQXtFXL00VDq9fTyZFxBlVkzrcy0+g6jwB11g R6dQ0KTfR7qwf0D1i+uXpUCqf+iZsDOjI2fC/EY0xhoN9QWKBih7BmYCbq/ntqaGzXfR EPXC/ayiuYy1I5CGlSsI083N3oUYshJI99ugUxAM5tQls51jZ7lFPw7d0Maw81fEK5sX Ebyg==
X-Gm-Message-State: AOUpUlE/dhppBxGnWpl3G4u7Q+VA5B76bwa6XZW0OkS4ibY+S7Z+bM+4 JbxgM4xngX+7OyYlByvjzc3e6Rs+WJ2xSohxAfARFw==
X-Google-Smtp-Source: AAOMgpenr2s3BMzM+pfuCQ79MvnzhIC6nihiutWkAc81dd/oWTjCj7fq3ugWMPeC6jBi4+t3J0jviz3vulPP6f744x0=
X-Received: by 2002:a24:5e0b:: with SMTP id h11-v6mr4509498itb.80.1532674967789; Fri, 27 Jul 2018 00:02:47 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 27 Jul 2018 00:02:46 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CANatvzzMhYowiCCCz+_q+zT6LYRjDa9ru33G-tcs44G8r8cBjg@mail.gmail.com>
References: <CAN1APdcCdPGVEHJh4FiQBirunHUxY7HV_idYPtyQT09Fe-fSUw@mail.gmail.com> <CANatvzzMhYowiCCCz+_q+zT6LYRjDa9ru33G-tcs44G8r8cBjg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 27 Jul 2018 00:02:46 -0700
Message-ID: <CAN1APde8DsAkH-APdxneg-zyzgpfSDiOPtTvJDYEtmqM=iTxfw@mail.gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002e3c30571f5b327"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/liYXokouXRLTS0aMZJYKrGCDak0>
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 07:02:51 -0000

Yes ideally you should include the packet length in AEAD, which of course
is the case already for long packet headers.

But on the other hand, it is widely accepted in cryptography that is is
safe to send the IV in clear text, and if isn’t, something else is wrong,
so from that point of view there shouldn’t be any dangers. Still it is
mildly disturbing that a verified tag does not correspond to single packet
size.

AES-GCM already includes a length in it’s tag, but it does of course not
cover content it does not include.

I’m not sure if it is reasonable to require a PN always being sent with the
shortest length possible, but it sure would save space on the wire.

Mikkel

On 27 July 2018 at 06.14.16, Kazuho Oku (kazuhooku@gmail.com) wrote:

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