From nobody Sat Jan 2 10:21:46 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE481A1B30 for ; Sat, 2 Jan 2016 10:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 tWTjr44VSxUx for ; Sat, 2 Jan 2016 10:21:43 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id CF0011A1B2E for ; Sat, 2 Jan 2016 10:21:43 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 22A2010224008; Sat, 2 Jan 2016 10:21:43 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 2 Jan 2016 10:21:43 -0800 (PST) Message-ID: <428283255cba3c5deae7989dc1f568c7.squirrel@www.trepanning.net> In-Reply-To: <22122.46006.525597.693993@fireball.acr.fi> References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <22122.46006.525597.693993@fireball.acr.fi> Date: Sat, 2 Jan 2016 10:21:43 -0800 (PST) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 18:21:45 -0000 On Fri, December 11, 2015 3:29 am, Tero Kivinen wrote: [snip] > As for the IKEv1, we had long discussion [1] on the ipsec list when we > had this issue with brainpool IKEv1 curves, and they were added to the > IKEv1 registry with note saying "Not for RFC 2409." [2] meaning they > are not for the IPsec use. They are only there for the 802.11 use. > > There was strong objections in the discussion for adding any new > algorithms for IKEv1 use, so specifying how this is used in the IKEv1 > does not really help, as there will be strong objections for getting > IANA numbers for IKEv1 use. Trying to administratively force people to do things they have no technical reason to do makes the IETF look impotent and kind of petty. If you want someone to use protocol BAR instead of protocol FOO then BAR should offer some compelling reason to change. A decree by the mandarins of the IETF is not compelling, as reality continues to demonstrate. best regards, Dan. From nobody Mon Jan 11 08:54:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25611A8A9B for ; Mon, 11 Jan 2016 08:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0hqziHXO5E-O for ; Mon, 11 Jan 2016 08:54:33 -0800 (PST) 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 65A601A8AA0 for ; Mon, 11 Jan 2016 08:54:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 73C6FBDF9 for ; Mon, 11 Jan 2016 16:54:26 +0000 (GMT) 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 lFTDslSwBgda for ; Mon, 11 Jan 2016 16:54:26 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AFDA4BE55 for ; Mon, 11 Jan 2016 16:54:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452531266; bh=ZhMO51z05o5Ir69l5QNfhDZ9S6IMQT/76ieQTCbfVBE=; h=To:From:Subject:Date:From; b=AF2OWs9PqxzQOJ5S72cR6UQdyfYvx9irdSCU3G4r2uw8utcbytl1W7y9Zkp3UPqa9 o5L8JLRKOtTw/q9sz9AXXq/WpfGyjgz3pkiy96bvM1FzpLnrxlgqEJNeCBTTNxw6bv BTlIjSHVW3303oY2Uuo8dm6gypJHMWCFaCL3G9gA= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5693DE41.3050102@cs.tcd.ie> Date: Mon, 11 Jan 2016 16:54:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Any BoF ideas for IETF95? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:54:35 -0000 Hiya, I just noticed the "important dates" [1] includes: " 2016-02-19 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF." In reality, if you do want a BoF in B-A, I suspect you'd want to be organising already, as the above date will sneak up really fast, and getting the right people in the room could be more of a challenge if travel-distance is an issue for folks. Anyway, please do ping Kathleen and I early if you have something in mind. (And don't be afraid to remind us of stuff we already chatted about, I at least am quite liable to forget stuff;-) Cheers, S. [1] https://ietf.org/meeting/important-dates-2016.html From nobody Fri Jan 15 16:59:23 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEF1B34B1 for ; Fri, 15 Jan 2016 16:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 w9JmhzPIp46u for ; Fri, 15 Jan 2016 16:59:21 -0800 (PST) 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 EF36D1B34B2 for ; Fri, 15 Jan 2016 16:59:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB42BBE55 for ; Sat, 16 Jan 2016 00:59:18 +0000 (GMT) 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 4gdOBJUPGF_q for ; Sat, 16 Jan 2016 00:59:17 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.41.53.98]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F05F0BEC6 for ; Sat, 16 Jan 2016 00:59:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452905957; bh=9IrBOtq6btlBjLTAycCA/eAXTRV0MqAkxegtRtQdNyY=; h=Subject:References:To:From:Date:In-Reply-To:From; b=sNjPh9onQ3ozQJKGNSWbc+x6/l2tQeMtMxnUDhgDU7DidKxbR01sk2aKNzO+mVSkn PaDyF14Ia84V2J3P4lDcLIe0tqgvIvMq4oHtKO87kcvFnxZlpKLILux1WfcIV+iVPM p8wNIzMi++coUkc7hTDD2yLZM9ddOMycrsy5J4CU= References: <20160116005444.17735.40712.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20160116005444.17735.40712.idtracker@ietfa.amsl.com> Message-ID: <569995E4.2070603@cs.tcd.ie> Date: Sat, 16 Jan 2016 00:59:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160116005444.17735.40712.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 00:59:23 -0000 We discussed this topic briefly at IETF94 and in more detail at the Marnew workshop. There seemed to be at least enough interest for a list so... Cheers, S. PS: I'd say best to wait 'till next Wednesday or so to start list discussion so that folks have time to join the list. -------- Forwarded Message -------- Subject: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys Date: Fri, 15 Jan 2016 16:54:44 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: @ericsson.com, stephen.farrell@cs.tcd.iedaniel.migault, lurk@ietf.org A new IETF non-working group email list has been created. List address: lurk@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=lurk To subscribe: https://www.ietf.org/mailman/listinfo/lurk Purpose: Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based the proof of ownership of a private key. Currently most trust models assume the private key is associated and owned by the peer. In addition, the remote peer is both responsible of the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of service on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application, - like a web browser - expects to authenticate a content provider while authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content. There may be a BoF at IETF95 to discuss this topic. For additional information, please contact the list administrators. From nobody Tue Jan 19 18:20:38 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4A1A015F for ; Tue, 19 Jan 2016 18:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 k2sRaBmS6Ofy for ; Tue, 19 Jan 2016 18:20:36 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A311A014B for ; Tue, 19 Jan 2016 18:20:36 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 8639E461D5; Wed, 20 Jan 2016 02:20:34 +0000 (UTC) Received: from bofh.nohats.ca (vpn-224-165.phx2.redhat.com [10.3.224.165]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0K2KVKn014827; Tue, 19 Jan 2016 21:20:33 -0500 To: Tero Kivinen , Stephen Farrell References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> From: Paul Wouters Message-ID: <569EEEEF.7070604@redhat.com> Date: Tue, 19 Jan 2016 21:20:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <22121.36056.8625.417621@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "saag@ietf.org" , rfc-ise@rfc-editor.org Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 02:20:37 -0000 On 12/10/2015 09:31 AM, Tero Kivinen wrote: > Stephen Farrell writes: >> On Dec17, the IESG will also be doing the conflict review for a >> draft [1] that documents some more about using GOST algorithms. >> >> Since we've typically handled national algorithms in this manner >> (basic alg details are documented as independent submission >> stream RFCs) I think this one does not represent a conflict with >> ongoing IETF work or process. But if I'm wrong, please do let me >> know. > > I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It > does not allocate any IANA numbers for them, so there is no way of > using them, so why include those sections in this draft at all. I > think it would be better to have those in the draft that allocates the > numbers which allows these to be used? > > Also specifying anything for the obsoleted IKEv1 protocol is bad > idea... What Tero said. I hadn't even seen this until now. I think it sets a bad precedent to allow IKE modifications against the working group's policies. One of those policies is "no more IKEv1 updates". I'm fine with an IKEv2 document being submitted to IPsecME for these new algorithms. Paul From nobody Wed Jan 20 02:10:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B71B39A2 for ; Wed, 20 Jan 2016 02:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MBxjISHSw2TZ for ; Wed, 20 Jan 2016 02:10:07 -0800 (PST) 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 EA9A01ACE4E for ; Wed, 20 Jan 2016 02:10:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3752BE47; Wed, 20 Jan 2016 10:10:04 +0000 (GMT) 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 FUZsPRh3Y_rp; Wed, 20 Jan 2016 10:10:04 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 092C0BE3E; Wed, 20 Jan 2016 10:10:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453284604; bh=9WKrfMFGIPTzMXxr7Jgk+ptKZCzKCIGGa9iak75WAFQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pYzsx8FGF0GSVlOrB8+MSJCuVdFMwpyOfX17vOrduBxyiHoxzBfi/EOPUQAOub8eH /iuCvHiqs1H1XYuqMQ1s1umpI7MpV+dJq912tk+3bzHAtrEauhgiGSRMcJSYBfSlmB 8FepQOz2Japs1sgx0nHnHWqsWUecU+Nqhsqm895Q= To: Paul Wouters , Tero Kivinen References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <569EEEEF.7070604@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <569F5CFB.3020506@cs.tcd.ie> Date: Wed, 20 Jan 2016 10:10:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569EEEEF.7070604@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" , rfc-ise@rfc-editor.org Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 10:10:10 -0000 I guess I should've looped back on this before. TL;DR: it's ok, or tell Nevil if you disagree On 20/01/16 02:20, Paul Wouters wrote: > On 12/10/2015 09:31 AM, Tero Kivinen wrote: >> Stephen Farrell writes: >>> On Dec17, the IESG will also be doing the conflict review for a >>> draft [1] that documents some more about using GOST algorithms. >>> >>> Since we've typically handled national algorithms in this manner >>> (basic alg details are documented as independent submission >>> stream RFCs) I think this one does not represent a conflict with >>> ongoing IETF work or process. But if I'm wrong, please do let me >>> know. >> >> I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? >> It does not allocate any IANA numbers for them, so there is no way >> of using them, so why include those sections in this draft at all. >> I think it would be better to have those in the draft that >> allocates the numbers which allows these to be used? >> >> Also specifying anything for the obsoleted IKEv1 protocol is bad >> idea... > > What Tero said. > > I hadn't even seen this until now. I think it sets a bad precedent to > allow IKE modifications against the working group's policies. One of > those policies is "no more IKEv1 updates". > > I'm fine with an IKEv2 document being submitted to IPsecME for these > new algorithms. Right. The IESG did return a please-don't-publish 5742 result to the ISE on the basis of the IKEv1 text. The authors were fine with fixing that, so they removed all the IKEv1 stuff. At that point the IESG were ok with the document from a 5742 conflict-review perspective. The authors did not accept all of Tero's comments but if you think that needs more work, then the thing to do is to send mail to the ISE (cc'd here) about the latest revision which is not yet an RFC. (You'd have to ask Nevil where it is in his publication queue.) Cheers, S. > > Paul > From nobody Fri Jan 22 20:51:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233931B30BF for ; Fri, 22 Jan 2016 20:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 V-oFC5iL-ep2 for ; Fri, 22 Jan 2016 20:51:11 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 193F21B30BE for ; Fri, 22 Jan 2016 20:51:11 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so109619326ykd.3 for ; Fri, 22 Jan 2016 20:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Loh4q0Zw2FsBpaaFRxHUpNA2szTmldIV7DnA2mVp6ms=; b=XOtBgC3wdwERmuikiAezgHTnSCv+WuffPwh2jN5kBnDBG20qJ8U1+RQjcoDTaSZQMy k2ieYVFicpAYOM1rV4dFMlz6Gm+JUmR7gtAnSEiQu8HEgqKnFLrRUL9ydIUJ9oORDYSG lhDXsZUj2IQrgVNlEpKbyobcKebBdbeArhpjs4L+xUgrfSvJb8lrXV7vjEEIJOqFTM0T Yru3BR/j9LWGK2SdgjZOjQhVeKQd3+DYACYr14TnEVxn3NeJN5j8RsbeB6j2zg1O+Z9p Kws/6c41bPcGU54xjUJ6+GxRr86IIHATamG+zExTHAEUbWdjvwuaYdVQLSlQP1KtYxAM XcVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Loh4q0Zw2FsBpaaFRxHUpNA2szTmldIV7DnA2mVp6ms=; b=Q2DYOjbugNr89266sqG7hL9+w0EX8ZK8NSVagcbb+SdGdHMd+Wy6BA3ZjxxLYhBvgi CqI9oX+ql7hgPQF8ZD23PhbH1D85R48cErK8UOEgYWth8cpeb7KKzuFRUYFHmHF1U+tN MC031haf1dIkoIARvezpayU6ALmHeKnzdX2EnqZ6HfCeDmdUg1ce0C8lR66xIIEsNkrV ZBTekf7D4wFz36Q9nBX1wNcgGW5wKoIeyAD4r82pYaX+BUiLwar0Vtaw0ypkifuzUEDK 4va/f08rpXUX5dJU6tQAkEy2o6wf7OC7Hru2VhTvkCC2AJ04oyIcJw/2ft5nv5Ou9Yf+ fjQA== X-Gm-Message-State: AG10YOTruNneKvtQ5AlPlgOsuEUDWpeQHZ8aZg5xYhd8T3x8DaG0fI5sHaA0mAICjQz73oFYJhqrxj8mK+6YCw== MIME-Version: 1.0 X-Received: by 10.37.5.151 with SMTP id 145mr1093150ybf.16.1453524670427; Fri, 22 Jan 2016 20:51:10 -0800 (PST) Received: by 10.13.216.150 with HTTP; Fri, 22 Jan 2016 20:51:10 -0800 (PST) Date: Fri, 22 Jan 2016 20:51:10 -0800 Message-ID: From: Watson Ladd To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 04:51:12 -0000 Dear all, MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept. Imagine my surprise when I found not just one, but two RFCs describing these options, both failing to mention the security properties they had when trusted parties would be compromised, and in particular the possibility of retroactive decryption in SAKKE. This should have been noted by someone at some point. How do we make sure this doesn't happen because reviews are being done by the wrong people? Sincerely, Watson From nobody Fri Jan 22 21:44:26 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC101B316D for ; Fri, 22 Jan 2016 21:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 cA84gAf_NapY for ; Fri, 22 Jan 2016 21:44:19 -0800 (PST) Received: from BLU004-OMC4S21.hotmail.com (blu004-omc4s21.hotmail.com [65.55.111.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179891B3168 for ; Fri, 22 Jan 2016 21:44:19 -0800 (PST) Received: from BLU406-EAS424 ([65.55.111.135]) by BLU004-OMC4S21.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 22 Jan 2016 21:44:18 -0800 X-TMN: [b7IHS8pzpLcDq1g+u32+odwVZw2pMTeL] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-F829E49A-A79D-4465-A219-1928F3B5FB54" Content-Transfer-Encoding: 7bit From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Fri, 22 Jan 2016 21:44:10 -0800 References: To: Watson Ladd In-Reply-To: X-OriginalArrivalTime: 23 Jan 2016 05:44:18.0022 (UTC) FILETIME=[19BAC060:01D155A1] Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 05:44:25 -0000 --Apple-Mail-F829E49A-A79D-4465-A219-1928F3B5FB54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Watson - MIKEY-IBAKE (RFC6267) and MIKEY-SAKKE (RFC 6509) are both Informational RFCs= . It is common for such documents to receive less scrutiny than standards t= rack documents. IMHO, we could be more transparent about the level of review that Informatio= nal documents receive. For example, here is an (understated) IESG note from E= AP-SIM, RFC 4186: IESG Note=20 The EAP-SIM protocol was developed by 3GPP. The documentation of EAP-SIM is p= rovided as information to the Internet community. While the EAP WG has verif= ied that EAP-SIM is compatible with EAP, as defined in RFC 3748, no other re= view has been done, including validation of the security claims. The IETF ha= s also not reviewed the security of the cryptographic algorithms. > On Jan 22, 2016, at 20:51, Watson Ladd wrote: >=20 > Dear all, >=20 > MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept. > Imagine my surprise when I found not just one, but two RFCs describing > these options, both failing to mention the security properties they > had when trusted parties would be compromised, and in particular the > possibility of retroactive decryption in SAKKE. This should have been > noted by someone at some point. How do we make sure this doesn't > happen because reviews are being done by the wrong people? >=20 > Sincerely, > Watson >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-F829E49A-A79D-4465-A219-1928F3B5FB54 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5XYXRzb24gLTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TUlLRVktSUJBS0UgKFJGQzYy NjcpIGFuZCBNSUtFWS1TQUtLRSAoUkZDIDY1MDkpIGFyZSBib3RoIEluZm9ybWF0aW9uYWwgUkZD cy4gJm5ic3A7SXQgaXMgY29tbW9uIGZvciBzdWNoIGRvY3VtZW50cyB0byByZWNlaXZlIGxlc3Mg c2NydXRpbnkgdGhhbiBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnRzLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+SU1ITywgd2UgY291bGQgYmUgbW9yZSB0cmFuc3BhcmVudCBhYm91dCB0aGUgbGV2 ZWwgb2YgcmV2aWV3IHRoYXQgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgcmVjZWl2ZS4gRm9yIGV4 YW1wbGUsIGhlcmUgaXMgYW4gKHVuZGVyc3RhdGVkKSBJRVNHIG5vdGUgZnJvbSBFQVAtU0lNLCBS RkMgNDE4Njo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iVUlDVEZvbnRUZXh0U3R5bGVU YWxsQm9keSI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5JRVNHIE5vdGUmbmJzcDs8L3NwYW4+PC9mb250 PjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+ PGZvbnQgZmFjZT0iVUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSI+PHNwYW4gc3R5bGU9IndoaXRl LXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij48YnI+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHki PjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyI+VGhlIEVBUC1TSU0gcHJvdG9jb2wgd2FzIGRldmVsb3BlZCBi eSAzR1BQLiAgVGhlIGRvY3VtZW50YXRpb24gb2YNCiAgIEVBUC1TSU0gaXMgcHJvdmlkZWQgYXMg aW5mb3JtYXRpb24gdG8gdGhlIEludGVybmV0IGNvbW11bml0eS4gIFdoaWxlDQogICB0aGUgRUFQ IFdHIGhhcyB2ZXJpZmllZCB0aGF0IEVBUC1TSU0gaXMgY29tcGF0aWJsZSB3aXRoIEVBUCwgYXMN CiAgIGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzc0 OCI+UkZDIDM3NDg8L2E+LCBubyBvdGhlciByZXZpZXcgaGFzIGJlZW4gZG9uZSwgaW5jbHVkaW5n DQogICB2YWxpZGF0aW9uIG9mIHRoZSBzZWN1cml0eSBjbGFpbXMuICBUaGUgSUVURiBoYXMgYWxz byBub3QgcmV2aWV3ZWQNCiAgIHRoZSBzZWN1cml0eSBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBhbGdv cml0aG1zLjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9kaXY+PGRpdj48YnI+T24gSmFuIDIyLCAyMDE2 LCBhdCAyMDo1MSwgV2F0c29uIExhZGQgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXRzb25ibGFkZEBn bWFpbC5jb20iPndhdHNvbmJsYWRkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9k aXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5EZWFyIGFsbCw8L3NwYW4+PGJy PjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TUlLRVktSUJBS0UgYW5kIE1JS0VZLVNBS0tFIGFyZSBp biB0aGUgbmV3cyBhcyBlbmFibGluZyBMRSBpbnRlcmNlcHQuPC9zcGFuPjxicj48c3Bhbj5JbWFn aW5lIG15IHN1cnByaXNlIHdoZW4gSSBmb3VuZCBub3QganVzdCBvbmUsIGJ1dCB0d28gUkZDcyBk ZXNjcmliaW5nPC9zcGFuPjxicj48c3Bhbj50aGVzZSBvcHRpb25zLCBib3RoIGZhaWxpbmcgdG8g bWVudGlvbiB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyB0aGV5PC9zcGFuPjxicj48c3Bhbj5oYWQg d2hlbiB0cnVzdGVkIHBhcnRpZXMgd291bGQgYmUgY29tcHJvbWlzZWQsIGFuZCBpbiBwYXJ0aWN1 bGFyIHRoZTwvc3Bhbj48YnI+PHNwYW4+cG9zc2liaWxpdHkgb2YgcmV0cm9hY3RpdmUgZGVjcnlw dGlvbiBpbiBTQUtLRS4gVGhpcyBzaG91bGQgaGF2ZSBiZWVuPC9zcGFuPjxicj48c3Bhbj5ub3Rl ZCBieSBzb21lb25lIGF0IHNvbWUgcG9pbnQuIEhvdyBkbyB3ZSBtYWtlIHN1cmUgdGhpcyBkb2Vz bid0PC9zcGFuPjxicj48c3Bhbj5oYXBwZW4gYmVjYXVzZSByZXZpZXdzIGFyZSBiZWluZyBkb25l IGJ5IHRoZSB3cm9uZyBwZW9wbGU/PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlNp bmNlcmVseSw8L3NwYW4+PGJyPjxzcGFuPldhdHNvbjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxi cj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+PHNwYW4+c2FhZyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9 Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWc8L2E+PC9zcGFuPjxicj48L2Rp dj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-F829E49A-A79D-4465-A219-1928F3B5FB54-- From nobody Fri Jan 22 22:12:46 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8951B31F3 for ; Fri, 22 Jan 2016 22:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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, FREEMAIL_FROM=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 fTRRzO8XpDLK for ; Fri, 22 Jan 2016 22:12:43 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 70F601B31F2 for ; Fri, 22 Jan 2016 22:12:43 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id mw1so4822280igb.1 for ; Fri, 22 Jan 2016 22:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sMVQd4aIcZTtYp2VSiHYK5uJi5QxJ/A12S3TrxdI5IQ=; b=bnrO8ND3rultn/RiQW0yp/xrphbooBdXNfelq7LzZfMF9m+un4wkT3VB6rtaXVHlbU k8rOyLJaAWjF39ZuYSlDjJwFTULn4iovvGccRI374iskrH4/A4kIfVa2JOvkrhOywu8K gVWfCAy5h5BamyepexAMK8aypquT6/QVc3KPYi2UHcbG8CeQMdSVpvF8rRsWp9y/KHis eBL9sog6heTQCVMVfSvkHMNuN06FfajSUxykgN++rJsG4RqUZ3SCy5ARdkM+Sh1gPEqJ oj1wznr5OyTLLru2QBwEbBwjWD/2z8eGUQ94OIE4HBcKW+/a9y/4sNmzXyL9lB12h3uy 4nhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sMVQd4aIcZTtYp2VSiHYK5uJi5QxJ/A12S3TrxdI5IQ=; b=k2DVC5S/q68cOYE9PRwxs9JaYgO1e6RuACMAbXCB54CV3nREEPKuZ7voOZHNcfuh98 oPETiHbKzSZpdR6sEpmdiomwawxZSRPVR6pcfmewdqRvm7+HJD89OGc40H479FFwJRf2 v+8UW1rKoMkrhILq10ec7apW2H+hdFUgwsz7QY+KcS1+jCPKRb7F8zL+FPeTvbAI888u sM8NhLNT62id/GB35OCW8Gvxg+cpx6DnuFoxI95duxI7Gdv/FdxnexTIkn58U/cLc14U NqLOpGHAdFjpYL3PrUwz6hRZf3kasnWM36WGP2VB7JD8G2kS/eSv/R0fEDIJ89WV9gC4 p0Fg== X-Gm-Message-State: AG10YORUm3SGh+2MryI6xBMWRQKPNy2JPQctNQ6jTqEpZhuHQQQMT8I3qGvhwXMs+fXyYDgcV/jZHmMn/WIMTQ== MIME-Version: 1.0 X-Received: by 10.50.124.72 with SMTP id mg8mr6868333igb.22.1453529562925; Fri, 22 Jan 2016 22:12:42 -0800 (PST) Received: by 10.36.31.66 with HTTP; Fri, 22 Jan 2016 22:12:42 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 01:12:42 -0500 Message-ID: From: Jeffrey Walton To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 06:12:44 -0000 > MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept. > Imagine my surprise when I found not just one, but two RFCs describing > these options, both failing to mention the security properties they > had when trusted parties would be compromised, and in particular the > possibility of retroactive decryption in SAKKE. This should have been > noted by someone at some point. How do we make sure this doesn't > happen because reviews are being done by the wrong people? > Related, in mobile, we always consider infrastructure to be compromised. Anything that interacts with a carrier's network is burned. "Carrier's network" is wishful thinking. Your device will camp to the strongest signal. The network does not authenticate to the handset, so you don't even know what network you are on or who is controlling it. Also see Chris Paget's tricks with GNU Radio. Secure mobile architectures, like NSA's Fishbowl, effectively tunnel back to a server controlled by the organization. That's where VoIP and SIP services are terminated. See, for example,Section 2.1.1, Security Relevant Components, in the NSA Mobility Capability Package. Jeff From nobody Sat Jan 23 00:16:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0A1B33E8 for ; Sat, 23 Jan 2016 00:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 7DKN1iZL3Y6V for ; Sat, 23 Jan 2016 00:16:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DA11B303E for ; Sat, 23 Jan 2016 00:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1202; q=dns/txt; s=iport; t=1453536973; x=1454746573; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Z+me1WyLC3WaVdU3BNeirjhRiPvZrnOSzC7ZCVC60lU=; b=a7MZnj3mVvyC47IOcuam0awh1NZE110uVxMyGeN4nNJQcrEBAewaGyOP 5Ve7JSVMavVmRpHcpyFCb2Er4uXIZK+PTxrJiPzJ5j+aAPfviuHR3OUws CnqIR344AuBwyt7ZkU9RiSGZUrej+Z2lszda40T3ZnGdyaGQay0eAOtQI 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgAINqNW/xbLJq1ejVCyBw6BYoYPA?= =?us-ascii?q?oFlFAEBAQEBAQGBCoRCAQEEI1UBEAshFgsCAgkDAgECAUUGAQwIAQGIF68Fjn8?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDwiLH4dMgToBBJZ2gnmBY4h6iSaFU44/HgFDg?= =?us-ascii?q?2o7h1EBAQE?= X-IronPort-AV: E=Sophos;i="5.22,335,1449532800"; d="asc'?scan'208";a="631854749" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2016 08:16:10 +0000 Received: from [10.61.218.177] ([10.61.218.177]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0N8GAK3008707; Sat, 23 Jan 2016 08:16:10 GMT To: Bernard Aboba , Watson Ladd References: From: Eliot Lear Message-ID: <56A336C8.5070904@cisco.com> Date: Sat, 23 Jan 2016 09:16:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dxiA4suvbX7fxNFqDITjK8SfDlnR8OFIS" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 08:16:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dxiA4suvbX7fxNFqDITjK8SfDlnR8OFIS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the other hand, speaking as both a past WG chair and an author, I never refuse help on security considerations section. And here's a reminder: not everyone is security savvy, and even those who are could use a second, third, and fourth pair of eyes in that area. --dxiA4suvbX7fxNFqDITjK8SfDlnR8OFIS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWozbJAAoJEIe2a0bZ0nozkOIH/19+cEsJpXNppvkWAhzsPRSh fgeW+z4migMkDBcFgT4G5VsjGeU/kcL77m95WpVTV2e9xeAbTUAGCIUqjk95Z6Wb 84GIjQY786ieW+6n6IjS7gBsFyooav4fT7C+E+lPUJHaXZyx96Pyv2GOe9cuZs+a ySOe1AiPlSpyEUmyAXht60ckRRgn2X+aN6MtDLNuKVgdJQ9g/k6WKEGvFDuWRRNV SJ2ok9mR/zHJkKE19k3TbDBC4UDiQw0BGNubRQbVzX6aPsSBIypVsTZVvt5hx++7 yG3evS46H6rr7qdr/r9PrWigGKhyyQJXRfKy5bNlcng7zvWmQqDW0lHuNz3wugE= =KZsv -----END PGP SIGNATURE----- --dxiA4suvbX7fxNFqDITjK8SfDlnR8OFIS-- From nobody Sat Jan 23 09:07:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09351B39A3 for ; Sat, 23 Jan 2016 09:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GYj8vDt9bX-G for ; Sat, 23 Jan 2016 09:06:59 -0800 (PST) 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 C3FAE1B39A0 for ; Sat, 23 Jan 2016 09:06:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC36FBE39; Sat, 23 Jan 2016 17:06:55 +0000 (GMT) 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 VJ5TV4zPQPXc; Sat, 23 Jan 2016 17:06:54 +0000 (GMT) Received: from [10.87.48.83] (unknown [86.46.16.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2442BE53; Sat, 23 Jan 2016 17:06:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453568814; bh=kVwINcEq8EzCTFj2q4slLNqxk4jqXGAqlOU4cEWc0Ls=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0i8YrKsIAcrUH1QPEFiy/EGql+gmZbo3ja0j/g74S3qHByJugGhLzm3fTMuuYAFwy 1tQJGsmaFLYuH2gEz/GEfkr8JokpZKPCXwbD3Xi+0XzD3G5HnXTjYbAZAUwE5U4MMq OzQMjc0b5gthYEJn6qTzNqNGoQA1LdswUv2FYBBk= To: Watson Ladd , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <56A3B321.3020201@cs.tcd.ie> Date: Sat, 23 Jan 2016 17:06:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:07:01 -0000 Hi Watson, On 23/01/16 04:51, Watson Ladd wrote: > Dear all, > > MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept. Yes. Not that it's news of course;-) Mind you, afaik about the only users of those schemes are folks employed by those who tend to be doing the interception. If that's not the case, that'd definitely be interesting to know about. As Bernard noted, these are informational RFCs and hence don't fall under RFC2804, which says that we don't standardise LI. > Imagine my surprise when I found not just one, but two RFCs describing > these options, both failing to mention the security properties they > had when trusted parties would be compromised, and in particular the > possibility of retroactive decryption in SAKKE. This should have been > noted by someone at some point. How do we make sure this doesn't > happen because reviews are being done by the wrong people? Well, I don't think that's quite the right question. Phrases like "wrong people" isn't going to help, and in this case the people involved didn't do any wrong that I can see. What we need to do is ensure as far as possible (given we're dealing with volunteer effort) that drafts get good review. In these cases I'd say the review was ok-ish, but it predates my time on the IESG so I wasn't involved directly. If you're interested, the document histories [1,2] and the secdir review threads [3,4] are as visible as ever. I'm not sure but wouldn't be surprised if there had been previous discussion on some wg lists. But, similarly to the more recent case with IBS [5], it can be hard to get folks to review what can be perceived as odd corner-case crypto specs. The dual-ec fiasco of course does make that more clearly important than was the case when these documents were processed. In the case of [5], I'm still holding a discuss (>1 year later) [6] on the basis that the scheme hasn't had public review. It's probably fair to say that we're less tolerant of that lack now, than we were 5 years ago. But note that even in the case of [5], all that the authors now need to get me to unblock it is ack that public review will be one of the things that would be needed to get that spec on the standards track at some point. (I expect they may do that and an RFC will issue but we'll see.) So this will likely end up similar to [1,2] in that there will be an RFC describing a scheme vulnerable to a big brother, albeit not on the standards track, a distinction that is not well understood even within the IETF community sometimes. Changing that ("the difference between standards-track and other kinds of RFC") would be a fairly major undertaking, and not one that likely to succeed in a useful manner IMO. Lastly, in this case, if you (or anyone) think some specifications really ought to be updated, then you are entirely free to write an Internet-draft clarifying the situation that formally updates the RFC(s) in question. I'd certainly look positively on a draft that supplied important missing information about the security properties of these, (or any), IETF stream RFC. So if you (or anyone else) needs help/advice on how one might go about doing that, just send me offlist mail and I'll try help. In the meantime, thanks Watson for accepting my invite to join the secdir review process - that is certainly one way to try help improve things. Cheers, S. [1] https://datatracker.ietf.org/doc/rfc6509/history/ [2] https://datatracker.ietf.org/doc/rfc6267/history/ [3] https://www.ietf.org/mail-archive/web/secdir/current/msg02434.html [4] https://www.ietf.org/mail-archive/web/secdir/current/msg02036.html [5] https://mailarchive.ietf.org/arch/search/?email_list=cfrg&gbt=1&index=rlo4nJkqio4HnVzS9_OIq9__byQ [6] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ballot/ > > Sincerely, > Watson > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Sat Jan 23 09:53:06 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33361A1B0E for ; Sat, 23 Jan 2016 09:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Eg7TGjLXEorh for ; Sat, 23 Jan 2016 09:53:04 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id BA2131A1ACA for ; Sat, 23 Jan 2016 09:53:04 -0800 (PST) Received: from dummy.name; Sat, 23 Jan 2016 17:53:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Steve Crocker X-Mailer: iPhone Mail (12H143) In-Reply-To: <56A336C8.5070904@cisco.com> Date: Sat, 23 Jan 2016 12:53:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56A336C8.5070904@cisco.com> To: Eliot Lear Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:53:05 -0000 FWIW, as the first security area director, I created the SAAG to provide sec= urity expertise to working groups outside of the security area precisely bec= ause the concepts involved in security are different from functionality, whi= ch is usually the focus in the other areas, and because expertise was in sho= rt supply. We didn't develop specific standards or requirements initially. Maybe it's t= ime for such, even if only in lightweight form such as a checklist, eg "forw= ard security?", etc. Steve Sent from my iPhone > On Jan 23, 2016, at 3:16 AM, Eliot Lear wrote: >=20 > On the other hand, speaking as both a past WG chair and an author, I > never refuse help on security considerations section. And here's a > reminder: not everyone is security savvy, and even those who are could > use a second, third, and fourth pair of eyes in that area. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Jan 23 11:28:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB941AC43A for ; Sat, 23 Jan 2016 11:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 V_LjMKe-vSuU for ; Sat, 23 Jan 2016 11:28:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E521AC3E4 for ; Sat, 23 Jan 2016 11:28:29 -0800 (PST) Received: from [192.168.10.131] ([213.235.249.182]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LiHc7-1ZiWRe3gXb-00nOgH; Sat, 23 Jan 2016 20:28:18 +0100 To: Steve Crocker , Eliot Lear References: <56A336C8.5070904@cisco.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56A3D453.4050407@gmx.net> Date: Sat, 23 Jan 2016 20:28:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ErUCVMMq5jQCd8petJDmbxvU32FAOgWdD" X-Provags-ID: V03:K0:yqr8hLF6N6nY7Vbj6UJ/BQ71Tazo2MxqLS+OwQmfWeki3xzgioO QOuMHkahKJBscpRP1W8n9+hmyL9UXYI8/Hn5TqOTXqf5Dya4b8KS19/u6JM7Vyu5i5HExVh xjjYm+PmXNQE9ny05gLQmPYYdPc7H7XZDqpHv5aeTPdbtvMGCWCxioumhIpJ/o1L0LMMFWw orAeJZHPVr0DZAGO3I+2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:a9UUcNPQcZc=:8PRFFGJt2CGSjrFIvboNJq 1SF5ENhIZmPvxCRWmGJtSsJxR2CpJmWWV4L9ZbTi5BElO2XK8Z2ZFCz2XUKbpLbg9hn/juP0e HbAb1sB/dmXWNMZcdpRL0wDeDCjhC0zmmRxD9GskgckYBIryMEKhE3iRaMbhR3qaew5RQMtZ3 NRFvjGx3RPidmRccO2TM5zwEguGLdfkDUwi4S07e824WYHY8RAxG7CMs6h4RF0dtXEUqbnUdJ IBBkFmHbenwR0as0FuBJNoMlRFBSXsNbFx8ETjpj7JUbYlTlN/8Hv3o5maXcAt11G63AjXJlD 5NhP9umPBih5JWqcq6tbQ7Mfj9vKYHS/Z4GEcDI9VnmIY84u4e2JlERwJma+Sti2gdUCNcZ6+ 5mKalpzL8qcbhMl8cHls03atZZfXqVlADLXsBBpvbNVpuBw5dgqnuayChsSE9A/CPagrF1i3S rozfrTCck7Vk0UUd/YLOzchF+gtxhm0T1LmX89ppdIL83XH7cjrljB92hOzD8AM9GiPvtXi0i vVgfh2EdJ38+j+EkvCEf7NDGxLJ13CGLYq28yF/2jJ3Pzzqmt7zJSInxq1isBkQYrDC0zexAR fXWFMKaIflKwhS99n3I2cloklYUqAv54kzSeA+MWIi/T2y2UZJ7sZN9zYf79172h9srV80jtt IqSyag6ZJmCEMm4/3amBJRr/fCYtXfqKV2yVvBM6li/Pkdp0D+doJDqD1ZqcBISniY80aFzoQ LzkSwt4aL9YSGBPpDH08nE1S2Z7iSPtqQlYharHRMC/ANtklc+M5uARtYos= Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 19:28:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ErUCVMMq5jQCd8petJDmbxvU32FAOgWdD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Two issues: * The security area directorate reviews all documents but the assignment of reviewers to documents is sort of random. Hence, it is not necessarily ensured that the right expertise is available with the right reviewer. In this case, the reviewer of both documents was not a VoIP security expert. * The requirements for reviews change over time. There is a bit of history related to the VoIP work -- see my other email. It is sometimes difficult for the IETF to make decisions when it comes to certain business models. Just look at the discussions that relate to what network operators should be doing with traffic: https://www.iab.org/activities/workshops/marnew/ Ciao Hannes On 01/23/2016 06:53 PM, Steve Crocker wrote: > FWIW, as the first security area director, I created the SAAG to provid= e security expertise to working groups outside of the security area preci= sely because the concepts involved in security are different from functio= nality, which is usually the focus in the other areas, and because expert= ise was in short supply. >=20 > We didn't develop specific standards or requirements initially. Maybe i= t's time for such, even if only in lightweight form such as a checklist, = eg "forward security?", etc. >=20 > Steve >=20 > Sent from my iPhone >=20 >> On Jan 23, 2016, at 3:16 AM, Eliot Lear wrote: >> >> On the other hand, speaking as both a past WG chair and an author, I >> never refuse help on security considerations section. And here's a >> reminder: not everyone is security savvy, and even those who are could= >> use a second, third, and fourth pair of eyes in that area. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --ErUCVMMq5jQCd8petJDmbxvU32FAOgWdD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWo9RUAAoJEGhJURNOOiAtppQIAJ+Z+GumhtuLjg68L+lqJlQc zM7za/e6rwilMl7iLX9uXL/HomWX7elcXrOcyNMft+HYwLq1U06gnq62sqQmt54M T4p9U7IQzbSN9h/mqIwwNmyCDG4uJa6WqH4tOEu9SFdW4L6XwKzc/1fd0fDZ9kJ4 nEPHlODYYaDs6j9dvferLYIsWtoiSgXb06LpzQhHQcBMB1bnvZ50qqHKi7SsQz03 9kQ9H66iG9jHrmv2Ywe0VaYyN74jVXyTFKkDtx5vOJlN1CO4RHh9Lr46fRCzYPkR WnsKVgxye6Z93veLBHzzlve8be+cKwTZ3c/EDBT8xbzIYtPKJtcnW8RMZPH4QhE= =JQqt -----END PGP SIGNATURE----- --ErUCVMMq5jQCd8petJDmbxvU32FAOgWdD-- From nobody Sat Jan 23 11:28:44 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCFC1ACE09 for ; Sat, 23 Jan 2016 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 7BmybXo9i50r for ; Sat, 23 Jan 2016 11:28:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112E01ACDAB for ; Sat, 23 Jan 2016 11:28:36 -0800 (PST) Received: from [192.168.10.131] ([213.235.249.182]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MO7Ca-1aSXVl49bQ-005V9X; Sat, 23 Jan 2016 20:28:34 +0100 To: Watson Ladd , "saag@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56A3D464.8080300@gmx.net> Date: Sat, 23 Jan 2016 20:28:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HSbwI3D37gQN32S1eC16MWgTa6HwFW4a6" X-Provags-ID: V03:K0:/rCl8r5qU8KXyS/0yCE8oQBVT4D13EUueihrvqyLwfdZPBfJZGD /cx8c1xFi8pIzjW0EePmECRp0Ix7tWjyw//sunqiewTAYV5kPMv3r9vo0UqBzVl+8VmfsgH qtPNv1RMsAmDXspsInLG9xyQ9RbK9B9eaihXp01owfru93dWOjkATZhBam/NwZ9ZUpsjAkA pB2NE0j4FpMP40QFhsigw== X-UI-Out-Filterresults: notjunk:1;V01:K0:AODaIyeYgGw=:7ku1sPBTO4WIwYPvxfWPBA SCyZFK6g+QArSAMFu5VWSWFxFiwC6YpysnBf4Vwp10fcGjhaAlQ4b8A4bryEYsU9LvBX+IyVa Z1X2eKouY+q2z1wVp9D9LiqYM1S4F+snyr5d9P1Wdj/sHe/bHq73XuaR1+LNS0IT/NSPL7n4o 7y+qDkgINLQ9u+4VfJl4+avWSc55S9JGhVnWL5ddNrhH04cMtsel4qTxynR0eGnUKMYNQWoAW w7RAZr6tYkd8WZ6A2hi2w6Oo5aVo6l1Ja9xk9eb2VO5tGzn8Q3XBH+8OA9a+STnst8ijvOATJ yWJx8HlhetC6+6vD9a4nIWHYRH+NxB9cTCFdlZtFDvSjFF4ZqoM4RT2XHV/KINbaq9rCWLx4o kUs/s9dHqPbzkBMAYqXDqTQWEz98ig1SKe0NKVUJ0D52NiLkCuNipQXWwCmVlapWPIycb9Ksm m+ihENIdKQR6PVHu0x02HPzqoPdRSnBCl6ICp2TlJ0NHjASUQkcEF14M1ekkWN9Yfhq/LZuAS wmg4q4sc0miHBhK2zc390YsUiWWErn464hU2Na2uXuIF3xO+qZBR2dJqES2ehtnp8KzaZeOSd AOU2rPhgdLjiqOXdIbNhHMDpHCdP5T/7L2hBt2vRbNqSN3OTdtkU4onmP4gacPdTXhZ/TUdgA CxcS9tQMp0lpM/+GODiRfJRuAdu7A4jq539eekg5aZcQkgwU/XANFGY6zEl+sAmsevMOGpjgb h9Ln7/utFyi2bI2spL9kPXRrRiupvkAmOzq3lBlH20/KO7aRoR92vI3kvqw= Archived-At: Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 19:28:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HSbwI3D37gQN32S1eC16MWgTa6HwFW4a6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [A personal note on this subject.] Hi Watson, I worked on VoIP security and contributed various specifications to that topic. At that time, there was the desire to accomplish an alignment between the 3GPP and the IETF. But, as you can imagine, the requirements were somewhat different and a few companies in the 3GPP had the desire to consider lawful intercept in the design of their solution. In the end both organizations went into a different direction but the MIKEY RFC required extensions to go through the IETF process. Several organizations, companies & persons wanted their own VoIP security extensions standardized, which required folks in the IETF to-do a fair amount of work for something nobody (in the IETF) was interested in. Recognizing the problems these rules were relaxed, see https://tools.ietf.org/html/rfc6309 But before those rules got relaxed various specifications were processed by the IETF*. They unfortunately received only minimal review but got published through the Standards Track and were shepherded by area directors. Unfortunately, these circumstances were not noted in the publication of those RFCs and now it appears that those documents had gone through a fair amount of review (and that those solutions are even endorsed by the IETF). Needless to say that this far from the through. Just as one data point, I commented on this difficult situation in a mail early 2012: https://www.ietf.org/mail-archive/web/emu/current/msg01844.html I believe there is a lesson to be learned for the future, namely to more clearly indicate the history of documents and the level of review documents have received. While it may be obvious to those who were involved in the work at that point in time it is less so after a few years by external parties. When you search for reviews done in the IETF for these specifications then it is clear that very little had been done. I wonder whether the IESG should have published a document with so little review as an Informational RFC through the Standards Track process. Ciao Hannes PS: I do not fully understand why MIKEY-SAKKE was published as an information RFC through the Standards Track process given that the IANA rules were relaxed already months before the publication of MIKEY-SAKKE. On 01/23/2016 05:51 AM, Watson Ladd wrote: > Dear all, >=20 > MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept. > Imagine my surprise when I found not just one, but two RFCs describing > these options, both failing to mention the security properties they > had when trusted parties would be compromised, and in particular the > possibility of retroactive decryption in SAKKE. This should have been > noted by someone at some point. How do we make sure this doesn't > happen because reviews are being done by the wrong people? >=20 > Sincerely, > Watson >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --HSbwI3D37gQN32S1eC16MWgTa6HwFW4a6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWo9RkAAoJEGhJURNOOiAtXn8H/1em4ZefglvuYIYDVRx0EcF5 5DoDSdMyToppiWsOjmRc+oFqe6fiNLuH3S5yksrc/APp4UraGddzHb3rUkElWhtO p5MGIyFZ9DJ6zee8dzxcEpNMleUL79C417tqtuRfx5X3HS7aMzatCXy4whW7NPDr /JrgD/DQkWPfe8RALMxB+fr1BLhxhxonBVSP3+ERNIcepF9P8dMgpaTcPXqeBS4I hdZrlb6VrpGaUsGz4oHb2NQ/joBwuxHd2ohTW4QILyNHluPAsUwqL5Ioc7Bdlong xy5xfccAr6DclOjoNEZnTUV8yy/z37IKVIsD/3yb841obeNXJO78fNqYUKEczic= =XvIJ -----END PGP SIGNATURE----- --HSbwI3D37gQN32S1eC16MWgTa6HwFW4a6-- From nobody Tue Jan 26 05:33:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78111A8A4D for ; Tue, 26 Jan 2016 05:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] 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 a_b23HyCqPNx for ; Tue, 26 Jan 2016 05:33:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8711A8A3C for ; Tue, 26 Jan 2016 05:33:46 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u0QDXeRG001126 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2016 15:33:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u0QDXd9P016307; Tue, 26 Jan 2016 15:33:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22183.30131.845899.845275@fireball.acr.fi> Date: Tue, 26 Jan 2016 15:33:39 +0200 From: Tero Kivinen To: Hannes Tschofenig In-Reply-To: <56A3D453.4050407@gmx.net> References: <56A336C8.5070904@cisco.com> <56A3D453.4050407@gmx.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Woefully deficient security considerations section. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 13:33:49 -0000 Hannes Tschofenig writes: > * The security area directorate reviews all documents but the assignment > of reviewers to documents is sort of random. Hence, it is not > necessarily ensured that the right expertise is available with the right > reviewer. In this case, the reviewer of both documents was not a VoIP > security expert. Actually that is partially by design. If we pick someone who is familiar with the area (i.e. VoIP expert) he is most likely already involved with the document, i.e., it is very likely that he has reviewed the draft and thinks it ok. Completely new fresh security review might find completely new issues in the draft, especially as that new reviewer do not assume that much on the things outside the spec. I.e. there has been reviews saying, I do not see how this protocol protects against X, it might be somewhere, but I cannot see it from this spec. And then we either might find out that yes, there is another document which is used with this and that protect from X (and add that to security considerations section), or we might notice that no, there actually is nothing there to protect from X. Of course if you are security expert in some protocol or area, you should really review all protocols related to that regardless whether they are going to be assigned for you in secdir or not. I myself for example try to review all IKE and IPsec related drafts. I do hope that others do similar things. You can also do secondary secdir review if you think you have something to say on the subject even if you are not assigned as reviewer, and if you send email to secdir-secretary@mit.edu, I can also give you credit for your review, i.e. mark you on the list that you will be skipped next time you do review... -- kivinen@iki.fi