Re: [Cfrg] CFRG Review Panel - Draft Charter

Aaron Zauner <> Wed, 11 May 2016 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8388312D195 for <>; Tue, 10 May 2016 23:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aKmJlQDtcBZQ for <>; Tue, 10 May 2016 23:04:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F23B712D145 for <>; Tue, 10 May 2016 22:58:51 -0700 (PDT)
Received: by with SMTP id r5so14388195pag.1 for <>; Tue, 10 May 2016 22:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=+ui32KwrePSBXS44Z6TI/I5VVmKvWO277IrzJvslD0g=; b=JfaYQqGea7qJUvcqF3dzJHGqC0UMGs6WnyI/E+lDckYE9Rc60acqc89NGzHXFeMy7z /HFI0NIUzbyUwiSI/XRiWU8BukM8iGZPGaYvaHkOYn1tOaBFHZ6Ri62ra3kNz9vkRgIt XHAGKtD5oODJplmw/JPDJd8mMnxQvb0LHrVKo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=+ui32KwrePSBXS44Z6TI/I5VVmKvWO277IrzJvslD0g=; b=IqyMGRXQYMTvmMGmbnnhUJzD0IyRCw5PvRwuDezEUKl0E7StcdbN95oU7qXivY9Lgv PaP6M/oqmtwWT/Zh4NWXgWJDCmvvDdiqgR/4dLSkk+u2K5WveYn8Wmu3IHfbmSmFDHj2 jNsIBtuxV61bkNslJlt6makL3dBN295B1hbPwANFdq5OX930KC/sAbHTd/XBVM5UL3y/ /TT+QksPBnedFOwmODN+Tqa6x0BrcvyL6K468YcMxYOFO9xKFYjWkCLWgVy2jIFK4eGp lMroLDGeFFUMqg3HABrYv0PNcfEFcn1sDGo7v9vA+WBslINt256957TqAPqm6FUwn18a +7Vw==
X-Gm-Message-State: AOPr4FU9he0HxQcpsyp+tjSqxuRuYGsu2lpmVFGa+pa7g3dvpynS1YibCaYpl+OLWwXCCQ==
X-Received: by with SMTP id kn6mr2079198pab.33.1462946331562; Tue, 10 May 2016 22:58:51 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id x89sm8690426pfa.87.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 22:58:50 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_5530231A-E358-477F-AE7C-3EA29B820EF2"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Aaron Zauner <>
In-Reply-To: <>
Date: Wed, 11 May 2016 12:58:46 +0700
Message-Id: <>
References: <> <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Resent-From: <>
Cc: "" <>
Subject: Re: [Cfrg] CFRG Review Panel - Draft Charter
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2016 06:04:45 -0000

> On 11 May 2016, at 03:14, Yoav Nir <> wrote:
> But nonce reuse doesn’t happen in many of our favorite protocols: SSH, TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of those, or at least no better than regular AES-GCM. I’d like a review to tell what kind of protocols or use cases might benefit from an algorithm with this property, such as multicast IPsec with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.

Full disclosure, since this is somewhat public by now anyways: It does happen in TLS. The chairs received an abstract on a soon-to-be published paper in the matter late yesterday as did Stephen Farrell (as you're aware you're not affected :)). One of the chairs has a full working copy/author version including PoC code for our attack.

To that extent may I ask the following question: with proposals like AES-GCM-SIV, should I press cryptographers that initially submitted to CAESAR to submit drafts to CFRG, fill up everyones pipeline and get CFRG into dead-lock? How do we deal with that problem? How's CFRG better/different for IETF than a proper crypto competition (even if some take ages, or seem to be a never ending story).