From nobody Thu May 1 08:02:56 2014 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 6B6B61A6F74 for ; Thu, 1 May 2014 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 yj9D3HWv-bOm for ; Thu, 1 May 2014 08:02:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE0DA1A6F7F for ; Thu, 1 May 2014 08:02:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8C6DBE70 for ; Thu, 1 May 2014 16:02:46 +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 EFHT6JB8EYQh for ; Thu, 1 May 2014 16:02:46 +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 1B296BE6E for ; Thu, 1 May 2014 16:02:46 +0100 (IST) Message-ID: <53626216.6070903@cs.tcd.ie> Date: Thu, 01 May 2014 16:02:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140501145735.18958.1971.idtracker@ietfa.amsl.com> In-Reply-To: <20140501145735.18958.1971.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wSihwybTnlRJSrkOp_8-_RWD9fo Subject: [saag] Fwd: Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC 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: Thu, 01 May 2014 15:02:55 -0000 FYI, this was discussed briefly here and has been discussed on the old secsh (ssh) WG mailing list. IETF LC has started. S -------- Original Message -------- Subject: Last Call: (Using ED25519 in SSHFP Resource Records) to Informational RFC Date: Thu, 01 May 2014 07:57:35 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Using ED25519 in SSHFP Resource Records' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. The file can be obtained via http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ballot/ No IPR declarations have been submitted directly on this I-D. Note that there is no current standardised format for the input to the hash function here, but there are two implementations of this so a codepoint is needed and useful. A standard public key format is likely to be developed in future (but could take some time) at which point it may make sense to assign another codepoint, but there are no issues with codepoint scarcity here so that seems like it will work given the implemeners seem ok with it, even if its not ideal. From nobody Thu May 1 13:38:29 2014 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 0FE1B1A6FDB for ; Thu, 1 May 2014 13:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 aE2-GmYHu_Ml for ; Thu, 1 May 2014 13:38:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id BDBC91A0976 for ; Thu, 1 May 2014 13:38:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8671F4824C; Thu, 1 May 2014 20:38:22 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 7B0DC48242; Thu, 1 May 2014 20:38:22 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 5F01647BF0; Thu, 1 May 2014 20:38:22 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 1 May 2014 16:38:21 -0400 From: "Salz, Rich" To: ianG , "saag@ietf.org" Date: Thu, 1 May 2014 16:38:20 -0400 Thread-Topic: [saag] Please review draft-iab-crypto-alg-agility-00.txt Thread-Index: Ac9kBnrz6sdkdWdQTJq2Kag6cNoghwBdm10w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> In-Reply-To: <53603BDD.2080109@iang.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PpKnsy14tvhT1Xq4li64rf55lZw Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt 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: Thu, 01 May 2014 20:38:26 -0000 > But *algorithm agility is a bad practice*. It should not be encouraged, = IMHO. I disagree. We don't have flag days any more, and there will always be a se= t of entities that want to communicate and will have to work their way thro= ugh a list to find a common tongue. Does it matter if we call it "TLS-A" "= TLS-B"... Or if we call it "TLS 1 with aes, 3des, ..." ? Either way, we h= ave millions of items in a deployed base, updated at different times and cy= cles (if at all) and their users want them to communicate as best as they c= an. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 02:52:30 2014 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 83EB21A09A6 for ; Fri, 2 May 2014 02:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=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 D6CrudaZnMoS for ; Fri, 2 May 2014 02:52:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847A1A09FD for ; Fri, 2 May 2014 02:52:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.56]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s429q8vp028650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2014 02:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399024342; bh=vl8JZW1l3V9D6bbIcxZR38wYBxK71rETG6wJu7B8I4A=; h=Date:To:From:Subject:In-Reply-To:References; b=gzt+YFuNG8S8Fg0Hnf5U/SYIQrPhVO45Q0JuLyymHwWNp4Ndtwd1zwAgpo2GBu/hY eAeF8l6mIIZDTX7zw1WMPNaEHZEAbIrPELCGR9Duu24C9L5i52XybkT7+KeRwWJ15h w7e/MITsfMI+rw+Q5LIHA05/TOXMzh03NhuyUj5k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399024342; i=@elandsys.com; bh=vl8JZW1l3V9D6bbIcxZR38wYBxK71rETG6wJu7B8I4A=; h=Date:To:From:Subject:In-Reply-To:References; b=JYSttYqhhTmS+JN0FVoQGKRXMtvSCZALOEUAc8GnRGH8APJe8LS+Z9bEdAPnijiBw 0nBfoPjQrwx1FiCmOaekkxuwkgXfRC6/kX3ZelL9nnRYkCOLLbcpIHCPkp8xhUMuMr S1lYgw78YJ1u+wn/pll1D20QZb/AzIVAepp5st/k= Message-Id: <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 May 2014 02:13:18 -0700 To: "Salz, Rich" , ianG , saag@ietf.org From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp .akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/upLsWv5RG9OCuyYUEhkAqXRBuNs Subject: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 09:52:28 -0000 Hi Rich, At 13:38 01-05-2014, Salz, Rich wrote: > > But *algorithm agility is a bad practice*. It should not be > encouraged, IMHO. > >I disagree. We don't have flag days any more, and there will always >be a set of entities that want to communicate and will have to work >their way through a list to find a common tongue. Does it matter if >we call it "TLS-A" "TLS-B"... Or if we call it "TLS 1 with aes, >3des, ..." ? Either way, we have millions of items in a deployed >base, updated at different times and cycles (if at all) and their >users want them to communicate as best as they can. There is the interoperability aspect. It's where the two sides enter into a security negotiation which can end up as better than nothing security. In other words, a little security is better than no security. The argument for that is, as mentioned about, the difficulty in making any changes to the deployed base. Despite the news about some national security agility the current trend in the IETF still looks like business as usual. The user wants to communicate with as many items as possible, and safely if that's cheap. There are, what I assume to be, a small number of users who will do the same thing as everyone else and presume that it is safe because that's the existing practice. That's where the algorithm agility gives me a security property which is inherently unsafe. Does it matter whether we call it "TLS-A" "TLS-B" ...? Yes. B is after A and it is safer. :-) Does it matter if we call it "TLS 1 with aes, 3des, ..."? That's a long list of strings. I do not understand the meaning of those strings. Regards, S. Moonesamy P.S. Our previous (unrelated) exchange and this subject could be questions about architecture. From nobody Fri May 2 05:44:44 2014 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 7038E1A6FB3 for ; Fri, 2 May 2014 05:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 1wKVA0fcW9wc for ; Fri, 2 May 2014 05:44:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 172231A0764 for ; Fri, 2 May 2014 05:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=450; q=dns/txt; s=iport; t=1399034678; x=1400244278; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=8TXRtTsbO+8CWzS71ay4dcN7VbpKnrPefye3jByDvvc=; b=IvR+UPKOjsDTkRqeGJ54AvnWF8ugnk/ajpcVJ+8TnLbwEicrxu1VofaI oCh5qaaSSr3eE27r6EVF0f6Gks8/R7/4on9a1uW4o9SbAV3jK7nVlQWzk FTsjb/MPppagnRIaQ/bRgrnV/Zjr/HONYIj8sTr16jlDckUlAHSmSfmGW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAJ+SY1OQ/khN/2dsb2JhbABagwaEDcFmgRAWdIIlAQEBBCNVEQsYAgIFFgsCAgkDAgECAUUGAQwIAQGIPaVYo3QXgSqNL4JvgUoBA5kwkm+DNjs X-IronPort-AV: E=Sophos;i="4.97,972,1389744000"; d="scan'208";a="35284331" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 02 May 2014 12:44:37 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.168.58]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s42Ciaqj011873; Fri, 2 May 2014 12:44:36 GMT Message-ID: <53639338.6000605@cisco.com> Date: Fri, 02 May 2014 14:44:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <53603BDD.2080109@iang.org> In-Reply-To: <53603BDD.2080109@iang.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AV6LmU8g7dFx-WILg-Vbni-Ixzs Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt 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: Fri, 02 May 2014 12:44:43 -0000 On 4/30/14, 1:55 AM, ianG wrote: > In general, I understand that many IETF algorithms make use of the > practice of algorithm agility. And therefore there is a need to > document and improve that situation overall. > > But *algorithm agility is a bad practice*. It should not be encouraged, > IMHO. Hence the major criticism of the document is that it appears to > promote a bad practice. Can you say why you think it's bad? Eliot From nobody Fri May 2 06:44:11 2014 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 8C1D91A2119 for ; Fri, 2 May 2014 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 5f1TWTE9DQRr for ; Fri, 2 May 2014 06:44:07 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 400341A08F7 for ; Fri, 2 May 2014 06:44:07 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D8EB7165660; Fri, 2 May 2014 13:44:04 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id CE1D7165657; Fri, 2 May 2014 13:44:04 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B51C21E0D2; Fri, 2 May 2014 13:44:04 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 2 May 2014 09:44:03 -0400 From: "Salz, Rich" To: S Moonesamy , "saag@ietf.org" Date: Fri, 2 May 2014 09:44:03 -0400 Thread-Topic: Algorithm agility (was: [saag] Please review draft-iab-crypto-alg-agility-00.txt) Thread-Index: Ac9l7DlJw60Nc0xvTnCgi0ciw8ErfgAH//IA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> In-Reply-To: <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/37r48qZYs9Uri85a1diamqESv1A Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 13:44:08 -0000 > Does it matter whether we call it "TLS-A" "TLS-B" ...? Yes. B is after = A and it is safer. :-) But 3DES is better than the newer RC4. I know you put a smiley there, but = TLS-A / TLS-B is just a list of strings too, in reality. > There are, what I assume to be, a small number of users who will do the s= ame thing as everyone else and presume that it is safe because that's the e= xisting practice. That's where the algorithm agility gives me a security p= roperty which is inherently unsafe. I don't understand your logic here. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 06:54:56 2014 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 92F861A6FBC for ; Fri, 2 May 2014 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HZUuH8GTS-Uf for ; Fri, 2 May 2014 06:54:53 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 340FF1A0816 for ; Fri, 2 May 2014 06:54:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 3D5C06D607; Fri, 2 May 2014 09:54:46 -0400 (EDT) Message-ID: <5363A3A4.7020404@iang.org> Date: Fri, 02 May 2014 14:54:44 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/q2ZkqZxamchyfNLoLY6BQxDFVyo Subject: Re: [saag] Algorithm agility 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: Fri, 02 May 2014 13:54:54 -0000 On 2/05/2014 14:44 pm, Salz, Rich wrote: >> Does it matter whether we call it "TLS-A" "TLS-B" ...? Yes. B is after A and it is safer. :-) > > But 3DES is better than the newer RC4. Only if you narrow your context down to some group of cryptographers advancing their art, or some immense world war of nation states cracking each others' codes. Meanwhile, back on the Internet, 3DES is the same as RC4, for the purposes of the people. > I know you put a smiley there, but TLS-A / TLS-B is just a list of strings too, in reality. Yes, they are. But they are a simple set to negotiation. Pick the latest, move on. They are self-ordered and self-cleansing. >> There are, what I assume to be, a small number of users who will do the same thing as everyone else and presume that it is safe because that's the existing practice. That's where the algorithm agility gives me a security property which is inherently unsafe. > > I don't understand your logic here. I read it as, everyone (statistically) will follow the default. So stop the nonsense, get rid of everything by the default, and everyone (statistically) will get a better deal. iang From nobody Fri May 2 06:55:32 2014 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 6B0561A6FB4 for ; Fri, 2 May 2014 06:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uU3xhCBj7bhn for ; Fri, 2 May 2014 06:55:28 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 774D11A0816 for ; Fri, 2 May 2014 06:55:28 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id AE81D6D607; Fri, 2 May 2014 09:55:25 -0400 (EDT) Message-ID: <5363A3CC.4020904@iang.org> Date: Fri, 02 May 2014 14:55:24 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eliot Lear , saag@ietf.org References: <53603BDD.2080109@iang.org> <53639338.6000605@cisco.com> In-Reply-To: <53639338.6000605@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wdXMvKcXaSqJ42OTnHwRviX4W3g Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt 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: Fri, 02 May 2014 13:55:29 -0000 On 2/05/2014 13:44 pm, Eliot Lear wrote: > > On 4/30/14, 1:55 AM, ianG wrote: >> In general, I understand that many IETF algorithms make use of the >> practice of algorithm agility. And therefore there is a need to >> document and improve that situation overall. >> >> But *algorithm agility is a bad practice*. It should not be encouraged, >> IMHO. Hence the major criticism of the document is that it appears to >> promote a bad practice. > > Can you say why you think it's bad? I'd love to and really should but have run out of time. Points are emerging in debate tho. iang From nobody Fri May 2 07:25:58 2014 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 865801A6FFB for ; Fri, 2 May 2014 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 JBuWm0Ioqb12 for ; Fri, 2 May 2014 07:25:55 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8D1A6FE0 for ; Fri, 2 May 2014 07:25:55 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 46B464827E; Fri, 2 May 2014 14:25:53 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3AC3E48278; Fri, 2 May 2014 14:25:53 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 1829F47BEE; Fri, 2 May 2014 14:25:53 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 2 May 2014 10:25:52 -0400 From: "Salz, Rich" To: ianG , "saag@ietf.org" Date: Fri, 2 May 2014 10:25:51 -0400 Thread-Topic: [saag] Algorithm agility Thread-Index: Ac9mDkYEemZcuTqITG66Lo/+F1E5ywAAcf7w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C177@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <5363A3A4.7020404@iang.org> In-Reply-To: <5363A3A4.7020404@iang.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qYRK665KVXUREY5KVDBgVh_A2Y0 Subject: Re: [saag] Algorithm agility 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: Fri, 02 May 2014 14:25:56 -0000 > Meanwhile, back on the Internet, 3DES is the same as RC4, for the purpose= s of the people. Hunh? One of the reasons why I am in favor of agility is from a software engineer= ing perspective. If you keep the data structures the same (when possible) = but only change the algorithm, then you only have to write the parsing and = generating code once, and dispatch off to a crypto library for the appropri= ate pieces. And the amount of code that I have to keep "secure", and worry = about things like constant-time and key exposure, is much less. If, however, you are putting out a new version every time you want to use n= ew crypto, then there will be immense pressure to change the data structure= s to "fix some defects" or "add an optimization." (RFC 893, anyone?) When t= hat happens, the job gets bigger as does the attack surface; we have to rem= ind everyone to think carefully about padding again, for example. Now, thi= s may not happen, but it could and the chance of really bad failure is pret= ty big. And the dispatch is now based on the data structure version and mus= t be carried throughout (or have spaghetti code), as opposed to localized. = Maybe you know of widely-used crypto packages that wouldn't fall into this = trap, but I don't. > Yes, they are. But they are a simple set to negotiation. Pick the lates= t, move on. They are self-ordered and self-cleansing. But as history shows us, advances in crypto aren't strictly linear. We've j= ust been through a period of whipsawing with Lucky-13, BEAST, and Crime. Wh= at's the likely cognitive dissonance and mass confusion when we advise ever= yone: "do TLS-B, no TLS-C, no sorry, back to B or maybe C depending." So crypto agility can make configuration harder (but auto-updating browsers= help), but I firmly believe that they make the underlying code more stable= , and therefore more secure. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 07:42:52 2014 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 A6F861A6FF5 for ; Fri, 2 May 2014 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] 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 OgHPq5ke13TI for ; Fri, 2 May 2014 07:42:48 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 764601A6FF4 for ; Fri, 2 May 2014 07:42:48 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA25321; Fri, 2 May 2014 10:42:44 -0400 (EDT) Date: Fri, 2 May 2014 10:42:44 -0400 (EDT) From: Mouse Message-Id: <201405021442.KAA25321@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 2 May 2014 10:36:27 -0400 (EDT) To: saag@ietf.org In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dUIyrkelPbBawWO9iBgm2vUBeFc Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 14:42:49 -0000 >> Yes. B is after A and it is safer. :-) > But 3DES is better than the newer RC4. In what respects? That's a rhetorical question. The point behind it is that not everyone - not every application, not every user, not every protocol - has the same tradeoffs. I can easily think of applications for which I'd prefer 3DES over arc4 and just as easily think of others for which I'd prefer the other way around. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Fri May 2 07:45:29 2014 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 96EFD1A09E8 for ; Fri, 2 May 2014 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 T3JIZJkKv7mS for ; Fri, 2 May 2014 07:45:26 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2281A08DE for ; Fri, 2 May 2014 07:45:26 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5A77448287; Fri, 2 May 2014 14:45:24 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4F048482C1; Fri, 2 May 2014 14:45:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 355E72FD61; Fri, 2 May 2014 14:45:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 2 May 2014 10:45:23 -0400 From: "Salz, Rich" To: Mouse , "saag@ietf.org" Date: Fri, 2 May 2014 10:45:23 -0400 Thread-Topic: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) Thread-Index: Ac9mFMxkR/X8oR/yR+Ca/KVBg/cVLAAAEZfQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C1A5@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <201405021442.KAA25321@Chip.Rodents-Montreal.ORG> In-Reply-To: <201405021442.KAA25321@Chip.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hsOGQ0UH91FB5VSTGakL-k0DFdY Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 14:45:27 -0000 > That's a rhetorical question. The point behind it is that not everyone -= not every application, not every user, not every protocol - has the same t= radeoffs. I can easily think of applications for which I'd prefer 3DES ove= r arc4 and just as easily think of others for which I'd prefer the other wa= y around. Isn't this another reason why agility is needed? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 07:46:12 2014 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 726A91A6FCE for ; Fri, 2 May 2014 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] 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 cAJR0K0t4d6k for ; Fri, 2 May 2014 07:46:09 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9A1A09E8 for ; Fri, 2 May 2014 07:46:09 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA09280; Fri, 2 May 2014 10:46:00 -0400 (EDT) Date: Fri, 2 May 2014 10:46:00 -0400 (EDT) From: Mouse Message-Id: <201405021446.KAA09280@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 2 May 2014 10:43:09 -0400 (EDT) To: saag@ietf.org In-Reply-To: <5363A3CC.4020904@iang.org> References: <53603BDD.2080109@iang.org> <53639338.6000605@cisco.com> <5363A3CC.4020904@iang.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RYOeI-FyIGo27rHlBVPJEiJA67A Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt 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: Fri, 02 May 2014 14:46:10 -0000 >>> But *algorithm agility is a bad practice*. >> Can you say why you think it's bad? > I'd love to and really should but have run out of time. So all we have to go on is your assertion that it's bad. I for one find that rather unconvincing, especially in view of the benefits I've seen arise from it in the case I know well (SSH) that does have algorithm negotiation baked into the protocol. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Fri May 2 07:50:35 2014 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 37BAE1A7008 for ; Fri, 2 May 2014 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lO_x5opMGFrh for ; Fri, 2 May 2014 07:50:32 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 163261A700D for ; Fri, 2 May 2014 07:50:32 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C67876D5FB; Fri, 2 May 2014 10:50:26 -0400 (EDT) Message-ID: <5363B0B0.6090707@iang.org> Date: Fri, 02 May 2014 15:50:24 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <201405021442.KAA25321@Chip.Rodents-Montreal.ORG> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C1A5@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C1A5@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_oyVPrfPNcpYW2f17hjDSSYlP3g Subject: Re: [saag] Algorithm agility 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: Fri, 02 May 2014 14:50:33 -0000 On 2/05/2014 15:45 pm, Salz, Rich wrote: >> That's a rhetorical question. The point behind it is that not everyone - not every application, not every user, not every protocol - has the same tradeoffs. I can easily think of applications for which I'd prefer 3DES over arc4 and just as easily think of others for which I'd prefer the other way around. > > Isn't this another reason why agility is needed? No, it's a reason why it is a nice to have. Need is a higher barrier. iang From nobody Fri May 2 07:51:29 2014 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 D4BE91A700D for ; Fri, 2 May 2014 07:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vl2xvIbB7x2E for ; Fri, 2 May 2014 07:51:26 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id BC5BA1A6FF4 for ; Fri, 2 May 2014 07:51:26 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 46BDD6D4B1; Fri, 2 May 2014 10:51:24 -0400 (EDT) Message-ID: <5363B0EA.1040309@iang.org> Date: Fri, 02 May 2014 15:51:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <53603BDD.2080109@iang.org> <53639338.6000605@cisco.com> <5363A3CC.4020904@iang.org> <201405021446.KAA09280@Chip.Rodents-Montreal.ORG> In-Reply-To: <201405021446.KAA09280@Chip.Rodents-Montreal.ORG> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LJwqAGDhtWTxMwnb_JYQdBJHn20 Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt 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: Fri, 02 May 2014 14:51:28 -0000 On 2/05/2014 15:46 pm, Mouse wrote: >>>> But *algorithm agility is a bad practice*. >>> Can you say why you think it's bad? >> I'd love to and really should but have run out of time. > > So all we have to go on is your assertion that it's bad. I for one > find that rather unconvincing, especially in view of the benefits I've > seen arise from it in the case I know well (SSH) that does have > algorithm negotiation baked into the protocol. Yep. Apologies. I understand that the words written aren't a cohesive case against. iang From nobody Fri May 2 07:55:44 2014 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 B9FB81A7011 for ; Fri, 2 May 2014 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 ZPYrOycsX2yM for ; Fri, 2 May 2014 07:55:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4F1A700A for ; Fri, 2 May 2014 07:55:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C0FC6474F0; Fri, 2 May 2014 14:55:39 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B4711474E8; Fri, 2 May 2014 14:55:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id AE74C2026; Fri, 2 May 2014 14:55:39 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 2 May 2014 10:55:39 -0400 From: "Salz, Rich" To: ianG , "saag@ietf.org" Date: Fri, 2 May 2014 10:55:38 -0400 Thread-Topic: [saag] Algorithm agility Thread-Index: Ac9mFeFC72jczB4JReOYs5XpyysRZgAAGCgQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C1BB@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <201405021442.KAA25321@Chip.Rodents-Montreal.ORG> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C1A5@USMBX1.msg.corp.akamai.com> <5363B0B0.6090707@iang.org> In-Reply-To: <5363B0B0.6090707@iang.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/G8VWfdUYdxf__KjrMdT6rh85Rw8 Subject: Re: [saag] Algorithm agility 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: Fri, 02 May 2014 14:55:43 -0000 > No, it's a reason why it is a nice to have. Need is a higher barrier. Agree with the second, but as for the first... reasonable people may disagr= ee. I find the risks I outlined earlier more compelling, and the belief th= at things are more secure without it to be just that, a belief. I think I'v= e said all I have to on this. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 08:27:39 2014 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 954FC1A6FF5 for ; Fri, 2 May 2014 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HJwKdhuQqrsn for ; Fri, 2 May 2014 08:27:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7A91A09AF for ; Fri, 2 May 2014 08:27:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A31212AB05D; Fri, 2 May 2014 15:27:33 +0000 (UTC) Date: Fri, 2 May 2014 15:27:33 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140502152733.GH27883@mournblade.imrryr.org> References: <53603BDD.2080109@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53603BDD.2080109@iang.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ms0e8ZPlIeTqwNwnedStavB-yHQ Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:27:38 -0000 On Wed, Apr 30, 2014 at 12:55:09AM +0100, ianG wrote: > But *algorithm agility is a bad practice*. It should not be encouraged, > IMHO. Hence the major criticism of the document is that it appears to > promote a bad practice. I can't in all honesty take this seriously. The problem with agility in TLS, for example, is that the protocol is very popular, and thus each constituency, unsurprisingly, wants to inject their own set of algorithms, and yet we try to interoperate, so everyone carries the kitchen sink. This is much more a consequence of ubiquity, rather than bad design. SSH also has agility but is not a general-purpose transport security library, has agility, but the algorithm bloat is manageable, the same is mostly true of PGP. If you build a Skype-like single source closed application, you can dispense with algorithm negotiation and support a very short sliding window protocol versions, with a fixed algorithm for each. A protocol that is used in a small number applications gets to stay pure. A protocol that is used by everyone grows barnacles. That's the cost of success. -- Viktor. From nobody Fri May 2 09:51:38 2014 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 4E8DE1A7D84 for ; Fri, 2 May 2014 09:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=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 nMPvv3FCblJz for ; Fri, 2 May 2014 09:51:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C42391A08E6 for ; Fri, 2 May 2014 09:51:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.56]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s42GpJ13012918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2014 09:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399049491; bh=3h7CMayit7cJSjzSYKm+6eGXp+GrzXQ3g2qD+kosUEo=; h=Date:To:From:Subject:In-Reply-To:References; b=ALr+va1EVxBNaCoUoKI+ABrhjeSsRzfn0OEwZWsHDAeTi8INKfoN9zF3HWf3JOMhE QcKvrr70XXGISAZ9+sVXt3WNpCO281L0WV41Jrm/wCUKYTFcMM3ewFdtHJfKZWjerZ i0uwvjjC6OQHH/B03cw1LtFTNZSsiWtyoxGGXTRU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399049491; i=@elandsys.com; bh=3h7CMayit7cJSjzSYKm+6eGXp+GrzXQ3g2qD+kosUEo=; h=Date:To:From:Subject:In-Reply-To:References; b=XdEXRa4/LygkFHuLAA04TEJkBPgY7EIDbaSO+c6Ogf+4Guy2udCkcNlemWZT2WOuz 3eQ5IHM4l31D0Fesf5eS0d0iH63E2Cs0WqkArQNRjSiwoDIRZETdQC1P0I0VDa39Jw HOsUIy+JThwOEnCxnOc2AyTPH/GRJgNSswZAVqUM= Message-Id: <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 May 2014 08:57:24 -0700 To: "Salz, Rich" , saag@ietf.org From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp .akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mVNNam-hKhHhRIecoMjFTvSTlSY Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 16:51:37 -0000 Hi Rich, At 06:44 02-05-2014, Salz, Rich wrote: >But 3DES is better than the newer RC4. I know you put a smiley >there, but TLS-A / TLS-B is just a list of strings too, in reality. Here's a list of strings: ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA PSK-3DES-EDE-CBC-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA ECDH-RSA-RC4-SHA ECDH-ECDSA-RC4-SHA RC4-SHA RC4-MD5 PSK-RC4-SHA EXP-RC4-MD5 I'll trim the list to exclude RC4: ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA PSK-3DES-EDE-CBC-SHA Most people won't be able to figure out which of the above strings are unsafe. I agree that TLS-A / TLS-B are merely strings. It is easier to follow "must implement TLS-B". >I don't understand your logic here. I hope the above explains the choices being given to the user. The is a message about crypto which was posted today ( https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html ). Regards, S. Moonesamy From nobody Fri May 2 10:38:38 2014 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 DF41D1A6F9A for ; Fri, 2 May 2014 10:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ag1Gw05LdIEH for ; Fri, 2 May 2014 10:38:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 69A191A6F88 for ; Fri, 2 May 2014 10:38:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B1E3B2AB05D; Fri, 2 May 2014 17:38:30 +0000 (UTC) Date: Fri, 2 May 2014 17:38:30 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140502173830.GJ27883@mournblade.imrryr.org> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mMxi_UjmSjcGUp2cpuPaPw8Kk-g Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 17:38:36 -0000 On Fri, May 02, 2014 at 08:57:24AM -0700, S Moonesamy wrote: > Most people won't be able to figure out which of the above strings are > unsafe. I agree that TLS-A / TLS-B are merely strings. It is easier to > follow "must implement TLS-B". GnuTLS tackles this problem by giving names to collections of ciphersuites that signal the requisite security level. OpenSSL is also moving in that direction, and Postfix which uses OpenSSL also encourages users to use named cipher grades, whose underlying cipherlists are for experts only. This is user-interface issue, applications that expose raw cipher names to users as the primary interface have poor user interfaces. -- Viktor. From nobody Fri May 2 11:43:44 2014 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 06B8A1A0913 for ; Fri, 2 May 2014 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 5GIuz5Hmye0Z for ; Fri, 2 May 2014 11:43:42 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06F1A0911 for ; Fri, 2 May 2014 11:43:42 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 54EC0482CC for ; Fri, 2 May 2014 18:43:39 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 49724482B6 for ; Fri, 2 May 2014 18:43:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 302459803D for ; Fri, 2 May 2014 18:43:39 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 2 May 2014 14:43:38 -0400 From: "Salz, Rich" To: "saag@ietf.org" Date: Fri, 2 May 2014 14:43:36 -0400 Thread-Topic: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) Thread-Index: Ac9mLWuwBiFKV40+Tyi75Yx9VSOVDwACIiJw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> <20140502173830.GJ27883@mournblade.imrryr.org> In-Reply-To: <20140502173830.GJ27883@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_kUfPqYmTwfUd42dQujJpuQEUzM Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 18:43:43 -0000 > GnuTLS tackles this problem by giving names to collections of ciphersuite= s that signal the requisite security level. OpenSSL is also moving in that= direction, and Postfix which uses OpenSSL also encourages users to use nam= ed cipher grades, whose underlying cipherlists are for experts only. I encourage the user of cipher profiles, but name them after features, whic= h is more stable, then strength qualifiers, which is a point in time statem= ent. That is, pfs-ciphers, not 'strong-ciphers.' What was strong (or HIGH, in = long-standing OpenSSL shorthand) in 1998 isn't in 2014, even though the con= fig might not have been revisited. I probably did not make this point sufficiently clear, when I first suggest= ed a profile mechanism on openssl-users. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri May 2 11:49:06 2014 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 9B3D01A6FD8 for ; Fri, 2 May 2014 11:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pf3RdYS-83K for ; Fri, 2 May 2014 11:49:03 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 152FC1A0312 for ; Fri, 2 May 2014 11:49:02 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so3551892lbg.29 for ; Fri, 02 May 2014 11:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=+wHM+z67tPVHaEPEc7nffpW4UTSVXqtCdGsGEYUql2I=; b=uYitK0oXrURuuEukjjBhzxNbaYThQrqKNGdpIaJ4K6MFCl2AIlnerZxPPmoZr6hogO c5q4RVXpHT5CKJod2WaNc3pxkKQG98M7joXfvWmPjBn9jspvZ3ybhZCGC74DHZxPW7Ql MmxfxSX/I1LeoOMGGpiVRjE0aV5lLysxdszusgftcd/WD4wlsOyGN1WKmLG5y8hfXqMJ qeWptgQJxQnWTF7hawgpl/Ll9QwcKgDyt10/vbwdcGGT+l3nMNciCMQGwsntmtT0XuGG IDdV74crCeMCLJNlT0yZY2A0aXiECgXD1mkkZEAJDxpzBP1N5KQDjlH4lEB9LGOfd2g/ 18lw== X-Received: by 10.112.53.170 with SMTP id c10mr1237074lbp.70.1399056539936; Fri, 02 May 2014 11:48:59 -0700 (PDT) MIME-Version: 1.0 Sender: mdchalmers@gmail.com Received: by 10.114.196.200 with HTTP; Fri, 2 May 2014 11:48:39 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> <20140502173830.GJ27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> From: Matthew Chalmers Date: Fri, 2 May 2014 13:48:39 -0500 X-Google-Sender-Auth: vsAQK5mMuHc9roiVrnFaCZhQEJE Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3f85215f8ea04f86f3ced Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TX0IQiYowcMNqcuLOSV62vXJhEg Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 18:49:04 -0000 --001a11c3f85215f8ea04f86f3ced Content-Type: text/plain; charset=UTF-8 I think (but I do not know) the idea with GnuTLS Priority Strings ( http://gnutls.org/manual/html_node/Priority-Strings.html) is that their descriptive names are vaguely accurate for the version in which they're used, but the suites within these "buckets" don't stay static across versions--so if you regularly upgrade, the names continue to carry the same "accuracy" but the algorithms behind them may change. This allows implementers to select the appropriate suite without knowing any details and as long as they keep their version patched/upgraded their selection remains relatively constant. On Fri, May 2, 2014 at 1:43 PM, Salz, Rich wrote: > > GnuTLS tackles this problem by giving names to collections of > ciphersuites that signal the requisite security level. OpenSSL is also > moving in that direction, and Postfix which uses OpenSSL also encourages > users to use named cipher grades, whose underlying cipherlists are for > experts only. > > I encourage the user of cipher profiles, but name them after features, > which is more stable, then strength qualifiers, which is a point in time > statement. > That is, pfs-ciphers, not 'strong-ciphers.' What was strong (or HIGH, in > long-standing OpenSSL shorthand) in 1998 isn't in 2014, even though the > config might not have been revisited. > > I probably did not make this point sufficiently clear, when I first > suggested a profile mechanism on openssl-users. > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11c3f85215f8ea04f86f3ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think (but I do not know) the idea with GnuTLS Priority = Strings (http://gnutls.org/manual/html_node/Priority-Strings.html) is that th= eir descriptive names are vaguely accurate for the version in which they= 9;re used, but the suites within these "buckets" don't stay s= tatic across versions--so if you regularly upgrade, the names continue to c= arry the same "accuracy" but the algorithms behind them may chang= e. This allows implementers to select the appropriate suite without knowing= any details and as long as they keep their version patched/upgraded their = selection remains relatively constant.


On Fri, May 2= , 2014 at 1:43 PM, Salz, Rich <rsalz@akamai.com> wrote:
> GnuTLS tackles this problem by giving names to collect= ions of ciphersuites that signal the requisite security level. =C2=A0OpenSS= L is also moving in that direction, and Postfix which uses OpenSSL also enc= ourages users to use named cipher grades, whose underlying cipherlists are = for experts only.

I encourage the user of cipher profiles, but name them after features= , which is more stable, then strength qualifiers, which is a point in time = statement.
That is, pfs-ciphers, not 'strong-ciphers.' =C2=A0 What was strong = (or HIGH, in long-standing OpenSSL shorthand) in 1998 isn't in 2014, ev= en though the config might not have =C2=A0been revisited.

I probably did not make this point sufficiently clear, when I first suggest= ed a profile mechanism on openssl-users.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSa= lz

_____________________________= __________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag

--001a11c3f85215f8ea04f86f3ced-- From nobody Fri May 2 12:57:21 2014 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 AD6FE1A6FC5 for ; Fri, 2 May 2014 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.648 X-Spam-Level: **** X-Spam-Status: No, score=4.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] 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 biqdwBwUteUr for ; Fri, 2 May 2014 12:57:17 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 32F151A6FA9 for ; Fri, 2 May 2014 12:57:17 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA28445; Fri, 2 May 2014 15:44:38 -0400 (EDT) Date: Fri, 2 May 2014 15:44:38 -0400 (EDT) From: Mouse Message-Id: <201405021944.PAA28445@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 2 May 2014 15:36:01 -0400 (EDT) To: saag@ietf.org In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> <20140502173830.GJ27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zH7UhvSHF227i3xNzVQJcg3dCck Subject: Re: [saag] Algorithm agility (was: Please review draft-iab-crypto-alg-agility-00.txt) 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: Fri, 02 May 2014 19:57:19 -0000 >> GnuTLS tackles this problem by giving names to collections of ciphersuites $ > I encourage the user of cipher profiles, but name them after features, which$ > That is, pfs-ciphers, not 'strong-ciphers.' "pfs-ciphers" doesn't really do what you want, because there may someday be many ways to get PFS, even if today there's only one. And, while I agree that "strong-ciphers" is a constantly sliding target, "512-bit strength" makes sense. It may be difficult to define precisely in many cases, and it may need rephrasing for end-user consumption (because of the whole 40-bit/128-bit debacle they've already had shoved at them), but it avoids the whole "what was once high strength is now medium strength" problem. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Fri May 2 13:05:47 2014 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 800241A6FFD for ; Fri, 2 May 2014 13:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.688 X-Spam-Level: **** X-Spam-Status: No, score=4.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294] 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 JwC-V_7DO4PQ for ; Fri, 2 May 2014 13:05:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D20431A6FF1 for ; Fri, 2 May 2014 13:05:43 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 22A55F984 for ; Fri, 2 May 2014 16:05:39 -0400 (EDT) Message-ID: <5363FA94.9050608@fifthhorseman.net> Date: Fri, 02 May 2014 16:05:40 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53603BDD.2080109@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742BFB0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502000517.0bbd7058@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C118@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140502073618.0b2fafe8@elandnews.com> <20140502173830.GJ27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130742C370@USMBX1.msg.corp.akamai.com> <201405021944.PAA28445@Chip.Rodents-Montreal.ORG> In-Reply-To: <201405021944.PAA28445@Chip.Rodents-Montreal.ORG> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iugNwSI87A7COU2bPtk7XHV0A1qb4CDrR" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WH7_3p292aJRP_jo-sENXxyMuZo Subject: Re: [saag] Algorithm agility 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: Fri, 02 May 2014 20:05:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iugNwSI87A7COU2bPtk7XHV0A1qb4CDrR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/02/2014 03:44 PM, Mouse wrote: >>> GnuTLS tackles this problem by giving names to collections of ciphers= uites $ >> I encourage the user of cipher profiles, but name them after features,= which$ >> That is, pfs-ciphers, not 'strong-ciphers.' >=20 > "pfs-ciphers" doesn't really do what you want, because there may > someday be many ways to get PFS, even if today there's only one. Technically, there's two: traditional discrete log DHE and there's ECDHE. But if we're nit-picking on the terminology, it's not the cipher that determines PFS at all, but rather the key exchange part of the negotiated cryptographic suite. (PFS suites use the same ciphers as non-PFS suites) Recent versions of GnuTLS have a priority string "PFS" that selects only suites that have forward-secret key exchange mechanisms. --dkg --iugNwSI87A7COU2bPtk7XHV0A1qb4CDrR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTY/qUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpchU4QAJiVxmWF1yLIjJ3vwLFov0+u agweOB0Dg2BgBZwNAEffOsrow+XeLbRLI6hXN0axrxwnGkB1Kj9cP19DKMGBexh6 oe1tdUtm/cHJY/4cGzZMOCwRTay6me6YX0seiylYyQ9WZ6qdXbllhwda7TlepFUK dL9ONsryl4lvuOhiyIrv4bvJWswHJzdDM5k8dp2RmJLihTbNyETzqnWpkOU2bPBE e4sHpmB27ApfP+gm/oc/V3Riu5JLX6CfnMkP+z4dP1YxAVBe5cHycj7T83+jjnz2 bFURka8XPqrc++fTGksp/bMGZtiSZLNMp+fiy77hLC2jg+6yJFlZmzR8dPKLXJww +U/tQkhRqwkfHsXzZD9ALJFcIH/geH8e9lc4Vy3QWzS7yDTkZRHkePuB8C77BXRq 5BZXYzaF7kk8kACaJcHEAU5qcp8bxjzCnoe0CrAJ0fCDhxeK0RUll8cZ3KcgsWnQ ZrLI7Rk6oq8mvT0lqOPZD0muCMIxY8mOGx1KvuRkYTYndNnNz7MIQ+5nQk4L0Nqr SsmCIi0KfNsPVJ5Pkhh+KkdZn6Z3P86sp4A2kUGf7Sv0JzEda6SpwMwpoSzz3lpE kbns0Knmuv/1uWFtue1eFjejRrTatOwGbslwMy3YhG2uH3H/NEVHwPSY7s7JljJe Xk/Z2+undqw5TGj26BW7 =Edt5 -----END PGP SIGNATURE----- --iugNwSI87A7COU2bPtk7XHV0A1qb4CDrR-- From nobody Sat May 3 08:45:53 2014 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 A07101A00DC for ; Sat, 3 May 2014 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 PIq4CDLnkK7O for ; Sat, 3 May 2014 08:45:50 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0081A00DA for ; Sat, 3 May 2014 08:45:50 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id E49E66D5B2; Sat, 3 May 2014 11:45:43 -0400 (EDT) Message-ID: <53650F27.6040607@iang.org> Date: Sat, 03 May 2014 16:45:43 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6HRz895F9dLcayWOBiW4ZkI5qX0 Subject: [saag] A case against algorithm agility (long) 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, 03 May 2014 15:45:52 -0000 I've jotted down some notes on the case against agility, as mooted. Sorry, long. It should be called "algorithm agility considered harmful" but I've found that some people are irrationally offended by words. Offense doesn't worry me, but distraction helps nobody. By algorithm agility, I mean the ability to swap AES for TDES for ChaCha20 or MD5 for SHA1 for SHA256 or GCM for CBC for CTR or RSA for EC for DSA for ... and including small groupings of same such as AES+HMAC+SHA+CBC. The ability to select the entire suite is another issue, maybe discussed later. 1. Black boxes they ain't. Algorithms are sometimes characterised as black boxes that can be substituted at will. Unfortunately it's only a hope, it's not met in practice. Consider (a) the emerging sense of sponge constructions, (b) emerging calls for 32 byte block sizes and a past of 8 bytes, (c) tendency for stream ciphers to be blocks underneath, (d) the whole stream v. block debate, (e) the shift to AE, (f) changing keylength goals over time. It's simply not the case that you can reliably blackbox the cipher, the hash, the mac, the mode or any other component. Yes, you can design something that substitutes in various black boxes according to this vision, and you can force all your algorithms to work as black boxes but the result is inelegant, klunky and undesirable. Hard to maintain, and new models cause contortions leading to weakness. 2. Strength. Universal substitution is bad, strength alignment is needed at a minimum, and this is not a casual endeavour for mindless tweaking. Draft section 2.4 makes it pretty clear that just switching black boxes back and forth is not sufficient, as the algorithms should be matched in strength. So, if we've decided to allow algorithm agility, we have in effect outsourced strength alignment to the public, which is someone who isn't capable of doing it. e.g., we are negligent by charter, we've squandered our chance to actually do what we ourselves are capable of doing: designing a matched suite. 3. Config. The choice of agility is a claim that the user population can make good choices. Yet, this isn't met by experience: Nobody (approximately) has confidence in user-land config strings, e.g., OpenSSL. They are so complicated and there are so many traps that only a real expert has confidence in own work, and that's not actually seen often enough to justify talking about it. Everyone (approximately) relies on defaults delivered, and so does everyone upstream, until you discover that your experts are also relying on other defaults from other experts who were relying... c.f. Android debacle. Over at the BetterCrypto group that publishes a guide on how to configure and use safer stronger algorithms, they seem (by my observation) to spend about half their time on one thing: OpenSSL config strings. What a waste. For what? 4. Marginality. Any benefits from tweaking/swapping/improving blackbox algorithms are marginal and/or esoteric. For the most part, any cipher gets you 99.999% of the grade. Same with any HMAC, any mode properly implemented. The only people who can or will crack weaker algorithms (DES? RC4) are people who will also bypass the crypto, and are already doing it. So if we were doing risk analysis (which is the only scientifically founded method, albeit weak) anything above DES is a waste. Now, it so happens that for next to no cost, we can do much better than DES, e.g., AES or better even. *So we might as well* and thus I fall also to hubristic desire for more algorithmic delight. But the /difference/ between is not going to effect the user public. It certainly doesn't justify enabling a difference. 5. Negotiation between software agents is a crock. Software agents don't negotiate, people do, and that's by definition. The complicated matching of ordered preferences that is called agent negotiation is a minefield of errors, bad user experience, and opportunity to attack. The complication ensures that implementations will not have an easy ride together, and even one implementation negotiating against itself is no easy thing. 6. Attacks. The existence of algorithm agility opens up the possibility of the downgrade attack. E.g., trick the config string (below) to default to the NULL cipher. Or trick the negotiation to choose the weakest cipher. Etc. It also opens up the possibility for bugs (benign) and lousy user experience. 7. Need. We still have no evidence that any attacker ever has attacked the crypto algorithms in TLS or other properly designed protocols (iii). The closest we've got (to my knowledge) is the 512RSA phishing attacks in the far east (yes, take that choice away, why on earth do we let users choose key sizes?). We simply have no reason to believe that any of the well-designed algorithms will be cracked in the next 10 years. Our expectation that they could, derived from WWII warstories and thrilling self-serving media headlines, is not a foundation to say there is any expectation at all. It seems that we expect them to fail, and we act as if they will fail, *because we can*. Not because it is likely. Meanwhile, our actual record of security is rock-bottom because while we put exorbitant attention on the next-to-impossible case of algorithm failure, we ignore the actual, measurable and costly failure that bad protocols contribute to in userland: phishing, server breaches etc. "Out of scope" means we aren't professionally doing risk analysis. 8. Speed. In contrast, ciphers are so slick these days that the best today competes with the best of 20 years ago, CPU cycle-wise. And 99.99% of the users have so much CPU that they can never notice the difference. (This is not to be confused with those who work at the sharp end, with heavily loaded and balanced machines. These are the people who can pay for performance, and do. They can also pay their suppliers and suppliers' suppliers to influence standards orgs, so it's probably wise to remember that these people can deal with any sub-optimal performance by two ways: buy influence here, or buy bigger boxes at the shop.) (Same applies to all HMACs, modes, etc.) 9. Problems. In contrast, there are plenty of problems in the protocol, the layouts, the interactions, the features. Check the evidence: as far as I am aware, all failures were outside the algorithms. 10. Track record. Historically, no record of agility saving us. The one time it might have saved us was in switching to RC4. That might be called a save, but it wasn't really; it was really a switch in protocol to use stream ciphers, and we switched back to arguably the worst cipher available. There was no designed agility to switch from block to stream... So if we think RC4 saved us, then we can (e.g.) no longer argue for stronger ciphers... 11. MD5. And then there is MD5 in TLS; why did it take so long to get rid of it? It turns out that algorithm agility wasn't universally deployed all the way through. Why not? Because it wasn't easy to put algorithm agility into all the places. So the one time we really needed it ... it wasn't there for us? 12. Distros rule! Actually getting a live switch *in algorithms* out to userland is very difficult. It's harder to get people to change their config strings than it is to send out a new distribution. Every Linux sysadm understands apt-get. Every apple user understands Security Update, click to restart. Every MS admin understands backup & re-install. Relatively few of them understand how to tweak the settings. Indeed, few of them have the first clue about algorithms. Indeed, it's really bad advice to say "switch to RC4" because we have little idea as to whether they'll get it right, or whether it'll trigger some other problems. 13. Arrogance. There's something of a hubristic bias in algorithm agility. We do it because we can, because its cool, and we're happy to ignore the downstream noise. We invent rationales as to why we should do it. We talk about how we optimised our implementation to get 5% better than the other guy. We pontificate on how CTR is better than GCM, because because, we enjoy poking our thumb at the NSA. I once knew a guy who said "it is my right to use odd-length RSA keys." I lost a couple of days debugging before I figured out why his keys would not communicate with mine. It is fine to do this in isolation, pushing rights and beliefs, but really, are we in the business of religion, exporting democracy, motherhood and apple pie? Or are we in the software business? Trying to get the maximum protection across to an Internet of users? What this doesn't argue against: A. the past. E.g., TLS is what it is, here and now, this is not an argument to suggest that TLS WG should drop everything and stop doing algorithm agility. They're stuck with their legacy, and the good thing is that we now have a good solid historical example to prove or disprove the hypothesis. B. this ID shouldn't be written. Regardless of the hypothesis, there are many protocols that use the technique. Documentation of it is a good thing. However, it is better to encourage them to use better practices than to laud the best practices of the past, once past their sell date. Notes. (i) where above I mostly write about ciphers, the arguments extend to other components and choices such as HMACs, modes, public key, lengths etc. (ii) this is just today's effort. I'll keep refining it, fire away! (iii) by properly designed protocols, I generally exclude wireless which are designed to be weak and breachable. By attack, I mean an aggressive breach including measurable damages. I accept rework as measurable damages, typically, but academic demos and reputation thefts don't cut it. From nobody Sat May 3 20:11:00 2014 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 A1B141A0140 for ; Sat, 3 May 2014 20:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 LbVyot-RfUHS for ; Sat, 3 May 2014 20:10:56 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 88A7C1A0103 for ; Sat, 3 May 2014 20:10:56 -0700 (PDT) X-AuditID: 12074422-f79186d00000135a-a7-5365afbd515f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A9.C0.04954.DBFA5635; Sat, 3 May 2014 23:10:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s443AqL4001269; Sat, 3 May 2014 23:10:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s443AnPv010668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 May 2014 23:10:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s443An9p018434; Sat, 3 May 2014 23:10:49 -0400 (EDT) Date: Sat, 3 May 2014 23:10:49 -0400 (EDT) From: Benjamin Kaduk To: ianG In-Reply-To: <53650F27.6040607@iang.org> Message-ID: References: <53650F27.6040607@iang.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLt3fWqwQdtTLouFXQfYLKb0dzI5 MHnMXH2E1WPJkp9MAUxRXDYpqTmZZalF+nYJXBmH/k5iLtjBWrF7wRLWBsZlLF2MnBwSAiYS z+YeZYWwxSQu3FvP1sXIxSEkMJtJ4t+Rf6wQzgZGiSNzlkFlDjJJrPr+GKxdSKBeYuKR92A2 i4CWxKo9MxhBbDYBFYmZbzYCNXBwiAhISBz8kA8SZhYQlLjUv4UJxBYWsJbo7J0PtplTQENi d+sBsDivgIPEnQWXocarSzy7eowNxBYV0JFYvX8KC0SNoMTJmU9YIGZaSpz7c51tAqPgLCSp WUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgQFKruL0g7GnweVDjEK cDAq8fCeuJUcLMSaWFZcmXuIUZKDSUmUd83k1GAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxy 04FyvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJ3u51QI2CRanpqRVp mTklCGkmDk6Q4TxAw1euBRleXJCYW5yZDpE/xagoJc6bBtIsAJLIKM2D64UlkleM4kCvCPPu AWnnASYhuO5XQIOZgAaLOyaDDC5JREhJNTD6Rm1cPVlxVd1n8ZtSdQFhjeVmn22+37pSsuj9 kj8cJduqdM4edVV88l/wjeLt46z9C17+4+Vesyj9UOsNiRVyTxwWzz0R+X72wcCQXqU/CpWK j59siH/3In9mo9n3764Rm+svpB3ZG+Ap0xMhxMgoNHFW/M3sGQnhn3iz+mLFFxS9MHbrYQtQ YinOSDTUYi4qTgQAwBnauv8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cc1_y4kWyxPZt0WBUnqIsq7VcQM Cc: saag@ietf.org Subject: Re: [saag] A case against algorithm agility (long) 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: Sun, 04 May 2014 03:10:58 -0000 On Sat, 3 May 2014, ianG wrote: > 4. Marginality. Any benefits from tweaking/swapping/improving blackbox > algorithms are marginal and/or esoteric. For the most part, any cipher > gets you 99.999% of the grade. Same with any HMAC, any mode properly > implemented. The only people who can or will crack weaker algorithms > (DES? RC4) are people who will also bypass the crypto, and are already > doing it. My apologies for cherry-picking just a single point, but commercial DES crackers are in the $200, 1-day range these days. That there is even a commercial market for it suggests that they are in use, and not just by people who could by pass the crypto. -Ben Kaduk From nobody Sun May 4 01:56:19 2014 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 E4BDC1A0049 for ; Sun, 4 May 2014 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 e0eitGAjpd_X for ; Sun, 4 May 2014 01:56:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 73AB41A002D for ; Sun, 4 May 2014 01:56:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F08E62AB05D; Sun, 4 May 2014 08:56:09 +0000 (UTC) Date: Sun, 4 May 2014 08:56:09 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140504085609.GO27883@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535CFA14.5020200@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jIh3OSErHt7_yh866fEusWv7dZg Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:56:17 -0000 On Sun, Apr 27, 2014 at 01:37:40PM +0100, Stephen Farrell wrote: > Or even maybe try suggest an alternative for the whole > thing if you've energy. OK. How about the below (removed TOC, BCP 78/79 boilerplate, pagebreaks, ... leaving just the content). This is quite short, and to the point, which is I think a significant advantage. Most of what is left unsaid is I think inessential to the definition. If the below is a reasonable start, and anyone wants to see some more words, I am not opposed to reasonable expansion of the text and/or clarification, provided we keep the separation of the essential definition from any illustrative examples or properties that some opportunistic security protocol or other might have. (XML, HTML, ... available, and I can post a more formal I-D if this is a reasonable starting point). -- Viktor. [Some appropriate IETF body] V. Dukhovni Internet-Draft Two Sigma Intended status: Informational May 4, 2014 Expires: November 5, 2014 Opportunistic Security: some protection most of the time draft-dukhovni-opportunistic-security-00 Abstract This memo defines the term "opportunistic security". In contrast to the established approach of delivering strong protection some of the time, opportunistic security strives to deliver at least some protection most of the time. The primary goal is therefore broad interoperability, with security policy tailored to the capabilities of peer systems. 1. Introduction Historically, Internet security protocols have prioritized strong protection for peers capable and motivated to absorb the associated costs. Since strong protection is not universally applicable, while communications traffic was sometimes strongly secured, more typically it was not protected at all. The fact that most traffic is unprotected facilitates nation-state pervasive monitoring (PM [I-D.farrell-perpass-attack]) by making it cost-effective (or at least not cost-prohibitive). Indiscriminate collection of communications traffic would be substantially less attractive if security protocols were designed to operate at a range of protection levels with encrypted transmission accessible to most if not all peers, and stronger security still available where required by policy or opportunistically negotiated. Encryption is easy, but key management is difficult. Key management at Internet scale remains an incompletely solved problem. The PKIX ([RFC5280]) key management model introduces costs that not all peers are willing to bear and is also not sufficient to secure communications when the peer reference identity is obtained indirectly over an insecure channel or communicating parties don't agree on a mutually trusted certification authority (CA). DNSSEC is not at this time sufficiently widely adopted to make DANE a viable alternative at scale. Trust on first use (TOFU) key management models (as with saved SSH fingerprints and various certificate pinning approaches) are fragile and require user intervention when key continuity fails. Without Internet-scale key management, authentication is often not possible. When protocols only offer the options of strongly- authenticated secure channels or else no security, most traffic gets no security protection. Therefore, in order to make encryption more ubiquitous, authentication needs to be optional. When strongly authenticated communication is not possible, unauthenticated encryption is still substantially stronger than cleartext. Opportunistic security encourages peers to employ as much security as possible, without falling back to unnecessarily weak options. In particular, opportunistic security encourages unauthenticated encryption when authentication is not an option. 2. Opportunistic Security Design Philosophy Interoperate to maximize deployment: The primary goal of designs that feature opportunistic security is to be able to communicate with any reasonably configured peer. If many peers are only capable of cleartext, then it is acceptable to fall back to cleartext when encryption is not possible. If authentication is only possible for some peers, then it is acceptable to authenticate only those peers and not the rest. Interoperability must be possible without bilateral coordination. Applications employing opportunistic security need to be deployable at Internet scale, with each peer independently configured to meet its own security needs (within the practical bounds of the application protocol). Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured. Maximize security peer by peer: Subject to the above large-scale interoperability goal, opportunistic security strives to maximize security based on the capabilities of the peer (or peers). For some opportunistic security protocols the maximal protection possible may be just unauthenticated encryption. For others, greater security may be an option, and opportunistic security may at times (in partial conflict with the interoperability goal) refuse to with peers where higher security is expected, but for some reason not achieved. The conditions under which connections fail should generally be limited to operational errors at one or the other peer or an active attack, so that well-maintained systems rarely encounter problems in normal use of opportunistic encryption. Encrypt by default: An opportunistic security protocol MUST interoperably achieve at least unauthenticated encryption between peer systems that don't explicitly disable this capability. Over time, as peer software is updated to support opportunistic security, only legacy systems or a minority of systems where encryption is disabled should be communicating in cleartext. Whenever possible, opportunistic security should employ Perfect Forward Secrecy (PFS) to make recovery of previously sent keys and plaintext computationally expensive even after disclosure of long- term keys. No misrepresentation of security: Unauthenticated communication or use of authentication that is vulnerable to MiTM attacks is not represented as strong security. Where strong security is required, opportunistic security is not a substitute, though the underlying mechanisms may in some cases be very similar. 3. Terminology The following definitions are derived from the Internet Security Glossary [RFC4949], where applicable. Perfect Forward Secrecy (PFS): For a key management protocol, the property that compromise of long-term keys does not compromise session/traffic/content keys that are derived from or distributed using the long-term keys. Man-in-the-Middle attack (MiTM): A form of active wiretapping attack in which an attacker intercepts and may selectively modify communicated data to masquerade as one of the entities involved in a communication. Masquerading enables the MiTM to violate the confidentiality and/or the integrity of communicated data passing through it. Trust on First Use (TOFU): In a protocol, TOFU typically consists of accepting an asserted identity, without authenticating that assertion, and caching a key or credential associated with the identity. Subsequent communication using the cached key/ credential is secure against a MiTM attack, if such an attack did not succeed during the (vulnerable) initial communication or if the MiTM is not present for all subsequent communications. The SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF) is sometimes used as a synonym. Unauthenticated Encryption: Encryption using a key management technique that enables unauthenticated communication between parties. The communication may be 1-way or 2-way unauthenticated. If 1-way, the initiator (client) or the target (server) may be anonymous. 4. Security Considerations Though opportunistic security potentially supports transmission in cleartext, unauthenticated encryption, or other protection levels short of the strongest potentially applicable, the effective security for users is increased, not reduced. Provided strong security is not required by policy or securely negotiated, nothing is lost by allowing weaker protection levels, indeed opportunistic security is strictly stronger than the alternative of providing no security services when maximal security is not applicable. 5. References [I-D.farrell-perpass-attack] Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an Attack", draft-farrell-perpass-attack-06 (work in progress), February 2014. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Author's Address Viktor Dukhovni Two Sigma Email: ietf-dane@dukhovni.org From nobody Sun May 4 04:46:42 2014 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 EC1C81A0071 for ; Sun, 4 May 2014 04:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 L327X5jsfTXq for ; Sun, 4 May 2014 04:46:39 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 648E51A006D for ; Sun, 4 May 2014 04:46:39 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1AF256D48F; Sun, 4 May 2014 07:46:34 -0400 (EDT) Message-ID: <53662898.7040808@iang.org> Date: Sun, 04 May 2014 12:46:32 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <53650F27.6040607@iang.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uvjy7zQLrIDIfQsM9TNfoAd88BM Cc: saag@ietf.org Subject: Re: [saag] A case against algorithm agility (long) 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: Sun, 04 May 2014 11:46:41 -0000 On 4/05/2014 04:10 am, Benjamin Kaduk wrote: > On Sat, 3 May 2014, ianG wrote: > >> 4. Marginality. Any benefits from tweaking/swapping/improving blackbox >> algorithms are marginal and/or esoteric. For the most part, any cipher >> gets you 99.999% of the grade. Same with any HMAC, any mode properly >> implemented. The only people who can or will crack weaker algorithms >> (DES? RC4) are people who will also bypass the crypto, and are already >> doing it. > > My apologies for cherry-picking just a single point, but commercial DES > crackers are in the $200, 1-day range these days. Ah very true, perhaps t-DES. And one can buy machines for crunching SHA256, albeit the first N digits in 10 minutes. I guess some of the programmable ones could be put to MD5 and SHA1 efforts. > That there is even a > commercial market for it suggests that they are in use, and not just by > people who could by pass the crypto. Yes, this is fascinating. There's also the SSL-interceptor boxes which allegedly will take your commercially provided sub-Root. Who uses those machines and why? Information like that would be really useful to tell us what matters. iang From nobody Sun May 4 05:17:04 2014 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 5E2B81A0083 for ; Sun, 4 May 2014 05:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZLI7JMNwnDh for ; Sun, 4 May 2014 05:16:58 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DC0AE1A007C for ; Sun, 4 May 2014 05:16:57 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so2569114lbi.33 for ; Sun, 04 May 2014 05:16:54 -0700 (PDT) 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=HcHkxxaWAbEQAOXHaWmQwPn6KmMpqxGmS3SrBESoEVg=; b=HXFDS1Z9xTAM5g4bz1juMKGLrO1nNWzbEAJZLxWetbn4N9KI6+kehzmQYU1GyKZacV Bm+U2HpRKY+4JhoevrwTxJZZaZrl+FqEFp6MvQe/clMhlHRU0VuiMO8M6MgFmgOiZd2E Z5MaoktId2eTjnGgaG3a6XRaIs4q6NtYk+YWVt43vryr6L24oWevTUa6FyBSv/Ub4o8Z jIVUDunVbpcrAj/SV/eY7OtQAzl6LtlOabyXKvqZ8figc8sU8KXYLf8sMYCkAGXkh7Zv PMkzcxDLthHN8oWz7LPjSGju9mq+w+BegckgkLdIFEWNFfztdqCAcSK4pVx5uf6JkrNr x0VQ== MIME-Version: 1.0 X-Received: by 10.152.242.164 with SMTP id wr4mr1571571lac.38.1399205814222; Sun, 04 May 2014 05:16:54 -0700 (PDT) Received: by 10.114.5.102 with HTTP; Sun, 4 May 2014 05:16:54 -0700 (PDT) Date: Sun, 4 May 2014 08:16:54 -0400 Message-ID: From: Rifaat Shekh-Yusef To: saag@ietf.org Content-Type: multipart/mixed; boundary=001a113409508653c704f891fd6e Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ji_t7i3OUBgfwxmsYElLlymR7Mg Subject: [saag] Key-Derivation Scheme 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: Sun, 04 May 2014 12:17:00 -0000 --001a113409508653c704f891fd6e Content-Type: multipart/alternative; boundary=001a113409508653c404f891fd6c --001a113409508653c404f891fd6c Content-Type: text/plain; charset=ISO-8859-1 Hi, There are few protocols (e.g. HTTP, SIP, OAuth, and STUN) that use a challenge-response mechanism to authenticate users. These protocols typically use Basic or Digest schemes, which have many limitations as described RFC2617. This email and the attached draft is to discuss the idea of creating a new scheme, Key-Derivation Authentication Scheme, to be used with the challenge-response mechanism. The scheme is based on the following NIST document: "NIST Special Publication 800-132 - Recommendations for Password-Based Key Derivations", December 2010. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf The scheme ensures that the password and the master-key are never sent on the wire, and allows for a better secure storage of passwords as it significantly increases the amount of computation needed to derive a key from a password in a dictionary attack. Any comments on the idea, described in the attached document, would be greatly appreciated. Regards, Rifaat --001a113409508653c404f891fd6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

There are few protocols (e.g. HTTP,= SIP, OAuth, and STUN) that use a challenge-response mechanism to authentic= ate users.
These protocols typically use Basic or Digest sche= mes, which have many limitations as described RFC2617.

This email and the attached draft is to discuss the ide= a of creating a new scheme, Key-Derivation Authentication Scheme, to be use= d with the challenge-response mechanism.

The schem= e is based on the following NIST document:
"NIST Special Publication 800-132 - Reco= mmendations for=A0Password-Based Key Deriva= tions", December 2010.

The scheme ensures that the password and the master-key= are never sent on the wire, and allows for a better secure storage of pass= words as it significantly increases the amount of computation needed to der= ive a key from a password in a dictionary attack.

Any comments on the idea, described in the attached doc= ument, would be greatly appreciated.

Regards,
=A0Rifaat



--001a113409508653c404f891fd6c--
--001a113409508653c704f891fd6e
Content-Type: text/plain; charset=US-ASCII; name="draft-yusef-key-derivation-00-01.txt"
Content-Disposition: attachment; 
	filename="draft-yusef-key-derivation-00-01.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_husapkpc0

IA0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFIuIFNoZWtoLVl1c2VmDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFj
ayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDMsIDIwMTQNCkV4cGlyZXM6IE5vdmVt
YmVyIDQsIDIwMTQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KDQoNCg0KICAgICAgICAgICAgICAgICBLZXktRGVyaXZhdGlvbiBBdXRoZW50aWNhdGlvbiBT
Y2hlbWUgDQogICAgICAgICAgICAgICAgICAgICBkcmFmdC15dXNlZi1rZXktZGVyaXZhdGlvbi0w
MA0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBzY2hlbWUs
IEtleS1EZXJpdmF0aW9uIEF1dGhlbnRpY2F0aW9uDQogICBTY2hlbWUsIHRoYXQgY291bGQgYmUg
dXNlZCB3aXRoIGFueSBjaGFsbGVuZ2UtcmVzcG9uc2UgYXV0aGVudGljYXRpb24NCiAgIGZyYW1l
d29yay4NCg0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFm
dCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBw
cm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl
IHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBG
b3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhh
dA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMg
YXMNCiAgIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk
b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJl
IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu
eQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh
cyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3
b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFm
dHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFj
dHMuaHRtbA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp
ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s
DQoNCg0KQ29weXJpZ2h0IGFuZCBMaWNlbnNlIE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIw
MTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3Vt
ZW50IGF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg
c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lv
bnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9y
Zy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0KIA0KDQoNClNoZWtoLVl1
c2VmLCBldC4gYWwuICAgIEV4cGlyZXMgTm92ZW1iZXIgNCwgMjAxNCAgICAgICAgICAgICAgICBb
UGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgS2V5LURlcml2YXRpb24gQXV0aGVudGljYXRp
b24gU2NoZW1lICAgICAgIE1heSAzLCAyMDE0DQoNCg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk
b2N1bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMg
dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0K
ICAgdG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMg
ZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMg
ZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u
cyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAgIGRlc2NyaWJlZCBpbiB0
aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAg
IDEgIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgMw0KICAgICAxLjEgIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyICBPcGVyYXRpb25zIE92ZXJ2aWV3
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMgIFRo
ZSBSZXNwb25zZSBIZWFkZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAgNA0KICAgNCAgVGhlIFJlcXVlc3QgSGVhZGVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICA1ICBFeGFtcGxlIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDYgIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
Nw0KICAgNyAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuICA3DQogICA4LiBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgIDkgIFJlZmVyZW5jZXMgIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAg
ICA5LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuICA3DQogICAgIDkuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KDQoNClNoZWtoLVl1c2Vm
LCBldC4gYWwuICAgIEV4cGlyZXMgTm92ZW1iZXIgNCwgMjAxNCAgICAgICAgICAgICAgICBbUGFn
ZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgS2V5LURlcml2YXRpb24gQXV0aGVudGljYXRpb24g
U2NoZW1lICAgICAgIE1heSAzLCAyMDE0DQoNCg0KMSAgSW50cm9kdWN0aW9uDQoNCiAgIFNvbWUg
cHJvdG9jb2xzIChlLmcuIEhUVFAgW0hUVFAtUDddLCBTSVAgW1JGQzMyNjFdLCBPQVVUSCAyLjAN
CiAgIFtSRkM2NzQ5XSwgYW5kIFNUVU4gW1JGQzUzODldKSB1c2UgYSBnZW5lcmFsIGZyYW1ld29y
ayBmb3IgYWNjZXNzDQogICBjb250cm9sIGFuZCBhdXRoZW50aWNhdGlvbiwgdmlhIGEgc2V0IG9m
IGNoYWxsZW5nZS1yZXNwb25zZQ0KICAgYXV0aGVudGljYXRpb24gc2NoZW1lcywgd2hpY2ggY2Fu
IGJlIHVzZWQgYnkgYSBzZXJ2ZXIgdG8gY2hhbGxlbmdlIGENCiAgIGNsaWVudCByZXF1ZXN0IGFu
ZCBieSBhIGNsaWVudCB0byBwcm92aWRlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uLg0KDQog
ICBNYW55IG9mIHRoZXNlIHN5c3RlbXMgdGhhdCB1c2UgdGhlIGNoYWxsZW5nZS1yZXNwb25zZSBm
cmFtZXdvcmsgcmVseQ0KICAgb24gcGFzc3dvcmRzIGNob3NlbiBieSB1c2VycyB3aGljaCB1c3Vh
bGx5IGhhdmUgbG93IGVudHJvcHkgYW5kIHdlYWsNCiAgIHJhbmRvbW5lc3MsIGFuZCBhcyBhIHJl
c3VsdCBjYW5ub3QgYmUgdXNlZCBhcyBjcnlwdG9ncmFwaGljIGtleXMuDQoNCiAgIFdoaWxlIGNh
bm5vdCBiZSB1c2VkIGRpcmVjdGx5IGFzIGNyeXB0b2dyYXBoaWMga2V5cywgdGhlIHBhc3N3b3Jk
cw0KICAgY2FuIHN0aWxsIGJlIHVzZWQgdG8gZGVyaXZlIGNyeXB0b2dyYXBoaWMga2V5cywgYnkg
dXNpbmcgS2V5DQogICBEZXJpdmF0aW9uIEZ1bmN0aW9uIChLREYpLg0KDQogICBUaGlzIGRvY3Vt
ZW50IGRlZmluZXMgYSBuZXcgc2NoZW1lLCBLZXktRGVyaXZhdGlvbiBBdXRoZW50aWNhdGlvbg0K
ICAgU2NoZW1lLCB0aGF0IGNvdWxkIGJlIHVzZWQgd2l0aCBhbnkgY2hhbGxlbmdlLXJlc3BvbnNl
IGF1dGhlbnRpY2F0aW9uDQogICBmcmFtZXdvcmsuDQoNCiAgIFRoZSBLZXktRGVyaXZhdGlvbiBz
Y2hlbWUgYWxsb3dzIGZvciBhIGJldHRlciBzZWN1cmUgc3RvcmFnZSBvZg0KICAgcGFzc3dvcmRz
LCBhcyBpdCBzaWduaWZpY2FudGx5IGluY3JlYXNlcyB0aGUgYW1vdW50IG9mIGNvbXB1dGF0aW9u
DQogICBuZWVkZWQgdG8gZGVyaXZlIGEga2V5IGZyb20gYSBwYXNzd29yZCBpbiBhIGRpY3Rpb25h
cnkgYXR0YWNrLg0KDQoNCjEuMSAgVGVybWlub2xvZ3kNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVT
VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNI
T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi
IGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg
aW4gUkZDIDIxMTkgW1JGQzIxMTldLg0KDQoNCjIgIE9wZXJhdGlvbnMgT3ZlcnZpZXcNCg0KICAg
V2hlbiBhbiBhY2NvdW50IGlzIGNyZWF0ZWQsIHRoZSBzZXJ2ZXIgdXNlcyBhIEtERiwgYSBzYWx0
LCBhIGtleQ0KICAgbGVuZ3RoLCBhbmQgYW4gaXRlcmF0aW9uIGNvdW50IHRvIGNyZWF0ZSBhIG1h
c3Rlci1rZXkgYmFzZWQgb24gdGhlDQogICB1c2VyJ3MgcGFzc3dvcmQsIGFzIGRlZmluZWQgaW4g
W05JU1QtS0RdLiBUaGUgc2VydmVyIHRoZW4gc3RvcmVzIHRoZQ0KICAgZm9sbG93aW5nIGluZm9y
bWF0aW9uIGluIHRoZSBkYXRhYmFzZTogDQoNCiAgICAgIG8gdXNlcm5hbWUNCiAgICAgIG8gaXRl
cmF0aW9uIGNvdW50DQogICAgICBvIHNhbHQNCiAgICAgIG8gbWFzdGVyLWtleQ0KDQoNCiAgIFdp
dGggdGhlIGNoYWxsZW5nZS1yZXNwb25zZSBmcmFtZXdvcmsgdGhlIGluaXRpYWwgcmVxdWVzdCBp
cyBzZW50DQogICB3aXRob3V0IHByb3ZpZGluZyBhbnkgY3JlZGVudGlhbHMuIFRoZSBzZXJ2ZXIg
dGhlbiBjaGFsbGVuZ2VzIHRoZQ0KICAgcmVxdWVzdCBhbmQgaW5jbHVkZXMgdGhlIEtleS1EZXJp
dmF0aW9uIHNjaGVtZSB3aXRoIGEgS0RGLCBhIHNhbHQsIGENCiANCg0KDQpTaGVraC1ZdXNlZiwg
ZXQuIGFsLiAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2Ug
M10NCgwNCkludGVybmV0LURyYWZ0ICAgIEtleS1EZXJpdmF0aW9uIEF1dGhlbnRpY2F0aW9uIFNj
aGVtZSAgICAgICBNYXkgMywgMjAxNA0KDQoNCiAgIGtleSBsZW5ndGgsIGFuZCBhbiBpdGVyYXRp
b24gY291bnQuIA0KDQogICBUbyBiZSBhYmxlIHRvIHByb3ZpZGUgY3JlZGVudGlhbHMgdG8gdGhl
IHNlcnZlciB0aGUgY2xpZW50IG11c3QNCiAgIGNyZWF0ZSB0aGUgbWFzdGVyLWtleSBhcyB3YXMg
ZG9uZSBieSB0aGUgc2VydmVyIHdoZW4gdGhlIGFjY291bnQgd2FzDQogICBpbml0aWFsbHkgY3Jl
YXRlZCBhcyBkZXNjcmliZWQgYWJvdmUuDQoNCiAgIFRoZSBjbGllbnQgdGhlbiBjcmVhdGVzIGEg
cHJvb2Ytb2YtcG9zc2Vzc2lvbiAocG9wKSB1c2luZyBhbiBITUFDLQ0KICAgSGFzaCBmdW5jdGlv
biB3aXRoIHRoZSBtYXN0ZXIta2V5IGFuZCB0aGUgc29tZSBoZWFkZXJzIGZyb20gdGhlDQogICBy
ZXF1ZXN0Lg0KDQogICBBIHZhbGlkIHJlc3BvbnNlIGZyb20gdGhlIGNsaWVudCB3aWxsIGNvbnRh
aW4gdGhlICdwb3AnIHdoaWNoIGVuc3VyZXMNCiAgIHRoYXQgdGhlIHBhc3N3b3JkIGFuZCB0aGUg
bWFzdGVyLWtleSBhcmUgbmV2ZXIgc2VudCBvbiB0aGUgd2lyZSwgYW5kDQogICBwcm92ZXMgdGhh
dCB0aGUgc2VuZGVyIGlzIGluIHBvc3Nlc3Npb24gb2YgdGhlIG1hc3Rlci1rZXkuDQoNCg0KMyAg
VGhlIFJlc3BvbnNlIEhlYWRlcg0KDQogICBXaGVuIGEgc2VydmVyIHJlY2VpdmVzIGEgcmVxdWVz
dCBmcm9tIGEgY2xpZW50LCBhbmQgYW4gYWNjZXB0YWJsZQ0KICAgYXV0aG9yaXphdGlvbiBpcyBu
b3Qgc2VudCwgdGhlIHNlcnZlciBjaGFsbGVuZ2VzIHRoZSBvcmlnaW5hdG9yIHRvDQogICBwcm92
aWRlIGNyZWRlbnRpYWxzIGJ5IHJlamVjdGluZyB0aGUgcmVxdWVzdCBhbmQgaW5jbHVkZSB0aGUg
S2V5LQ0KICAgRGVyaXZhdGlvbiBzY2hlbWUuDQoNCiAgIFRoZSByZXNwb25zZSBzaG91bGQgaW5j
bHVkZSB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQoNCg0KICAgS0RGIChSRVFVSVJFRCkNCg0K
ICAgICAgQSBkZXRlcm1pbmlzdGljIGFsZ29yaXRobSB1c2VkIHRvIGRlcml2ZSBjcnlwdG9ncmFw
aGljIGtleXMgZnJvbSBhDQogICAgICBzaGFyZWQgc2VjcmV0IGxpa2UgYSBwYXNzd29yZC4gQSBn
b29kIGV4YW1wbGUgb2Ygc3VjaCBhIGZ1bmN0aW9uDQogICAgICBpcyBITUFDLVNIQTItMjU2Lg0K
DQoNCiAgIEl0ZXJhdGlvbnMgKE9QVElPTkFMKQ0KDQogICAgICBUaGUgbnVtYmVyIG9mIGl0ZXJh
dGlvbnMgdGhhdCB0aGUgS0RGIHdpbGwgYmUgYXBwbGllZCBvbiB0aGUgc2FsdA0KICAgICAgYW5k
IHBhc3N3b3JkLiBUaGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhpcyBwYXJhbWV0ZXIgaXMgMTAwMC4N
Cg0KDQoNCiAgIFtPUEVOIElTU1VFXQ0KDQogICBTZWN0aW9uIDUuMiBvZiB0aGUgW05JU1QtS0Rd
IGRvY3VtZW50IGluZGljYXRlcyB0aGF0IGZvciBzb21lIHN5c3RlbXMNCiAgIGFuIGl0ZXJhdGlv
biBjb3VudCBvZiAxMCwwMDAsMDAwIG1heSBiZSBhcHByb3ByaWF0ZS4gU2hvdWxkDQogICAxMCww
MDAsMDAwIGJlIHRoZSBkZWZhdWx0Pw0KDQoNCg0KDQogDQoNCg0KU2hla2gtWXVzZWYsIGV0LiBh
bC4gICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoM
DQpJbnRlcm5ldC1EcmFmdCAgICBLZXktRGVyaXZhdGlvbiBBdXRoZW50aWNhdGlvbiBTY2hlbWUg
ICAgICAgTWF5IDMsIDIwMTQNCg0KDQogICBTYWx0IChSRVFVSVJFRCkNCg0KICAgICAgQSByYW5k
b20gdmFsdWUgdGhhdCBpcyB1c2VkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBzYW1lIHBhc3N3b3Jk
DQogICAgICB3aWxsIGFsd2F5cyBiZSBoYXNoZWQgZGlmZmVyZW50bHkuIFRoZSBzYWx0IE1VU1Qg
YmUgZ2VuZXJhdGVkDQogICAgICB1c2luZyBhbiBhcHByb3ZlZCBSYW5kb20gTnVtYmVyIEdlbmVy
YXRvci4NCg0KDQogICBLZXktU2l6ZSAoUkVRVUlSRUQpDQoNCiAgICAgIFRoZSBzaXplIG9mIHRo
ZSBkZXJpdmVkIGtleSBpbiBiaXRzLg0KDQoNCg0KNCAgVGhlIFJlcXVlc3QgSGVhZGVyIA0KDQog
ICBUaGUgY2xpZW50IGlzIGV4cGVjdGVkIHRvIHJldHJ5IHRoZSByZXF1ZXN0LCBwYXNzaW5nIGFu
IGF1dGhvcml6YXRpb24NCiAgIHdpdGggdGhlIEtleS1EZXJpdmF0aW9uIHNjaGVtZS4gDQoNCg0K
ICAgUG9wIChSRVFVSVJFRCkNCg0KICAgICAgVGhlIFBvcCBpcyBkZXJpdmVkIGZyb20gYXBwbHlp
bmcgdGhlIEhNQUMtU0hBMjU2IG9uIHNvbWUtcmVxdWVzdC0NCiAgICAgIGhlYWRlcnMgdXNpbmcg
dGhlIG1hc3Rlci1rZXksIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgIFBvcCA9IEhNQUMtU0hBMjU2
KG1hc3Rlci1rZXksIHNvbWUtcmVxdWVzdC1oZWFkZXJzKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiANCg0KDQpTaGVraC1ZdXNlZiwgZXQuIGFsLiAgICBF
eHBpcmVzIE5vdmVtYmVyIDQsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy
bmV0LURyYWZ0ICAgIEtleS1EZXJpdmF0aW9uIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSAgICAgICBN
YXkgMywgMjAxNA0KDQoNCjUgIEV4YW1wbGUNCg0KICAgQ2xpZW50ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXJ2ZXINCiAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgQ3JlYXRlIGFuIGFjY291bnQgb24gdGhl
IHNlcnZlciAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIHwgICAg
ICAgICAxLiBTZWxlY3Q6IEtERiwgc2FsdCwgaXRlcmF0aW9uLWNvdW50LCBrZXktbGVuZ3RoICAg
IHwNCiAgICAgfCAgICAgICAgIDIuIG1hc3Rlci1rZXkgPSBLREYoUGFzc3dvcmQsIFNhbHQsIEl0
ZXJhdGlvbnMsIEtleS1TaXplKQ0KICAgICB8ICAgICAgICAgMy4gU3RvcmUgaW4gREI6IHVzZXJu
YW1lLCBzYWx0LCBpdGVyYXRpb25zLCBtYXN0ZXIta2V5DQogICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgICB8IEluaXRpYWwtUmVxdWVzdCB1c2VybmFtZUBkb21haW4uY29tICAgICAgICAg
ICAgICAgICAgICAgICAgICB8DQogICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAg
ICAgICAgICAgICAgICBDaGFsbGVuZ2U6IEtleS1EZXJpdmF0aW9uICAgICAgICAgICAgICAgICAg
ICB8DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgS0RGLCBzYWx0LCBrZXktc2l6
ZSwgaXRlcmF0aW9uLWNvdW50DQogICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DQogICBtYXN0ZXIta2V5ID0gS0RGKFBhc3N3b3JkLCBTYWx0LCBJdGVyYXRpb25zLCBLZXkt
U2l6ZSkgICAgICAgICAgIHwNCiAgIFBvcCA9IEhNQUMtU0hBMjU2KG1hc3Rlci1rZXksIHNvbWUt
cmVxdWVzdC1oZWFkZXJzKSAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIHwgUmVz
cG9uc2UgdXNlcm5hbWVAZG9tYWluLmNvbSB3aXRoIFBvcCAgICAgICAgICAgICAgICAgICAgICAg
IHwNCiAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0+fA0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgVGhlIHNlcnZlciBjYWxjdWxhdGVzIHRoZSBQb3AgYmFzZWQg
fA0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBvbiB0aGUgcmVjZWl2ZWQgcmVxdWVz
dCwgdXNpbmcgaXRzICB8DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIG1hc3Rlci1r
ZXksIGFuZCBjb21wYXJlcyBpdCB0byB0aGUgIHwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgICAgUG9wIGl0IHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudCAgICAgfA0KICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIw
MCBPSyBbdG9rZW4sIGV4cGlyZXMsIC4uLl0gfA0KICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiANCg0KDQpTaGVraC1ZdXNlZiwg
ZXQuIGFsLiAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2Ug
Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgIEtleS1EZXJpdmF0aW9uIEF1dGhlbnRpY2F0aW9uIFNj
aGVtZSAgICAgICBNYXkgMywgMjAxNA0KDQoNCjYgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN
CiAgIDxTZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0Pg0KDQoNCjcgIElBTkEgQ29uc2lkZXJh
dGlvbnMNCg0KICAgPElBTkEgY29uc2lkZXJhdGlvbnMgdGV4dD4NCg0KOC4gQWNrbm93bGVkZ21l
bnRzDQoNCiAgIFRoZSBhdXRob3Igd291bGQgbGlrZSB0byB0aGFuayBXYXRzb24gTGFkZCBhbmQg
WW9hdiBOaXIgZm9yIHRoZWlyDQogICByZXZpZXcgYW5kIGNvbW1lbnRzIG9uIHRoZSBwcmUtcHVi
bGlzaGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4NCg0KDQo5ICBSZWZlcmVuY2VzDQoNCjkuMSAg
Tm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3
b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1l
bnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KDQogICBbTklTVC1L
RF0gICJOSVNUIFNwZWNpYWwgUHVibGljYXRpb24gODAwLTEzMiAtIFJlY29tbWVuZGF0aW9ucyBm
b3INCiAgICAgICAgICAgICAgUGFzc3dvcmQtQmFzZWQgS2V5IERlcml2YXRpb25zIiwgRGVjZW1i
ZXIgMjAxMC4NCg0KICAgICAgICAgICAgICBodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlv
bnMvbmlzdHB1YnMvODAwLTEzMi9uaXN0LQ0KICAgICAgICAgICAgICBzcDgwMC0xMzIucGRmDQoN
Cg0KDQo5LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzMyNjFdICBSb3NlbmJl
cmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywgRy4sIEpvaG5zdG9uLA0KICAgICAg
ICAgICAgICBBLiwgUGV0ZXJzb24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiwgYW5kIEUu
DQogICAgICAgICAgICAgIFNjaG9vbGVyLCAiU0lQOiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9j
b2wiLCBSRkMgMzI2MSwNCiAgICAgICAgICAgICAgSnVuZSAyMDAyLg0KDQogICBbUkZDNTM4OV0g
IFJvc2VuYmVyZywgSi4sIE1haHksIFIuLCBNYXR0aGV3cywgUC4sIGFuZCBELiBXaW5nLA0KICAg
ICAgICAgICAgICAiU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIiwg
UkZDIDUzODksDQogICAgICAgICAgICAgIE9jdG9iZXIgMjAwOC4NCg0KICAgW1JGQzY3NDldICBI
YXJkdCwgRC4sICJUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrIiwgICAgICAg
DQogICAgICAgICBSRkMgNjc0OSwgT2N0b2JlciAyMDEyLg0KDQogICBbSFRUUC1QN10gIEZpZWxk
aW5nLCBSLiwgUmVzY2hrZSwgSi4sICJIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wNCiAgIChI
VFRQLzEuMSk6IEF1dGhlbnRpY2F0aW9uIiwgZHJhZnQtaWV0Zi1odHRwYmlzLXA3LWF1dGggKFdv
cmsgaW4NCiAgIFByb2dyZXNzKSwgRmVicnVhcnkgMjAxNC4NCiANCg0KDQpTaGVraC1ZdXNlZiwg
ZXQuIGFsLiAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2Ug
N10NCgwNCkludGVybmV0LURyYWZ0ICAgIEtleS1EZXJpdmF0aW9uIEF1dGhlbnRpY2F0aW9uIFNj
aGVtZSAgICAgICBNYXkgMywgMjAxNA0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQoNCiAgIFJp
ZmFhdCBTaGVraC1ZdXNlZnMNCiAgIEF2YXlhDQogICAyNTAgU3lkbmV5IFN0cmVldA0KICAgQmVs
bGV2aWxsZSwgT250YXJpbw0KICAgQ2FuYWRhDQoNCiAgIFBob25lOiArMS02MTMtOTY3LTUyNjcN
CiAgIEVtYWlsOiByaWZhYXQuaWV0ZkBnbWFpbC5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
U2hla2gtWXVzZWYsIGV0LiBhbC4gICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE0ICAgICAgICAg
ICAgICAgIFtQYWdlIDhdDQo=
--001a113409508653c704f891fd6e--


From nobody Sun May  4 05:35:40 2014
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 8A4D71A0083 for ; Sun,  4 May 2014 05:35:37 -0700 (PDT)
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 rtTRyb3AtxdE for ; Sun,  4 May 2014 05:35:36 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CD0881A0062 for ; Sun,  4 May 2014 05:35:35 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id f8so528841wiw.14 for ; Sun, 04 May 2014 05:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5oxb6dMK+Ir/dkdPBIlo38X47SCy+968A0mjpKgQi18=; b=bp8qjfFhMkZg67RhkmZK4jo3hn6zbtYVUtr/n3d4CLZChg6sF31YHOBxLDaC44HUzO uapU1qLr+qTGNc5mTErbFMcm73K0ayH15ee2TZMustXb/N3zuo5y1fZgwJBu9APLAzjl FAGryWoTNQPsM8oDe7B4yF4QDdULjz6gsSptzhzPvhx/I4bnzoMCS4tzG3uBnGEQLprn SREW96yeX42PwH18Xl+t+OXepnYSGm0fKIeJ3Y9SDd++34c4gK33eGpuNr+FemLkq4JQ k7IczFGVwmoJeAOBQtzXJMlYCp4xl5tgZ+M+OB/h67tXuNlO4NNntt3sdlD8CpBDf461 KiVA==
X-Received: by 10.194.201.73 with SMTP id jy9mr1621975wjc.51.1399206932292; Sun, 04 May 2014 05:35:32 -0700 (PDT)
Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pl6sm11765382wjc.0.2014.05.04.05.35.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 May 2014 05:35:31 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Yoav Nir 
In-Reply-To: <53662898.7040808@iang.org>
Date: Sun, 4 May 2014 15:35:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A635D15-5F35-4FDE-BD73-9A923B53EDBF@gmail.com>
References: <53650F27.6040607@iang.org>  <53662898.7040808@iang.org>
To: ianG 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0INzmvmttLD5u-PwLHsWA8vR-6A
Cc: saag@ietf.org
Subject: Re: [saag] A case against algorithm agility (long)
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: Sun, 04 May 2014 12:35:37 -0000

On May 4, 2014, at 2:46 PM, ianG  wrote:

> On 4/05/2014 04:10 am, Benjamin Kaduk wrote:
>=20
>> That there is even a
>> commercial market for it suggests that they are in use, and not just =
by
>> people who could by pass the crypto.
>=20
>=20
> Yes, this is fascinating.  There's also the SSL-interceptor boxes =
which
> allegedly will take your commercially provided sub-Root.  Who uses =
those
> machines and why?

These boxes are used for whatever purpose people want access to the =
plaintext for. Uses range from running so-called "next generation =
firewall=94([1]) policy on them, to looking for dissidents in certain =
countries.

Commercial CAs rarely give sub-root certificates, and when they do, they =
have  name constraints ([2]), so they can=92t be used for generating =
fake certificates for mail.google.com.  These boxes generally either =
generate their own self-signed CA, or get a corporate sub-CA. Either =
way, it requires clients to be configured with the interception CA.

Yoav=20

[1] =93next generation firewall=94 is a marketing term, but in general =
classic firewall can block addresses, protocols and ports, whereas =93next=
 generation=94 looks at higher layers as well. So a classic firewall can =
block your access to Facebook, a next-generation firewall can block your =
access to Farmville.
[2] Yes, there were cases where this was not followed.=20=


From nobody Sun May  4 09:28:55 2014
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 415261A018E for ; Sun,  4 May 2014 09:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 LYJacNMQGS8z for ; Sun,  4 May 2014 09:28:48 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 565C71A0177 for ; Sun,  4 May 2014 09:28:48 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BE2522AB05D; Sun,  4 May 2014 16:28:43 +0000 (UTC)
Date: Sun, 4 May 2014 16:28:43 +0000
From: Viktor Dukhovni 
To: saag@ietf.org
Message-ID: <20140504162843.GP27883@mournblade.imrryr.org>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TrpWMG-TuIGAPvYLpjaO7HHpzMo
Subject: Re: [saag] Key-Derivation Scheme
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 May 2014 16:28:51 -0000

On Sun, May 04, 2014 at 08:16:54AM -0400, Rifaat Shekh-Yusef wrote:

> Any comments on the idea, described in the attached document, would be
> greatly appreciated.

Why is this the right forum for discussion of the new scheme, rather
than a cryptography mailing list?

As for feedback:

    * This is subject to replay attacks.

    * This does not authenticate the server to the client.

    * Undetected disclosure of the server's master database makes it
      possible to authenticate to the server as any user, which is not the
      case when the server stores password hashes, and the users
      send passwords (the primary use-case in the cited standard).

    * This seems unlikely to get much traction.

-- 
	Viktor.


From nobody Sun May  4 09:47:18 2014
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 4BECA1A00E8 for ; Sun,  4 May 2014 09:47:14 -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 C54k-ohhR7OF for ; Sun,  4 May 2014 09:47:11 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 465DC1A00CB for ; Sun,  4 May 2014 09:47:11 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id s7so3815333lbd.28 for ; Sun, 04 May 2014 09:47:07 -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=YUE4bOJqgqpshv3D902FmnQUuYepI+sKB1h++53xLuM=; b=Zxe0U9KDIjFSo+h1HwRvmkYpyA87dhYzGB56pjntam7hS/IPrMru1kOxc+gAATqG2J KW5PdmwHPlk2mV7g4mWH//mQKP/qe4mB/giNUo7LVzY9V2c7MSD0jOe1OmFePulGA3w9 lRFOPif6rWh2GwoQal3MHNSxmPs4v/Q7wvqln6/k40CPcXI1Sfld/C81JtebrEP7EDb7 P4OVMA8xj6fRfUdV7dy+pk6T682URBTD6KEfeVm5AlkD1CpcE6n/eAKpSKl28bt9nmMn jGAkp/QaODr8T/ol/HNVQ5VKNHkXdWKqEy7sClg9TE4YKfzrAa0lxvprj/msivYjyo5R iC7Q==
MIME-Version: 1.0
X-Received: by 10.112.50.194 with SMTP id e2mr22006833lbo.4.1399222027483; Sun, 04 May 2014 09:47:07 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Sun, 4 May 2014 09:47:07 -0700 (PDT)
In-Reply-To: <20140504162843.GP27883@mournblade.imrryr.org>
References:  <20140504162843.GP27883@mournblade.imrryr.org>
Date: Sun, 4 May 2014 12:47:07 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: saag@ietf.org
Content-Type: multipart/alternative; boundary=001a11336c26e8fbcf04f895c3f9
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hdUprdl_jqNg6PVkf9U24BL1jhE
Subject: Re: [saag] Key-Derivation Scheme
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: Sun, 04 May 2014 16:47:14 -0000

--001a11336c26e8fbcf04f895c3f9
Content-Type: text/plain; charset=ISO-8859-1

Hi Viktor,

Thanks for your comments. Please see my reply inline...

Regards,
 Rifaat



On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni
wrote:

> On Sun, May 04, 2014 at 08:16:54AM -0400, Rifaat Shekh-Yusef wrote:
>
> > Any comments on the idea, described in the attached document, would be
> > greatly appreciated.
>
> Why is this the right forum for discussion of the new scheme, rather
> than a cryptography mailing list?
>
> I am not sure of the best list to discuss this, and I was told to start
here.
The draft is *not* introducing any new crypto algorithms.



> As for feedback:
>
>     * This is subject to replay attacks.
>
> This is mitigated by the number of iterations that server chooses to use
to create the user's master-key.



>     * This does not authenticate the server to the client.
>
> It was not meant to authenticate the server.



>     * Undetected disclosure of the server's master database makes it
>       possible to authenticate to the server as any user, which is not the
>       case when the server stores password hashes, and the users
>       send passwords (the primary use-case in the cited standard).
>
> I am not sure I understand this comment; can you please elaborate?


Thanks,
 Rifaat



>     * This seems unlikely to get much traction.
>
> --
>         Viktor.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--001a11336c26e8fbcf04f895c3f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Viktor,

Thanks for your comments. Pl=
ease see my reply inline...

Regards,
=A0=
Rifaat




On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni <viktor1dane@dukho=
vni.org> wrote:


On Sun, May 04, 2014 at 08:16:54AM -0400, Rifaat Shekh-Yuse=
f wrote:



> Any comments on the idea, described in the attached document, would be=


> greatly appreciated.




Why is this the right forum for discussion of the new scheme, rather<=
br>
than a cryptography mailing list?


I am not sure of the best list to discuss this, and I=
 was told to start here.
The draft is not introducing any =
new crypto algorithms.

=A0


As for feedback:



=A0 =A0 * This is subject to replay attacks.


This is mitigated by the number of iterations that se=
rver chooses to use to create the user's master-key.

=

=A0


=A0 =A0 * This does not authenticate the server to the client.


It was not meant to authenticate the server.

=A0

=A0 =A0 * Undetected disclosure of the server's master database makes i=
t

=A0 =A0 =A0 possible to authenticate to the server as any user, which is no=
t the

=A0 =A0 =A0 case when the server stores password hashes, and the users

=A0 =A0 =A0 send passwords (the primary use-case in the cited standard).

I am not sure I understand this comment; can you plea=
se elaborate?


Thanks,
=A0=
Rifaat

=A0


=A0 =A0 * This seems unlikely to get much traction.



--

=A0 =A0 =A0 =A0 Viktor.



_______________________________________________

saag mailing list

saag@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/saag





--001a11336c26e8fbcf04f895c3f9--


From nobody Sun May  4 22:31:26 2014
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 310721A0251 for ; Sun,  4 May 2014 22:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level: 
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaLQkyk8z6nI for ; Sun,  4 May 2014 22:31:24 -0700 (PDT)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE291A0250 for ; Sun,  4 May 2014 22:31:24 -0700 (PDT)
Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta15.emeryville.ca.mail.comcast.net with comcast id y5Va1n0060b6N64AF5X2PT; Mon, 05 May 2014 05:31:02 +0000
Received: from [192.168.1.8] ([71.202.164.227]) by omta03.emeryville.ca.mail.comcast.net with comcast id y5XL1n0054uhcbK8P5XLSr; Mon, 05 May 2014 05:31:20 +0000
Message-ID: <5366F7E2.7000605@brainhub.org>
Date: Sun, 04 May 2014 22:30:58 -0400
From: Andrey Jivsov 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: ianG , saag@ietf.org
References: <53650F27.6040607@iang.org>
In-Reply-To: <53650F27.6040607@iang.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399267862; bh=jmNAdQtAPJ5RwKwvOWg3wsU+nk0+UlXdvyYd9p5x5WY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uQGeRPD3WWQ0CqUzaqOT/6wI8HIPgC/rm06wKrpjYr/pmgwQJJJPZ2yurgHbc1t6o 75RUTbIT8yDGr4mL4WQtgEsgzDCp/2c3tfMY0raKmJEihhd2JaUhDYCfsC+QpvgreZ 4Dyq81LYtOTKgb22rxj4BMHcZuNd0urIz4K7wscgvlBWA7z9tno7OUVnuK/kuNuWoq d8/3zgy1xcy2y6btLjIZu7TFz4DLDhGPxOfzNhA4FBqbhjjLWZHMraPv3Zh4Iie2eV X+mizTB6ETFOaT+uJYMYRYmwMdfHhC4JsRlsJRQoMvJnBO311qvHiFopa6PuYhPj1q aGAwrmyrfvd3Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FtY0TnvKUhaevghR6bU7QI57RgE
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 05:31:25 -0000

On 05/03/2014 11:45 AM, ianG wrote:
> I've jotted down some notes on the case against agility, as mooted.
> Sorry, long.
>
> It should be called "algorithm agility considered harmful" but I've
> found that some people are irrationally offended by words.  Offense
> doesn't worry me, but distraction helps nobody.
>
...

It is a good idea to limit the number of possible permutations of 
allowed algorithms.

However, the pros for the algorithm agility are:
* compliance with standards (unless all standards in the world specify 
the same suite)
* upgrade to new algorithms (the time-line of the "old" and the "new" 
algorithms typically overlap)
* easier system maintenance (it's easier to add only a new algorithm to 
an old product that is only maintained as opposed to actively developed)
* there might be no single algorithm that is perfect for everybody


From nobody Mon May  5 02:47:10 2014
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 E21121A029B for ; Mon,  5 May 2014 02:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=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 ngn7eu7M41-l for ; Mon,  5 May 2014 02:47:06 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D651A00DF for ; Mon,  5 May 2014 02:47:06 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.134.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s459kWCx027729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 02:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399283210; bh=xZnY4Gnvr9b8HHkoF3xzTg4jeFY6FoFPr72GujV/JBM=; h=Date:To:From:Subject:In-Reply-To:References; b=c583i7Jl4frCESlHPaNGaElPr2ZgsXiHBd7o3jI7DSnI1lEegnQ44HYON9dLue4EP YbhlfECL+u8O0WZZAQ7WQGsn13+zY1FV/HT4CtJA1NWpnuafAV8kJffrtIpTuUxg+o HZRQ8c7mO92uDWM/rOehpi04nbaP9HAGPYvGg9SA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399283210; i=@elandsys.com; bh=xZnY4Gnvr9b8HHkoF3xzTg4jeFY6FoFPr72GujV/JBM=; h=Date:To:From:Subject:In-Reply-To:References; b=zi6QNOEznoDEAgLSoNx6ay+cN+D3iwmjyxZsUwnGHRsGuLCNYf8M/TXRlY4NFKKER Mb9syzPCUCEUXUmmIbdKX5UmrbOFJL26cyYgpMjU8Mtywd45a1+ItQ6DQVN+ZIE+qP QosqEsS+ytA9pAmLOhg0IAMg7PZ30hKNmkeKOK8w=
Message-Id: <6.2.5.6.2.20140505020707.0bd48c48@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 05 May 2014 02:35:43 -0700
To: Andrey Jivsov , saag@ietf.org
From: S Moonesamy 
In-Reply-To: <5366F7E2.7000605@brainhub.org>
References: <53650F27.6040607@iang.org> <5366F7E2.7000605@brainhub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sEQcdTiKz64woHyXG-_kmQznyog
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 09:47:08 -0000

Hi Andrey,
At 19:30 04-05-2014, Andrey Jivsov wrote:
>It is a good idea to limit the number of possible permutations of 
>allowed algorithms.
>
>However, the pros for the algorithm agility are:
>* compliance with standards (unless all standards in the world 
>specify the same suite)

There is an international industry standards group working on a 
reference architecture.  A draft which was published last month 
required compliance with a standard in which there is a security issue.

Is there a possibility that all standards in the world specify the 
same suite?  That sounds unlikely.  However, I looked at standards 
from two countries [1] and I found that they were referencing the 
same standard.

>* there might be no single algorithm that is perfect for everybody

Yes.

Every algorithm does not have to be standardized [2].  That can be a 
mechanism which implementations can use for other algorithms.

Regards,
S. Moonesamy

1. I took a quick look and I found more than two countries.  As I did 
not read the documentation I cannot say that there are more than two countries.

2. What the IETF considers as a standard.  


From nobody Mon May  5 03:30:01 2014
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 C822D1A02A3 for ; Mon,  5 May 2014 03:29:59 -0700 (PDT)
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 QARiO8FiGa2U for ; Mon,  5 May 2014 03:29:58 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 567AF1A02A5 for ; Mon,  5 May 2014 03:29:58 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u57so763387wes.32 for ; Mon, 05 May 2014 03:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hYjfMXMiUVp/j2zXIz1r4Bw8H53qJ5l5+C1RSlnYjGc=; b=V02HvQBbzSZn7bW8R2CDRVlaCaaeoZBCZEy7gaUj2smSzPUNFOarB7v1G5LspJ1Ksh e3SfFffnQHqapXP5X7naJeqXubW2Q9MEG51IcxuAzdat9RqSt9CBq8GtFjogHefQF/U8 cS0I6JY9NMihyj1iwR3Ihu/ZL4ctCsMMktXrAjklx8ko61mVJnY1qS9NGXFz0NiyYdy+ JvTknaNwF6Q/rRli1zSOwbyBECt4I0J46QcBKqzkWGO7sgLYCQh5gyVoTus7OLQiZyKm OBW0a/C+yuFQd9+Rwkv9m+LVDtFeOkUybtJF1N7fd6FIfXJsuglzslswtkc4iK1FEr7n xESQ==
X-Received: by 10.180.12.206 with SMTP id a14mr15225384wic.48.1399285794481; Mon, 05 May 2014 03:29:54 -0700 (PDT)
Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id cd10sm16891653wib.0.2014.05.05.03.29.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 03:29:53 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Yoav Nir 
In-Reply-To: <6.2.5.6.2.20140505020707.0bd48c48@resistor.net>
Date: Mon, 5 May 2014 13:29:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CF4CFC1-736F-4D4A-843E-1C6D96598443@gmail.com>
References: <53650F27.6040607@iang.org> <5366F7E2.7000605@brainhub.org> <6.2.5.6.2.20140505020707.0bd48c48@resistor.net>
To: S Moonesamy 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gjvchJAFP_Ve5_Darvn8Bp7Os2o
Cc: saag@ietf.org
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 10:29:59 -0000

On May 5, 2014, at 12:35 PM, S Moonesamy  wrote:

> Hi Andrey,
> At 19:30 04-05-2014, Andrey Jivsov wrote:
>> It is a good idea to limit the number of possible permutations of =
allowed algorithms.
>>=20
>> However, the pros for the algorithm agility are:
>> * compliance with standards (unless all standards in the world =
specify the same suite)
>=20
> There is an international industry standards group working on a =
reference architecture.  A draft which was published last month required =
compliance with a standard in which there is a security issue.
>=20
> Is there a possibility that all standards in the world specify the =
same suite?  That sounds unlikely.  However, I looked at standards from =
two countries [1] and I found that they were referencing the same =
standard.

You didn=92t say which countries, but if your IPsec/TLS/SSH/SMIME is =
carrying personal information in Russia, it is required to use GOST.  In =
Japan you can use Camelia, but I don=92t know if that would fulfil the =
legal requirements in Europe.

That=92s the beauty of algorithm agility. The same implementation of =
these protocols can be used with all of these different algorithms.

So I think Andrey meant national standards as well as IETF, IEEE, or ISO =
standards.

Yoav


From nobody Mon May  5 04:13:06 2014
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 453A81A02AF for ; Mon,  5 May 2014 04:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AJ1DDD8oHC7n for ; Mon,  5 May 2014 04:13:03 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id B1C951A029E for ; Mon,  5 May 2014 04:13:03 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 00C5A6D5FA; Mon,  5 May 2014 07:12:55 -0400 (EDT)
Message-ID: <53677237.8010908@iang.org>
Date: Mon, 05 May 2014 12:12:55 +0100
From: ianG 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Andrey Jivsov , saag@ietf.org
References: <53650F27.6040607@iang.org> <5366F7E2.7000605@brainhub.org>
In-Reply-To: <5366F7E2.7000605@brainhub.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/91UO9xqv5B81WoW2_hPCYkCcy6U
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 11:13:05 -0000

On 5/05/2014 03:30 am, Andrey Jivsov wrote:
> On 05/03/2014 11:45 AM, ianG wrote:
>> I've jotted down some notes on the case against agility, as mooted.
>> Sorry, long.
>>
>> It should be called "algorithm agility considered harmful" but I've
>> found that some people are irrationally offended by words.  Offense
>> doesn't worry me, but distraction helps nobody.
>>
> ...
> 
> It is a good idea to limit the number of possible permutations of
> allowed algorithms.


:)

