Re: [Cfrg] how can CFRG improve cryptography in the Internet?
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 12 February 2014 20:21 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 7609D1A06BC for <cfrg@ietfa.amsl.com>; Wed, 12 Feb 2014 12:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level:
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 650W1XeB2YEW for <cfrg@ietfa.amsl.com>; Wed, 12 Feb 2014 12:20:59 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6627E1A06AD for <cfrg@irtf.org>; Wed, 12 Feb 2014 12:20:59 -0800 (PST)
Received: from [192.168.10.228] ([80.43.126.29]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Md3ZK-1VvSh83rtq-00IF7H for <cfrg@irtf.org>; Wed, 12 Feb 2014 21:20:57 +0100
Message-ID: <52FBAA96.8090802@gmx.net>
Date: Wed, 12 Feb 2014 17:08:38 +0000
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: David McGrew <mcgrew@cisco.com>
References: <CACsn0ckOL8xdp5z7DdB9wyHhFpax0DhVXjsUMuGj39HgKk4YBA@mail.gmail.com> <52f50c59.aa1b8c0a.77c0.4985SMTPIN_ADDED_MISSING@mx.google.com> <CACsn0cnYkDwyAdwdf0+-JtksWu4NhKPr3L2emG2b3kFDe5v6hg@mail.gmail.com> <52F52E2D.8090104@cisco.com> <52F55236.1070800@gmx.net> <52F925FD.4030204@cisco.com>
In-Reply-To: <52F925FD.4030204@cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="MGwwFOarDkDqkErWx43HqGxja0Wder7pa"
X-Provags-ID: V03:K0:92JQ73RH1Oa0gKT5jakZI5CG18c/LKt1eOHlFcXFMZpqF+NFeHZ mdlFLhj/7roLnWCM22FFo10AbF3qjOPsMj4y9kMre3c++20eS00mszNHGcI4TV+TtmNpeRo nuF1G7Q6lOVCOas1aEQSmhF+hwpqIMzJDFEDSmFQezjHin5vZutDEx+lAAYz1TvUm7LSIr6 Py2YHKzzOsetKrNLeY9WA==
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "nmav@gnutls.org" <nmav@gnutls.org>
Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
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: Wed, 12 Feb 2014 20:21:02 -0000
Hi David, I believe it is important to move beyond writing specifications to improving implementations and deployments. I think we both agree. I have been arguing for this for a while now and got pretty much no positive feedback. I also tried to convince the IAB that this would be somewhat important and completely failed. The response I got was: "This would require a completely different skill set." and "ISOC should do it." I don't have a good story for how to do that even at the level of individual work groups. I tried this in the OAuth working group and couldn't really find a way how to reach out to the large number of guys implementing OAuth libraries let alone those who deploy them. The CFRG might, unfortunately, not be the right group either. To me it seems that the folks in this group are focused on crypto (as the name of the group indicates). What we need is guys who understand the broader Internet ecosystem and know how to improve security libraries and to reach out to the wider Internet (security) community. One does not need to start from scratch since some of these communities exist but they often have no connection to the IETF or the relationship is very weak. As such, you often find a misalignment between the IETF security community and various other groups. My impression is that most IETF participants have not even recognized the need to take any action yet. I have often heard that this is "out-side-the-scope". Ciao Hannes On 02/10/2014 07:18 PM, David McGrew wrote: > HI Hannes, > > On 02/07/2014 04:37 PM, Hannes Tschofenig wrote: >> Hi David, >> >> good discussion points. >> >> Here are my views: >> >> a) If we look at the problems at the entire Internet software lifecycle, >> as I did in >> http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01, >> then I believe it is fair to say that the problems at the level of >> cryptographic primitives are the least challenging issues with Internet >> security. That's good news. > > thanks for chiming in, I think you are right regarding primitives; let > me note that weak protocols and insecure deployment practices are > perfectly in scope for CFRG as well as primitives. But the other > major category of weakness, widespread exploitable vulnerabilities in > software implementations, is one that is hugely important, and which is > out of scope for CFRG. The problem of exploitable vulnerabilities > doesn't get the air-time that it deserves, relative to the other > issues. An exploit could force its victim to do all sorts of bad > cryptographic practices, such as leak a key in an IV, or use a fixed or > low-entropy key. > >> >> The problems you mentioned with RADIUS have little to do with work that >> would be done in the CFRG. RADIUS, similarly to Diameter, does not offer >> end-to-end security and that's something that could be fixed in the IETF >> (and there is work ongoing in the DIME working group for Diameter at >> least). The main challenge, however, is the attitude problem of those >> deploying the protocol. > > I agree about the attitude, but I don't agree that CFRG couldn't > help. Surely we don't need new crypto mechanisms to solve the > problems with RADIUS, but analyzing and documenting security issues and > helping to socialize them with the IETF and the user base are all in > charter and are worth doing. > >> >> b) I do, however, believe that the CFRG could play an interesting role. >> I am curious whether it would be possible to move some of the tasks that >> are currently done in NIST to the IRTF, namely the cryptographic >> algorithm selections. I know that this is a job that is today not done >> by the IETF/IRTF but I believe it could be done since the ingredients >> are: >> * open and transparent process for publishing, commenting, and selecting >> an algorithm >> * a suitable way for publishing these documents. >> >> Doing this work in a global standards organization also gives it more >> credibility. I am also confident that the IETF/IRTF community could >> reach out to researchers working on hash algorithms, encryption >> algorithms, etc. >> >> Just a thought... > > Agree that IETF is and should be willing to act as an international > standards body for crypto, and that CFRG could support that process. > We need to be careful not to over-commit in this area, but if the IETF > wanted CFRG to vet some crypto standards options, we should be able to > do that. > > David > >> >> Ciao >> Hannes >> >> >> On 02/07/2014 07:04 PM, David McGrew wrote: >>> Hi All, >>> >>> it is healthy to have a discussion on what CFRG and IETF can do >>> differently to improve security and privacy in the Internet. >>> >>> Ultimately, we are not limited by the current CFRG charter, but rather >>> by our collective willingness to do the work that needs to be done, and >>> I suppose on our ability to develop enough rough consensus about what >>> needs to be done. We do have a charter that we need to stick to at >>> present, but we can do more within that charter, and we can consider >>> changes to the charter if we think those are needed. (Though note that >>> we would need to get those changes approved.) >>> >>> An approach that might work for us is to develop replacement mechanisms >>> for the ones in current use that we think need to be replaced, keeping >>> in mind that the actual replacement might take ten years or so, or might >>> never happen. At the same time, we can document the problems with >>> existing mechanisms, to help provide a motivation for that replacement. >>> >>> It is worthwhile to keep in mind the interoperability problems that can >>> be caused by changes in cryptography, and the inertia created by all of >>> those millions of crypto implementations that are currently in use. We >>> can't expect new crypto to appear in a five year old piece of software >>> that is no longer supported by its creator, for instance, and that will >>> slow down adoption of newer crypto, no matter how much better it is. >>> As a practical matter, we also need to realize that many users of >>> cryptography believe that there is no economic justification for >>> deploying new crypto until breaking the old crypto scheme is so easy >>> that a script kiddie can do it with a backtrack CD-ROM. The burden is >>> on us to provide this justification. >>> >>> At the same time, I share the frustration that too much bad cryptography >>> is in use, which should have been replaced long ago. The fact that it >>> might take years to replace is no excuse not to start the process now. >>> I'm thinking of RADIUS and other protocols that are used with >>> human-generated passwords (and are not PAKE systems) in particular. It >>> would be *great* to have CFRG document what protocols are bad, and how >>> bad they are, in a way that we could demonstrate expert consensus on our >>> opinions. If we did a decent job, I bet we could get a slot in front of >>> the IESG or some other responsible IETF group. I am confident that, if >>> we can offer IETF good information about the security of current >>> standards, they will find a way to propagate and use that information. >>> >>> An aside: a history of crypto protocols at IETF might provide some >>> useful perspective; maybe a couple of people who were involved would be >>> willing to write up something? It might be useful to focus on one >>> case study where things were done wrong, and one where things were done >>> right. >>> >>> David >>> >>> On 02/07/2014 12:10 PM, Watson Ladd wrote: >>>> On Fri, Feb 7, 2014 at 8:39 AM, Blumenthal, Uri - 0558 - MITLL >>>> <uri@ll.mit.edu> wrote: >>>>> Don Johnson, for one. Carl Meyer. (Yes, those guys who invented >>>>> Lucifer and DES ciphers.) >>>>> >>>>> You keep forgetting (or simply aren't old enough to be aware?) of how >>>>> things were done back when the "Cryptography: The New Dimension" book >>>>> was published. >>>>> >>>>> The standard was "MAC, then Encrypt", and it had reasons for doing >>>>> things in that order. In fact, SNMP was the first IETF protocol >>>>> (circa 1992-1994) to diverge from that approach, and it took some >>>>> flak for not doing what was the conventional wisdom of that day. >>>> Was that flack informed? Or was it coming from people who didn't >>>> really understand the mathematics behind crypto? Were those reasons >>>> informed? Just because everyone was making the same mistakes doesn't >>>> make those mistakes less serious. Even if we make Bellare-Nampare the >>>> point at which no one should have done MAC then Encrypt, that was 13 >>>> years ago. Bard explained BEAST 9 years before the demonstration. >>>> >>>> The best you can say is that the TLS WG was woefully slow in >>>> responding to the changing situation. >>>> >>>>> Since then the priorities and the attacks changed, and now >>>>> "Encrypt-then-MAC" is the standard. >>>>> >>>>> Watson, I'd like to join other suggesting that you become less >>>>> combative here. I'm not a "peacenik" myself, but any patience has a >>>>> limit. >>>> What should the CFRG and the IETF do more broadly to ensure that >>>> blunders as serious as the ones above don't happen again? What has the >>>> CFRG done to ensure that other 90's era protocols have these problems >>>> addressed, particularly when the WGs responsible have disbanded? >>>> Should we simply let sleeping dogs lie, and work on ensuring that new >>>> protocols don't make similar mistakes? >>>> I'm here to fix the problems: explain what I need to do to fix them, >>>> and I'll do it. >>>> >>>> Sincerely, >>>> Watson >>>>> -- >>>>> Regards, >>>>> Uri Blumenthal Voice: (781) 981-1638 >>>>> Cyber Systems and Technology Fax: (781) 981-0186 >>>>> MIT Lincoln Laboratory Cell: (339) 223-5363 >>>>> 244 Wood Street Email: <uri@ll.mit.edu> >>>>> Lexington, MA 02420-9185 >>>>> >>>>> Web: http://www.ll.mit.edu/CST/ >>>>> >>>>> >>>>> >>>>> MIT LL Root CA: >>>>> >>>>> <https://www.ll.mit.edu/labcertificateauthority.html> >>>>> >>>>> >>>>> DSN: 478-5980 ask Lincoln ext.1638 >>>>> >>>>> ----- Original Message ----- >>>>> From: Watson Ladd [mailto:watsonbladd@gmail.com] >>>>> Sent: Friday, February 07, 2014 11:28 AM >>>>> To: Nikos Mavrogiannopoulos <nmav@gnutls.org> >>>>> Cc: cfrg@irtf.org <cfrg@irtf.org> >>>>> Subject: Re: [Cfrg] NSA sabotaging crypto standards >>>>> >>>>> On Fri, Feb 7, 2014 at 8:11 AM, Nikos Mavrogiannopoulos >>>>> <nmav@gnutls.org> wrote: >>>>>> On 02/07/2014 04:59 PM, Watson Ladd wrote: >>>>>> >>>>>>> But let's go into detail about how well the cryptographers did in >>>>>>> TLS. >>>>>>> In 1995 Phil Rogaway tells everyone to use encrypt-then-MAC. >>>>>> I believe you are oversimplifying things. Indeed Rogaway suggested >>>>>> encrypt-then-MAC, but other cryptographers were suggesting >>>>>> MAC-then-Encrypt (authenticate what is meant not what is sent). There >>>>>> was also no attack known for MAC-then-encrypt. >>>>> Show me one cryptographer who recommended MAC-then-Encrypt. >>>>> Also, absence of known attacks is not the same as absence of attacks. >>>>> Encrypt-then-MAC was the conservative choice. >>>>> >>>>>> In general it is very easy to see the obvious solution 20 years >>>>>> later, >>>>>> but the challenge is to properly decide at the right time. >>>>> It was obvious then: encrypt-then-MAC was known secure, while >>>>> MAC-then-encrypt was not. >>>>> Any excuse vanishes with Bellare-Nampare (2000). Of course, even if we >>>>> take the best interpretation, the TLS WG frittered away 9 years after >>>>> being informed of an attack. >>>>> >>>>> Sincerely, >>>>> Watson Ladd >>>>>> regards, >>>>>> Nikos >>>>>> >>>>>> _______________________________________________ >>>>>> Cfrg mailing list >>>>>> Cfrg@irtf.org >>>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>> >>>>> -- >>>>> "Those who would give up Essential Liberty to purchase a little >>>>> Temporary Safety deserve neither Liberty nor Safety." >>>>> -- Benjamin Franklin >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.t… internet-drafts
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Dan Harkins
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Watson Ladd
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… David McGrew
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Watson Ladd
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… David McGrew
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Dan Harkins
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Paul Lambert
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Watson Ladd
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Dan Harkins
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Yoav Nir
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Watson Ladd
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Mike Hamburg
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Dan Harkins
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Robert Ransom
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Watson Ladd
- Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-… Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] 2^40. I can't exhibit it, but it exist… Paul Lambert
- Re: [Cfrg] 2^40. I can't exhibit it, but it exist… Michael Hamburg
- Re: [Cfrg] 2^40. I can't exhibit it, but it exist… Watson Ladd
- [Cfrg] publishing dragonfly (was: Re: 2^40. I can… David McGrew
- Re: [Cfrg] publishing dragonfly (was: Re: 2^40. I… Eggert, Lars
- Re: [Cfrg] publishing dragonfly (was: Re: 2^40. I… Manger, James
- Re: [Cfrg] publishing dragonfly (was: Re: 2^40. I… Eggert, Lars
- [Cfrg] NSA sabotaging crypto standards Manger, James
- Re: [Cfrg] NSA sabotaging crypto standards Alexandre Anzala-Yamajako
- Re: [Cfrg] how can CFRG improve cryptography in t… Rob Stradling
- Re: [Cfrg] NSA sabotaging crypto standards Eggert, Lars
- Re: [Cfrg] NSA sabotaging crypto standards Watson Ladd
- Re: [Cfrg] NSA sabotaging crypto standards Paul Hoffman
- Re: [Cfrg] NSA sabotaging crypto standards Watson Ladd
- Re: [Cfrg] NSA sabotaging crypto standards Paul Hoffman
- Re: [Cfrg] NSA sabotaging crypto standards David McGrew
- Re: [Cfrg] NSA sabotaging crypto standards Dan Harkins
- Re: [Cfrg] NSA sabotaging crypto standards Watson Ladd
- Re: [Cfrg] how can CFRG improve cryptography in t… David McGrew
- Re: [Cfrg] NSA sabotaging crypto standards Nikos Mavrogiannopoulos
- Re: [Cfrg] NSA sabotaging crypto standards Watson Ladd
- Re: [Cfrg] NSA sabotaging crypto standards Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] NSA sabotaging crypto standards Watson Ladd
- [Cfrg] how can CFRG improve cryptography in the I… David McGrew
- Re: [Cfrg] how can CFRG improve cryptography in t… Daniel Kahn Gillmor
- Re: [Cfrg] NSA sabotaging crypto standards Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] how can CFRG improve cryptography in t… Hannes Tschofenig
- Re: [Cfrg] how can CFRG improve cryptography in t… Rene Struik
- Re: [Cfrg] how can CFRG improve cryptography in t… Stephen Farrell
- Re: [Cfrg] how can CFRG improve cryptography in t… dan
- Re: [Cfrg] how can CFRG improve cryptography in t… Watson Ladd
- Re: [Cfrg] how can CFRG improve cryptography in t… Daniel Kahn Gillmor
- Re: [Cfrg] how can CFRG improve cryptography in t… David McGrew
- Re: [Cfrg] how can CFRG improve cryptography in t… Stephen Farrell
- Re: [Cfrg] how can CFRG improve cryptography in t… Tom Ritter
- Re: [Cfrg] how can CFRG improve cryptography in t… Igoe, Kevin M.
- Re: [Cfrg] how can CFRG improve cryptography in t… Hannes Tschofenig
- Re: [Cfrg] how can CFRG improve cryptography in t… Hannes Tschofenig
- Re: [Cfrg] how can CFRG improve cryptography in t… Hannes Tschofenig
- Re: [Cfrg] how can CFRG improve cryptography in t… David McGrew
- Re: [Cfrg] how can CFRG improve cryptography in t… Paul Lambert
- Re: [Cfrg] how can CFRG improve cryptography in t… Watson Ladd
- Re: [Cfrg] how can CFRG improve cryptography in t… Rene Struik
- Re: [Cfrg] how can CFRG improve cryptography in t… Geoffrey Waters
- Re: [Cfrg] how can CFRG improve cryptography in t… S Moonesamy
- Re: [Cfrg] how can CFRG improve cryptography in t… David McGrew