Re: [Cfrg] NSA sabotaging crypto standards

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 06 February 2014 19:29 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1356F1A0420 for <cfrg@ietfa.amsl.com>; Thu, 6 Feb 2014 11:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 NOeYxQmN-mry for <cfrg@ietfa.amsl.com>; Thu, 6 Feb 2014 11:29:21 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A63E61A045C for <cfrg@irtf.org>; Thu, 6 Feb 2014 11:29:20 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s16J9BBU083243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Feb 2014 12:09:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CACsn0cmFpQEBbv=3EWvUff3EnNuuiqyzjJqFR6Dy97VjLREVVg@mail.gmail.com>
Date: Thu, 06 Feb 2014 11:29:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7217D26-4D5B-4115-AF7D-48FB82FABE50@vpnc.org>
References: <20140203192451.6268.76511.idtracker@ietfa.amsl.com> <7af2f9df96e5867d493c614806235363.squirrel@www.trepanning.net> <CACsn0cm1f-P95je5AbEbZ02Ut3+HM7Hx28P6j46TqE-=06eZDg@mail.gmail.com> <52F00EF3.3040505@cisco.com> <CACsn0c=zS5GKex3eF_hKgTsL1kH=TiBi3iAP9oMrJ9hDQcT4Gw@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B81B7DE5@SC-VEXCH2.marvell.com> <CACsn0cn0TaHsDkyN2ewOorxxBzXivCg=QGR-ZnBiC3nJhvhpRg@mail.gmail.com> <14AB44E0-4C90-4E4C-A656-885A31CF4C02@checkpoint.com> <CACsn0cmDT-FAN8uMZ0w8TX6GKPAZjnrexLeFQd7QhRfoY6AGFQ@mail.gmail.com> <75e1e853dc391b418062ee5e51adeb2f.squirrel@www.trepanning.net> <CABqy+sr7ZKrACj4Ga2_75d9Kea0aKbrp2P5fWWu4YZP53zijxw@mail.gmail.com> <CACsn0cmS152wYQWHiX8ykzaMM=6b=r=fwVuLfPj_u0wmoq0jKw@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B81B7F7C@SC-VEXCH2.marvell.com> <CACsn0c=a5PvZOZgVRjHaJ2avGCPHF6b6nOpNh+iT0909X-jUFA@mail.gmail.com> <52F23D52.4090509@cisco.com> <EFA9E215-3B01-43C6-A8F0-3F98E3ED2E26@netapp.com> <3E30D764-7E19-45DB! -9D6D-63949F5B36CB@netapp.com> <255B9BB34FB7D647A506DC292726F6E1153AE65F2E@WSMSG3153V.srv.dir.telstra.com> <570B8BE5-1362-4D08-A22D-FE86FC4A77DC@netapp.com> <CACsn0ckm95r4x7VBrW81+f7Resf7RcS6iOBPx3yqu9m1VuELhw@mail.gmail.com> <6F8C22FA-B968-4B3C-8A8D-C24F1DFC5021@vpnc.org> <CACsn0cmFpQEBbv=3EWvUff3EnNuuiqyzjJqFR6Dy97VjLREVVg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] NSA sabotaging crypto standards
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:29:22 -0000

On Feb 6, 2014, at 11:10 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Thu, Feb 6, 2014 at 10:48 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> On Feb 6, 2014, at 9:00 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>> 
>>> IETF working groups will follow suit if they see that some new
>>> protocol is documented by the CFRG.
>> 
>> Can you give examples of that? Having been active in many IETF WGs for 15+ years, I can't think of one, but I could have forgotten some.
> 
> Dragonfly in TLS was the first time this happened.

Sorry, but that is wrong. Dan Harkins brought it to the TLS WG long before it was considered by the CFRG.

> Had Rene Struik not
> noticed that CFRG hadn't done anything, life would be interesting.

Life is always interesting. :-)

> My understanding was that CFRG existed so that IETF WGs without
> cryptographers could borrow some temporarily from us.

I hope Lars' repeated messages about that have disabused you of that notion. There are lots of cryptographers in the TLS WG, the IPsecME WG, the defunct S/MIME and OpenPGP WGs, and so on.

> That's what the
> HTTP
> auth people are doing, and what TLS did with Dragonfly.

It is incorrect to state that the httpauth WG and the TLS WG have no cryptographers.

A different view, one that we rely on in the IPsecME WG, is that any time we're doing something "interesting" with crypto, we alert the CFRG. Almost all the time, we don't hear anything back, so we assume that we can continue.

>>> That's the role
>>> the CFRG exists to play: supporting IETF WGs when they have to
>>> evaluate crypto.
>> 
>> Evaluating crypto is quite different than creating "some new protocol". The CFRG most often evaluates existing crypto protocols and modes, it doesn't create them.
> 
> I think we're saying the same thing: IETF WG wants a protocol that
> does blah. They look around and see the proposals blah1, blah2 etc.
> exist.
> Then one of them gets picked. Whether this is defining a new protocol
> or evaluating the existing blah1, blah2, etc. is I think more semantic
> than anything else. A useful evaluation results in changes to address
> found deficiencies, or a statement that there are none and will be
> none. The easiest time to replace a broken mechanism is when it is
> being designed, before it is deployed. If we are playing catchup to
> deployment, the only thing we can say is "we're doomed" when we find a
> problem.

Fully agree. But I fear you place too much emphasis on IETF WGs for that. In the case of Dragonfly, the work was initiated *outside the IETF*, and only brought in later when it seemed we might align with other SDOs.

> There is also the everpresent turning the paper into a spec. This is
> fairly routine for most protocols, but the details matter, and can
> completely change what actually is going on. SSL v3 looked like it was
> using CBC mode, but because they decided to use chained IV's, actually
> were doing something completely different.

Yes, that. The CFRG used to be much more active in those evaluations. I would love to see it get re-energized on that. If nothing else, there are enough crypto professors here who could say to one of their indentured servants^W^Wgrad students, "take a look at this new proposal; finding something wrong with it is the correct answer".

>>> Furthermore, if we aren't actually
>>> producing documents meant to say "This is X, and X is good" for some
>>> definition of good, what are we doing here?
>> 
>> Lots of things:
>> 
>> - This is X, and while X is good, doing Y in X would be very bad
>> 
>> - This is X, and we have some shaky feelings about X, but we're totally fine with Z, which can be used in most of the same places
>> 
>> - Current IETF protocols use X, but X is now out of favor for these reasons; please strongly consider using Z
>> 
>> In the latter two cases, Z is not "some new protocol", they are existing ones that have been studied.
> 
> Are any of the CFRG WG drafts/IRTF publications actually of this form?

Many of the encryption mode documents and advice given to WGs are exactly of that form. Your current "new curves; warnings attached" document seems to be.

> I really don't know: from my review of the mailing list
> the CFRG did very little up until last year or so. I agree these are
> also documents that require production, especially when some ancient
> protocol hasn't been studied because it isn't as attractive a target
> as TLS. We need some sort of idea how to do this kind of review
> systematically.
> I've tried by reviewing all cfrg drafts, but there are some emails I'm
> behind on, and there is no way I can do all 7 thousand RFCs in a
> reasonable amount of time.

Consider cloning....

--Paul Hoffman