> However, the pros for the algorithm agility are:
> * compliance with standards (unless all standards in the world specify
> the same suite)


Why is this a pro?  What conceivable benefit is there to users in
adopting others' standards, when they already have their own?

We're talking about a single protocol that communicates with its own
agents only;  it's TLS versus SSH, they don't ever talk to each other,
it's not like Esperanto versus German.

Here you are in a standards setting, which means you set standards.  By
outsourcing the setting of standards, that means you are not doing the
job.  I can see the argument that you simply want to use other peoples'
work, but I can't see why you would want to save on work by re-use, and
duplicate with your own as well.  Makes no sense to me.


> * upgrade to new algorithms


Yes, just to set the context, there are three different mechanisms
available.  Algorithm agility is (to me) the substitution of new
algorithms within a protocol connection context.  There is also suite
substitution which sets the whole stack.  Then there is also version
upgrade which changes the whole protocol.  Latter is TLS1.1 => TLS1.2.

> (the time-line of the "old" and the "new"
> algorithms typically overlap)

(a result, not an objective)

> * easier system maintenance (it's easier to add only a new algorithm to
> an old product that is only maintained as opposed to actively developed)


Only if you ignore all the other things going on.


> * there might be no single algorithm that is perfect for everybody


The combination of your points 1 & 4 means that every algorithm that has
any single benefit has to be supported by everyone, taken to the extreme.

