From nobody Mon May 4 12:22:33 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336451ACE65 for ; Mon, 4 May 2015 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QxrskUzUAjJQ for ; Mon, 4 May 2015 12:22:31 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id D5D791A8AC4 for ; Mon, 4 May 2015 12:22:30 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t44JMT22031891 for ; Mon, 4 May 2015 12:22:29 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 376994010FC0 for ; Mon, 4 May 2015 12:22:30 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzZBa55vNbmD for ; Mon, 4 May 2015 12:22:29 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id 469EA4010FC1 for ; Mon, 4 May 2015 12:22:29 -0700 (PDT) Message-ID: <5547C6EF.8030001@well.com> Date: Mon, 04 May 2015 12:22:23 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5530EEAB.5050601@cs.tcd.ie> <20150421165947.GA3690@lo.psyced.org> In-Reply-To: <20150421165947.GA3690@lo.psyced.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [perpass] perpass: what next? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 19:22:32 -0000 There are lots of highly relevant clues on what Perpass group might want to tackle next in this long summary of Ed Snowden's recent video-talk with cryptographers at Princeton: https://www.lightbluetouchpaper.org/ " ... Yesterday Ed Snowden spent four hours with a group of cryptographers from industry and academia, of which I was privileged to be one. The topic was the possible and likely countermeasures, both legal and technical, against state surveillance. Ed attended as the “Snobot”, a telepresence robot that let him speak to us, listen and move round the room, from a studio in Moscow. As well as over a dozen cryptographers there was at least one lawyer and at least one journalist familiar with the leaked documents. Yesterday’s meeting was under the Chatham House rule, so I may not say who said what; any new disclosures may have been made by Snowden, or by one of the journalists, or by one of the cryptographers who has assisted journalists with the material. [snip] . . . " From nobody Fri May 8 09:02:42 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413131ACCEC for ; Fri, 8 May 2015 09:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IzXWUIba7smZ for ; Fri, 8 May 2015 09:02:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9421ACC86 for ; Fri, 8 May 2015 09:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3210BE8F for ; Fri, 8 May 2015 17:02:37 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ITWbUar9Ww5 for ; Fri, 8 May 2015 17:02:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65923BE3F for ; Fri, 8 May 2015 17:02:37 +0100 (IST) Message-ID: <554CDE1C.8060201@cs.tcd.ie> Date: Fri, 08 May 2015 17:02:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [perpass] Fwd: [saag] draft-smith-encrypted-traffic-management X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 16:02:40 -0000 FYI. As this relates to draft-mm-wg-effect-encrypt and we said we'd use the saag list for that, please head on over there if you'd like to discuss this some more, Ta, S. -------- Forwarded Message -------- Subject: [saag] draft-smith-encrypted-traffic-management Date: Fri, 8 May 2015 15:35:15 +0000 From: Smith, Kevin, (R&D) Vodafone Group To: saag@ietf.org Dear all, I've posted a draft on 'Network management of encrypted traffic' [1]. This follows up from the acknowledgement in both the 'Pervasive Monitoring is an attack' BCP [2] and the IAB statement on Internet confidentiality [3] to strike a balance that allows non-intrusive network management to continue to operate. The aim of the draft is to list ways to enable this, including new work (such as SPUD) looking into the problem. As such it intends to provide privacy-aware solutions to the effects of encryption raised in [2]. All comments and feedback very welcome. Thanks for your time! Kevin Kevin Smith, Vodafone R&D [1] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/ [2] https://tools.ietf.org/html/rfc7258 [3] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ [4] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Sun May 10 08:44:52 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0228C1A1B92 for ; Sun, 10 May 2015 08:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Nbj6xkCtrT6K for ; Sun, 10 May 2015 08:44:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948A61A1B81 for ; Sun, 10 May 2015 08:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 06283BED2; Sun, 10 May 2015 16:44:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lLm1lYweIkz; Sun, 10 May 2015 16:44:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 69EBCBED0; Sun, 10 May 2015 16:44:46 +0100 (IST) Message-ID: <554F7CED.5020606@cs.tcd.ie> Date: Sun, 10 May 2015 16:44:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: perpass OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Kathleen Moriarty Subject: [perpass] IESG perpass chat X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:44:51 -0000 All, Last week, the IESG met for our annual "retreat" and reviewed the fine work that you've all gotten done related to this list in the last year and a half. The slides we used for that chat are at [1]. The outcome was that the IESG are happy that we're continuing to use this list for triage of relevant topics, but more importantly that the IESG remain fully supportive (I asked a few times, just to be sure:-) of people doing work in the IETF to make improvements in this space. That's not as much of a NOOP as it may sound - the IESG has had a good few personnel changes since 2013, so it's really quite a good thing. Anyway, that means that if you have a relevant draft you've written and we need to figure out a home for that or how to process it within the IETF, then you should ask Kathleen or me when you think your stuff is ready. If you think some work should be done and are willing to do that, then please start a thread here and we can discuss it, but be ready to write drafts etc. to actually do the work wherever in the IETF it may land. (If you think someone else should do some work, then I have to say that that doesn't really usually work out so maybe think a bit more before starting a thread that asks us all to go get you a pony:-) And as always, Kathleen and I are available to help if you're not sure how to get stuff done, whether it's relevant etc. Just send one or both of us mail and we'll try help. There were also a few specific actions that IESG folks took to try shuffle things forward (e.g. I'm supposed to help Jari write a blog or some other non-natural-for-me thing, Alissa is going to try scare up some more expertise on traffic analysis and mitigating that etc.) but nothing that we need to go into detail on here until we're actually getting the associated bits of work done. In summary: please keep on doing the good work you've been doing. Please also do more of that. And the IESG are ready to, and happy to, help you get that done. Cheers, Stephen/Kathleen. [1] http://down.dsg.cs.tcd.ie/misc/perpass-retreat-2015-final.pdf From nobody Tue May 26 09:41:01 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829F01A9252 for ; Tue, 26 May 2015 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GuZ1wWg0vhWR for ; Tue, 26 May 2015 09:40:58 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id C152C1A9245 for ; Tue, 26 May 2015 09:40:57 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t4QGeu3R023429 for ; Tue, 26 May 2015 09:40:56 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 1F94D400CBDB for ; Tue, 26 May 2015 09:40:57 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIG3bsqdsotm for ; Tue, 26 May 2015 09:40:55 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id 66221400CB9D for ; Tue, 26 May 2015 09:40:55 -0700 (PDT) Message-ID: <5564A215.90403@well.com> Date: Tue, 26 May 2015 09:40:53 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: perpass References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------000008070202010209030205" Archived-At: Subject: [perpass] Possible attack on Diffie-Hellman key exchange X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:41:00 -0000 This is a multi-part message in MIME format. --------------000008070202010209030205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit ---------- Forwarded message ---------- From: *Rodney Van Meter* > Subject: possible attack on Diffie-Hellman key exchange It seems some researchers have uncovered a way to *pre-compute* part of the function necessary for breaking D-H, in a way that depends *only* on the prime number used. It’s a substantial amount of CPU time to do, but is within the range of plausible for someone like the NSA for 1024 bit keys. The existing IKE RFC recommends (requires?) use of one of a small set of prime numbers defined at https://tools.ietf.org/html/rfc5996#appendix-B and https://tools.ietf.org/html/rfc3526 Blog post from Scott Aaronson: http://www.scottaaronson.com/blog/?p=2293 Follow the links to the paper, too: https://weakdh.org/imperfect-forward-secrecy.pdf Their website has more information, and a test for whether your browser is vulnerable to the same attack: https://weakdh.org/ Of course, the obvious answer is to just raise the key length and/or use your own prime numbers rather than the ones in the spec, but who knows what else waits to be discovered? This serves as something of a motivation for continued work on alternatives to D-H; not because we believe D-H is inherently busted, or even that we necessarily believe that quantum key distribution (QKD) has no vulnerabilities of its own, but simply to have alternatives available as research lurches forward. We are working on documenting (as an RFC) a method for using QKD-generated keys with IKE in place of D-H. Our I-D has expired, but working is continuing, and we are actually generalizing it to support other methods of creating keys, including one-time pads that are delivered via some out-of-band mechanism. https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt --------------000008070202010209030205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
---------- Forwarded message ----------
From: Rodney Van Meter <rdv@sfc.wide.ad.jp>
Subject: possible attack on Diffie-Hellman key exchange

