Re: [Cfrg] What is the standard we are going to apply?

David McGrew <> Tue, 24 December 2013 05:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A16D1AE427 for <>; Mon, 23 Dec 2013 21:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.439
X-Spam-Status: No, score=-14.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eqcd3IUPJEj for <>; Mon, 23 Dec 2013 21:56:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 70B5A1AE193 for <>; Mon, 23 Dec 2013 21:56:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2811; q=dns/txt; s=iport; t=1387864608; x=1389074208; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sskAcvETzF1LooAEnzVMVNZ6J72grpm97dYnieDwS5c=; b=UfaB3NtcrfwjdSneqZywwoZ+NwptVTmKg02Ip71qcGeN6o6tGCYzj81u t27m7kyppAx+RCPnfnyj9f3GJ2kAe7cJd0jcp13PvjClfy25hp+1Apn5D Nm6eWOojVMLcXsD5QCWcfVHOKE2Ze1gu6e+abJ021l5+b/t2mk8i6lZWw k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,541,1384300800"; d="scan'208";a="98768419"
Received: from ([]) by with ESMTP; 24 Dec 2013 05:56:48 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id rBO5uluM024403; Tue, 24 Dec 2013 05:56:47 GMT
Message-ID: <>
Date: Tue, 24 Dec 2013 00:56:47 -0500
From: David McGrew <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Watson Ladd <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [Cfrg] What is the standard we are going to apply?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Dec 2013 05:56:53 -0000

HI Watson,

On 12/23/2013 12:00 PM, Watson Ladd wrote:
> This is a different but related issue to that of the removal of Kevin.
> Simply put, when an IETF WG hands us a protocol to evaluate will we
> a) demand a reduction in the ROM
> b) demand a tight reduction in the ROM
> c) demand a tight reduction in the standard model+some signatures
> d) demand a reduction in the standard model+signatures
> e) demand ProVerif verification
> f) say "it looks good to us".
> I vote for one of a-d, and e if applicable. f appears to be the
> historic standard and
> has resulted in a litany of failures, from TLS cipher combinations
> that have side-channel
> attacks and worse, to IPsec catastrophically failing in certain configurations.

You raise some good points.   It would be a good idea to establish what 
proof techniques are preferred, and to have that debate outside of the 
context of any particular proposal.

However, there are other important considerations, such as: what attack 
model is being considered?  It might be the case that, for protocol A, 
we have case f) when side channel attacks are allowed, and we have case 
a) otherwise.   For protocol B, we have case d) regardless of whether 
side channel attacks are allowed.   In that case, I think I would go 
with protocol B, but could reasonably be debated.

Another consideration is: what computational assumptions are we making?  
If we allow an unbounded adversary, then we had better be using an 
information-theoretic secure system.   Of course, in practice, we will 
want to make some sort of computational assumption ;-)

> Cryptography is subject to the twelve networking truths, and to a
> rephrasing of one of them
> "certain truths in cryptography are only apparent to mathematicians".
> As a result I feel the
> CFRG should take a more proactive stance on being "the crypto people"
> at the IETF/IRTF, and should use this position to promote stronger
> cryptography with better guarantees than what
> has existed so far in the IETF.

I am glad to hear your enthusiasm, and let me suggest that the best 
first step is to build and document consensus within our group.



> After the work of Kenneth Patterson it is clear that those of us who
> are cryptographers absolutely need to participate in the standards
> process with an aim of ensuring that the most important cryptosystems
> in the world are secure. Let's treat TLS like millions of dollars,
> billions of confidential emails, and tons of confidential information
> are entrusted to it daily, because
> that is how it is used.
> Sincerely,
> Watson Ladd
> _______________________________________________
> Cfrg mailing list