Again, you have to look hard and deep:  why are you opening the door to
supporting more than one?  Why are you opening the door to many many
algorithms?  Where's the benefit for the user?




iang


From nobody Mon May  5 07:57:13 2014
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 1AC071A00A5 for ; Mon,  5 May 2014 07:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=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 yq94y8T9t8iC for ; Mon,  5 May 2014 07:57:08 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3B1A0366 for ; Mon,  5 May 2014 07:57:07 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.134.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s45EufP6009680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 07:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399301814; bh=DgxXoWB2iBu32Op+uqnXCpYxKElMduqkGZ7rpCJ7+FA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=N39AaEcCWqt6SVGMEipN1sb8n9SB64CUsdNTrRmr1iE7NhYkqlZn1ArAvwFQYT3uS TNdMm033ALbopUoeCCGs8IJPeCb6/fsyLEW5IcMk6bhJhiYiOpr1ptfQEmnX8oBBwf p4EIUL4I8VB12gjcBV6VRmJjyKhH+c+gmoeIrfHk=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399301814; i=@elandsys.com; bh=DgxXoWB2iBu32Op+uqnXCpYxKElMduqkGZ7rpCJ7+FA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sa6G6rTH/Sw1ZN0i1KreZAXzxva150WylAgIg+N532JpnDuSG5Se3+H3rthqWL4d/ xOtu2+8XMIjb9V3egOwQKe1fHFupTyIGJOBgXzaCj+igV8X1W48Qk1Gz4OatHVDxt0 G9EO33Q78hTzKR8NLDfkNjoTZIgounGtrH88Ie7o=
Message-Id: <6.2.5.6.2.20140505064813.0cbc65e8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 05 May 2014 07:41:24 -0700
To: Yoav Nir 
From: S Moonesamy 
In-Reply-To: <9CF4CFC1-736F-4D4A-843E-1C6D96598443@gmail.com>
References: <53650F27.6040607@iang.org> <5366F7E2.7000605@brainhub.org> <6.2.5.6.2.20140505020707.0bd48c48@resistor.net> <9CF4CFC1-736F-4D4A-843E-1C6D96598443@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/kd4HybZuZ0M78etU-KWcaA0E4GM
Cc: saag@ietf.org
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 14:57:10 -0000