It seems some researchers have uncovered a way to *pre-compute* part of the function necessary for breaking D-H, in a way that depends *only* on the prime number used.  It’s a substantial amount of CPU time to do, but is within the range of plausible for someone like the NSA for 1024 bit keys.  The existing IKE RFC recommends (requires?) use of one of a small set of prime numbers defined at

Blog post from Scott Aaronson:
http://www.scottaaronson.com/blog/?p=2293
Follow the links to the paper, too:
Their website has more information, and a test for whether your browser is vulnerable to the same attack:

Of course, the obvious answer is to just raise the key length and/or use your own prime numbers rather than the ones in the spec, but who knows what else waits to be discovered? This serves as something of a motivation for continued work on alternatives to D-H; not because we believe D-H is inherently busted, or even that we necessarily believe that quantum key distribution (QKD) has no vulnerabilities of its own, but simply to have alternatives available as research lurches forward.  We are working on documenting (as an RFC) a method for using QKD-generated keys with IKE in place of D-H. Our I-D has expired, but working is continuing, and we are actually generalizing it to support other methods of creating keys, including one-time pads that are delivered via some out-of-band mechanism.


--------------000008070202010209030205-- From nobody Tue May 26 09:54:25 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593581AC3BA for ; Tue, 26 May 2015 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4jF8YABxwYqH for ; Tue, 26 May 2015 09:54:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D4D1ACCF4 for ; Tue, 26 May 2015 09:54:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91579BE9A; Tue, 26 May 2015 17:54:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igmYB44mIaRu; Tue, 26 May 2015 17:54:08 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B8C6BE8F; Tue, 26 May 2015 17:54:01 +0100 (IST) Message-ID: <5564A528.8020806@cs.tcd.ie> Date: Tue, 26 May 2015 17:54:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Liebhold , perpass References: <5564A215.90403@well.com> In-Reply-To: <5564A215.90403@well.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [perpass] Possible attack on Diffie-Hellman key exchange X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:54:22 -0000 Hiya, That's being discussed at length on the TLS list. I figure any conclusions from there will percolate to IPsec etc in good time. Is there another angle we ought be considering too or is that probably ok? Cheers, S. On 26/05/15 17:40, Mike Liebhold wrote: > > ---------- Forwarded message ---------- > From: *Rodney Van Meter* > > Subject: possible attack on Diffie-Hellman key exchange > > It seems some researchers have uncovered a way to *pre-compute* part of > the function necessary for breaking D-H, in a way that depends *only* on > the prime number used. It’s a substantial amount of CPU time to do, but > is within the range of plausible for someone like the NSA for 1024 bit > keys. The existing IKE RFC recommends (requires?) use of one of a small > set of prime numbers defined at > https://tools.ietf.org/html/rfc5996#appendix-B and > https://tools.ietf.org/html/rfc3526 > > Blog post from Scott Aaronson: > http://www.scottaaronson.com/blog/?p=2293 > Follow the links to the paper, too: > https://weakdh.org/imperfect-forward-secrecy.pdf > Their website has more information, and a test for whether your browser > is vulnerable to the same attack: > https://weakdh.org/ > > Of course, the obvious answer is to just raise the key length and/or use > your own prime numbers rather than the ones in the spec, but who knows > what else waits to be discovered? This serves as something of a > motivation for continued work on alternatives to D-H; not because we > believe D-H is inherently busted, or even that we necessarily believe > that quantum key distribution (QKD) has no vulnerabilities of its own, > but simply to have alternatives available as research lurches forward. > We are working on documenting (as an RFC) a method for using > QKD-generated keys with IKE in place of D-H. Our I-D has expired, but > working is continuing, and we are actually generalizing it to support > other methods of creating keys, including one-time pads that are > delivered via some out-of-band mechanism. > https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt > > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From nobody Tue May 26 10:13:59 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445091A924B for ; Tue, 26 May 2015 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MGl7q9SapDkA for ; Tue, 26 May 2015 10:13:55 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69A1A897E for ; Tue, 26 May 2015 10:13:55 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t4QHDncA015083; Tue, 26 May 2015 10:13:51 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 52993400E5ED; Tue, 26 May 2015 10:13:50 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhkq5-xDMSWm; Tue, 26 May 2015 10:13:49 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id 79C36400E5EC; Tue, 26 May 2015 10:13:48 -0700 (PDT) Message-ID: <5564A9CA.6090304@well.com> Date: Tue, 26 May 2015 10:13:46 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , perpass References: <5564A215.90403@well.com> <5564A528.8020806@cs.tcd.ie> In-Reply-To: <5564A528.8020806@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [perpass] Possible attack on Diffie-Hellman key exchange X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:13:57 -0000 (√) thanks. I'm glad to learn the right people are on the case from TLS and IPsec perspectives - but who specifically will scope out new prospective architectures -across the stack - for "other methods of creating keys, including one-time pads that are delivered via some out-of-band mechanism." Specifically, what are the new viable "out of band" mechanisms, and how would those scale effectively. Is that still out of scope for perpass? On 5/26/15 9:54 AM, Stephen Farrell wrote: > Hiya, > > That's being discussed at length on the TLS list. I figure any > conclusions from there will percolate to IPsec etc in good time. > Is there another angle we ought be considering too or is that > probably ok? > > Cheers, > S. > > > On 26/05/15 17:40, Mike Liebhold wrote: >> ---------- Forwarded message ---------- >> From: *Rodney Van Meter* > >> Subject: possible attack on Diffie-Hellman key exchange >> >> It seems some researchers have uncovered a way to *pre-compute* part of >> the function necessary for breaking D-H, in a way that depends *only* on >> the prime number used. It’s a substantial amount of CPU time to do, but >> is within the range of plausible for someone like the NSA for 1024 bit >> keys. The existing IKE RFC recommends (requires?) use of one of a small >> set of prime numbers defined at >> https://tools.ietf.org/html/rfc5996#appendix-B and >> https://tools.ietf.org/html/rfc3526 >> >> Blog post from Scott Aaronson: >> http://www.scottaaronson.com/blog/?p=2293 >> Follow the links to the paper, too: >> https://weakdh.org/imperfect-forward-secrecy.pdf >> Their website has more information, and a test for whether your browser >> is vulnerable to the same attack: >> https://weakdh.org/ >> >> Of course, the obvious answer is to just raise the key length and/or use >> your own prime numbers rather than the ones in the spec, but who knows >> what else waits to be discovered? This serves as something of a >> motivation for continued work on alternatives to D-H; not because we >> believe D-H is inherently busted, or even that we necessarily believe >> that quantum key distribution (QKD) has no vulnerabilities of its own, >> but simply to have alternatives available as research lurches forward. >> We are working on documenting (as an RFC) a method for using >> QKD-generated keys with IKE in place of D-H. Our I-D has expired, but >> working is continuing, and we are actually generalizing it to support >> other methods of creating keys, including one-time pads that are >> delivered via some out-of-band mechanism. >> https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt >> >> >> >> >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> From nobody Tue May 26 10:48:54 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32E41A005F for ; Tue, 26 May 2015 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UW8QFVh6BDth for ; Tue, 26 May 2015 10:48:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD921A038A for ; Tue, 26 May 2015 10:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 351CDBEC9; Tue, 26 May 2015 18:48:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdcmBTEOp1hD; Tue, 26 May 2015 18:48:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0B52BECF; Tue, 26 May 2015 18:48:44 +0100 (IST) Message-ID: <5564B1FC.3000007@cs.tcd.ie> Date: Tue, 26 May 2015 18:48:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Liebhold , perpass References: <5564A215.90403@well.com> <5564A528.8020806@cs.tcd.ie> <5564A9CA.6090304@well.com> In-Reply-To: <5564A9CA.6090304@well.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [perpass] Possible attack on Diffie-Hellman key exchange X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:48:53 -0000 Hiya, On 26/05/15 18:13, Mike Liebhold wrote: > (√) thanks. I'm glad to learn the right people are on the case from TLS > and IPsec perspectives - but who specifically will scope out new > prospective architectures -across the stack - for "other methods of > creating keys, including one-time pads that are delivered via some > out-of-band mechanism." > > Specifically, what are the new viable "out of band" mechanisms, and how > would those scale effectively. Well, for key agreement (which is the scope here) we do have some clear recommendations - prefer ECDH (soon with our newly selected curves, now with NIST curves) and then DH 2048 or better. And after that probably fall back to RSA key transport. The role (if any) for site-specific integer DH primes is being discussed on the TLS list including with the authors of the logjam paper. My guess is they may want to revisit a bit of the phrasing of some of the recommendations from the paper, so we'll see how that pans out. For lower level crypto mechanism things, then CFRG is the right place within the IETF/IRTF though they are currently busy with finishing the new curves work so it'll likely be a while before they have bandwidth for much more. That said, I don't think CFRG is a good place to invent new crypto but rather it's a good place to figure out which of the already peer reviewed academic cryptography work we want to take into standards, and how, at the bit fiddling level. CFRG ought be doing the selection (which requires real knowledge of the state of the art) and defining the bit fiddling (where IETFers can help) but not the basic inventing of algorithms or similar. For that last, CHES and the crypto conferences or are really better venues as would be any IACR journal or equivalent. Algorithm work really is better started in a peer-reviewed academic context and not dealt with on our mailing lists. (This thread [1] is a fine example of why it's a bad idea to try invent stuff on our mailing lists;-) [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg06790.html > Is that still out of scope for perpass? Hope the above helps - the main idea of this list is to find the right place for stuff, so asking "where" and getting views on that is entirely correct. (And more are welcome.) S. > > > On 5/26/15 9:54 AM, Stephen Farrell wrote: >> Hiya, >> >> That's being discussed at length on the TLS list. I figure any >> conclusions from there will percolate to IPsec etc in good time. >> Is there another angle we ought be considering too or is that >> probably ok? >> >> Cheers, >> S. >> >> >> On 26/05/15 17:40, Mike Liebhold wrote: >>> ---------- Forwarded message ---------- >>> From: *Rodney Van Meter* >> > >>> Subject: possible attack on Diffie-Hellman key exchange >>> >>> It seems some researchers have uncovered a way to *pre-compute* part of >>> the function necessary for breaking D-H, in a way that depends *only* on >>> the prime number used. It’s a substantial amount of CPU time to do, but >>> is within the range of plausible for someone like the NSA for 1024 bit >>> keys. The existing IKE RFC recommends (requires?) use of one of a small >>> set of prime numbers defined at >>> https://tools.ietf.org/html/rfc5996#appendix-B and >>> https://tools.ietf.org/html/rfc3526 >>> >>> Blog post from Scott Aaronson: >>> http://www.scottaaronson.com/blog/?p=2293 >>> Follow the links to the paper, too: >>> https://weakdh.org/imperfect-forward-secrecy.pdf >>> Their website has more information, and a test for whether your browser >>> is vulnerable to the same attack: >>> https://weakdh.org/ >>> >>> Of course, the obvious answer is to just raise the key length and/or use >>> your own prime numbers rather than the ones in the spec, but who knows >>> what else waits to be discovered? This serves as something of a >>> motivation for continued work on alternatives to D-H; not because we >>> believe D-H is inherently busted, or even that we necessarily believe >>> that quantum key distribution (QKD) has no vulnerabilities of its own, >>> but simply to have alternatives available as research lurches forward. >>> We are working on documenting (as an RFC) a method for using >>> QKD-generated keys with IKE in place of D-H. Our I-D has expired, but >>> working is continuing, and we are actually generalizing it to support >>> other methods of creating keys, including one-time pads that are >>> delivered via some out-of-band mechanism. >>> https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt >>> >>> >>> >>> >>> >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>> > > > From nobody Tue May 26 12:54:39 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99D1A03D5 for ; Tue, 26 May 2015 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lcG6SVX_PUmr for ; Tue, 26 May 2015 12:54:30 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA64A1A0197 for ; Tue, 26 May 2015 12:54:29 -0700 (PDT) Received: by wgme6 with SMTP id e6so38268881wgm.2 for ; Tue, 26 May 2015 12:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hQLe9ZhnJFSN6ErYFbz4O0v9yu2zZCXpPIWQSTUMD/Y=; b=ysXRBz16y50WoAmcQrvI0eQ6BbTmMh9xeLEdzFx3/m7XXJjj+F8ZbdMuLPYOcEns8M xGsYAHrv+PnDbbimmnNUWGIAhnWzxnEWXOT8yqlBBoWyHRSnmZRPS35Bb1UKGwt4+uPc 6GEMosxf47peq9smNOThhwuAv02GnhwCb7ocRGvka1X76g2RURMD0KC1hmHUdbGCWnaX uF3LxmW8Odw1mO5IKqA7GOo0P/7WrT9rPsHIykTkbYgO06hIyQkB5qT2v8gy8cd2GkH8 ioGoaxu+zKjxbMmnb6N2Xz377fNujtW1bnBAoOLD1WEQyL5A//HZ4Mpoyg5/mwMwT3Qc xcoQ== MIME-Version: 1.0 X-Received: by 10.180.74.104 with SMTP id s8mr44747041wiv.40.1432670068422; Tue, 26 May 2015 12:54:28 -0700 (PDT) Received: by 10.195.17.163 with HTTP; Tue, 26 May 2015 12:54:28 -0700 (PDT) In-Reply-To: <20150526135254.9974.64001.idtracker@ietfa.amsl.com> References: <20150526135254.9974.64001.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 12:54:28 -0700 Message-ID: From: Ted Hardie To: "" Content-Type: multipart/alternative; boundary=f46d043c804a823e150517017e28 Archived-At: Subject: [perpass] Fwd: [IAB] I-D Action: draft-iab-privsec-confidentiality-mitigations-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:54:35 -0000 --f46d043c804a823e150517017e28 Content-Type: text/plain; charset=UTF-8 Howdy, This is a very drafty -00 that the IAB's privsec program is working on. It is missing much, and any reviews and suggestions are welcome (One of the things missing is a contributors section, since some of this came out of the drafts originally submitted to perpass.) Thanks for any attention you can give, Ted ---------- Forwarded message ---------- From: Date: Tue, May 26, 2015 at 6:52 AM Subject: [IAB] I-D Action: draft-iab-privsec-confidentiality-mitigations-00.txt To: i-d-announce@ietf.org Cc: iab@iab.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Confidentiality in the Face of Pervasive Surveillance Author : Ted Hardie Filename : draft-iab-privsec-confidentiality-mitigations-00.txt Pages : 9 Date : 2015-05-19 Abstract: The IAB has published [I-D.iab-privsec-confidentiality-threat] in response to several revelations of pervasive attack on Internet communications. In this document we survey the mitigations to those threats which are currently available or which might plausibly be deployed. We discuss these primarily in the context of Internet protocol design, focusing on robustness to pervasive monitoring and avoidance of unwanted cross-mitigation impacts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-iab-privsec-confidentiality-mitigations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-iab-privsec-confidentiality-mitigations-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --f46d043c804a823e150517017e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

This is a very dra= fty -00 that the IAB's privsec program is working on.=C2=A0 It is missi= ng much, and any reviews and suggestions are welcome (One of the things mis= sing is a contributors section, since some of this came out of the drafts o= riginally submitted to perpass.)

Tha= nks for any attention you can give,

Ted


---------- Forwarded messag= e ----------
From: = <internet-drafts@ietf.org>
Date: Tue, May 26, 2015 at 6:52 AM
Subject: [IAB] I-D Ac= tion: draft-iab-privsec-confidentiality-mitigations-00.txt
To: i-d-announce@ietf.org
Cc: iab@iab.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Internet Architecture Board Working = Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Confidentiality in the Face of Pervasive Surveillance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ted = Hardie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iab= -privsec-confidentiality-mitigations-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-19

Abstract:
=C2=A0 =C2=A0The IAB has published [I-D.iab-privsec-confidentiality-threat]= in
=C2=A0 =C2=A0response to several revelations of pervasive attack on Interne= t
=C2=A0 =C2=A0communications.=C2=A0 In this document we survey the mitigatio= ns to those
=C2=A0 =C2=A0threats which are currently available or which might plausibly= be
=C2=A0 =C2=A0deployed.=C2=A0 We discuss these primarily in the context of I= nternet
=C2=A0 =C2=A0protocol design, focusing on robustness to pervasive monitorin= g and
=C2=A0 =C2=A0avoidance of unwanted cross-mitigation impacts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= ab-privsec-confidentiality-mitigations/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-iab-privs= ec-confidentiality-mitigations-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/


--f46d043c804a823e150517017e28--