Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts

Paul Wouters <> Sun, 10 March 2019 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 931A6127968 for <>; Sat, 9 Mar 2019 18:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3yolnBQd1iUx for <>; Sat, 9 Mar 2019 18:47:08 -0800 (PST)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFF9A1275E9 for <>; Sat, 9 Mar 2019 18:47:07 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 44H5HF5W7Hz20h; Sun, 10 Mar 2019 03:47:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1552186025; bh=Rp6VNcxzgOt2SfhJKZhfoM+dpu16eb3RXAwrs5OG6V4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MnontxGCl6gqSsmhk6suAv3Q/rBhRTMU7SeUGrWn28wNQG/7yjdnaCl27k2zRxJnF rt+Lioa56FpIugNajqZGutlfBPGH++eFAcblWAeM0lW03miwNzBCTzOjd8Jfz267r0 dtBKAhltlMDQer6MQiTg7XPZ4XJ4CF1FicFTOXVE=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id m-Tpa1_v6AEX; Sun, 10 Mar 2019 03:47:04 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sun, 10 Mar 2019 03:47:03 +0100 (CET)
Received: by (Postfix, from userid 1000) id 81F095E4BAB; Sat, 9 Mar 2019 21:47:02 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 81F095E4BAB
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C3B14116028; Sat, 9 Mar 2019 21:47:02 -0500 (EST)
Date: Sat, 9 Mar 2019 21:47:02 -0500 (EST)
From: Paul Wouters <>
To: Tony Arcieri <>
cc: CFRG <>,, "RFC ISE (Adrian Farrel)" <>, secdir <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Archived-At: <>
Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Mar 2019 02:47:11 -0000

On Sat, 9 Mar 2019, Tony Arcieri wrote:

> Here is the specific wording he is suggesting:
>  "Phillip Rogaway offers a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant
> implementation of any IETF standards-track protocol supporting AES-OCB (RFC 7253)."
> I think he's looking for guidance around how to properly phrase that if anyone has a more concrete suggestion for how to put it in the
> form of an IPR statement.

While this phrasing would solve the issues for some protocols, such as IKE
and IPsec, it is still a request that the IETF publish a cryptographic
standard that cannot be freely used. The IETF normally does not do that
unless there are exceptional reasons to do so. It would be good to see
thse reasons written up for evaluation.

It would be problematic too if someone using an RFC wouldn't realise
their use of this standard would be in violation of Mr. Rogaway's IPR.

I also believe allowing OCB for only TLs in the past was a mistake we
should not repeat in a slightly different form by covering a few more

Note also RFC 3979:

    Over the last few years the IETF has adopted stricter requirements
    for some security technologies.  It has become common to have a
    mandatory-to-implement security technology in IETF technology
    specifications.  This is to ensure that there will be at least one
    common security technology present in all implementations of such a
    specification that can be used in all cases.  This does not limit the
    specification from including other security technologies, the use of
    which could be negotiated between implementations.  An IETF consensus
    has developed that no mandatory-to-implement security technology can
    be specified in an IETF specification unless it has no known IPR
    claims against it or a royalty-free license is available to
    implementers of the specification unless there is a very good reason
    to do so.

As the IETF has been moving towards reducing the number of algorithms,
it would not make sense to promote a new algorithm that can never become

Maybe it would be good to involve the IETF Trust in this matter?