Hi Yoav,
At 03:29 05-05-2014, Yoav Nir wrote:
>You didn't say which countries, but if your IPsec/TLS/SSH/SMIME is 
>carrying personal information in Russia, it is required to use 
>GOST.  In Japan you can use Camelia, but I don't know if that would 
>fulfil the legal requirements in Europe.

I did not mention the name countries or the technology as my comments 
were probably off-topic. :-)

Camellia is in the recommended list for Japan since 2013.

>That's the beauty of algorithm agility. The same implementation of 
>these protocols can be used with all of these different algorithms.

I am not disagreeing with what you wrote.  It is worthwhile to 
consider whether there are any valid arguments against algorithm agility.

>So I think Andrey meant national standards as well as IETF, IEEE, or 
>ISO standards.

Yes.

Regards,
S. Moonesamy 


From nobody Mon May  5 08:15:16 2014
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 C5DC01A02BE for ; Mon,  5 May 2014 08:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.455
X-Spam-Level: *
X-Spam-Status: No, score=1.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6] 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 eeMVpJ22gy6m for ; Mon,  5 May 2014 08:15:11 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB01A02B6 for ; Mon,  5 May 2014 08:15:11 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id F1F31350078 for ; Mon,  5 May 2014 08:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=aFRo9vv0gf339+h2lZLZ +V0TBFs=; b=gZ2FCKI6IJ55t94a8Njl9MaqPaNLqUc3z3m3FfaWSh9XYg2dBZar JIz7kx8Rxua9YjJRY1OrRTMK25U7V1LZKe3jFG1pZgM0hj3nvcqcBjN+m70SFTG1 ktBd+ZFMZ7kxN6WN/9W93F56sCoG8H7EdO7nqiKLMpfj+S0yHVsyKHM=
Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 6F5AF350058 for ; Mon,  5 May 2014 08:15:07 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id t61so2364352wes.11 for ; Mon, 05 May 2014 08:15:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.120.68 with SMTP id la4mr3417695wjb.40.1399302906083; Mon, 05 May 2014 08:15:06 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 08:15:05 -0700 (PDT)
In-Reply-To: <53650F27.6040607@iang.org>
References: <53650F27.6040607@iang.org>
Date: Mon, 5 May 2014 10:15:05 -0500
Message-ID: 
From: Nico Williams 
To: ianG 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5EQ4TB6RktqFEJGsugqaMB3q6ik
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 15:15:13 -0000

On Sat, May 3, 2014 at 10:45 AM, ianG  wrote:
> By algorithm agility, I mean the ability to swap AES for TDES for
> ChaCha20 or MD5 for SHA1 for SHA256 or GCM for CBC for CTR or RSA for EC
> for DSA for ... and including small groupings of same such as
> AES+HMAC+SHA+CBC.  The ability to select the entire suite is another
> issue, maybe discussed later.

That's not what we generally mean by algorithm agility.
> 1.  Black boxes they ain't.  Algorithms are sometimes characterised as
> black boxes that can be substituted at will.  Unfortunately it's only a
> hope, it's not met in practice.

That clarifies: you're against a-la carte negotiation.  (Actually, no,
you appear to be against algorithm agility in general.  See below.)

FYI, SSHv2 has a la carte negotiation of key exchange, host
authentication, and cipher+cipher mode (the last always as atomic
pairs) that since the beginning.  There's a case study for you.
Please demonstrate how it's been a problem.

> Consider (a) the emerging sense of sponge constructions, (b) emerging
> calls for 32 byte block sizes and a past of 8 bytes, (c) tendency for

"past"?

> stream ciphers to be blocks underneath, (d) the whole stream v. block
> debate, (e) the shift to AE, (f) changing keylength goals over time.

I agree that 3DES is NOT an appropriate substitute for AES, primarily
because 3DES has a very small block size (64 bits), which impacts on
re-keying considerations and authenticated encryption options.

I also agree that cipher and cipher mode MUST be negotiated as
registered pairs, not a la carte.  This is pretty clear, and I don't
know anyone who is arguing otherwise.

> It's simply not the case that you can reliably blackbox the cipher, the
> hash, the mac, the mode or any other component.  Yes, you can design
> something that substitutes in various black boxes according to this
> vision, and you can force all your algorithms to work as black boxes but
> the result is inelegant, klunky and undesirable.  Hard to maintain, and
> new models cause contortions leading to weakness.

It sounds to me like the only thing you have an argument against is
negotiation of cipher separately from cipher mode.  But no one is
arguing for the other side of that.  It seems to me like you're just
putting up a strawman -- yes, it's easy to knock down!

> [...]

> 5.  Negotiation between software agents is a crock.  Software agents
> don't negotiate, people do, and that's by definition.  The complicated
> matching of ordered preferences that is called agent negotiation is a
> minefield of errors, bad user experience, and opportunity to attack.
> The complication ensures that implementations will not have an easy ride
> together, and even one implementation negotiating against itself is no
> easy thing.

Bunk.  Software negotiates on behalf of people.

> 6.  Attacks.  The existence of algorithm agility opens up the
> possibility of the downgrade attack.  E.g., trick the config string
> (below) to default to the NULL cipher.  Or trick the negotiation to
> choose the weakest cipher.  Etc.

We know how to protect against downgrade attacks.  The biggest problem
w.r.t. downgrade attacks is fallback reconnection, a particularly
obnoxious problem for TLS for historical reasons.

> It also opens up the possibility for bugs (benign) and lousy user
> experience.

This is not really an acceptable argument.  Everything we implement
opens up the possibility of bugs.  It's very difficult to win such an
argument (DJB does this very well when it comes to EC, for example, so
it can be done, but that's a very particular case and not at all
germane to this discussion).

> 7.  Need.  We still have no evidence that any attacker ever has attacked
> the crypto algorithms in TLS or other properly designed protocols (iii).
>  The closest we've got (to my knowledge) is the 512RSA phishing attacks
> in the far east (yes, take that choice away, why on earth do we let
> users choose key sizes?).

Nonsense.  The CBC IV chaining bugs were exploited against SSHv2.  We
were very glad back then to have deployed AES in counter mode as that
saved our butts.

> We simply have no reason to believe that any of the well-designed
> algorithms will be cracked in the next 10 years.  Our expectation that
> they could, derived from WWII warstories and thrilling self-serving
> media headlines, is not a foundation to say there is any expectation at
> all.  It seems that we expect them to fail, and we act as if they will
> fail, *because we can*.  Not because it is likely.

I don't buy this.

> Meanwhile, our actual record of security is rock-bottom because while we
> put exorbitant attention on the next-to-impossible case of algorithm
> failure, we ignore the actual, measurable and costly failure that bad
> protocols contribute to in userland:  phishing, server breaches etc.
> "Out of scope" means we aren't professionally doing risk analysis.

Algorithms most definitely have failed us, sometimes spectacularly!
E.g., MD5, CBC w/ IV chaining, RC4, ...

> [...]

> 11.  MD5.  And then there is MD5 in TLS;  why did it take so long to get
> rid of it?  It turns out that algorithm agility wasn't universally
> deployed all the way through.  Why not?  Because it wasn't easy to put
> algorithm agility into all the places.
>
> So the one time we really needed it ... it wasn't there for us?

It's very difficult to switch algorithms in PKIX.  I.e., we didn't
have algorithm agility for signature hashes.  You've refuted your own
argument.

>
> 12.  Distros rule!  Actually getting a live switch *in algorithms* out
> to userland is very difficult.  It's harder to get people to change
> their config strings than it is to send out a new distribution.  Every
> Linux sysadm understands apt-get.  Every apple user understands Security
> Update, click to restart.  Every MS admin understands backup & re-install.
>
> Relatively few of them understand how to tweak the settings.  Indeed,
> few of them have the first clue about algorithms.  Indeed, it's really
> bad advice to say "switch to RC4" because we have little idea as to
> whether they'll get it right, or whether it'll trigger some other problems.

Configuration management is faster than patch application.  Way, way
faster.  In an emergency this is very handy.

> 13.  Arrogance.  There's something of a hubristic bias in algorithm
> agility.  We do it because we can, because its cool, and we're happy to
> ignore the downstream noise.  We invent rationales as to why we should
> do it.  We talk about how we optimised our implementation to get 5%

Performance matters.  Bad perf -> risk of substantial non-deployment.

> better than the other guy.  We pontificate on how CTR is better than
> GCM, because because, we enjoy poking our thumb at the NSA.

Huh?  GCM is a counter mode.  Just what the heck are you talking about??

> I once knew a guy who said "it is my right to use odd-length RSA keys."
>  I lost a couple of days debugging before I figured out why his keys
> would not communicate with mine.  It is fine to do this in isolation,
> pushing rights and beliefs, but really, are we in the business of
> religion, exporting democracy, motherhood and apple pie?

What has this got to do with alg. agility?

Nico
--


From nobody Mon May  5 09:10:49 2014
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 E6AE81A0381 for ; Mon,  5 May 2014 09:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 Oq_-RglVJGDI for ; Mon,  5 May 2014 09:10:44 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D11A03AA for ; Mon,  5 May 2014 09:10:43 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s45G9vlu005641; Mon, 5 May 2014 09:10:38 -0700
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1kngkfn422-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 05 May 2014 09:10:38 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 5 May 2014 09:10:37 -0700
From: Paul Lambert 
To: Yoav Nir , ianG 
Date: Mon, 5 May 2014 09:11:59 -0700
Thread-Topic: [saag] A case against algorithm agility (long)
Thread-Index: Ac9ofI08AFSWTjHaSsa7rCsIfE9KrA==
Message-ID: 
References: <53650F27.6040607@iang.org>  <53662898.7040808@iang.org> <9A635D15-5F35-4FDE-BD73-9A923B53EDBF@gmail.com>
In-Reply-To: <9A635D15-5F35-4FDE-BD73-9A923B53EDBF@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-05_02:2014-05-05,2014-05-05,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405050261
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Qvqw2eQu1qc87uqoAfpZ9KcgCBM
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 16:10:46 -0000

>
>> On 4/05/2014 04:10 am, Benjamin Kaduk wrote:
>>=20
>>> That there is even a
>>> commercial market for it suggests that they are in use, and not just by
>>> people who could by pass the crypto.
>>=20
>>=20
>> Yes, this is fascinating.  There's also the SSL-interceptor boxes which
>> allegedly will take your commercially provided sub-Root.  Who uses those
>> machines and why?
>
>These boxes are used for whatever purpose people want access to the
>plaintext for. Uses range from running so-called "next generation
>firewall=B2([1]) policy on them, to looking for dissidents in certain
>countries.
>
>Commercial CAs rarely give sub-root certificates, and when they do, they
>have  name constraints ([2]), so they can=B9t be used for generating fake
>certificates for mail.google.com.

No, the intermediate certificates sometimes do not have constraints. There
is a medium sized country that issued unconstrained intermediate
certificates to all of their middle school districts.  Also, revocation
checking for intermediates is typically broken in implementations -
particularly for OCSP stapling.

Paul


