Re: [quicwg/base-drafts] Reference "Nonces are Noticed" in the header protection analysis section (#3031)

Martin Thomson <notifications@github.com> Mon, 16 September 2019 05:23 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2C1200FB for <quic-issues@ietfa.amsl.com>; Sun, 15 Sep 2019 22:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 1ImJPI_IGRPX for <quic-issues@ietfa.amsl.com>; Sun, 15 Sep 2019 22:23:52 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B04F12008C for <quic-issues@ietf.org>; Sun, 15 Sep 2019 22:23:52 -0700 (PDT)
Date: Sun, 15 Sep 2019 22:23:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568611431; bh=Rwckjkmka9DZCTXSkzz3CNQhy+dmD9NzDqCutRpwAWA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=upfgar3HolgZ9kDtzyq4AF53/UajlZzb7sA4nTGexSfibzCmttAsQibUggvO56R7h yUMxXwfdAsakECYYQv6+zGCjjaNWvyo9Uj2NQvT75LKGDicFKB+Ai2npwQgUBjfK9I SoRSkxnyAbEROWCI3rPd0YiXYE8LZF5oEUGrkqJM=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYW6DK6FUOL4AUG3LV3RRANPEVBNHHB22UPUM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3031/review/288407951@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3031@github.com>
References: <quicwg/base-drafts/pull/3031@github.com>
Subject: Re: [quicwg/base-drafts] Reference "Nonces are Noticed" in the header protection analysis section (#3031)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d7f1c675e445_49233facf44cd96c70517"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/tsWxyo9dm052zWy4y2zfGcryl68>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 05:23:55 -0000

martinthomson commented on this pull request.

I like the Nonces paper.  That validates a lot of what we have previously only theorized.

> -    date: 2014-11-06
-    seriesinfo:
-      ISBN: 978-1466570269
+      - ins: P. Rogaway
+    date: 2002-09-20
+    target: "https://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf"
+
+  NAN:
+    title: "Nonces are Noticed: AEAD Revisited"
+    author:
+      - ins: M. Bellare
+      - ins: R. Ng
+      - ins: B. Tackmann
+    date: 2019-06-01
+    target: https://eprint.iacr.org/2019/624
+    seriesinfo: Advances in Cryptology – CRYPTO 2019, pages 235-265

So this is not the same paper (the link references a full paper of which the CRYPTO 2019 piece was just a preview).  Not sure how to thread that.

Will the CRYPTO version have a DOI that we can use?

>      author:
-      - ins: J. Katz
-      - ins: Y. Lindell
-    date: 2014-11-06
-    seriesinfo:
-      ISBN: 978-1466570269
+      - ins: P. Rogaway
+    date: 2002-09-20
+    target: "https://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf"

This has the same property as the one below, except that you don't cite the proceedings:

> [21] P. Rogaway. Authenticated-encryption with associated-data.Ninth ACM Conference onComputer and Communications Security(CCS-9). ACM Press, 2002. Proceedings version of this paper

>  
 ~~~
 protected_field = field XOR PRF(hp_key, sample)
 ~~~
 
-This construction is secure against chosen plaintext attacks (IND-CPA) {{IMC}}.
+Assuming hp_key is distinct from the packet protection key, this construction

This isn't an assumption, it's a property we provide.

```suggestion
As `hp_key` is distinct from the packet protection key, this construction
```

>  
 ~~~
 protected_field = field XOR PRF(hp_key, sample)
 ~~~
 
-This construction is secure against chosen plaintext attacks (IND-CPA) {{IMC}}.
+Assuming hp_key is distinct from the packet protection key, this construction
+(HN1) achieves AE2 security and therefore guarantees privacy of `field`, the

I would expand this to cite {{NAN}} again.

```suggestion
(HN1) achieves AE2 security as defined in {{NAN}} and therefore guarantees privacy of `field`, the
```

>  
 ~~~
 protected_field = field XOR PRF(hp_key, sample)
 ~~~
 
-This construction is secure against chosen plaintext attacks (IND-CPA) {{IMC}}.
+Assuming hp_key is distinct from the packet protection key, this construction
+(HN1) achieves AE2 security and therefore guarantees privacy of `field`, the
+protected packet header. One important distinction between HN1 and the header
+protection construction in this document is that the latter uses an AEAD
+algorithm as the PRF. However, since the encrypted output of an AEAD is

I'm not sure that the distinction this middle sentence makes is relevant.  The definition of HN1 only depends on F being a PRF.  The existing header protection functions use a PRF.  We should probably say something about what it takes to define a new header protection scheme somewhere though.

>  
 ~~~
 protected_field = field XOR PRF(hp_key, sample)
 ~~~
 
-This construction is secure against chosen plaintext attacks (IND-CPA) {{IMC}}.
+Assuming hp_key is distinct from the packet protection key, this construction
+(HN1) achieves AE2 security and therefore guarantees privacy of `field`, the
+protected packet header. One important distinction between HN1 and the header
+protection construction in this document is that the latter uses an AEAD
+algorithm as the PRF. However, since the encrypted output of an AEAD is
+pseudorandom {{DefnAEAD}}, this achieves the properties desired from a PRF.

I don't think that you need to cite Rogaway's paper here.  We're not relying on the properties of an AEAD (the HN1 construction was, so it might be a little misleading to skew that direction).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3031#pullrequestreview-288407951