Re: Forgery limits in QUIC

Matt Joras <matt.joras@gmail.com> Fri, 01 May 2020 20:10 UTC

Return-Path: <matt.joras@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 AF9433A1BDE for <quic@ietfa.amsl.com>; Fri, 1 May 2020 13:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 lyipj4fL809Z for <quic@ietfa.amsl.com>; Fri, 1 May 2020 13:10:45 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 B09E43A1BDB for <quic@ietf.org>; Fri, 1 May 2020 13:10:45 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id n207so2987198vkf.8 for <quic@ietf.org>; Fri, 01 May 2020 13:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PjyY/JEZlEaDeN26cddjKwdDhC84T9oZVOHiqguVz6M=; b=tpVdNNc12dllPuIzCqWQEkThkOFwBkibmfiGBFsgwUae2RVFSxAE4ejOiHJGkD7NPk lUG3GJsVgRzZWTu/dgwMrGbbMI1YThfTSWjwOi49eU3JIdOKpcv3XlsieGR3k2xMB77+ zuRyLK1qdIBFcp5YRnzOEDaXXcTenmzu0J/4eNccXfPqhsY2auuhtyxWOFbHtTWhe8hw NKRQzEsdwuuIBXwZbXYPZXNe7DV52lncP7+B0iL/xGNTn46EIlSaTKXQu7gpA4oOa7oW F4keU+UOj8vHRde6QVUmC0lbdCZzJtg6rqiYz39iipeN5/Um4y2LsnnJE4k+/5T7MpXu K1Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjyY/JEZlEaDeN26cddjKwdDhC84T9oZVOHiqguVz6M=; b=dGd/ZR/9l4i6BwMe9+QnXinlZDcAmXVNyiJ5iGRM/Gpu1y9GQsYpbeqFxtJixSZKvF /9Z+rnWZn14vwQzyprLwLSSEU5lxLWaMSJKlreQmfS8z+AamZ425uXJWq+2QHsmt44re Zj9AkO3yAFkfv0cI09boTfBLlEtjVi3eNjfj+D4+A1lSsc6dGIUnNiRTsKDw5oOxcHzX XJ6b8fgqLspHWNWPS3cBoIHMYFC6VcnL8qXFzc9i5klqQGq/Rk/3LSGceP0ysJVPMgXb eDF6B7xEhybboBPSyk4q2n7bHIoEczhjfXyi+GCKiOda+Su31sUs++rNV27kxSFUeHTr 7tfA==
X-Gm-Message-State: AGi0PuZsQWCxzVWXRbODrowa+MXHq7MHQQQKBxplqYr49kDKHidlA7MN 7uzYxJuhwxAxvR+4O9Y54YeGS3sKFKAs60aI4HEwSa3e
X-Google-Smtp-Source: APiQypJSy3gQjXjo0ET15xberY/fJnd6iv98qBnMjXS6HLvgZDbDNJbvkkD2GzAtIlBlkLCHAjw4jT9n143w64JLZEk=
X-Received: by 2002:a1f:3190:: with SMTP id x138mr4100959vkx.41.1588363844471; Fri, 01 May 2020 13:10:44 -0700 (PDT)
MIME-Version: 1.0
References: <c32379cb-43c1-4db8-9f0a-b7294085dd6d@www.fastmail.com> <d7f385d4-b6cb-4565-ba35-4c096239fd34@www.fastmail.com>
In-Reply-To: <d7f385d4-b6cb-4565-ba35-4c096239fd34@www.fastmail.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Fri, 1 May 2020 13:10:32 -0700
Message-ID: <CADdTf+jMUfoNsXcBD_-cVN0JhH4X8ESUyi91N9q6mx-m8iy6QQ@mail.gmail.com>
Subject: Re: Forgery limits in QUIC
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b94e8b05a49bc644"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_hFX33RhVaH1Lm46fxTDzCkYJUw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 01 May 2020 20:10:51 -0000

On Thu, Apr 30, 2020 at 11:15 PM Martin Thomson <mt@lowentropy.net> wrote:

> OK, I thought this would be easy.  I was wrong.  But it still might be
> easy.
>
> The draft currently defines four AEAD functions.  We have a good analysis
> for three of those functions.  We lack an analysis of the last.  That is
> AEAD_AES_128_CCM.
>
> It turns out that we never really had a good analysis of CCM.  TLS 1.3
> conveniently fails to say anything about it.
>
> My suggestion is that we remove CCM from QUIC until we have an
> understanding of its robustness against confidentiality attacks with
> multiple successful applications of protection AND integrity attacks with
> multiple forgery attempts.  We need to base our recommendations about
> limits on something more than what we have now.
>
> I realize that this is a fairly dramatic change, but I think we need to
> hold our ciphers to a high standard.  I will attempt to find an analysis
> myself, as I would expect it to exist, but I have a poor history of success
> finding the right cryptographic paper.  If anyone is able to provide
> pointers, that would be appreciated.
>
Is it actually a fairly dramatic change? The supported cipher suite is not
a huge consideration for us, and I would guess this is generally true.
We've only implemented AEAD_AES_128_GCM and AEAD_AES_256_GCM. Perhaps this
is more of a concern for those wishing to ship embedded stacks, since AFAIK
CCM is nominally simpler to implement?

Removing it seems straightforward unless someone was has a good reason to
want to ship CCM specifically.


> On Fri, May 1, 2020, at 14:45, Martin Thomson wrote:
> > I have just opened https://github.com/quicwg/base-drafts/issues/3619
> >
> > tl;dr We need to recommend limits on the number of failed decryptions.
> >
> > I am now working on a pull request to add this to the spec.
> >
> > I realize that we're nearing the end, but this is an important security
> > improvement and the result of some good work by cryptography
> > researchers, who have done a lot to improve our confidence that QUIC
> > can deliver on its promises of providing confidentiality and integrity..
> >
> > A big thanks to Felix G√ľnther, Marc Fischlin, Christian Janson, and
> > Kenny Paterson for their work on this.
> >
> >
>
>