>These boxes generally either generate their own self-signed CA, or get a
>corporate sub-CA. Either way, it requires clients to be configured with
>the interception CA.
>
>Yoav=20
>
>[1] =B3next generation firewall=B2 is a marketing term, but in general
>classic firewall can block addresses, protocols and ports, whereas =B3next
>generation=B2 looks at higher layers as well. So a classic firewall can
>block your access to Facebook, a next-generation firewall can block your
>access to Farmville.
>[2] Yes, there were cases where this was not followed.
>_______________________________________________
>saag mailing list
>saag@ietf.org
>https://www.ietf.org/mailman/listinfo/saag


From nobody Mon May  5 09:43:57 2014
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 B4F921A03ED for ; Mon,  5 May 2014 09:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ9BAFVV0TK9 for ; Mon,  5 May 2014 09:43:53 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A432E1A03D4 for ; Mon,  5 May 2014 09:43:53 -0700 (PDT)
Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s45GhmHJ040989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 May 2014 09:43:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90]
From: Paul Hoffman 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Mon, 5 May 2014 09:43:47 -0700
To: saag 
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SbKhuYi5ik55YNBTPosi_C1bFuk
Subject: [saag] On slow uptake of new crypto protocols
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, 05 May 2014 16:43:54 -0000

It's always nice when someone measures stuff for us.

=
http://news.netcraft.com/archives/2014/05/05/sha-2-very-cryptographic-so-s=
ecure-such-growth-wow.html

--Paul Hoffman=


From nobody Mon May  5 10:18:52 2014
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 8A3391A02DD for ; Mon,  5 May 2014 10:18:50 -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 Sm0-5ymilKi2 for ; Mon,  5 May 2014 10:18:48 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D51A02FB for ; Mon,  5 May 2014 10:18:47 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id pn19so1562319lab.1 for ; Mon, 05 May 2014 10:18:44 -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=9zRSvJhaSYdG1JXWTLcAvrRKj4aYd1YKqYWNPg3HhXE=; b=Cf1yssPDHvyOp9XLNIAWwN+PODuwHFA1ThgV9s066hwC+43GekZ1sJpFpthNnoJ1SY QbHxvhuCqEOGvjfljRZ9QSJCle8xVdZFURxXKNnN2Nm+X4a4A0cT5bEDlmWwpPkJsQPP QqpdAdBKVbPlcp59I1Pm8QBQdPjvtLjWz+t+PcuM1n6KVGYgpH9g/gp2+FT4CfA/1nzz zwDPJBiUYPtY6H2dZg331GncSsr6cdviJpLEbvoYVF6XPT/y4qKLbpK6wM26r8hkh5o9 fJDpmWkRHn4RNs+HdfXizQraCvollzNdyAvOCtLgf6uxboQdkpKS4aohu8IaqT13og0b R8iQ==
MIME-Version: 1.0
X-Received: by 10.112.146.202 with SMTP id te10mr1779436lbb.75.1399310323904;  Mon, 05 May 2014 10:18:43 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Mon, 5 May 2014 10:18:43 -0700 (PDT)
In-Reply-To: 
References:  <20140504162843.GP27883@mournblade.imrryr.org> 
Date: Mon, 5 May 2014 13:18:43 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: saag@ietf.org
Content-Type: multipart/alternative; boundary=047d7b3a83e0c9770c04f8aa522c
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1uQdC40chaBKHbh2RNIo32oZ_ew
Subject: Re: [saag] Key-Derivation Scheme
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, 05 May 2014 17:18:50 -0000

--047d7b3a83e0c9770c04f8aa522c
Content-Type: text/plain; charset=ISO-8859-1

Viktor,



> On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni  > wrote:
>
>>
>>
>     * Undetected disclosure of the server's master database makes it
>>       possible to authenticate to the server as any user, which is not the
>>       case when the server stores password hashes, and the users
>>       send passwords (the primary use-case in the cited standard).
>>
>>
>
The protocols require the server to store H(A1) in the case of Digest,
which is a hash of username:real:password.
If the database is compromise, then the server will have the same problem.
Is that what you are talking about here?

Regards,
 Rifaat

--047d7b3a83e0c9770c04f8aa522c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Viktor,

=A0
<=
div dir=3D"ltr">


On Sun, May 4, 2014 at 12:28 PM, Viktor Dukhovni <viktor1dane@dukho=
vni.org> wrote:



=A0=A0

=A0 =A0 * Undetected disclosure of the server's master database makes i=
t

=A0 =A0 =A0 possible to authenticate to the server as any user, which is no=
t the

=A0 =A0 =A0 case when the server stores password hashes, and the users

=A0 =A0 =A0 send passwords (the primary use-case in the cited standard).


<=
br>
The protocols require the server to store H(A1) in the case o=
f Digest, which is a hash of username:real:password.
If the datab=
ase is compromise, then the server will have the same problem.


Is that what you are talking about here?

Rega=
rds,
=A0Rifaat




--047d7b3a83e0c9770c04f8aa522c--


From nobody Mon May  5 10:27:09 2014
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 2CB511A03BA for ; Mon,  5 May 2014 10:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Dd9vrjxhmHvM for ; Mon,  5 May 2014 10:27:03 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2187B1A01BB for ; Mon,  5 May 2014 10:27:03 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id AECEC6D5EC; Mon,  5 May 2014 13:26:53 -0400 (EDT)
Message-ID: <5367C9DC.10009@iang.org>
Date: Mon, 05 May 2014 18:26:52 +0100
From: ianG 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nico Williams 
References: <53650F27.6040607@iang.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/56nglygeKw_EyueaaeUH_mFugus
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 17:27:05 -0000

On 5/05/2014 16:15 pm, Nico Williams wrote:
> On Sat, May 3, 2014 at 10:45 AM, ianG  wrote:

> I also agree that cipher and cipher mode MUST be negotiated as
> registered pairs, not a la carte.  This is pretty clear, and I don't
> know anyone who is arguing otherwise.


Meet the draft:

https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1

Especially 2.1:

   Some approaches carry one identifier for each algorithm that is used.
   Other approaches carry one identifier for a suite of algorithms.
   Either approach is acceptable; however, designers are encouraged to
   pick one of these approaches and use it consistently throughout the
   protocol.

Before we go further, can we just agree on what the above says, and what
the draft implies?

I think it says that "a la carte" is acceptable, to use your term.

...

> Nonsense.  The CBC IV chaining bugs were exploited against SSHv2.  We
> were very glad back then to have deployed AES in counter mode as that
> saved our butts.


Any reference to that?



iang


From nobody Mon May  5 10:32:55 2014
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 D576E1A03F7 for ; Mon,  5 May 2014 10:32:53 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7, 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 KNBLNl_zVGoK for ; Mon,  5 May 2014 10:32:51 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9871A03EC for ; Mon,  5 May 2014 10:32:51 -0700 (PDT)
Received: from mail215-va3-R.bigfish.com (10.7.14.229) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 May 2014 17:32:47 +0000
Received: from mail215-va3 (localhost [127.0.0.1])	by mail215-va3-R.bigfish.com (Postfix) with ESMTP id 051274C02B4;	Mon,  5 May 2014 17:32:47 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: PS-3(zzbb2dI98dIdbb0idbf2izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h17326ah8275bh8275dh1de097h186068h5eeeK1d68dehz2fh109h2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h27e2h)
Received-SPF: pass (mail215-va3: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(24454002)(243025003)(479174003)(51704005)(199002)(189002)(66066001)(50986999)(36756003)(19580405001)(19580395003)(86362001)(81342001)(19300405004)(81542001)(92566001)(19273905006)(2656002)(87936001)(92726001)(79102001)(80022001)(76176999)(99396002)(77982001)(64706001)(54356999)(77096999)(83322001)(20776003)(15975445006)(31966008)(76482001)(74502001)(74482001)(74662001)(4396001)(15202345003)(101416001)(21056001)(83072002)(83506001)(46102001)(85852003)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail215-va3 (localhost.localdomain [127.0.0.1]) by mail215-va3 (MessageSwitch) id 1399311165983586_29808; Mon,  5 May 2014 17:32:45 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.228])	by mail215-va3.bigfish.com (Postfix) with ESMTP id EBF9D60020D; Mon,  5 May 2014 17:32:45 +0000 (UTC)
Received: from AMSPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.5) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 May 2014 17:32:44 +0000
Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT002.eurprd03.prod.outlook.com (10.255.40.37) with Microsoft SMTP Server (TLS) id 14.16.453.0; Mon, 5 May 2014 17:32:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 5 May 2014 17:32:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0934.000; Mon, 5 May 2014 17:32:42 +0000
From: "Paterson, Kenny" 
To: ianG , Nico Williams 
Thread-Topic: [saag] A case against algorithm agility (long)
Thread-Index: AQHPZubNd9Iu85kHOUqnSs3I53FZdpsyG8iAgAAk0gCAABJcgA==
Date: Mon, 5 May 2014 17:32:41 +0000
Message-ID: 
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org>
In-Reply-To: <5367C9DC.10009@iang.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [80.42.220.21]
x-forefront-prvs: 0202D21D2F
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
Content-Type: text/plain; charset="utf-7"
Content-ID: <43E9FBF3216BE747B2D4B6B66AF98167@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PC2EtqtR59DF7ANkyQf1yHWNxWM
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 17:32:54 -0000

On 05/05/2014 18:26, +ACI-ianG+ACI- +ADw-iang+AEA-iang.org+AD4- wrote:

+AD4APg- Nonsense.  The CBC IV chaining bugs were exploited against SSHv2. =
 We
+AD4APg- were very glad back then to have deployed AES in counter mode as t=
hat
+AD4APg- saved our butts.
+AD4-
+AD4-
+AD4-Any reference to that?

How about these:

http://www.kb.cert.org/vuls/id/958563

http://www.openssh.com/txt/cbc.adv


and

http://www.isg.rhul.ac.uk/+AH4-kp/SandPfinal.pdf


(for details of the attack).

Cheers,

Kenny



From nobody Mon May  5 10:43:10 2014
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 12EA71A0411 for ; Mon,  5 May 2014 10:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 14oQWxtwRPc9 for ; Mon,  5 May 2014 10:43:07 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 35DCC1A0413 for ; Mon,  5 May 2014 10:43:06 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id E1B04B806B for ; Mon,  5 May 2014 10:43:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=OhfBRB2uu5fCgir8pKlM 7Ua9Eo8=; b=Iuv9AZ4trQHVZKWbUPbnTp1bE/T88Z1U8TM78ouuxB2R57eW/k85 pGQS2hviYzC/9lDo9D8IV8sRyf3OMbWJrwpuPvDnIrDwJz5aI189BKUKc13K/lKu CbKe5KOLVD1Q2eONVU6KXXz/V9DrsA8Ff3wDnT63UrAp5cwez1X/uT0=
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 82D2EB805C for ; Mon,  5 May 2014 10:43:02 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id x12so5946835wgg.6 for ; Mon, 05 May 2014 10:43:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.108.147 with SMTP id hk19mr16995663wib.42.1399311781478;  Mon, 05 May 2014 10:43:01 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 10:43:01 -0700 (PDT)
In-Reply-To: <5367C9DC.10009@iang.org>
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org>
Date: Mon, 5 May 2014 12:43:01 -0500
Message-ID: 
From: Nico Williams 
To: ianG 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/R6h37PFTC3oVjV5s-aGtjmAX2T4
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 17:43:08 -0000

On Mon, May 5, 2014 at 12:26 PM, ianG  wrote:
> On 5/05/2014 16:15 pm, Nico Williams wrote:
>> On Sat, May 3, 2014 at 10:45 AM, ianG  wrote:
>
>> I also agree that cipher and cipher mode MUST be negotiated as
>> registered pairs, not a la carte.  This is pretty clear, and I don't
>> know anyone who is arguing otherwise.
>
>
> Meet the draft:
>
> https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1
>
> Especially 2.1:
>
>    Some approaches carry one identifier for each algorithm that is used.
>    Other approaches carry one identifier for a suite of algorithms.
>    Either approach is acceptable; however, designers are encouraged to
>    pick one of these approaches and use it consistently throughout the
>    protocol.
>
> Before we go further, can we just agree on what the above says, and what
> the draft implies?

Not really.  It's not clear that the quoted text means that cipher and
cipher mode can be negotiated separately.  I don't think anyone has
proposed such a thing in recent times (years).

> I think it says that "a la carte" is acceptable, to use your term.

As a term or as a concept?

> ...
>
>> Nonsense.  The CBC IV chaining bugs were exploited against SSHv2.  We
>> were very glad back then to have deployed AES in counter mode as that
>> saved our butts.
>
> Any reference to that?

I don't have one handy.  I was at a vendor at the time and we had
already shipped AES in counter mode (with HMAC for authentication), so
it was easy for us to tell our customers what configuration changes
needed to be done to address the problem.

Nico
--


From nobody Mon May  5 10:58:18 2014
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 BE0DE1A0433 for ; Mon,  5 May 2014 10:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 kkb1tS-cttQ9 for ; Mon,  5 May 2014 10:58:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C98AD1A0438 for ; Mon,  5 May 2014 10:58:11 -0700 (PDT)
Received: from [192.168.10.129] ([64.71.18.60]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MK0Np-1Wg06g3yXl-001U80; Mon, 05 May 2014 19:58:05 +0200
Message-ID: <5367D128.2020804@gmx.net>
Date: Mon, 05 May 2014 19:58:00 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Paul Hoffman , saag 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2UVf72PjdxRNEeIU8sUcULsUhVUf5qWAU"
X-Provags-ID: V03:K0:RBOQkBpD2qt5WMt+vclj8hTSlJYGDAQqfys7YqftOKUuAJI6P7A fPzVnrPcd2jiuwA8hZW9QJv8B52k6JCm64HpZKNdt0KQ34iV+ypc/tmtQxdaWr0lu95bxRB 12Xm1nw48XGEaLAqSRsZjVWllxdfn+K3hvlTWZO3bIzn8Ar30L8mklcElSr367iRu5DTbP2 6GYGl1YqQ4n465dxl6XpQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3cYKu95C622ja812d5pgFv5JQV0
Subject: Re: [saag] On slow uptake of new crypto protocols
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, 05 May 2014 17:58:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2UVf72PjdxRNEeIU8sUcULsUhVUf5qWAU
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for sharing this article.

It would be good to brainstorm about how to improve that situation
(which I had raised in the past) instead of spending our time on writing
documents.

I believe we ignore the real problems (which are obviously difficult)
and focus on more convenient work instead (which unfortunately does not
change a lot).

Ciao
Hannes

On 05/05/2014 06:43 PM, Paul Hoffman wrote:
> It's always nice when someone measures stuff for us.
>=20
> http://news.netcraft.com/archives/2014/05/05/sha-2-very-cryptographic-s=
o-secure-such-growth-wow.html
>=20
> --Paul Hoffman
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>=20


--2UVf72PjdxRNEeIU8sUcULsUhVUf5qWAU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTZ9EoAAoJEGhJURNOOiAt9v0H/0BfSB5hf+6xlYEqgya80CA8
IYZayVyR431TE0l+51H34cSBIdiwzJT5I4TQDwZxv9Rc2/bYEzcR2B8fLK643j1P
V4ckheQD3SegKdUXIxbOjWDxkXPTsOGZnTACynSnvkx9MPSD1MlHqg+GUawd9BL6
eC3C4GL+8hYaH6jM7yQy3WqQlGY6zUUxqWCKgOnUo4JTiE4SSAyyYVtRvpY/NLhD
rE/LzQfHzQJnt9rlq6uHZPdmZwo41tKsuRxWk7lBhxFHLcZ2yag+N93NV7zr6EfO
3RiQXSQIGIUFF+XsiDHwapAV0/lynmCHAL0Tnhc+PL8fx3bYC9XniHmpEO4xvvM=
=GP64
-----END PGP SIGNATURE-----

--2UVf72PjdxRNEeIU8sUcULsUhVUf5qWAU--


From nobody Mon May  5 11:15:01 2014
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 063D91A03A5 for ; Mon,  5 May 2014 11:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 d4w2i9caO_P3 for ; Mon,  5 May 2014 11:14:58 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF181A02DE for ; Mon,  5 May 2014 11:14:58 -0700 (PDT)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 521743B8062 for ; Mon,  5 May 2014 11:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7ldXnozIXMIt7/yrU+v3 egcfCmM=; b=u+dO7XIBr+YZW4GyszuYK/FG5VzpFYk03YpVKn2xZl/uJgsTGoY0 cc6Z09YwREhp0iABiflM8+Qglh9lP0S4tJUpPKUhUfpctltO6ZzTFWLBQegJKiEW FiZ7AbaIUSOISd61nkmOE0091Gcz5Ur7S4BiYnAIKO5I3JmCAefQG4Y=
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 00F853B805B for ; Mon,  5 May 2014 11:14:54 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so1366545wes.1 for ; Mon, 05 May 2014 11:14:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.211.116 with SMTP id nb20mr17002242wic.5.1399313693820;  Mon, 05 May 2014 11:14:53 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 11:14:53 -0700 (PDT)
In-Reply-To: <5367C9DC.10009@iang.org>
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org>
Date: Mon, 5 May 2014 13:14:53 -0500
Message-ID: 
From: Nico Williams 
To: ianG 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XxzaIsy7qSBVxPy1qgbbuDPzXHE
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 18:15:00 -0000

On Mon, May 5, 2014 at 12:26 PM, ianG  wrote:
> Meet the draft:
>
> https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1
>
> Especially 2.1:
>
>    Some approaches carry one identifier for each algorithm that is used.
>    Other approaches carry one identifier for a suite of algorithms.
>    Either approach is acceptable; however, designers are encouraged to
>    pick one of these approaches and use it consistently throughout the
>    protocol.

The I-D is a bit barebones at this time -- that tends to be the case
with -00s...  It certainly needs to expand on the details of algorithm
negotiation quite a bit.  In particular it should say that one should
not design protocols to negotiate ciphers and cipher modes separately.
 Text on the pros/cons of a-la-carte vs. cartesian product negotiation
would be handy.

ISTR presentations to SAAG about algorithm agility that could be
leveraged here.  IIRC it was EKR who presented.

Nico


PS: There was no need to post that long screed.  It would have been
better to focus on the cipher-and-mode matter first, especially if you
don't object to a-la-carte negotiation in general.  Long rambling
rants can be a bit of a DoS on the community.  Try to keep it shorter.
 Edit, edit, edit until you have a concise post.


From nobody Mon May  5 11:32:03 2014
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 F050E1A0406 for ; Mon,  5 May 2014 11:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2] 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 agSU1rUmsFzy for ; Mon,  5 May 2014 11:32:00 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 710601A03F0 for ; Mon,  5 May 2014 11:32:00 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 060DC2AB0B4; Mon,  5 May 2014 18:31:56 +0000 (UTC)
Date: Mon, 5 May 2014 18:31:55 +0000
From: Viktor Dukhovni 
To: saag@ietf.org
Message-ID: <20140505183155.GT27883@mournblade.imrryr.org>
References:  <20140504162843.GP27883@mournblade.imrryr.org>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BkaShqfEVLN-VIEo1-lL_zTlKQo
Subject: Re: [saag] Key-Derivation Scheme
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 May 2014 18:32:02 -0000

On Mon, May 05, 2014 at 01:18:43PM -0400, Rifaat Shekh-Yusef wrote:

> The protocols require the server to store H(A1) in the case of Digest,
> which is a hash of username:real:password.
> If the database is compromise, then the server will have the same problem.
> Is that what you are talking about here?

I don't believe this is the right forum for dissecting novel
cryptography.  While I piggy-backed some observations about the
proposal in my initial response, they were not in invitation to
continue the discussion.

-- 
	Viktor.


From nobody Mon May  5 11:45:23 2014
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 0EF6F1A0426 for ; Mon,  5 May 2014 11:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 Ib9HE1rFxC8l for ; Mon,  5 May 2014 11:45:17 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42F1A042A for ; Mon,  5 May 2014 11:45:17 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id c6so840266lan.32 for ; Mon, 05 May 2014 11:45:13 -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=+YPm2CXf5I+x3wFO2s1gcEptn/RQTshPA4c0qB5xGfg=; b=pDJSNOA6pN1L8cNsyvvDxrQysnl54mYbYuRgdKXX3PH8qRzD3xFuORoytODXJ7rz+h tpv8BuohKCWB3WXJHgVcKyuGubuntEJQVDtZD8cqfr6hYRWQLKWobKzon04cOM05VsRO aEfLJjKyCSXGMB7BXp9VAo+rRZwl4JF6PMXeYumcbTTOGvuGK8Udszw+mhBnSV5egbr1 qiydwukAaUQX2gIt9Miq5UGC1jdgA/fLkj0eCqm3khG3kFj74Qst1nMhJNZRNYlx5nfP n6CtkU8oOtCkngWef0E+DemT+Bn1mopybqKaFkUX62w0TOt8IFC0ZvOTj3jJShu7IVGM NNbQ==
MIME-Version: 1.0
X-Received: by 10.152.115.225 with SMTP id jr1mr2294151lab.64.1399315513498; Mon, 05 May 2014 11:45:13 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Mon, 5 May 2014 11:45:13 -0700 (PDT)
In-Reply-To: <20140505183155.GT27883@mournblade.imrryr.org>
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org>
Date: Mon, 5 May 2014 14:45:13 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: saag@ietf.org
Content-Type: multipart/alternative; boundary=001a11c353a81c607304f8ab886e
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sqCR9sN8ml__Jm8xZomALpOg_xs
Subject: Re: [saag] Key-Derivation Scheme
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, 05 May 2014 18:45:20 -0000

--001a11c353a81c607304f8ab886e
Content-Type: text/plain; charset=ISO-8859-1

What is the right forum?

Regards,
 Rifaat


On Mon, May 5, 2014 at 2:31 PM, Viktor Dukhovni wrote:

> On Mon, May 05, 2014 at 01:18:43PM -0400, Rifaat Shekh-Yusef wrote:
>
> > The protocols require the server to store H(A1) in the case of Digest,
> > which is a hash of username:real:password.
> > If the database is compromise, then the server will have the same
> problem.
> > Is that what you are talking about here?
>
> I don't believe this is the right forum for dissecting novel
> cryptography.  While I piggy-backed some observations about the
> proposal in my initial response, they were not in invitation to
> continue the discussion.
>
> --
>         Viktor.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--001a11c353a81c607304f8ab886e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


What is the right forum?

Regards,
=

=A0Rifaat


On Mon, May 5, 2014 at 2:31 PM, Viktor Dukhovni <vikto=
r1dane@dukhovni.org> wrote:


On Mon, May 05, 2014 at 01:1=
8:43PM -0400, Rifaat Shekh-Yusef wrote:



> The protocols require the server to store H(A1) in the case of Digest,=


> which is a hash of username:real:password.

> If the database is compromise, then the server will have the same prob=
lem.

> Is that what you are talking about here?




I don't believe this is the right forum for dissecting novel

cryptography. =A0While I piggy-backed some observations about the

proposal in my initial response, they were not in invitation to

continue the discussion.




--

=A0 =A0 =A0 =A0 Viktor.



_______________________________________________

saag mailing list

saag@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/saag





--001a11c353a81c607304f8ab886e--


From nobody Mon May  5 11:57:49 2014
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 6C0341A0469 for ; Mon,  5 May 2014 11:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Pllo9EDT9cZ7 for ; Mon,  5 May 2014 11:57:45 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 372971A045B for ; Mon,  5 May 2014 11:57:45 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 449146D5A6; Mon,  5 May 2014 14:57:38 -0400 (EDT)
Message-ID: <5367DF22.6010003@iang.org>
Date: Mon, 05 May 2014 19:57:38 +0100
From: ianG 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nico Williams 
References: <53650F27.6040607@iang.org>		<5367C9DC.10009@iang.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8wh7LkmXAGtdPRDXsOCwSn57EK0
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 18:57:47 -0000

On 5/05/2014 19:14 pm, Nico Williams wrote:
> On Mon, May 5, 2014 at 12:26 PM, ianG  wrote:
>> Meet the draft:
>>
>> https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1
>>
>> Especially 2.1:
>>
>>    Some approaches carry one identifier for each algorithm that is used.
>>    Other approaches carry one identifier for a suite of algorithms.
>>    Either approach is acceptable; however, designers are encouraged to
>>    pick one of these approaches and use it consistently throughout the
>>    protocol.
> 
> The I-D is a bit barebones at this time -- that tends to be the case
> with -00s...  It certainly needs to expand on the details of algorithm
> negotiation quite a bit.  In particular it should say that one should
> not design protocols to negotiate ciphers and cipher modes separately.
>  Text on the pros/cons of a-la-carte vs. cartesian product negotiation
> would be handy.


Right.  I suppose it could be read either way, and I read it the other way.


> ISTR presentations to SAAG about algorithm agility that could be
> leveraged here.  IIRC it was EKR who presented.


Hmmm, anyone have the refs?


> Nico
> 
> 
> PS: There was no need to post that long screed.  It would have been
> better to focus on the cipher-and-mode matter first, especially if you
> don't object to a-la-carte negotiation in general.  Long rambling
> rants can be a bit of a DoS on the community.  Try to keep it shorter.
>  Edit, edit, edit until you have a concise post.


I was briskly told to make the case, get to the back of the queue ;)



iang


From nobody Mon May  5 11:59:48 2014
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 7ACF51A0470 for ; Mon,  5 May 2014 11:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 N6ALeNydBXqB for ; Mon,  5 May 2014 11:59:41 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id B129D1A0441 for ; Mon,  5 May 2014 11:59:41 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 16A1C6D5A6; Mon,  5 May 2014 14:59:36 -0400 (EDT)
Message-ID: <5367DF99.1060700@iang.org>
Date: Mon, 05 May 2014 19:59:37 +0100
From: ianG 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Paterson, Kenny" ,  Nico Williams 
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-7
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/T-GNeWl8L-aCCFHFkh-tJodOHwI
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 18:59:43 -0000

On 5/05/2014 18:32 pm, Paterson, Kenny wrote:
>>> Nonsense.  The CBC IV chaining bugs were exploited against SSHv2.  We
>>> were very glad back then to have deployed AES in counter mode as that
>>> saved our butts.
>>
>>
>> Any reference to that?
> 
> How about these:

Thanks!  Excellent.  Was there any fallout, any actual attacks or damages?

> http://www.kb.cert.org/vuls/id/958563
> 
> http://www.openssh.com/txt/cbc.adv

     "A future version of OpenSSH may make CTR mode ciphers the default
and/or implement other countermeasures, but at present we do not feel
that this issue is serious enough to make an emergency release."



On the face of those texts, this was a nice exploit of academic note,
but not a likely one, nor a practical one.  Something to be fixed, but
not something to inform our design choices in the future.

I'll let my point 7. stand unless there is some info about attacks and
damages.

(One question:  is Nico's claim that this is an example of "being saved"
more to do with commercial vendors' need to ship product with no
theoretical or known flaws?)



> 
> and
> 
> http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf
> 
> 
> (for details of the attack).
> 
> Cheers,
> 
> Kenny


thanks again,

iang


From nobody Mon May  5 12:24:12 2014
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 B8BB31A0452 for ; Mon,  5 May 2014 12:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.94
X-Spam-Level: 
X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] 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 qhntyas6W52i for ; Mon,  5 May 2014 12:24:05 -0700 (PDT)
Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4641A0455 for ; Mon,  5 May 2014 12:24:05 -0700 (PDT)
Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA09654; Mon, 5 May 2014 15:23:38 -0400 (EDT)
Date: Mon, 5 May 2014 15:23:38 -0400 (EDT)
From: Mouse 
Message-Id: <201405051923.PAA09654@Chip.Rodents-Montreal.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
X-Composition-Start-Date: Mon, 5 May 2014 15:22:14 -0400 (EDT)
To: saag@ietf.org
In-Reply-To: 
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org> 
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZntYSIoVm0N4hYxBcjUh3HodSTU
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 19:24:07 -0000

> http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf

Fascinating.  Thank you; I'd somehow managed to not hear of that.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From nobody Mon May  5 12:25:54 2014
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 E72161A0452 for ; Mon,  5 May 2014 12:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 PCVESnaC1-2m for ; Mon,  5 May 2014 12:25:46 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E27E91A045C for ; Mon,  5 May 2014 12:25:45 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 888086B0078 for ; Mon,  5 May 2014 12:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fETVL77DEP08v2Cd4PAS g5lQI8o=; b=JY6mFN2e3jiUDdUcQqN68rzQxaVW5N43jtm3H0j3SmoK7kmmuExZ xxlJZJsWKwT6FaFjW2nWYcQDLOzaLfFfJJYXciNx7a6+DijGK3JT3mPG2vYi4DYW G4VQBpVVn7FDh2qJdXZbepowxPAeT9/8jjGgHeuUiavWLnPYTy0jq88=
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 3600F6B0070 for ; Mon,  5 May 2014 12:25:42 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id x48so2668212wes.36 for ; Mon, 05 May 2014 12:25:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.221.8 with SMTP id qa8mr17289509wic.39.1399317941018; Mon, 05 May 2014 12:25:41 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 12:25:40 -0700 (PDT)
In-Reply-To: <5367DF99.1060700@iang.org>
References: <53650F27.6040607@iang.org>  <5367C9DC.10009@iang.org>  <5367DF99.1060700@iang.org>
Date: Mon, 5 May 2014 14:25:40 -0500
Message-ID: 
From: Nico Williams 
To: ianG 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/G-saZ5qNUSY9L0SMb0EhIA5iwCU
Cc: "saag@ietf.org" 
Subject: Re: [saag] A case against algorithm agility (long)
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, 05 May 2014 19:25:50 -0000

On Mon, May 5, 2014 at 1:59 PM, ianG  wrote:
> (One question:  is Nico's claim that this is an example of "being saved"
> more to do with commercial vendors' need to ship product with no
> theoretical or known flaws?)

We considered the attack realistic in some environments, therefore we
felt we had to fix it.  Since we had shipped AES in counter mode, we
didn't have to hurry all that much, so in a sense we were "saved" some
negative consequences.

Nico
--


From nobody Mon May  5 13:12:09 2014
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 BE28E1A04AC for ; Mon,  5 May 2014 13:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.044
X-Spam-Level: 
X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334] 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 1cJgC_ZrYI-F for ; Mon,  5 May 2014 13:12:04 -0700 (PDT)
Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF91A04A9 for ; Mon,  5 May 2014 13:11:52 -0700 (PDT)
Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 37DB220078710 for ; Mon,  5 May 2014 13:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=H63m03ic7tI582vMJBBlmQr oajQ=; b=T+e5GciWwiwVxt8DXvpkeE32vGU7ciWuM5qu9LNMmOyw+QaRryMQQni ucnMRSJ7HxXK9CzK/l8xwc/ahvxbBgdYl9lAN4Z2Ms3dPJgiK6k5K5TIVBOp/lWX fBCcoK9FyjdChIw4AXNelDLoR9rAihyevJzw0LR1BlCYNpfnWDcE=
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id E04002007870B for ; Mon,  5 May 2014 13:11:48 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id f8so2376595wiw.8 for ; Mon, 05 May 2014 13:11:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.221.8 with SMTP id qa8mr17432066wic.39.1399320707893; Mon, 05 May 2014 13:11:47 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 13:11:47 -0700 (PDT)
In-Reply-To: <20140505183155.GT27883@mournblade.imrryr.org>
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org>
Date: Mon, 5 May 2014 15:11:47 -0500
Message-ID: 
From: Nico Williams 
To: "saag@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/N765I2gUYfmYhjBWXeZbum300kg
Subject: Re: [saag] Key-Derivation Scheme
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, 05 May 2014 20:12:07 -0000

On Mon, May 5, 2014 at 1:31 PM, Viktor Dukhovni
 wrote:
> On Mon, May 05, 2014 at 01:18:43PM -0400, Rifaat Shekh-Yusef wrote:
>
>> The protocols require the server to store H(A1) in the case of Digest,
>> which is a hash of username:real:password.
>> If the database is compromise, then the server will have the same problem.
>> Is that what you are talking about here?
>
> I don't believe this is the right forum for dissecting novel
> cryptography.  While I piggy-backed some observations about the
> proposal in my initial response, they were not in invitation to
> continue the discussion.

Is there novel cryptography here?  The referenced NIST publication
refers to PKCS#5, which is in widespread use in Internet protocols.
It is not novel.

My response to the proposed I-D is that we already have protocols
making use of PBKDF2, such as SCRAM (RFC5802).  Any new proposals in
this space should take existing protocols into consideration.

Also, we *do* need novel PBKDFs, like scrypt.  Those should first be
discussed in CFRG (cfrg@ietf.org).

Nico
--


From nobody Mon May  5 13:30:32 2014
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 B3D1F1A04F1 for ; Mon,  5 May 2014 13:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 j9UhvJUpFIUj for ; Mon,  5 May 2014 13:30:30 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D8BA31A04E9 for ; Mon,  5 May 2014 13:30:29 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wp18so1436580obc.17 for ; Mon, 05 May 2014 13:30:26 -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 :cc:content-type; bh=AIm+ZLWd0RzYnPVS8aQEz2D8blU5OIhuFGZAClA5sSI=; b=ba6y//HHwzBlk8FdUSYyc1gryVi5gLLPc1c/rxqAaBotUroAzxVSe4tRU23EmHZmOe ry13lcCaqUFNuDoYdh2udS3hCcp4R8cOsA7DuEMico2y/artUqP/a/6bp9cweCUyG/Xv 3tAUdEvmoPHG0IM6BjREKfvjTkJmlDbM0zFuWRWOhO8BlLNq0g0rQmQLACTdAGPUr1eg TUgZyQDOMotmcZEty+dQkO4ggKPuMB7geioeWv4ZA8wRXtolGwm/MBI5KyGAlLucfsU2 nNIjYV/ktDb9Le1rM+/EYJN8aIF+cTMW1WCCduC42ToLW+kdSROnviTbPachuo0L/7+a byhQ==
MIME-Version: 1.0
X-Received: by 10.60.15.38 with SMTP id u6mr35420788oec.26.1399321826372; Mon, 05 May 2014 13:30:26 -0700 (PDT)
Received: by 10.182.80.100 with HTTP; Mon, 5 May 2014 13:30:26 -0700 (PDT)
In-Reply-To: 
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org> 
Date: Mon, 5 May 2014 16:30:26 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=089e013cc0246333ad04f8ad0029
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NQf3uxwxA34b8Vm1AjuPkAa2mfc
Cc: "saag@ietf.org" 
Subject: Re: [saag] Key-Derivation Scheme
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, 05 May 2014 20:30:31 -0000

--089e013cc0246333ad04f8ad0029
Content-Type: text/plain; charset=ISO-8859-1

Hi Nico,

Thanks for you comments.
As I mentioned in a previous email, "The draft is *not* introducing any new
crypto algorithms.", so I agree with you that there is no novel
cryptography here.
I will take a look at the SCRAM document.

I will also take a look at scrypt.
I have looked at J-PAKE as a possible protocol that could fit into a
challenge-response framework.
When I have some text around these I will try to discuss them on the CFRG
mailing list.

How about this draft? where should this be discussed?

Regards,
 Rifaat


On Mon, May 5, 2014 at 4:11 PM, Nico Williams  wrote:

> On Mon, May 5, 2014 at 1:31 PM, Viktor Dukhovni
>  wrote:
> > On Mon, May 05, 2014 at 01:18:43PM -0400, Rifaat Shekh-Yusef wrote:
> >
> >> The protocols require the server to store H(A1) in the case of Digest,
> >> which is a hash of username:real:password.
> >> If the database is compromise, then the server will have the same
> problem.
> >> Is that what you are talking about here?
> >
> > I don't believe this is the right forum for dissecting novel
> > cryptography.  While I piggy-backed some observations about the
> > proposal in my initial response, they were not in invitation to
> > continue the discussion.
>
> Is there novel cryptography here?  The referenced NIST publication
> refers to PKCS#5, which is in widespread use in Internet protocols.
> It is not novel.
>
> My response to the proposed I-D is that we already have protocols
> making use of PBKDF2, such as SCRAM (RFC5802).  Any new proposals in
> this space should take existing protocols into consideration.
>
> Also, we *do* need novel PBKDFs, like scrypt.  Those should first be
> discussed in CFRG (cfrg@ietf.org).
>
> Nico
> --
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--089e013cc0246333ad04f8ad0029
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Nico,

Thanks for you comments.
=

As I mentioned in a previous email, "The draft is=A0not=A0introducing any new crypto algorithms.", so I agree with you that there is no novel cryptography here.

I will take a look at the SCRAM document.

I w=
ill also take a look at scrypt.=A0
I have looked at J-PAKE as a p=
ossible protocol that could fit into a challenge-response framework.


When I have some text around these I will try to discuss them on the C=
FRG mailing list.

How about this draft? where shou=
ld this be discussed?

Regards,
=A0Rifaat=





On Mon,=
 May 5, 2014 at 4:11 PM, Nico Williams <nico@cryptonector.com><=
/span> wrote:


On Mon, May 5, 2014 at 1:31 =
PM, Viktor Dukhovni

<viktor1dane@dukhovni.org> wrote:

> On Mon, May 05, 2014 at 01:18:43PM -0400, Rifaat Shekh-Yusef wrote:
>

>> The protocols require the server to store H(A1) in the case of Dig=
est,

>> which is a hash of username:real:password.

>> If the database is compromise, then the server will have the same =
problem.

>> Is that what you are talking about here?

>

> I don't believe this is the right forum for dissecting novel

> cryptography. =A0While I piggy-backed some observations about the

> proposal in my initial response, they were not in invitation to

> continue the discussion.




Is there novel cryptography here? =A0The referenced NIST publication<=
br>
refers to PKCS#5, which is in widespread use in Internet protocols.

It is not novel.



My response to the proposed I-D is that we already have protocols

making use of PBKDF2, such as SCRAM (RFC5802). =A0Any new proposals in

this space should take existing protocols into consideration.



Also, we *do* need novel PBKDFs, like scrypt. =A0Those should first be

discussed in CFRG (cfrg@ietf.org).



Nico

--




_______________________________________________

saag mailing list

saag@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/saag





--089e013cc0246333ad04f8ad0029--


From nobody Tue May  6 10:34:29 2014
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 6C7031A01AE for ; Tue,  6 May 2014 10:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Level: 
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 m1jtrbsfhBbt for ; Tue,  6 May 2014 10:34:27 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 69FBE1A0196 for ; Tue,  6 May 2014 10:34:27 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7048EA888018; Tue,  6 May 2014 10:34:23 -0700 (PDT)
Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 6 May 2014 10:34:23 -0700 (PDT)
Message-ID: <98cf4fcf5dd66587207642309c2c84ee.squirrel@www.trepanning.net>
In-Reply-To: 
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org>  
Date: Tue, 6 May 2014 10:34:23 -0700 (PDT)
From: "Dan Harkins" 
To: "Rifaat Shekh-Yusef" 
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: http://mailarchive.ietf.org/arch/msg/saag/3ZSxCMwN4RRApVtcVA0nPh_Yvps
Cc: "saag@ietf.org" 
Subject: Re: [saag] Key-Derivation Scheme
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, 06 May 2014 17:34:28 -0000

On Mon, May 5, 2014 1:30 pm, Rifaat Shekh-Yusef wrote:
> Hi Nico,
>
> Thanks for you comments.
> As I mentioned in a previous email, "The draft is *not* introducing any
> new
> crypto algorithms.", so I agree with you that there is no novel
> cryptography here.
> I will take a look at the SCRAM document.
>
> I will also take a look at scrypt.
> I have looked at J-PAKE as a possible protocol that could fit into a
> challenge-response framework.

  The NIST document says:

    "The scheme ensures that the password and the master-key are
      never sent on the wire, and allows for a better secure storage of
      passwords as it significantly increases the amount of computation
      needed to derive a key from a password in a dictionary attack."

So it merely increases the amount of computation needed to perform
a dictionary attack, it does not prevent a dictionary attack. It's much
better to actually prevent  a dictionary attack and any PAKE protocol
would do that for you.

  Dan.



From nobody Tue May  6 13:32:26 2014
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 A55A01A02A7 for ; Tue,  6 May 2014 13:32:23 -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 Cn3F2EAHZNI3 for ; Tue,  6 May 2014 13:32:21 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 727FD1A01B6 for ; Tue,  6 May 2014 13:32:21 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id w7so28874lbi.15 for ; Tue, 06 May 2014 13:32:16 -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 :cc:content-type; bh=Z8hjd2vsVQFStKHmj2r6/aha/uKG4pB6Csrgat3jcJk=; b=BlCXkK5y+3gaJe2NqVXVmI1v+cmtgz3urXAah4mUB0PM1vw1U11MGMKvgvQKUhGJb6 8qJHf5hyHsVOtk/BNF7u3sj4AKAwpfKHkRgujhPfZMYhBJsCPW9G/71gUn6nCy0RFgEo j+coaGTRZZ0hipdZ33MiMRFYGGgasB8KmJdyICYnKE407XmWnF6VCbZOxX4h7Usnwp2j hBGLjudg5l7lBKyFDkXCptC9kUau2B7O2GUmc71RLPyidqgRJ2OFIc72+7pF5b7NHWok Ajpda2tKi9IMKdaCrHgJktN8WDLL8mN5B/wxZ3POgEFkI/QE2kD9XVP84RMrz/c5poyh FHkg==
MIME-Version: 1.0
X-Received: by 10.112.201.1 with SMTP id jw1mr6213881lbc.47.1399408336683; Tue, 06 May 2014 13:32:16 -0700 (PDT)
Received: by 10.114.5.102 with HTTP; Tue, 6 May 2014 13:32:16 -0700 (PDT)
In-Reply-To: <98cf4fcf5dd66587207642309c2c84ee.squirrel@www.trepanning.net>
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org>   <98cf4fcf5dd66587207642309c2c84ee.squirrel@www.trepanning.net>
Date: Tue, 6 May 2014 16:32:16 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=001a11c36ca8ce4c7b04f8c124e6
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Wsd03kpKYTSk5GbJbhHJ5y-lIEU
Cc: "saag@ietf.org" 
Subject: Re: [saag] Key-Derivation Scheme
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, 06 May 2014 20:32:23 -0000

--001a11c36ca8ce4c7b04f8c124e6
Content-Type: text/plain; charset=ISO-8859-1

Hi Dan,

The NIST document talks about the latter part of the quote (the increase of
computation).

I guess that the result would depend on the number of iterations selected
by the server.
If the solution can tolerate some delay in the initial communication
between the client and the sever, then the server can select an iteration
number that would practically prevent a dictionary attack.

I agree with you that PAKE-based solution would be better, but these
solutions will either require some changes to the challenge-response
framework, or will not fit into the challenge-response framework.
I am looking at J-PAKE; will see if that fits into the challenge-response
framework.

Regards,
 Rifaat



On Tue, May 6, 2014 at 1:34 PM, Dan Harkins  wrote:

>
>
> On Mon, May 5, 2014 1:30 pm, Rifaat Shekh-Yusef wrote:
> > Hi Nico,
> >
> > Thanks for you comments.
> > As I mentioned in a previous email, "The draft is *not* introducing any
> > new
> > crypto algorithms.", so I agree with you that there is no novel
> > cryptography here.
> > I will take a look at the SCRAM document.
> >
> > I will also take a look at scrypt.
> > I have looked at J-PAKE as a possible protocol that could fit into a
> > challenge-response framework.
>
>   The NIST document says:
>
>     "The scheme ensures that the password and the master-key are
>       never sent on the wire, and allows for a better secure storage of
>       passwords as it significantly increases the amount of computation
>       needed to derive a key from a password in a dictionary attack."
>
> So it merely increases the amount of computation needed to perform
> a dictionary attack, it does not prevent a dictionary attack. It's much
> better to actually prevent  a dictionary attack and any PAKE protocol
> would do that for you.
>
>   Dan.
>
>
>

--001a11c36ca8ce4c7b04f8c124e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Dan,

The NIST document talks about t=
he latter part of the quote (the increase of computation).
I guess that the result would depend on the number of iteratio=
ns selected by the server.=A0


If the solution can tolerate some delay in the initial communication b=
etween the client and the sever, then the server can select an iteration nu=
mber that would practically prevent a dictionary attack.



I agree with you that PAKE-based solution would be better, but t=
hese solutions will either require some changes to the challenge-response f=
ramework, or will not fit into the challenge-response framework.

I am looking at J-PAKE; will see if that fits into the challenge-response f=
ramework.

Regards,
=A0Rifaat




On Tue, May 6, 2014 at 1:34 PM, Dan Harkins <dharkins@lounge.org&g=
t; wrote:






On Mon, May 5, 2014 1:30 pm, Rifaat Shekh-Yusef wrote:

> Hi Nico,

>

> Thanks for you comments.


> As I mentioned in a previous email, "The draft is *not* int=
roducing any


> new

> crypto algorithms.", so I agree with you that there is no novel
> cryptography here.

> I will take a look at the SCRAM document.

>

> I will also take a look at scrypt.

> I have looked at J-PAKE as a possible protocol that could fit into a
> challenge-response framework.




=A0 The NIST document says:



=A0 =A0 "The scheme ensures that the password and the master-key are
=A0 =A0 =A0 never sent on the wire, and allows for a better secure storage =
of

=A0 =A0 =A0 passwords as it significantly increases the amount of computati=
on

=A0 =A0 =A0 needed to derive a key from a password in a dictionary attack.&=
quot;




So it merely increases the amount of computation needed to perform
a dictionary attack, it does not prevent a dictionary attack. It's much=


better to actually prevent =A0a dictionary attack and any PAKE protocol

would do that for you.



=A0 Dan.









--001a11c36ca8ce4c7b04f8c124e6--


From nobody Thu May  8 08:25:10 2014
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 A99E71A02CF; Mon,  5 May 2014 09:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level: 
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] 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 yiHnC9VHqSVs; Mon,  5 May 2014 09:16:03 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 018771A02B6; Mon,  5 May 2014 09:16:02 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E6712804DA; Mon,  5 May 2014 12:15:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399306555; bh=3Vrt+uWAdDlXvqbm51j9Ih3183+BlH1iHhE+cgNWGg4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qVoWbVgrP7uTB8QyO1Wcf139R66Q6JWTuMo0nsa8UrhqUo6WX7vNwQsLirM5D4Rbw B7NqDpJjrbzOdzzDuU1sfioaSz7TgH+Hlsky5+roIlK1AUmHzObMf/VCvzzwgyCx1R z+WbYxvZRNmMUntvC031ZohlzURhTkU5NnZlBMYI=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s45GFqCK026731; Mon, 5 May 2014 12:15:53 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 5 May 2014 12:15:52 -0400 (EDT)
From: Paul Wouters 
To: ietf@ietf.org, saag@ietf.org
In-Reply-To: <536775D2.4090708@raphaeldurand.fr>
Message-ID: 
References: <536775D2.4090708@raphaeldurand.fr>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xeG6NTk-TNSUCnYwIlGXrC8xzew
X-Mailman-Approved-At: Thu, 08 May 2014 08:25:08 -0700
Cc: draft-loreto-httpbis-explicitly-auth-proxy@tools.ietf.org
Subject: Re: [saag] Trust and provacy problems with draft-loreto-httpbis-explicitly-auth-proxy
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, 05 May 2014 16:16:05 -0000

On Mon, 5 May 2014, Raphaël Durand wrote:

> I've just read the draft draft-loreto-httpbis-explicitly-auth-proxy, and I see a lot of trust and privacy problem in this
> "Explicit auth proxy".
> https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/?include_text=1
> 
> The first problem is in the "opt-out" section (3.3).
> First, it has to be "opt-in" not "opt-out" (it's called an "explicit auth proxy isn't it ?")

It refers to the user having accepted to proxy for everything and than
explicitely excluding something. So I don't have a problem with that
specific toggle - I do, like you,  have a problem with the entire document.

> "To ensure the trustfulness of proxies, certification authorities validation procedure for issuing proxy certificates
> should be more rigorous than for issuing normal certificates and may also include technical details and processes relevant
> for the security assurance."
> 
> No, public CA must not sign these certificates. Proxies certificates must be signed by a local CA explicitly trusted by the
> user.

I fully agree.

> "6. Security Considerations
> "Those resources are protected end-to- end between user agent and origin server as usual."
> 
> No they are not, there is a third-party proxy between them. The user do not operate it, so he can't trust it.

Indeed, and it further interferes and breaks out-of-band key validation,
such as TLSA/DNSSEC. So a protocol modification is completely useless,
as the application needs to turn off so many security features, it might
as well take the certificate check/override into the application as
well.

I must say, it is becoming rather tiring to see new incantations of
protocol modifications to account for "legalised MITM attacks". How
many times do we have to repeat that is a problem to be solved at the
application and/or OS level and not at the protocol level?

We have enough problems keeping our protocols secure without adding
dangerous protocol-based legalised attack modes into our protocols.

I am strongly against in-band MITM protocol modifications as specified
by this draft, its precursor drafts, and the inevitable follow up drafts.

Take your legalised enterprise MITM ideas to the OS and browser vendors.

Paul


From nobody Thu May  8 08:42:09 2014
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 05D501A00B1 for ; Thu,  8 May 2014 08:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 CAlx25ybPJLF for ; Thu,  8 May 2014 08:42:05 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9311A0096 for ; Thu,  8 May 2014 08:42:05 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 9CDA620047B6D for ; Thu,  8 May 2014 08:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=b/LmJCqRjCJlbqW87jxKyNcXBFA=; b=VU+p0JLZgB+ pXM+X14M8uHQamgHt0NZNQ8aalmt9LfWmdpQKGv2rhL5jDLd7Hef72kFTsK4zFwF XKTMKknfgmQIXKReEtu8Q/RxV5JUAjmeJ2bN6BioHu4avxwBom3d+Q+zSvPVJCAV rTtkV3HAUSFGeiL1yQRAaDDOAjm5tqHo=
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 5271B20047B65 for ; Thu,  8 May 2014 08:42:00 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id n12so2714452wgh.5 for ; Thu, 08 May 2014 08:41:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.143.109 with SMTP id sd13mr742530wjb.95.1399563719019; Thu, 08 May 2014 08:41:59 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 8 May 2014 08:41:58 -0700 (PDT)
Date: Thu, 8 May 2014 10:41:58 -0500
Message-ID: 
From: Nico Williams 
To: "saag@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jT-yOJzn2RvKSAKZAcc4v50DFWo
Subject: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 15:42:06 -0000

I think so.

DNSSEC is a PKI after all.  If we need CT (certificate transparency)
for PKIX, why wouldn't we also need it for DNSSEC?

I think the answer is that we will need CT for DNSSEC.

What would CT look like for DNSSEC?

Nico
--


From nobody Thu May  8 08:55:41 2014
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 17DB51A0078 for ; Thu,  8 May 2014 08:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 DTnuMnYIcczY for ; Thu,  8 May 2014 08:55:38 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 18FC41A0065 for ; Thu,  8 May 2014 08:55:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8CFCABE54; Thu,  8 May 2014 16:55:32 +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 8LbBKcC+kOEo; Thu,  8 May 2014 16:55:31 +0100 (IST)
Received: from [190.112.52.71] (unknown [190.112.52.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D77DCBE56; Thu,  8 May 2014 16:55:29 +0100 (IST)
Message-ID: <536BA8ED.4020209@cs.tcd.ie>
Date: Thu, 08 May 2014 16:55:25 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Nico Williams ,  "saag@ietf.org" 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Sw0MWv7g-tXGGAxzNEH2EYM7W4s
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 15:55:40 -0000

Hi Nico,

On 08/05/14 16:41, Nico Williams wrote:
> I think so.
> 
> DNSSEC is a PKI after all.  If we need CT (certificate transparency)
> for PKIX, why wouldn't we also need it for DNSSEC?
> 
> I think the answer is that we will need CT for DNSSEC.
> 
> What would CT look like for DNSSEC?

We have a WG (trans [1]) that is chartered to do CT but
also to consider whether there are further uses for that
kind of log. I'd say that list might be better for this
discussion, but maybe check with the chair (Melinda, cc'd)
to see if she'd prefer have that discussion now or after
some more of the initial work is done.

Cheers,
S.

[1] https://tools.ietf.org/wg/trans/

> 
> Nico
> --
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
> 


From nobody Thu May  8 09:10:42 2014
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 8F9B41A006B for ; Thu,  8 May 2014 09:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 eTedfqQS-SHm for ; Thu,  8 May 2014 09:10:39 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EC2111A005E for ; Thu,  8 May 2014 09:10:38 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 92BC11635 for ; Thu,  8 May 2014 09:10:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ver08Xhe4UY4mOYYaFRF dmB3/M4=; b=wvhViT1a+J0Ko+PardeGaEXJAiLw8ajfeET5lnSYPKAe1Uz+tV6O gqOL9MPUfUGDedn+StuSqoMOZ6fH5ZZsviyJss/VaTFC3Ma4b++wOrmXTcmm5C/6 fZu2SGy8MmBJc+0SPbrp/H3o8OaRiWVvANK1436CXfU2WiNcUH6RG5g=
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 4006F1601 for ; Thu,  8 May 2014 09:10:34 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id x12so2667833wgg.21 for ; Thu, 08 May 2014 09:10:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.160.166 with SMTP id xl6mr4288459wib.42.1399565433144; Thu, 08 May 2014 09:10:33 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 8 May 2014 09:10:33 -0700 (PDT)
In-Reply-To: <536BA8ED.4020209@cs.tcd.ie>
References:  <536BA8ED.4020209@cs.tcd.ie>
Date: Thu, 8 May 2014 11:10:33 -0500
Message-ID: 
From: Nico Williams 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/l9OIVVx9hL2cRqgnSV-KEgjNr7w
Cc: "saag@ietf.org" 
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 16:10:39 -0000

On Thu, May 8, 2014 at 10:55 AM, Stephen Farrell
 wrote:
>> DNSSEC is a PKI after all.  If we need CT (certificate transparency)
>> for PKIX, why wouldn't we also need it for DNSSEC?
>
> We have a WG (trans [1]) that is chartered to do CT but
> also to consider whether there are further uses for that
> kind of log. I'd say that list might be better for this

I figured TRANS would be appropriate, but I thought I should check
here first just in case.

> discussion, but maybe check with the chair (Melinda, cc'd)
> to see if she'd prefer have that discussion now or after
> some more of the initial work is done.

OK.  Thanks,

Nico
--


From nobody Thu May  8 11:48:19 2014
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 9071E1A00B3 for ; Thu,  8 May 2014 11:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 OnK9eHThfC8D for ; Thu,  8 May 2014 11:48:16 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id D70CD1A0087 for ; Thu,  8 May 2014 11:48:15 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t61so2970960wes.34 for ; Thu, 08 May 2014 11:48:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uY7/8fsX1tfYRq+ZMWXE5LnuM7alZ8KGRpyfAnBPMGk=; b=MBvAjHjxm2sgaMbEhPnTPvIhJ6FsLG0SHSCMtUk5EpG83nTpQs2DC9VYewLgbw4yEw By4McfMc4O6oXQPedhxOovBDfCam+4Rl+rn0ltpgYc+r9DLT5IxCC0GnIfRQwHK48Wps nNpnmaQ5Ixoh+Ob7AMxJFK6DOT5iNr1oPfMYLUFX6Ic0vsopPzK4RaJaPTEViJgQ9b0P Iyyzz4Hd1zdqVTOEosxbD90OBVO9B6EZhwTG2RoHh3gNC1puuNfULACqiF0fDzTfb0Nh f/8bf6ytQNDBvPGV+2eQzlJ4MlByqz7iN4XqtvROkBQOVvMyN2Xi+XS/wtiza17JiLIt m+TQ==
X-Gm-Message-State: ALoCoQk/gFWhm5VW/7KQA/gJSmyzSMacncxow3B4O5ARBBYikk2YLgPFOHQs4JyUjgIUdEYrCldR
MIME-Version: 1.0
X-Received: by 10.180.221.8 with SMTP id qa8mr14144085wic.39.1399574890652; Thu, 08 May 2014 11:48:10 -0700 (PDT)
Received: by 10.194.62.70 with HTTP; Thu, 8 May 2014 11:48:10 -0700 (PDT)
Received: by 10.194.62.70 with HTTP; Thu, 8 May 2014 11:48:10 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 8 May 2014 14:48:10 -0400
Message-ID: 
From: Warren Kumari 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=001a1134c8be31ab2c04f8e7ecbc
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-NnFr6etGGrE5NsLDLgYdv3up3k
Cc: saag@ietf.org
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 18:48:17 -0000

--001a1134c8be31ab2c04f8e7ecbc
Content-Type: text/plain; charset=UTF-8

On May 8, 2014 11:42 AM, "Nico Williams"  wrote:
>
> I think so.
>
> DNSSEC is a PKI after all.  If we need CT (certificate transparency)
> for PKIX, why wouldn't we also need it for DNSSEC?
>
> I think the answer is that we will need CT for DNSSEC.
>

About to get on a plane, but I chatted with Ben Laurie about this a while
ago, and it is something on his radar...

W

> What would CT look like for DNSSEC?
>
> Nico
> --
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

--001a1134c8be31ab2c04f8e7ecbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On May 8, 2014 11:42 AM, "Nico Williams" <nico@cryptonector.com> wrote:

>

> I think so.

>

> DNSSEC is a PKI after all. =C2=A0If we need CT (certificate transparen=
cy)

> for PKIX, why wouldn't we also need it for DNSSEC?

>

> I think the answer is that we will need CT for DNSSEC.

>


About to get on a plane, but I chatted with Ben Laurie about=
 this a while ago, and it is something on his radar...


W


> What would CT look like for DNSSEC?

>

> Nico

> --

>

> _______________________________________________

> saag mailing list

> saag@ietf.org

> https://www.iet=
f.org/mailman/listinfo/saag




--001a1134c8be31ab2c04f8e7ecbc--


From nobody Thu May  8 12:37:02 2014
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 F03D01A0067 for ; Thu,  8 May 2014 12:36:58 -0700 (PDT)
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 Mv783Ltu8Gp4 for ; Thu,  8 May 2014 12:36:56 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D08651A00B5 for ; Thu,  8 May 2014 12:36:56 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id lf10so772241pab.34 for ; Thu, 08 May 2014 12:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=saCwlI9soQ5+6L0KG431zuusRo+U6SewdkWiRhg5O+I=; b=JZ4/FVM33HWoGL8TW4FTWNTZ9jF5FxzeK0HZK4un5oPLn3os24XJeUK9v8GH9oLHXd ganETDFBNWKsotQ6dMNeviUPvtF3lvXHejPdhsZH1tShJVRt4tEuf4vlo9B3A2GqTW2T 21EbZlVVJwyvqyWSqIcV90xr9LbtRE/mXZU7TdXAsfXSYW0IU77iVCxnZz8+aIuUbOY/ vDaFf2z3eZ/tGayKayX/13NvI6JyWwmGEMABs6vJvXZKHK9lGNDsnEuxJ9WO04umZFsD akl7r5l2d+ZU+kmz7k6zFtxpvss19hSeCfSR7IbhB31bu3G/iAtx4J+XpPL8KnQEjGAH h1Hg==
X-Received: by 10.67.13.226 with SMTP id fb2mr11218022pad.146.1399577812208; Thu, 08 May 2014 12:36:52 -0700 (PDT)
Received: from spandex.local (63-140-93-189.dynamic.dsl.acsalaska.net. [63.140.93.189]) by mx.google.com with ESMTPSA id io8sm3390762pbc.96.2014.05.08.12.36.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 12:36:51 -0700 (PDT)
Message-ID: <536BDCCF.1050109@gmail.com>
Date: Thu, 08 May 2014 11:36:47 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Stephen Farrell ,  Nico Williams , "saag@ietf.org" 
References:  <536BA8ED.4020209@cs.tcd.ie>
In-Reply-To: <536BA8ED.4020209@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XpvHdnYeUAXI8NjEypBGZ6GkxYM
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 19:36:59 -0000

On 5/8/14 7:55 AM, Stephen Farrell wrote:
> We have a WG (trans [1]) that is chartered to do CT but
> also to consider whether there are further uses for that
> kind of log. I'd say that list might be better for this
> discussion, but maybe check with the chair (Melinda, cc'd)
> to see if she'd prefer have that discussion now or after
> some more of the initial work is done.

Things are going smoothly and quietly enough that I think
it wouldn't be disruptive to start a discussion of new
CT applications, and we've actually talked briefly about
logging DNSSEC in another project I'm on, so sure, it'd
be fine to start a discussion on the trans mailing list.

Melinda


From nobody Thu May  8 13:04:39 2014
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 2F3191A0134 for ; Thu,  8 May 2014 13:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 PaTL7rr2LIDX for ; Thu,  8 May 2014 13:04:35 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF791A0131 for ; Thu,  8 May 2014 13:04:32 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id C5353674070 for ; Thu,  8 May 2014 13:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=b/NO0P6qlNGrVH8e2uo3 L/IxslA=; b=YFTcnRwnpIvq72WhD2nB/ORmsY/KA/6HXQc7j2n0/XXfmK3OvbfR WL36VzMqDd8XQQOUfDgrxtbera3G+8FqT8LooBzSt0PFGd3PApiv1SR0OMorJnV8 zag87nX8Rz3QCRHPUh7nDw2PQJzfJt8KpAme3mpqk8cyJx7HYnNbdEE=
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 71BAD67406A for ; Thu,  8 May 2014 13:04:27 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so2966457wev.5 for ; Thu, 08 May 2014 13:04:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.143.109 with SMTP id sd13mr70458wjb.95.1399579465585; Thu, 08 May 2014 13:04:25 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 8 May 2014 13:04:25 -0700 (PDT)
In-Reply-To: <536BDCCF.1050109@gmail.com>
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com>
Date: Thu, 8 May 2014 15:04:25 -0500
Message-ID: 
From: Nico Williams 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FHkpUMMy260226ZKomiIC4CxRA4
Cc: "saag@ietf.org" 
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Thu, 08 May 2014 20:04:36 -0000

On Thu, May 8, 2014 at 2:36 PM, Melinda Shore  wrote:
> Things are going smoothly and quietly enough that I think
> it wouldn't be disruptive to start a discussion of new
> CT applications, and we've actually talked briefly about
> logging DNSSEC in another project I'm on, so sure, it'd
> be fine to start a discussion on the trans mailing list.

Thanks.  I will!

While we're at it I suppose I should explain why I think we need this:

a) because DNSSEC is a PKI and so it follows that we should want CT
for it for the same reasons as for PKIs,

and

b) DANE bypasses PKI even when DANE is used with PKI, since DNSSEC
could be MITMed by a zone in the path to the target.

And I really like DANE.  For DANE to really take off I think we're
likely need CT!

Nico
--


From nobody Fri May  9 08:36:28 2014
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 2ECF71A0016 for ; Fri,  9 May 2014 08:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xotOUlIKrBnn for ; Fri,  9 May 2014 08:36:23 -0700 (PDT)
Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) by ietfa.amsl.com (Postfix) with ESMTP id D02AE1A0008 for ; Fri,  9 May 2014 08:36:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0AD50149E74; Fri,  9 May 2014 11:36:18 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8BC6B1486E7;  Fri,  9 May 2014 11:36:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson 
In-Reply-To: 
Date: Fri, 9 May 2014 11:36:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com>
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com> 
To: Nico Williams 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eGL_oZIwEoqPHLDEScGvNycKEhg
Cc: "saag@ietf.org" 
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Fri, 09 May 2014 15:36:25 -0000

On May 8, 2014, at 4:04 PM, Nico Williams  wrote:

> On Thu, May 8, 2014 at 2:36 PM, Melinda Shore =
 wrote:
>> Things are going smoothly and quietly enough that I think
>> it wouldn't be disruptive to start a discussion of new
>> CT applications, and we've actually talked briefly about
>> logging DNSSEC in another project I'm on, so sure, it'd
>> be fine to start a discussion on the trans mailing list.
>=20
> Thanks.  I will!
>=20
> While we're at it I suppose I should explain why I think we need this:
>=20
> a) because DNSSEC is a PKI and so it follows that we should want CT
> for it for the same reasons as for PKIs,
>=20
DNSSEC is not a PKI it is a method to protect the information in DNS.

DNSSEC validated data can be leveraged to act like a keying provider=20
as DANE or SSHFP are doing.=20

> and
>=20
> b) DANE bypasses PKI even when DANE is used with PKI, since DNSSEC
> could be MITMed by a zone in the path to the target.
>=20
> And I really like DANE.  For DANE to really take off I think we're
> likely need CT!


Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it =
is used
to provide Keying information  ?

	Olafur


From nobody Fri May  9 08:55:30 2014
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 1D2171A007A for ; Fri,  9 May 2014 08:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 uvoGh3bRWuoH for ; Fri,  9 May 2014 08:55:26 -0700 (PDT)
Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F32E61A0059 for ; Fri,  9 May 2014 08:55:25 -0700 (PDT)
Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 1BD812C806E for ; Fri,  9 May 2014 08:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZQcGeOz6MBhzDQgb2ofR mBfUNlg=; b=YaVrhaBtK9ko/rQ+UltIX3rTuM5GnvnVo71KJ/UqAO9eHLyWvh8i JFPMXb5XifvZiyGe1xj6ejhmzx1eYFXDcKq6GZYC/C4BxCtCDwq/NlnA49pZ8cc+ ZWLgRvLfENiETmGszDqNQKaQEuLSL4zjY6K1jTmXiHV229PI+EbsTrM=
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id C1A892C8056 for ; Fri,  9 May 2014 08:55:20 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hm4so1557910wib.5 for ; Fri, 09 May 2014 08:55:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.221.8 with SMTP id qa8mr3878901wic.39.1399650919418; Fri, 09 May 2014 08:55:19 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 08:55:19 -0700 (PDT)
In-Reply-To: <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com>
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com>  <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com>
Date: Fri, 9 May 2014 10:55:19 -0500
Message-ID: 
From: Nico Williams 
To: Olafur Gudmundsson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tNBWdg9NApqCCmLec1IQ_H906Hc
Cc: "saag@ietf.org" 
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Fri, 09 May 2014 15:55:27 -0000

On Fri, May 9, 2014 at 10:36 AM, Olafur Gudmundsson  wrote:
>
> On May 8, 2014, at 4:04 PM, Nico Williams  wrote:
>
>> On Thu, May 8, 2014 at 2:36 PM, Melinda Shore  wrote:
>>> Things are going smoothly and quietly enough that I think
>>> it wouldn't be disruptive to start a discussion of new
>>> CT applications, and we've actually talked briefly about
>>> logging DNSSEC in another project I'm on, so sure, it'd
>>> be fine to start a discussion on the trans mailing list.
>>
>> Thanks.  I will!
>>
>> While we're at it I suppose I should explain why I think we need this:
>>
>> a) because DNSSEC is a PKI and so it follows that we should want CT
>> for it for the same reasons as for PKIs,
>>
> DNSSEC is not a PKI it is a method to protect the information in DNS.

It's a hierarchical public key distribution mechanism: it distributes
zone public signing keys and so on.  It most certainly is a PKI.  It
only isn't PKI in the sense of using certificates and certification
authorities and other PKIX things.

I don't really care for an argument about whether we should call
DNSSEC a PKI though.  I care about arguments as to whether or not we
need CT for it, and if we agree that we need it, how to go about
getting it.

> DNSSEC validated data can be leveraged to act like a keying provider
> as DANE or SSHFP are doing.

Sure, but even without those it distributes zone public keys.  DANE
and such are trivial/minor (and long-envisioned) uses of DNSSEC.

>> and
>>
>> b) DANE bypasses PKI even when DANE is used with PKI, since DNSSEC
>> could be MITMed by a zone in the path to the target.
>>
>> And I really like DANE.  For DANE to really take off I think we're
>> likely need CT!
>
> Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it is used
> to provide Keying information  ?

The former.  The point of CT is to keep CAs (PKIX) / delegation
signers (DNSSEC) honest, so they don't MITM users.

CT becomes more important when end-points' public keys are distributed
via DNSSEC, a-la DANE, but it was always going to be necessary.

Nico
--


From nobody Fri May  9 09:15:41 2014
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 DC3CB1A002F for ; Fri,  9 May 2014 09:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UnGDKCi7Z3bM for ; Fri,  9 May 2014 09:15:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 711541A001A for ; Fri,  9 May 2014 09:15:38 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 35CEA2AB0B1; Fri,  9 May 2014 16:15:31 +0000 (UTC)
Date: Fri, 9 May 2014 16:15:31 +0000
From: Viktor Dukhovni 
To: saag@ietf.org
Message-ID: <20140509161530.GI27883@mournblade.imrryr.org>
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com>  <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JHAkgjy5P45tnjAdJbsVc4ISwgc
Subject: Re: [saag] Will DNSSEC need something like CT?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 May 2014 16:15:40 -0000

On Fri, May 09, 2014 at 11:36:13AM -0400, Olafur Gudmundsson wrote:

> > And I really like DANE.  For DANE to really take off I think we're
> > likely need CT!

I think that for DANE to take off we need DNSSEC deployment, thus
ongoing user-interface improvements in tools to manage and register
DNSSEC zones, plus progress on DNSSEC last-mile issues.  Lack of
CT is far from a significant barrier to DANE adoption.  The barriers
are:

    * DNSSEC last mile issues
    * DNSSEC is not widely adopted
    * Security toolkits lack DANE verification code.

So far, we only have a few initial implementations:

    * SSHFP RRs.
    * DANE TLSA for SMTP (so far just Postfix, draft basically done)
    * DANE TLSA for XMPP (so far implementations only support DANE-EE(3)
      and opportunistic security model not spelled out in draft).

> Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it
> is used to provide Keying information  ?

It is not clear to me whether, how or when CT might work for DNSSEC.
What is clear, is that waiting for DNSSEC CT is not a sound reason
to delay DANE implementation.

-- 
	Viktor.


From nobody Fri May  9 09:22:29 2014
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 B2CF31A005F for ; Fri,  9 May 2014 09:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 icJx4oJOrayw for ; Fri,  9 May 2014 09:22:26 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 612141A0043 for ; Fri,  9 May 2014 09:22:26 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 9CD8D200B9990 for ; Fri,  9 May 2014 09:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=hl0tI9A8Cpy69/OkLdA5vwT peKw=; b=Ea8i9LNrNlEhJgQIW0b9tyTevmq+o4CWV2o6t4aZZ/tFhnnv8AJR6L+ YeB+SRVFb79r1aXVFCTAeLKSuMxM92R9mjWyKiXOqCYNYirfcQcZ8SO4DNduIlQ+ Pc+FWq5oJT149WW+XuKJVCzs6irNiFbyvsWoL0fWMN6zE6wbBnrc=
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 45EAA200B998F for ; Fri,  9 May 2014 09:22:21 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so4116808wgg.0 for ; Fri, 09 May 2014 09:22:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.120.68 with SMTP id la4mr9166226wjb.40.1399652540021; Fri, 09 May 2014 09:22:20 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 09:22:19 -0700 (PDT)
In-Reply-To: <20140509161530.GI27883@mournblade.imrryr.org>
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com>  <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com> <20140509161530.GI27883@mournblade.imrryr.org>
Date: Fri, 9 May 2014 11:22:19 -0500
Message-ID: 
From: Nico Williams 
To: "saag@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Zn3BFwms7SlebHfpuqWsLH_1yFM
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Fri, 09 May 2014 16:22:27 -0000

On Fri, May 9, 2014 at 11:15 AM, Viktor Dukhovni
 wrote:
> On Fri, May 09, 2014 at 11:36:13AM -0400, Olafur Gudmundsson wrote:
>
>> > And I really like DANE.  For DANE to really take off I think we're
>> > likely need CT!
>
> I think that for DANE to take off we need DNSSEC deployment, thus
> [...]

Eh, that was true of PKI too.

>> Questions: Do you need DNSSEC-CT for all uses of DNSSEC or only when it
>> is used to provide Keying information  ?
>
> It is not clear to me whether, how or when CT might work for DNSSEC.
> What is clear, is that waiting for DNSSEC CT is not a sound reason
> to delay DANE implementation.

Agreed, but note that no one said or implied that adoption/deployment
of DANE and such should be delayed until we have DNSSEC CT!

Nico
--


From nobody Fri May  9 11:12:13 2014
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 DBF091A032D for ; Fri,  9 May 2014 11:12:12 -0700 (PDT)
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 SCaQ7abQ1OOU for ; Fri,  9 May 2014 11:12:11 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8E01A032E for ; Fri,  9 May 2014 11:12:11 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id y10so3969865pdj.39 for ; Fri, 09 May 2014 11:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BV+EgvEQ5k+SiZURxRLeU3MhdKUsXBTJ93B40kc+BTo=; b=u16Ou266WNhYa6ThElt60kn3HRrBdJ9zPX5E7LnEKX3da3K9pnHrH0McKGADShwya9 Qxi9q56eeQ3XUjzlhWP3eDpJ86qv6plTBeCeewcFS1GPG7BCSQAqokbjQxe3q9sl3wxI /nG1jDVw7AgNEfRHZi+6twCNLx/wSuV5p80pZATOjEUpuurL2J+B0VUCbWG/DdDN12pD 0W+3ZACwUqFfLFUsaL4qjvjZvg2/cgH+0fz3HDWG6dn9oU98VjWHypu8E1f+vfcBTFac bbGmcETI+khAw0FcOwVmbwPc4Es+m7M20PSlhQ2vxKQEcGrng5ZLb6LuOSE4bQ4ciO9M 2pDQ==
X-Received: by 10.66.184.239 with SMTP id ex15mr23115412pac.122.1399659126430;  Fri, 09 May 2014 11:12:06 -0700 (PDT)
Received: from spandex.local (63-140-99-143.dynamic.dsl.acsalaska.net. [63.140.99.143]) by mx.google.com with ESMTPSA id bc4sm8784267pbb.2.2014.05.09.11.12.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 11:12:05 -0700 (PDT)
Message-ID: <536D1A74.8050209@gmail.com>
Date: Fri, 09 May 2014 10:12:04 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: saag@ietf.org
References:  <536BA8ED.4020209@cs.tcd.ie> <536BDCCF.1050109@gmail.com>  <253566F7-4B6D-44F8-AAB7-1E4ACF0E4AA7@ogud.com> <20140509161530.GI27883@mournblade.imrryr.org>
In-Reply-To: <20140509161530.GI27883@mournblade.imrryr.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-j0H9sme4gsK0RqsV0uCgFomLY8
Subject: Re: [saag] Will DNSSEC need something like CT?
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: Fri, 09 May 2014 18:12:13 -0000

On 5/9/14 8:15 AM, Viktor Dukhovni wrote:
> I think that for DANE to take off we need DNSSEC deployment, thus
> ongoing user-interface improvements in tools to manage and register
> DNSSEC zones, plus progress on DNSSEC last-mile issues.  Lack of
> CT is far from a significant barrier to DANE adoption.  

I don't think it's any barrier to DANE adoption - we've had
nearly ubiquitous adoption of TLS without CT.  And at the risk
of shooting off my own foot, CT is not the only approach to
addressing problems around certificate misissuance.

You've touched on one of the issues around DNSSEC (non-)
deployment, which is the lack of validators.  We're hoping to
ease that process with getdns (http://getdnsapi.net).  I'm
in the process of reworking the Python bindings but even in
their current state retrieving a TLSA record, pulling out the
certificate, and doing something with it is just a few lines
of code.  At a hack battle at TNW Europe a couple of weeks
ago one of the teams put up http://dnssec-name-and-shame.com/
using the getdns Node.js bindings.

At any rate, bring the DNSSEC and DANE discussions over to the
trans mailing list and let's see whether or not there's interest
and energy to move the work along.

Melinda



From nobody Wed May 14 03:32:45 2014
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 B2D0F1A0025 for ; Wed, 14 May 2014 03:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 732NlfYZJRLK for ; Wed, 14 May 2014 03:32:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 235381A0015 for ; Wed, 14 May 2014 03:32:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC4C3BE6E for ; Wed, 14 May 2014 11:32:34 +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 N5j5YhBNTUB3 for ; Wed, 14 May 2014 11:32:34 +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 B31FABEA1 for ; Wed, 14 May 2014 11:32:34 +0100 (IST)
Message-ID: <53734643.4010303@cs.tcd.ie>
Date: Wed, 14 May 2014 11:32:35 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "saag@ietf.org" 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
X-Forwarded-Message-Id: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ORTJeoNwKONApNC4wjFRLG9eESSOEVQdV"
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_vPAHHCsMi4R0hb-dR8-xFRuPvM
Subject: [saag] Fwd: [Cfrg] Looking for two new CFRG co-chairs
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, 14 May 2014 10:32:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ORTJeoNwKONApNC4wjFRLG9eESSOEVQdV
Content-Type: multipart/mixed;
 boundary="------------000405090405090707080909"

This is a multi-part message in MIME format.
--------------000405090405090707080909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


FYI, if you know of someone who'd be good, please a) tell
Lars and b) hassle that person:-) And yes, you can be that
person as well - there's need for IETF clue as well as
pure crypto-clue.

Cheers,
S.


-------- Original Message --------
Subject: [Cfrg] Looking for two new CFRG co-chairs
Date: Wed, 14 May 2014 06:58:17 +0000
From: Eggert, Lars 
Reply-To: irtf-chair@irtf.org 
To: cfrg@irtf.org 

Hi CFRG,

David McGrew has informed me that he needs to step down as co-chair of
CFRG soon, because other responsibilities no longer allow him the time
that to do a good job in that function. The CFRG's other current
co-chair, Kevin Igoe, is retiring in 2015 and will then also step down.

First, I'd like to sincerely thank David for all the hard work he put
into running the group for the last few years!

Second, we've decided to look for two new co-chairs at this time, and
have the CFRG run with three chairs until Kevin retires in 2015. This is
to ensure a smooth handover at a time where the group is busy with
critical work.

The new chair team should have deep crypto experience, sufficient time
to manage the work of the group, some familiarity with the IETF, and the
ability to travel to (and host) the physical meetings of the group. Note
that it's not required that each individual chair fulfill all of these
criteria; but the team should as a whole. (For example, it's probably
sufficient if one chair has some IETF experience, etc.)

If you are interested in being considered as a co-chair, please send me
a quick email off-list. If you believe that some other community member
may be a good chair, please convince them to put their name forward, too.=


Lars Eggert
IRTF Chair




--------------000405090405090707080909
Content-Type: text/plain; charset=UTF-8;
 name="Attached Message Part"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="Attached Message Part"

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg


--------------000405090405090707080909--

--ORTJeoNwKONApNC4wjFRLG9eESSOEVQdV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTc0ZDAAoJEC88hzaAX42iLy8IALGulZgqTc39TPyecWSaq1Dn
0hpGpD/w5ybG8ON1rfrFKfyP8kOQmMOykUPPvaQonPGxUQyDyOQQ0EGXCk5dJ44U
UMKIcOlo6T7S3adPd3TV8FoMcF81Nndzw785XsWJdA+5VSBp5cwNOmVNuPJacuHL
yLikkpvUntzQX2O42keXj0cKFOeQNIO/d5uunzne5XOjJmznczgQXSjYXi3lPt2X
2/QDCzZul9OGn0q72Cqa46+s0E8T0XxT44OMMKbPPWNXftaz94L+YhJl9y1ztLDj
L33i+Vsmpl2u+bnlGUJevaBLD7vRmGITwKSBdlZVPXks8rUCCp53Wcyg34CkNdI=
=LlYN
-----END PGP SIGNATURE-----

--ORTJeoNwKONApNC4wjFRLG9eESSOEVQdV--


From nobody Wed May 14 05:53:27 2014
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 4F37B1A0090 for ; Wed, 14 May 2014 05:53:25 -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 49khWF_GoJMD for ; Wed, 14 May 2014 05:53:23 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AA1FC1A007B for ; Wed, 14 May 2014 05:53:22 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id ec20so1378323lab.19 for ; Wed, 14 May 2014 05:53:15 -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 :cc:content-type; bh=kypPWHiJWvdxPa4+douDh8cE49NURZ0aQIeaqyChYXc=; b=bE6b8UCbETc7ladV/K6l08hXIm/2hT5/BfR/CwhYfwmC2zrQDvquMhBb9P750nqUeU EvU705GbK/e1AQHf/pcsslw5hVam1ayAMiFXzvf9oLi1yEiTfrxbyK5VOKNoWvTE8s3w Iak4MsYtJZnm5ze0O9VGGkbb+3vOFptFbjezhBXRX/r5oXuKI3P2xbNo69PxEMm0oK0g 7FOJ2WfyycW0sZ0eZ1RcHVxEsRu6GIMBMn1vcFSNiJ2c7h3XHi14zP0LvvBxTNQHUkY9 GdjtObP+zHOQJj0xSJUnZfuZvU+Bryv3pav3CS2gNderN87UA8k1V8BU3NWT9f6xqCWF uDMA==
MIME-Version: 1.0
X-Received: by 10.112.76.66 with SMTP id i2mr2406694lbw.37.1400071995387; Wed, 14 May 2014 05:53:15 -0700 (PDT)
Received: by 10.114.12.234 with HTTP; Wed, 14 May 2014 05:53:15 -0700 (PDT)
In-Reply-To: 
References:  <20140504162843.GP27883@mournblade.imrryr.org>   <20140505183155.GT27883@mournblade.imrryr.org>   <98cf4fcf5dd66587207642309c2c84ee.squirrel@www.trepanning.net> 
Date: Wed, 14 May 2014 08:53:15 -0400
Message-ID: 
From: Rifaat Shekh-Yusef 
To: Dan Harkins 
Content-Type: multipart/alternative; boundary=14dae9cfcabcf1f6ad04f95ba9bb
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rGokyprxYLwiBRmaSeHtg0hFMGc
Cc: "saag@ietf.org" 
Subject: Re: [saag] Key-Derivation Scheme
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, 14 May 2014 12:53:25 -0000

--14dae9cfcabcf1f6ad04f95ba9bb
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I sent two emails to the CFRG mailing list to continue this discussion.

The first email to discuss the idea of PAKE-based solution:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04523.html

The second email to continue the Key-Derivation Scheme idea using the
Scrypt function and performing mutual authentication:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04536.html

I would appreciate any comments on these emails on the CFRG mailing list.

Regards,
 Rifaat



On Tue, May 6, 2014 at 4:32 PM, Rifaat Shekh-Yusef wrote:

> Hi Dan,
>
> The NIST document talks about the latter part of the quote (the increase
> of computation).
>
> I guess that the result would depend on the number of iterations selected
> by the server.
> If the solution can tolerate some delay in the initial communication
> between the client and the sever, then the server can select an iteration
> number that would practically prevent a dictionary attack.
>
> I agree with you that PAKE-based solution would be better, but these
> solutions will either require some changes to the challenge-response
> framework, or will not fit into the challenge-response framework.
> I am looking at J-PAKE; will see if that fits into the challenge-response
> framework.
>
> Regards,
>  Rifaat
>
>
>
> On Tue, May 6, 2014 at 1:34 PM, Dan Harkins  wrote:
>
>>
>>
>> On Mon, May 5, 2014 1:30 pm, Rifaat Shekh-Yusef wrote:
>> > Hi Nico,
>> >
>> > Thanks for you comments.
>> > As I mentioned in a previous email, "The draft is *not* introducing any
>> > new
>> > crypto algorithms.", so I agree with you that there is no novel
>> > cryptography here.
>> > I will take a look at the SCRAM document.
>> >
>> > I will also take a look at scrypt.
>> > I have looked at J-PAKE as a possible protocol that could fit into a
>> > challenge-response framework.
>>
>>   The NIST document says:
>>
>>     "The scheme ensures that the password and the master-key are
>>       never sent on the wire, and allows for a better secure storage of
>>       passwords as it significantly increases the amount of computation
>>       needed to derive a key from a password in a dictionary attack."
>>
>> So it merely increases the amount of computation needed to perform
>> a dictionary attack, it does not prevent a dictionary attack. It's much
>> better to actually prevent  a dictionary attack and any PAKE protocol
>> would do that for you.
>>
>>   Dan.
>>
>>
>>
>

--14dae9cfcabcf1f6ad04f95ba9bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,

I sent two emails to the CFRG maili=
ng list to continue this discussion.

The first ema=
il to discuss the idea of PAKE-based solution:

The second email to continue the Key-Derivation S=
cheme idea using the Scrypt function and performing mutual authentication:<=
/div>






On Tue, May 6, 2014 at 4:32 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.=
com> wrote:


Hi Dan,

The NIST document talks about t=
he latter part of the quote (the increase of computation).
I guess that the result would depend on the number of iteratio=
ns selected by the server.=A0



If the solution can tolerate some delay in the initial communication b=
etween the client and the sever, then the server can select an iteration nu=
mber that would practically prevent a dictionary attack.




I agree with you that PAKE-based solution would be better, but t=
hese solutions will either require some changes to the challenge-response f=
ramework, or will not fit into the challenge-response framework.



I am looking at J-PAKE; will see if that fits into the challenge-response f=
ramework.

Regards,
=A0Rifaat





On Tue, May 6, 2014 at 1:34 PM, Dan Harkins <dharkins@lounge.org&g=
t; wrote:







On Mon, May 5, 2014 1:30 pm, Rifaat Shekh-Yusef wrote:

> Hi Nico,

>

> Thanks for you comments.


> As I mentioned in a previous email, "The draft is *not* int=
roducing any


> new

> crypto algorithms.", so I agree with you that there is no novel
> cryptography here.

> I will take a look at the SCRAM document.

>

> I will also take a look at scrypt.

> I have looked at J-PAKE as a possible protocol that could fit into a
> challenge-response framework.




=A0 The NIST document says:



=A0 =A0 "The scheme ensures that the password and the master-key are
=A0 =A0 =A0 never sent on the wire, and allows for a better secure storage =
of

=A0 =A0 =A0 passwords as it significantly increases the amount of computati=
on

=A0 =A0 =A0 needed to derive a key from a password in a dictionary attack.&=
quot;




So it merely increases the amount of computation needed to perform
a dictionary attack, it does not prevent a dictionary attack. It's much=


better to actually prevent =A0a dictionary attack and any PAKE protocol

would do that for you.



=A0 Dan.












--14dae9cfcabcf1f6ad04f95ba9bb--


From nobody Wed May 21 06:19:56 2014
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 9CDDD1A0675 for ; Wed, 21 May 2014 06:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level: 
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] 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 TByUIDJObFp6 for ; Wed, 21 May 2014 06:19:50 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A02161A0687 for ; Wed, 21 May 2014 06:19:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F928BE80 for ; Wed, 21 May 2014 14:19: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 32BLZ3JU+X-h for ; Wed, 21 May 2014 14:19:45 +0100 (IST)
Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D209CBE76 for ; Wed, 21 May 2014 14:19:45 +0100 (IST)
Message-ID: <537CA7F1.4030002@cs.tcd.ie>
Date: Wed, 21 May 2014 14:19:45 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "saag@ietf.org" 
References:  <53734643.4010303@cs.tcd.ie>
In-Reply-To: <53734643.4010303@cs.tcd.ie>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LNMsKDc0bbh8MZd3zNDB3d84BJU
Subject: Re: [saag] Fwd: [Cfrg] Looking for two new CFRG co-chairs
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, 21 May 2014 13:19:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


An update: Lars has some fine crypto-type candidates who've
offered, which is great. He could do with a couple more
options for folks with IETF-clue and maybe who'd be willing
and able to handle meetings etc. So please send Lars a mail
if you'd be willing to help out. Obviously the more crypto
clue you have the better, but good IETF/security clue (and
cycles) could well be good enough. (And you'd learn some
more crypto as you go inevitably;-)

Thanks,
S.

On 14/05/14 11:32, Stephen Farrell wrote:
> 
> FYI, if you know of someone who'd be good, please a) tell Lars and
> b) hassle that person:-) And yes, you can be that person as well -
> there's need for IETF clue as well as pure crypto-clue.
> 
> Cheers, S.
> 
> 
> -------- Original Message -------- Subject: [Cfrg] Looking for two
> new CFRG co-chairs Date: Wed, 14 May 2014 06:58:17 +0000 From:
> Eggert, Lars  Reply-To: irtf-chair@irtf.org
>  To: cfrg@irtf.org 
> 
> Hi CFRG,
> 
> David McGrew has informed me that he needs to step down as co-chair
> of CFRG soon, because other responsibilities no longer allow him
> the time that to do a good job in that function. The CFRG's other
> current co-chair, Kevin Igoe, is retiring in 2015 and will then
> also step down.
> 
> First, I'd like to sincerely thank David for all the hard work he
> put into running the group for the last few years!
> 
> Second, we've decided to look for two new co-chairs at this time,
> and have the CFRG run with three chairs until Kevin retires in
> 2015. This is to ensure a smooth handover at a time where the group
> is busy with critical work.
> 
> The new chair team should have deep crypto experience, sufficient
> time to manage the work of the group, some familiarity with the
> IETF, and the ability to travel to (and host) the physical meetings
> of the group. Note that it's not required that each individual
> chair fulfill all of these criteria; but the team should as a
> whole. (For example, it's probably sufficient if one chair has some
> IETF experience, etc.)
> 
> If you are interested in being considered as a co-chair, please
> send me a quick email off-list. If you believe that some other
> community member may be a good chair, please convince them to put
> their name forward, too.
> 
> Lars Eggert IRTF Chair
> 
> 
> 
> 
> 
> _______________________________________________ saag mailing list 
> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTfKfxAAoJEC88hzaAX42iaV8IAK/LJSYiIO4u0xHju4qmwLr9
OXv7ufl2foWu2WmgGpUS+7gncRkRsihpfx4mnkaG66keTDp+wMFQ6tdWDWy2L7sg
8tCoc/u8Aq0/UgDUAP3stS+ugzkgGC4ZQKyf0vHV5Mt4umxJSvHQtClGoE4Tidkc
oymUg5zvfT2FlGUyrlHMwd9kaOvSziEU3tnjf6yWjogLdUp9tiXcvPALhrqu/7f0
yOA/DzV8Ad7dhyvOqHZNhTqM6Q04x31gqp31Net54DLqEePm/FF1JK56KLNH0F4E
ku6eKLKMYirgVqB9fozPW1Md7XbRdmhaAH7Dwnd9a4wdDHhmCxF38daxu3VpXt0=
=2gJr
-----END PGP SIGNATURE-----


From nobody Fri May 23 07:07:49 2014
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 131591A0198 for ; Fri, 23 May 2014 07:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 gr6A_MYspXEu for ; Fri, 23 May 2014 07:07:43 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533D81A0091 for ; Fri, 23 May 2014 07:07:43 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s4NE7cCe006795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 23 May 2014 07:07:41 -0700
Message-ID: <537F560C.4020900@dcrocker.net>
Date: Fri, 23 May 2014 07:07:08 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "saag@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 23 May 2014 07:07:41 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xWOLIDjVzTMKiegEw_Ix83ZX5Kk
Subject: [saag] Alternative terminology to "certificate" or "credential"?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 May 2014 14:07:47 -0000

Hi.

I'm looking for a term that refers to a package associating a key with
"other attributes" but which does not imply the usual Certificate
Authority trust model.

Rather, packaging things together is separate from statements of trust
about the package supplier or the contents of the package.

The bare word "certificate" might be theoretically reasonable, but
established usage means people will typically assume it invokes the
usual CA model.

The only candidate term I've come across is 'credential', but my own
impression matches that of Wikipedia:

   http://en.wikipedia.org/wiki/Digital_credential

   "Because of the still evolving, and sometimes conflicting,
   terminologies used in the fields of computer science, computer
   security, and cryptography, the term "digital credential" is used
   quite confusingly in these fields"


Any suggestions?

Thanks.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri May 23 07:16:32 2014
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 9A2AF1A01B6 for ; Fri, 23 May 2014 07:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 PczmchgA3uTo for ; Fri, 23 May 2014 07:16:28 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF01A0147 for ; Fri, 23 May 2014 07:16:28 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 51D061656FB; Fri, 23 May 2014 14:16:26 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 46B581656F3; Fri, 23 May 2014 14:16:26 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2CA8B98065; Fri, 23 May 2014 14:16:26 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 23 May 2014 10:16:25 -0400
From: "Salz, Rich" 
To: "dcrocker@bbiw.net" , "saag@ietf.org" 
Date: Fri, 23 May 2014 10:16:24 -0400
Thread-Topic: [saag] Alternative terminology to "certificate" or "credential"?
Thread-Index: Ac92kGSAlaV67rv8QEaiOF1Z9nIqlAAASA8Q
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35657@USMBX1.msg.corp.akamai.com>
References: <537F560C.4020900@dcrocker.net>
In-Reply-To: <537F560C.4020900@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UNVignYjedkhruX4PzTd4WYm0WM
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 14:16:29 -0000

> I'm looking for a term that refers to a package associating a key with "o=
ther attributes" but which does not imply the usual Certificate Authority t=
rust model.

SAML uses the term "assertions," which seems a good fit.

	/r$

-- =20
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz


From nobody Fri May 23 07:18:20 2014
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 8356A1A059F for ; Fri, 23 May 2014 07:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 blSVLj7f12r5 for ; Fri, 23 May 2014 07:18:18 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id DD5DF1A0147 for ; Fri, 23 May 2014 07:18:17 -0700 (PDT)
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 23 May 2014 07:17:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.98,893,1392192000"; d="scan'208";a="516654551"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga001.jf.intel.com with ESMTP; 23 May 2014 07:17:55 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 23 May 2014 07:17:55 -0700
Received: from fmsmsx106.amr.corp.intel.com ([169.254.6.137]) by FMSMSX101.amr.corp.intel.com ([169.254.1.134]) with mapi id 14.03.0123.003; Fri, 23 May 2014 07:17:55 -0700
From: "Walker, Jesse" 
To: "dcrocker@bbiw.net" , "saag@ietf.org" 
Thread-Topic: [saag] Alternative terminology to "certificate" or "credential"?
Thread-Index: AQHPdpBms0BxqNTPIEeJzxHLdEPguptONkgA
Date: Fri, 23 May 2014 14:17:54 +0000
Message-ID: 
References: <537F560C.4020900@dcrocker.net>
In-Reply-To: <537F560C.4020900@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.200.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_zH-siSrdD3ldsL3_lM2E0kfqH8
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 14:18:19 -0000

A word we use in the industry for this function is "manifest". A manifest i=
s a signed collection of attributes, one usually being the hash of the data=
 to which the manifest refers (often an executable image).

> -----Original Message-----
> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Dave Crocker
> Sent: Friday, May 23, 2014 7:07 AM
> To: saag@ietf.org
> Subject: [saag] Alternative terminology to "certificate" or "credential"?
>=20
>=20
> Hi.
>=20
> I'm looking for a term that refers to a package associating a key with "o=
ther
> attributes" but which does not imply the usual Certificate Authority trus=
t model.
>=20
> Rather, packaging things together is separate from statements of trust ab=
out
> the package supplier or the contents of the package.
>=20
> The bare word "certificate" might be theoretically reasonable, but establ=
ished
> usage means people will typically assume it invokes the usual CA model.
>=20
> The only candidate term I've come across is 'credential', but my own
> impression matches that of Wikipedia:
>=20
>    http://en.wikipedia.org/wiki/Digital_credential
>=20
>    "Because of the still evolving, and sometimes conflicting,
>    terminologies used in the fields of computer science, computer
>    security, and cryptography, the term "digital credential" is used
>    quite confusingly in these fields"
>=20
>=20
> Any suggestions?
>=20
> Thanks.
>=20
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>=20
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


From nobody Fri May 23 08:49:44 2014
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 0F2421A0689 for ; Fri, 23 May 2014 08:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 cZccxC8oUh2x for ; Fri, 23 May 2014 08:49:35 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0C111A0692 for ; Fri, 23 May 2014 08:49:32 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 60F2A2007D805 for ; Fri, 23 May 2014 08:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rlXPRAFyFz87Ssqf5spS iNjQ5gg=; b=w8LNTzbChn/GAJ7Wmyyuc7BMZ537tMasIs0TcL5srOEgeUgs47du DWd/nL+c4TxWl51PxLi+hCC3ZLQ0n14LIg2oHht3X3JgLbYiEdleQTainZ5sHTIE VSBuOUcwRrjWGH96C/XyRlwTmfg8jpIrd3adLXAM4+CQ6vOksisvoiM=
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 0A7F52007D802 for ; Fri, 23 May 2014 08:49:30 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so5186774wes.1 for ; Fri, 23 May 2014 08:49:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.77.225 with SMTP id v1mr4051618wiw.5.1400860169677; Fri, 23 May 2014 08:49:29 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 23 May 2014 08:49:29 -0700 (PDT)
In-Reply-To: <537F560C.4020900@dcrocker.net>
References: <537F560C.4020900@dcrocker.net>
Date: Fri, 23 May 2014 10:49:29 -0500
Message-ID: 
From: Nico Williams 
To: Dave Crocker 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MXFpE6NR956BFDWspbPOnAcehcw
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 15:49:36 -0000

On Fri, May 23, 2014 at 9:07 AM, Dave Crocker  wrote:
> The only candidate term I've come across is 'credential', but my own
> impression matches that of Wikipedia:

Credential is what we use in the GSS-API.  It's the most generic term
we have for "something that can be used to authenticate to another
party".

All the other terms in use for this are mechanism-specific:

 - certificate -> PKIX (and others, like Persona)
 - ticket -> Kerberos (and others, like TLS resumption)
 - assertion -> SAML
...

The main downside of "credential" is that for many people it means
"password" or "something to use to get a {certificate, ticket,
assertion, ...} with".

But I don't think that looking yet another new term is the right way
forward: that's how we end up with glossaries bloated with near
synonyms.  New terminology where existing one will do... just creates
a barrier to entry, and had better be strongly justified (e.g., it
really solves a problem).

Nico
--


From nobody Fri May 23 08:49:47 2014
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 4A68B1A068E for ; Fri, 23 May 2014 08:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 4YskPrbo1REU for ; Fri, 23 May 2014 08:49:44 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4F1A0689 for ; Fri, 23 May 2014 08:49:43 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id F331B67C072 for ; Fri, 23 May 2014 08:49:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TFxEQjWTlZP/x/Oz27m9 AKLOYDg=; b=vy0DGcH53uBWdr92cYnjF+ZVMNf8ol05wSbUT8KMWHBiZF6YsFSj b5uYKLpMatzH6O8lQPC6k/U+9ytBH3QibcoApGeNeX6o6UEz65jpnjMfJNdME56A wM5LcoOzBAAElCicpB2yjfj3bxDvB2QG6LgTyzOF2WQzQ01v1WMsPiw=
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A0E2B67C057 for ; Fri, 23 May 2014 08:49:41 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id x12so4900040wgg.18 for ; Fri, 23 May 2014 08:49:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.12.135 with SMTP id y7mr4042028wib.39.1400860180457; Fri, 23 May 2014 08:49:40 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 23 May 2014 08:49:40 -0700 (PDT)
In-Reply-To: 
References: <537F560C.4020900@dcrocker.net> 
Date: Fri, 23 May 2014 10:49:40 -0500
Message-ID: 
From: Nico Williams 
To: "Walker, Jesse" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GjNRM4gCDGobNpTqRcUqj0JE2Bc
Cc: "dcrocker@bbiw.net" , "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 15:49:45 -0000

On Fri, May 23, 2014 at 9:17 AM, Walker, Jesse  wrote:
> A word we use in the industry for this function is "manifest". A manifest is a signed collection of attributes, one usually being the hash of the data to which the manifest refers (often an executable image).

I've never heard that used in a context where "credential" would also
have worked.  I don't think it generalizes as well as "credential"
either (e.g., calling a Kerberos ticket a "manifest" just does not
seem to me to fit).

Nico
--


From nobody Fri May 23 09:02:45 2014
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 0C9FA1A00C6 for ; Fri, 23 May 2014 09:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LTI-CoibFzKL for ; Fri, 23 May 2014 09:02:42 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276871A0039 for ; Fri, 23 May 2014 09:02:42 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s4NG2atb009414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 09:02:40 -0700
Message-ID: <537F70FE.6080701@dcrocker.net>
Date: Fri, 23 May 2014 09:02:06 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Nico Williams 
References: <537F560C.4020900@dcrocker.net> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 23 May 2014 09:02:40 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TXagBL2ydBrspMCHygE1SPNTyQs
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 May 2014 16:02:43 -0000

On 5/23/2014 8:49 AM, Nico Williams wrote:
> On Fri, May 23, 2014 at 9:07 AM, Dave Crocker  wrote:
> The main downside of "credential" is that for many people it means
> "password" or "something to use to get a {certificate, ticket,
> assertion, ...} with".

The history of ambiguity for 'credential' seems pretty serious to me.
It's difficult -- actually, I believe impossible -- to get everyone to
adapt, once there's a long, problematic history.

So I'm looking for a term that is not tied to any existing services.  It
might apply to some, but would stand separate from them.

The world is possibly considering different models than what is
currently entrenched and I'd like to have a term that isn't tied to any
existing (and poorly adopted) mode.


> 
> But I don't think that looking yet another new term is the right way
> forward: that's how we end up with glossaries bloated with near
> synonyms. 

Having no precise term for a distinctive use case makes it unlikely
people will properly attend to that case.

I have only just started using PGP.  I note that Thunderbird's module
asks me to rate the level of trust I have in the key.  I think this
matches the idea of a "level of assurance" step that is decoupled from
the semantics of the key-containing package -- where the latter is what
I'm looking for a label to describe.

This de-coupling of actual trust assessment from the packaging and
delivery mechanism for the key is exactly what I want to emphasize.

It's not that the package carries no implied trust.  It's that the trust
isn't institutionalized in the definition of the package, and that the
real trust assessment is an independent process.

My immediate reaction is that 'assertion' might work well, although
'manifest' sounds interesting...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Fri May 23 09:05:45 2014
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 E6DE01A0673 for ; Fri, 23 May 2014 09:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 35rCjCHdRtq3 for ; Fri, 23 May 2014 09:05:43 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0771A06B3 for ; Fri, 23 May 2014 09:05:43 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id D58B394075 for ; Fri, 23 May 2014 09:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=cdrO03lPMn7QfHUpjmeS ymtrues=; b=g9Oxvgw6jCUNc6kknD6PlQeUmEoit81m4Zq8aTgOrEH0JVXl4jKV rziKepq+1GpQKEfavWWKYpz0zuWBojVE9Hl/fa/gTj+1EBbR78aNLGjaxekDRrCK n9N2S2dVkxz0xmPf52BjYZ1e/elLQ4jsrXlFyMTf6ZccK9yqx2PEevg=
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 6AE2594076 for ; Fri, 23 May 2014 09:05:41 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f8so1129365wiw.4 for ; Fri, 23 May 2014 09:05:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.93.202 with SMTP id cw10mr2532218wjb.95.1400861140367; Fri, 23 May 2014 09:05:40 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 23 May 2014 09:05:40 -0700 (PDT)
In-Reply-To: <537F70FE.6080701@dcrocker.net>
References: <537F560C.4020900@dcrocker.net>  <537F70FE.6080701@dcrocker.net>
Date: Fri, 23 May 2014 11:05:40 -0500
Message-ID: 
From: Nico Williams 
To: Dave Crocker 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BTMDxAzvwenwnudMnp3d6ltSgX8
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 16:05:44 -0000

On Fri, May 23, 2014 at 11:02 AM, Dave Crocker  wrote:
> On 5/23/2014 8:49 AM, Nico Williams wrote:
>> On Fri, May 23, 2014 at 9:07 AM, Dave Crocker  wrote:
>> The main downside of "credential" is that for many people it means
>> "password" or "something to use to get a {certificate, ticket,
>> assertion, ...} with".
>
> The history of ambiguity for 'credential' seems pretty serious to me.
> It's difficult -- actually, I believe impossible -- to get everyone to
> adapt, once there's a long, problematic history.
>
> So I'm looking for a term that is not tied to any existing services.  It
> might apply to some, but would stand separate from them.
>
> The world is possibly considering different models than what is
> currently entrenched and I'd like to have a term that isn't tied to any
> existing (and poorly adopted) mode.

When I find myself having to deal with "credential"'s extreme
generality I qualify it.  E.g., "cryptographic credential" ==
{certificate, ticket, assertion, ...}, while "initial credential" ==
something to use in authenticating to a Kerberos AS, SACRED server,
IdP, ...

That's one thing I really like about credential: it's easy to modify
with an adjective or adjectival phrase.

Nico
--


From nobody Fri May 23 09:43:04 2014
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 E080C1A0744 for ; Fri, 23 May 2014 09:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 FSGcFiVQjxks for ; Fri, 23 May 2014 09:42:58 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7331A024A for ; Fri, 23 May 2014 09:42:57 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s4NGgnMW012126; Fri, 23 May 2014 09:42:49 -0700
Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1m1euuec58-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 09:42:49 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Fri, 23 May 2014 09:42:48 -0700
From: Paul Lambert 
To: "dcrocker@bbiw.net" , "saag@ietf.org" 
Date: Fri, 23 May 2014 09:42:46 -0700
Thread-Topic: [saag] Alternative terminology to "certificate" or "credential"?
Thread-Index: Ac92pgd2exYadB5NRzqiG/x3WL/j1g==
Message-ID: 
References: <537F560C.4020900@dcrocker.net>
In-Reply-To: <537F560C.4020900@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-23_06:2014-05-23,2014-05-23,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405230212
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/o-iYcT0R128drK3Dsi-CQniOKys
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 16:43:00 -0000

On 5/23/14, 7:07 AM, "Dave Crocker"  wrote:

>
>Hi.
>
>I'm looking for a term that refers to a package associating a key with
>"other attributes" but which does not imply the usual Certificate
>Authority trust model.

To build more complicated and interesting trust models we do need
a new framework and terminology.  The relationships that we could
describe in a =8Cpackage=B9 of information may or may not serve
the same functions that we currently describe as a credential.

I=B9m partial to describing such constructs in terminology that could
be mapped to formal logical models or programming analogies.
Specifically, expressions of attribute bindings to a key are just
one type of =8Cstatement=B9.  A =8Csigned statement=B9 would be a
certificate-like structure.


>
>Rather, packaging things together is separate from statements of trust
>about the package supplier or the contents of the package.

Yes - =8Cstatement of trust=B9  is a nice term for a statement that
delegates a attribute range to a target/key.

Paul

>
>The bare word "certificate" might be theoretically reasonable, but
>established usage means people will typically assume it invokes the
>usual CA model.

>The only candidate term I've come across is 'credential', but my own
>impression matches that of Wikipedia:
>
>   http://en.wikipedia.org/wiki/Digital_credential
>
>   "Because of the still evolving, and sometimes conflicting,
>   terminologies used in the fields of computer science, computer
>   security, and cryptography, the term "digital credential" is used
>   quite confusingly in these fields"
>
>
>Any suggestions?
>
>Thanks.
>
>d/
>--=20
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
>
>_______________________________________________
>saag mailing list
>saag@ietf.org
>https://www.ietf.org/mailman/listinfo/saag


From nobody Fri May 23 09:56:59 2014
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 8D3E71A074D for ; Fri, 23 May 2014 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 eddcLdnuhgY7 for ; Fri, 23 May 2014 09:56:57 -0700 (PDT)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6861A01FF for ; Fri, 23 May 2014 09:56:56 -0700 (PDT)
Received: by mail-ve0-f182.google.com with SMTP id sa20so6555016veb.41 for ; Fri, 23 May 2014 09:56:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=I8QWcOsD/5CQC7VcCYrsWjXg6BA59A0//R9brxZT2mU=; b=QbaUPMn4qkez9fRRqzxePYlNcyJsC3Q1A7KSC0diUGyWPkPCU/+Ed5f6mR/uJJz06d fL/Ky+WwHQ46BDnnbAqynestodzkb/Y78e/zkeKySB0J0xcKTc2XxMxDznZkZ+3uNWC0 o9+zrygEO+rY17Ax0AoUzBiCLM0KmU7CcZaEEIs96IftCxyVHQzdaZgTjFurgXCpMBf3 b5LHSSKjiPUKyi4fcnn2geXdxavw9ryLlavCnhNjW8Re021yJFY4jwtXqQwgaAEa5h/2 vXWwbKdxO5e9fxkFbQ43PnzlkxOpvhNDfGMtVF9jB3XPYV0OPb7lq9DFvAmcGp5O7qUf UNrA==
X-Gm-Message-State: ALoCoQk0s+G2VgY0Jo+AXusGkQ0xl/NML/XP+UXPT/n+wkkzu3Fdhw5AfTamnnCkUbHFw8PwFOxZ
X-Received: by 10.58.47.36 with SMTP id a4mr1621392ven.63.1400864214737; Fri, 23 May 2014 09:56:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Fri, 23 May 2014 09:56:34 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35657@USMBX1.msg.corp.akamai.com>
References: <537F560C.4020900@dcrocker.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35657@USMBX1.msg.corp.akamai.com>
From: Tim Bray 
Date: Fri, 23 May 2014 11:56:34 -0500
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a11c396d0e5fe7804fa141db3
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yWsVfg433h3qDGaOJP--IF2Jk8w
Cc: "dcrocker@bbiw.net" , "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 16:56:58 -0000

--001a11c396d0e5fe7804fa141db3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In OpenID Connect, based on OAuth 2, they call the individual assertions in
a package =E2=80=9Cclaims=E2=80=9D, and the claims are packaged up in an =
=E2=80=9CID Token=E2=80=9D.  It=E2=80=99s
all nice terminology, because =E2=80=9Cclaim=E2=80=9D is accurately descrip=
tive, =E2=80=9DID=E2=80=9D
describes what the payload is, =E2=80=9CToken=E2=80=9D tells you that it's =
a thing you send
around the network, and none of those words carry connotations that are apt
to cause faulty preconceptions to set in.

So I suspect that you might do well to consciously avoid re-using
terminology that comes with well-established but probably-misleading
semantics.


On Fri, May 23, 2014 at 9:16 AM, Salz, Rich  wrote:

> > I'm looking for a term that refers to a package associating a key with
> "other attributes" but which does not imply the usual Certificate Authori=
ty
> trust model.
>
> SAML uses the term "assertions," which seems a good fit.
>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: rsalz@jabber.me; Twitter: RichSalz
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>



--=20
- Tim Bray (If you=E2=80=99d like to send me a private message, see
https://keybase.io/timbray)

--001a11c396d0e5fe7804fa141db3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In =
OpenID Connect, based on OAuth 2, they call the individual assertions in a =
package =E2=80=9Cclaims=E2=80=9D, and the claims are packaged up in an =E2=
=80=9CID Token=E2=80=9D. =C2=A0It=E2=80=99s all nice terminology, because =
=E2=80=9Cclaim=E2=80=9D is accurately descriptive, =E2=80=9DID=E2=80=9D des=
cribes what the payload is, =E2=80=9CToken=E2=80=9D tells you that it's=
 a thing you send around the network, and none of those words carry connota=
tions that are apt to cause faulty preconceptions to set in.




So I suspect that you might do=
 well to consciously avoid re-using terminology that comes with well-establ=
ished but probably-misleading semantics.





On Fri,=
 May 23, 2014 at 9:16 AM, Salz, Rich <rsalz@akamai.com> wrote=
:



> I'm looking for a term that refers to a package associating a key =
with "other attributes" but which does not imply the usual Certif=
icate Authority trust model.



SAML uses the term "assertions," which seems a good fit.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$



--

Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM: rsalz@jabber.me; Twitter: RichSa=
lz



_______________________________________________

saag mailing list

saag@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/saag





-- 
- Tim Bray (If you=E2=80=99d like to send me a private message, s=
ee https://keybase=
.io/timbray)







--001a11c396d0e5fe7804fa141db3--


From nobody Fri May 23 10:21:12 2014
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 76C941A01DD for ; Fri, 23 May 2014 10:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 raph2SqYAcC7 for ; Fri, 23 May 2014 10:21:10 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 041E71A0049 for ; Fri, 23 May 2014 10:21:10 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 718D72AC086 for ; Fri, 23 May 2014 10:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gRim+9C3bcUZuC/IP1NO b5Rgj3s=; b=KLq33VP7RJd7+9VKy0+34nMOx5hYjGCDWvFSGw+lzX7w6SnYqVP5 igVO4JnsAgQO9b5776pjiAHyj74BTb1zywFmXpUorwVu35bWESzSJ6czwCSPxbws XjXLHG6c4F9lNIwwGzhcmoB66zAPZl1UPA+tAWMvBjYWugvHfCiEbe4=
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 23E8D2AC07A for ; Fri, 23 May 2014 10:21:07 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u56so5102880wes.37 for ; Fri, 23 May 2014 10:21:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.212.77 with SMTP id ni13mr4491241wic.5.1400865666917; Fri, 23 May 2014 10:21:06 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Fri, 23 May 2014 10:21:06 -0700 (PDT)
In-Reply-To: 
References: <537F560C.4020900@dcrocker.net>  <537F70FE.6080701@dcrocker.net> 
Date: Fri, 23 May 2014 12:21:06 -0500
Message-ID: 
From: Nico Williams 
To: Dave Crocker 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HMX9gGePS-YqR6RadzwWNWx2OQs
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Fri, 23 May 2014 17:21:10 -0000

I would also point to the debate about "opportunistic X" as an example
of where we considered existing terminology carefully and settled on
reusing a bit of existing terminology for carefully considered reasons
(namely that "opportunistic" is too awesome and unique an
English-language adjective to pass it over for much lesser
alternatives).  That case is also an example of using a phrase instead
of a single word.

I strongly prefer "X credential", where X is an adjective like
"cryptographic".  "Credential" is too good a word to throw out on
account of past usage of it.

Nico
--


From nobody Wed May 28 11:14:19 2014
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 DB76B1A042D for ; Wed, 28 May 2014 11:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 KApM9WrYuraI for ; Wed, 28 May 2014 11:14:16 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0641A01D9 for ; Wed, 28 May 2014 11:14:16 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s4SIE9KL016195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 28 May 2014 11:14:12 -0700
Message-ID: <5386274B.4070507@dcrocker.net>
Date: Wed, 28 May 2014 11:13:31 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "saag@ietf.org" 
References: <537F560C.4020900@dcrocker.net>
In-Reply-To: <537F560C.4020900@dcrocker.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 28 May 2014 11:14:12 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DdGKTx1F1i6bXIDniWsfGeCOsEA
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 18:14:18 -0000

On 5/23/2014 7:07 AM, Dave Crocker wrote:
> I'm looking for a term that refers to a package associating a key with
> "other attributes" but which does not imply the usual Certificate
> Authority trust model.
> 
> Rather, packaging things together is separate from statements of trust
> about the package supplier or the contents of the package


Many thanks to the folk who offered and discussed candidate vocabulary.

An ad hoc, separate (small-group) discussion yesterday developed
surprisingly strong rough consensus on a term:

     signet

It nicely has relevant natural-language semantics and no apparent
security area, term-of-art baggage.

d/



-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu May 29 15:21:58 2014
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 CC2541A0293 for ; Thu, 29 May 2014 15:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 meF79MEVUtpT for ; Thu, 29 May 2014 15:21:55 -0700 (PDT)
Received: from mailout4.easymail.ca (mailout1.easymail.ca [64.68.200.113]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD6D1A0195 for ; Thu, 29 May 2014 15:21:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id 51D1CE319; Thu, 29 May 2014 18:21:47 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca
Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyB4gsUZ0KuL; Thu, 29 May 2014 18:21:46 -0400 (EDT)
Received: from [192.168.3.137] (24-205-93-255.dhcp.psdn.ca.charter.com [24.205.93.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id B74E0E2F4; Thu, 29 May 2014 18:21:45 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D378CC1D-C61F-4712-812A-9E136738C05D"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Henry B Hotz 
In-Reply-To: <5386274B.4070507@dcrocker.net>
Date: Thu, 29 May 2014 15:21:44 -0700
Message-Id: 
References: <537F560C.4020900@dcrocker.net> <5386274B.4070507@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UeyqNMA2Q8yI-0RLKbC6JKuoudo
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
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: Thu, 29 May 2014 22:21:56 -0000

--Apple-Mail=_D378CC1D-C61F-4712-812A-9E136738C05D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

So the idea is that a SAML assertion, GSS credential, and X.509 =
certificate are all examples of a signet? I agree that the existing =
dictionary definition of the word is nice for the purpose (though I =
would have voted for Nico's suggestion).

On May 28, 2014, at 11:13 AM, Dave Crocker  wrote:

> On 5/23/2014 7:07 AM, Dave Crocker wrote:
>> I'm looking for a term that refers to a package associating a key =
with
>> "other attributes" but which does not imply the usual Certificate
>> Authority trust model.
>>=20
>> Rather, packaging things together is separate from statements of =
trust
>> about the package supplier or the contents of the package
>=20
>=20
> Many thanks to the folk who offered and discussed candidate =
vocabulary.
>=20
> An ad hoc, separate (small-group) discussion yesterday developed
> surprisingly strong rough consensus on a term:
>=20
>     signet
>=20
> It nicely has relevant natural-language semantics and no apparent
> security area, term-of-art baggage.
>=20
> d/
>=20
>=20
>=20
> --=20
> Dave Crocker

Personal email.  hbhotz@oxy.edu




--Apple-Mail=_D378CC1D-C61F-4712-812A-9E136738C05D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

So =
the idea is that a SAML assertion, GSS credential, and X.509 certificate =
are all examples of a signet? I agree that the existing dictionary =
definition of the word is nice for the purpose (though I would have =
voted for Nico's suggestion).

On May 28, 2014, at =
11:13 AM, Dave Crocker <dhc2@dcrocker.net> =
wrote:

On 5/23/2014 7:07 AM, Dave Crocker wrote:
I'm looking for a term that refers to a package =
associating a key with
"other attributes" but which does not imply =
the usual Certificate
Authority trust model.

Rather, packaging =
things together is separate from statements of trust
about the =
package supplier or the contents of the =
package


Many thanks to the folk who offered and =
discussed candidate vocabulary.

An ad hoc, separate (small-group) =
discussion yesterday developed
surprisingly strong rough consensus on =
a term:

     signet

It nicely has =
relevant natural-language semantics and no apparent
security area, =
term-of-art baggage.

d/



-- 
Dave =
Crocker



Personal =
email.  hbhotz@oxy.edu







=

--Apple-Mail=_D378CC1D-C61F-4712-812A-9E136738C05D--


From nobody Thu May 29 16:48:25 2014
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 BB0501A071B for ; Thu, 29 May 2014 16:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hgn1JBz3Crkn for ; Thu, 29 May 2014 16:48:22 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2327A1A072F for ; Thu, 29 May 2014 16:48:22 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s4TNmEvm002069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 16:48:18 -0700
Message-ID: <5387C716.3080206@dcrocker.net>
Date: Thu, 29 May 2014 16:47:34 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Henry B Hotz 
References: <537F560C.4020900@dcrocker.net> <5386274B.4070507@dcrocker.net> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 29 May 2014 16:48:18 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/o1TFwVym_bXbDw948xmi_aFcDqs
Cc: "saag@ietf.org" 
Subject: Re: [saag] Alternative terminology to "certificate" or "credential"?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 23:48:23 -0000

On 5/29/2014 3:21 PM, Henry B Hotz wrote:
> So the idea is that a SAML assertion, GSS credential, and X.509
> certificate are all examples of a signet? I agree that the existing
> dictionary definition of the word is nice for the purpose (though I
> would have voted for Nico's suggestion).


Hmmm.  I hadn't thought of signet as being a superset of things like
X.509 certs.  I'd been thinking of it as an alternative.

But I suppose the definition I gave really is that generic.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net