From nobody Wed Apr 1 08:56:30 2015 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 495951A1B40 for ; Tue, 31 Mar 2015 02:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, 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 C6ZfG6Elof0S for ; Tue, 31 Mar 2015 02:22:16 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F10D1A1A2F for ; Tue, 31 Mar 2015 02:22:15 -0700 (PDT) Received: from [193.109.254.3] by server-11.bemta-14.messagelabs.com id 63/AC-22533-6476A155; Tue, 31 Mar 2015 09:22:14 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-12.tower-184.messagelabs.com!1427793733!7382230!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26215 invoked from network); 31 Mar 2015 09:22:13 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-12.tower-184.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Mar 2015 09:22:13 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout04.vodafone.com (Postfix) with ESMTP id 3lGQCn4pXdznTtB for ; Tue, 31 Mar 2015 11:22:13 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3lGQCn3fRtzxPsM for ; Tue, 31 Mar 2015 11:22:13 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3lGQCn2Vq6zxNym for ; Tue, 31 Mar 2015 11:22:13 +0200 (CEST) Received: from VOEXM17W.internal.vodafone.com ([169.254.1.163]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 11:22:10 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: Ubiquitous encryption draft feedback - mobile case Thread-Index: AdBrlAn3G74K8pspTryGfEX1HMRvtA== Date: Tue, 31 Mar 2015 09:22:09 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 08:56:29 -0700 Subject: [saag] Ubiquitous encryption draft feedback - mobile case 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, 31 Mar 2015 09:22:18 -0000 Hi Kathleen & Al, Thanks for publishing this draft, which makes a lot of sense. I support app= roaches that allow network management to persist without breaching encrypti= on or introducing any security/privacy weakness, and this paper provides a = sound reference for such work. I'd like to offer an additional (sub) section on the particular case of tr= affic management for mobile networks, along the lines of: "Bandwidth in cellular radio networks tends to be more volatile than in fix= ed networks. This is a result of variance in radio signal strength as a use= r moves around a cell, the rapid ingress and egress of connections as users= handoff between adjacent cells, and sudden congestion at certain cells at = certain times. Mobile networks account for this by queuing traffic accordin= g to its required bandwidth and acceptable latency, and hence spread the av= ailable bandwidth sensibly across users: for example, a user is unlikely to= notice a 20ms delay when receiving a Web page, email or instant message re= sponse, but will likely notice video buffering or VoIP call jitter. The net= work manages the queue so that each user has an acceptable experience as co= nditions vary. Application and transport layer encryption makes the traffic= type detection less accurate, impacting queue management." Also section 4.1 highlights many similarities between Enterprise and a gove= rnment-regulated mobile network. A couple of minor typos in the Introduction: "These efforts are necessary to improve end users expectation of privacy," s/improve end users expectation/improve an end user's expectation "Many attackers and those that pose a greater threat are already using stro= ng encryption and tools like TOR [TOR] to prevent active attacks from on th= eir data streams." s/from/ All best, Kevin Kevin Smith, Vodafone R&D From nobody Wed Apr 1 12:22:56 2015 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 7B2361A887A for ; Wed, 1 Apr 2015 12:22:54 -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 72G35cal6ch2 for ; Wed, 1 Apr 2015 12:22:53 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D189A1A036E for ; Wed, 1 Apr 2015 12:22:52 -0700 (PDT) Received: by lajy8 with SMTP id y8so44307985laj.0 for ; Wed, 01 Apr 2015 12:22:51 -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=AiCo4uNziiBqxVT4sVOBXvm1ol9XYcJ+lDhHtEBcm/A=; b=O6pe2J4oqPEbeZqUTuqoDcMytrkrDL8LDjnjpAESa+KN6ZV1qIGTpsa5gRpcpUYf8o 5NDbrWOeIwg1xeffPq7ZToSqauApY4O1ouGUNTjvOKjGinX6xSoGlxjlB5x9ssDyZP78 E/mzRyMrBpi+C/zvtrZd1W2gnrplN0dbzyPqNiYR6m8YQkr1bs8zlmg+K1BNAW8uA85l 1fKAu+Box18O4UFU8Tkpej5539oklKvfBvh+nPGy0bttZELSEcPerJUcBma7yDPp6bXl ZukHcoEsza10XpWaE2zJpz1jzmCrsmY49c4QuwMomi33Pt6dNCQN0Yup19jOe8lzPbHk 6X2g== MIME-Version: 1.0 X-Received: by 10.112.29.36 with SMTP id g4mr29368446lbh.56.1427916171384; Wed, 01 Apr 2015 12:22:51 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 12:22:51 -0700 (PDT) In-Reply-To: <8B8C515B-3D14-4D17-AAD3-72A0EFF99E0D@iab.org> References: <8B8C515B-3D14-4D17-AAD3-72A0EFF99E0D@iab.org> Date: Wed, 1 Apr 2015 15:22:51 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a1133f9942a1b420512aea42f Archived-At: Subject: [saag] Fwd: Date change for CARIS submissions 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, 01 Apr 2015 19:22:54 -0000 --001a1133f9942a1b420512aea42f Content-Type: text/plain; charset=UTF-8 Please note the submission date change to April 10th for the CARIS workshop. We look forward to your submission and participation. Thank you, Kathleen ---------- Forwarded message ---------- From: IAB Chair Date: Wed, Apr 1, 2015 at 3:17 PM Subject: Date change for CARIS submissions To: ietf list , ietf@ietf.org Dear colleagues, The Co-ordinating Attack Response at Internet Scale (CARIS) workshop program committee is extending the deadline for submissions by one week, to 10 April 2015. The call for papers is available from https://www.iab.org/activities/workshops/caris/call-for-papers/. For more information on CARIS, please see https://www.iab.org/activities/workshops/caris/. Best regards, Andrew Sullivan IAB Chair -- Best regards, Kathleen --001a1133f9942a1b420512aea42f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please note the submission date change to April 10th for t= he CARIS workshop.=C2=A0 We look forward to your submission and participati= on.

Thank you,
Kathleen

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername">IAB Chair <iab-chair@iab.org>
Date: Wed, A= pr 1, 2015 at 3:17 PM
Subject: Date change for CARIS submissions
To: = ietf list <ietf-announce@ietf.= org>, ietf@ietf.org


= Dear colleagues,

The Co-ordinating Attack Response at Internet Scale (CARIS) workshop
program committee is extending the deadline for submissions by one
week, to 10 April 2015.=C2=A0 The call for papers is available from
https://www.iab.org/activities/workshops/caris/call-for-= papers/.=C2=A0 For
more information on CARIS, please see
https://www.iab.org/activities/workshops/caris/.

Best regards,

Andrew Sullivan
IAB Chair




--

Best regards,
Kath= leen
--001a1133f9942a1b420512aea42f-- From nobody Tue Apr 7 14:13:41 2015 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 CBF5D1A9005 for ; Tue, 7 Apr 2015 14:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrkydmTut5Lc for ; Tue, 7 Apr 2015 14:13:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B65C1A901D for ; Tue, 7 Apr 2015 14:13:38 -0700 (PDT) Received: from [192.168.10.163] ([64.71.18.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOwY7-1Yjk5H3CSt-006Kdr for ; Tue, 07 Apr 2015 23:13:37 +0200 Message-ID: <5524487E.7020505@gmx.net> Date: Tue, 07 Apr 2015 23:13:34 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4sfAjgt2Mc43bcksLfrxAcp0cM2wxPQwh" X-Provags-ID: V03:K0:sJBWqoC8W6gnzHxADHJ4B7urG4qOqyjZox5zWuPDd0zrJHgv8Yz U9bc5iRrR9b9wOY1/0X1uMqfuWXIgGBXf7nNyNHQ8l8JF6kgZEuBJt4dvpaQJ9hcH7Ox5DB AK6eGUm2TX2pf+CS3X0ZGNUMxjhVs4zMhGRh1/1LXy0mcpVbjT736UlWrqZalKPF4/Ay/3z pDzjdJipWwoXm+TNV2t8w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] TLS VPN side meeting at IETF 92 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, 07 Apr 2015 21:13:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4sfAjgt2Mc43bcksLfrxAcp0cM2wxPQwh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was wondering whether there are some meeting notes from the TLS VPN side meeting at IETF 92 available since I was not able to attend the Bar-= BOF Thanks. Ciao Hannes --4sfAjgt2Mc43bcksLfrxAcp0cM2wxPQwh 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: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVJEh+AAoJEGhJURNOOiAtsBoIAKFTDF0laxpBX+W579g3wbH0 Fx7Da5YKoxK4Bmm/v5gJYqTygxR2qmUoUHq6S5D+x36++1hcyS+QViJzImf0v75K /MrD0I6nZ80u9SR2MRKe8lXZAewjWxx0LO96W/ulJ9VMkxp1UlhSNfpQK4Pd4xxw NPAkMhYCOXMMVEnAaudaAz+ZE9PRotZ68shiDY/a77/1zOJPx98e7+Qrpn7K1T+S WNSn8GyEZW/j6J9MBnDq4/g7UmObC9l0RYO1yr2cYrnQUzaugZky5QIk3kADOU3o 1z8MSsqb5i8BTaZrEcqQPE97A3qaPmHp3aa/mP7O/THWQ+5w/G5GoHdLDJxJnok= =Rh4P -----END PGP SIGNATURE----- --4sfAjgt2Mc43bcksLfrxAcp0cM2wxPQwh-- From nobody Fri Apr 10 05:23:40 2015 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 755861B2E5F for ; Fri, 10 Apr 2015 05:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-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 7CxMGkfMTv8f for ; Fri, 10 Apr 2015 05:23:37 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672131B2E1A for ; Fri, 10 Apr 2015 05:23:37 -0700 (PDT) Received: by wizk4 with SMTP id k4so125983315wiz.1 for ; Fri, 10 Apr 2015 05:23:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=xT0BIbMLma4UiGgrubiBwGIQk/re23opjrADDPvPHKw=; b=OxHzxJMqXYecRuAQbuW+S6RQxFjJzmm4drJ4+jz/NFtEQZTgaZTz/fgD11x3M5GeHw 2q+HwmYZ/2EwhoTwM79fUlVAPT/QRBFek41qgb2f8WZv2q0GbvBb795XkJUOP3J2uiRW AxGIWwaDUjQdeavqodB8vgxv+VuqXBodUmM+AMPw/XCUVcUSBkrq9lxk+Qtbu5qJu0Oa 8bjUYybQ18aVUS9/oZqknteQwrsLYnvghFe8jl69rYh9cMSIKUhRMHD7VLVWlQXMhpNg fY74iUE+qp79dE0SBJvsNtSocGTWJc2YI35/hNUCWn5mYDwiAw2MkFQvELCnd42bLIZt qO3A== X-Gm-Message-State: ALoCoQkS/e4yELjqChDcIzDmSnKiuIvMSaAUgYkt1+S9trUXSfjVXY01OtXA3gF4I889vsWro37r X-Received: by 10.194.79.199 with SMTP id l7mr2354960wjx.158.1428666849350; Fri, 10 Apr 2015 04:54:09 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id 14sm2641777wjv.0.2015.04.10.04.54.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 04:54:08 -0700 (PDT) Message-ID: <5527B9DD.4020800@azet.org> Date: Fri, 10 Apr 2015 13:54:05 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Paul Wouters References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> <5508A726.5090406@azet.org> <551984FC.8020006@redhat.com> In-Reply-To: <551984FC.8020006@redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0B22088E4B13F282D2908C7F" Archived-At: Cc: saag@ietf.org Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 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, 10 Apr 2015 12:23:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B22088E4B13F282D2908C7F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Paul Wouters wrote: > On 03/17/2015 06:13 PM, Aaron Zauner wrote: >=20 >> IPSec might (!) work well if you use one vendor throughout your networ= k, >=20 > That's a somewhat obsoleted viewpoint. While I think that is correct fo= r IKEv1 and all the proprietary bold-on solutions, I do not see as many i= ssues with > IKEv2. Although for large scale solutions, there tends to be a strong v= endor-lock but mostly in the management/gui aspects of having many device= s (not endusers) >=20 >> solutions. Because IPSec is such an overly complicated protocol there'= s not much security in the clients that are available throughout enduser = operating >> system. >=20 > I'm not sure what you mean here. With the exception of group PreShared = Keys and in particular Aggressive Mode IKEv1, yes that's broken and shoul= d not be used. > But it _has_ been obsoleted for almost a decade now. >=20 > Apple, for example, uses racoon (a NetBSD client) for >> IPSec. It only supports IKEv1 in Aggressive Mode. That's a pretty big = userbase that is forced to use an insecure protocol. >=20 > It does support IKEv2 in the latest iOS, but the provisioning is so loc= ked up that people haven't made it work yet >=20 > It does suppor IKEv1 with certificates, which is _not_ insecure, even i= n Aggressive Mode. And a lot of Users will struggle with configuring this. That's why Cisco et al ship management solutions with e.g. AnyConnect. See below: >=20 > As for those still think IPsec is too hard to configure, according to h= ttp://www.theguardian.com/technology/2015/jan/09/why-netflix-wont-block-v= pn-users there > are 30 million people using a VPN to access netflix. With the apple vs = android split, that's about 15 million end users who are using IPsec just= fine. Right. I've reviewed a lot of these services, most of them do _not_ support IKEv1 with Certificates but rather use a pre-shared key, which most of them, put up publicly on their website. Some providers do have better solutions, most offer a combination of Services with the primary choice for endusers being OpenVPN or L2TP/IPSec (PSK public and the same for all users). Aaron --------------enig0B22088E4B13F282D2908C7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVJ7ndAAoJEOTbZJL9ubXVDhoP/3a6fFM+34MBZr166ma7xPvE GM8mduhGdXOQiL0zfaBHk0ZQjTgNuCdhtgtlI7A6TQURAwZ+AVQWo74qH3iuCg96 JPysXAL2Ou5Aaq5rJsW/y4pPkur+AgftfaQEcxSJrMSuLGL1jUXZBhTlDVniNSFC 4hpRKvAsV3QX7mY7iPahGByQYd1KtjT6dldiubq9BXGD74zlN+VSitAc7GyqbFVP RmmEEEnUktpG7s9GXtcY5MOqyV2pNL7XhEAN6rQPlmWU1IPXl8/5ZiRUM9EL7l3t NjBYVFVUnaamZd9bWQBeiAVNWBx1bnHgACIX6V5bKTYDiWYHSnjsdlMhcFIiQ5Xn ERYb3DXj4i4yZ1KPadY8svMKtkdIaNvlgdzcDGt3lEp3AbXXD+T5ZUBd9qit6VrH jew9SP3T9Sp3tKzTsX6qgQmYOmdIdEbAcC2q+0YGfwPK+Mgzi2d1dRS9EWxNvZbl fN4v8AJOYBvHTSzQUEHqGrYSJ4l4QBD4YvQ+5qQjzpC9ttrMUjxTCw1MUjHH1MnX TslaCA74+3nSPU5hEzidcPlpxpcydlOzrMQ1fwMIUHjnNRfvZBaoBw7DoB4Q4njb Tl51pjheOUecSauv2MdmOD9n4lvLZTkQgyJ1dRalbYO4y4HFcJb919l/of1G0HS0 Bw4fuO6QV068sV0q1K+M =b4YS -----END PGP SIGNATURE----- --------------enig0B22088E4B13F282D2908C7F-- From nobody Fri Apr 10 05:25:18 2015 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 573A81B2F0C for ; Fri, 10 Apr 2015 05:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jbmzDSQtgpQk for ; Fri, 10 Apr 2015 05:25:14 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCD81B2E02 for ; Fri, 10 Apr 2015 05:25:14 -0700 (PDT) Received: by wiaa2 with SMTP id a2so24247996wia.0 for ; Fri, 10 Apr 2015 05:25:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=h/BICe1zufjuAxTNni55QYn/S52guDDovW0UTGokodQ=; b=fd1BgDWW8q4hB5ahqD02yGIVze/88xRWzhlCKdG0a7DKxlfDTe2EfncYO+CkcacAk+ URYod9QmqzbKoLttJ78s2Y7rjZnBC3QKXno+08ARyX9HX8py+QuDQ1dfo5gIEDGRYoCm kd9XiAMXSGPtsmKSy2y152AuN0Xuisj0LKVchl37ct/M6/NkAVLeLimPB0SKMylmqtH5 zYw3ef5ILiKP6IBvMIsKZ0kCIIUfWPwD8DlwhvrmHb5lMoWEJWIxX8wOQOOR7hflOBJQ 3dhCIzz0DtudLUbeZjOILiNi/8QL14IoJSpPuTHFzPWQ1GeSpQ2LtSl28769DPHbiayF p9zQ== X-Gm-Message-State: ALoCoQlKaPWnhD9agKi1i0X8GpN6vOawvdqImjQITQ9Ki3eYXqI312wBborVl7+Pt/jWbO+Gz7JI X-Received: by 10.194.95.4 with SMTP id dg4mr2302941wjb.81.1428666930500; Fri, 10 Apr 2015 04:55:30 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id hu1sm3118001wib.6.2015.04.10.04.55.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 04:55:29 -0700 (PDT) Message-ID: <5527BA2E.5050904@azet.org> Date: Fri, 10 Apr 2015 13:55:26 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Paul Wouters References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> <5508A726.5090406@azet.org> <551984FC.8020006@redhat.com> <5527B9DD.4020800@azet.org> In-Reply-To: <5527B9DD.4020800@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAC51A019C7000ACB63838745" Archived-At: Cc: saag@ietf.org Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92 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, 10 Apr 2015 12:25:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC51A019C7000ACB63838745 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Aaron Zauner wrote: > Right. I've reviewed a lot of these services, most of them do _not_ > support IKEv1 with Certificates but rather use a pre-shared key, which > most of them, put up publicly on their website. Some providers do have > better solutions, most offer a combination of Services with the primary= > choice for endusers being OpenVPN or L2TP/IPSec (PSK public and the sam= e > for all users). >=20 Ah, yes and a couple of these VPN Providers ship their own Apps for users to install with either TLS VPN or IPSec support, varies. Aaron --------------enigAC51A019C7000ACB63838745 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVJ7ouAAoJEOTbZJL9ubXVCdMQAJMmAXiuZnbUSUpyTGLJJGxR J4jm2EWCP1rJv8qaD3NGw11+dOdrkJmfVHCg0ZoaP3QeLF5Be+9fm0kPV+rwe5m1 ixaCD7mQccIcXVjPw3aUsfREy/BK7aEnmXHnPkFu2e2FxKelxeGpUN78GMHTQl0a YIgVt8mNILsK7HcPU4+HMPuqB6gB1KNYuIkyY4RIvbRj5hVJWoYMa/YEY703nNSF KTB56Su3l8PKgQ7YvLx6sFqGpihEyzhamTnu5sR3o1J0JpHx0kwEoqK4YAnIUgi9 0gtMNepkfw7hA+sbhcyA/7hrSL8/eneGJyiX7H+jVLY+IlItsPY1m6+0W3UceKjW dQtj3EOppCMHkKWwSjmn3PanB5Nw5KIe+B+4000ZR4PjKwbozoMLsYgwx2gDZaG/ TZCJURw/0F15YeIlHWF2WsSs0N6UruFVToeXEgakYyOTpziqt26p8yF8DEN2mYCy FE14HaVxgJnUhwxqpPqDw8dtYWFIgFEI0WJjEmLyCIY7+i3R4AXFcIekrtnxdLyC fLifLjSpnbV0cQqlo2ouNQGbtCw5htFQMLnZxBqY6kohViCb84yuXdLlWGqvovPB /EO8016ZAkoT0d8guZDshUP72dUJFTc5hZoUatPCkPCdfLAEvUtWREQfk0ZAFFHK MxWmRNbwY4EtSsmYg1J+ =avod -----END PGP SIGNATURE----- --------------enigAC51A019C7000ACB63838745-- From nobody Fri Apr 10 14:24:51 2015 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 A77AB1A8A6C for ; Fri, 10 Apr 2015 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] 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 to6YtpaW2q0F for ; Fri, 10 Apr 2015 14:24:47 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9A1A8A60 for ; Fri, 10 Apr 2015 14:24:47 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 0FED1F240F5; Fri, 10 Apr 2015 17:24:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id x6CzBndxtdcP; Fri, 10 Apr 2015 17:24:15 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BB64CF240FE; Fri, 10 Apr 2015 17:24:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <53B6FEB0.50804@iang.org> Date: Fri, 10 Apr 2015 17:24:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> To: ianG X-Mailer: Apple Mail (2.1085) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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, 10 Apr 2015 21:24:49 -0000 I am working on -03 of the crypto-alg-agility document, and I went back = to your message as part of that work. I have tried to put together some words that show that both extremes can = be problematic. I hope that you and the others on this list will review = and comment. Russ =3D =3D =3D =3D =3D =3D =3D 4. Cryptographic Algorithm Specifications 4.1. Too Many Choices Can Be Harmful When it is too easy to specify the use of arbitrary cryptographic algorithms, the algorithms get implemented and deployed. Some people say that the freedom to specify algorithms independently from the rest of the protocol has lead to the specifications of vanity cryptographic algorithms. Once deployed, it is quite difficult to remove algorithms because interoperability with some party will be impacted. As a result, weak ciphers stick around far too long. Sometimes implementors are forced to maintain cryptographic algorithm implementation well beyond their useful lifetime. All implementors are expected to support the mandatory-to-implement cryptographic algorithm, and they can include any others algorithms that they desire. The mandatory-to-implement algorithms are chosen to be highly secure, following the guidance in RFC 1984 [RFC1984]. Generally, the mandatory-to-implement algorithms ought to be preferred, and the other algorithms ought to be selected only in special situations. However, it can be very difficult for a skilled system administer to determine the proper configuration to achieve these preferences. In some cases, more than one mandatory-to-implement cryptographic algorithm has been specified. The is intended to ensure that a secure cryptographic algorithm will be available, even if one of the mandatory-to-implement algorithms is broken. There is always a fallback. However, this adds to the difficult decision for a skilled system administer to determine the proper configuration to achieve their preferences. 4.2. Picking One True Cipher Suite Can Be Harmful After great study and evaluation, the protocol designer could select the one true cipher suite. This has at least two desirable consequences. First, the protocol is simpler since there is no need for algorithm negotiation. Second, system administrators do not need to make any algorithm-related configuration decisions. However, the only way to respond to news that the one true algorithm has been broken is to update the protocol specification to the next version, implement the new specification, and then get it deployed. Experience with the transition from SHA-1 to SHA-256 indicates that this cycle takes more than five years. On Jul 4, 2014, at 3:21 PM, ianG wrote: > I wonder if it is is possible to list the potential strategies for alg > agility? And perhaps add their pros&cons? Here's a strawman list of > possibilities, with full intent to be rewritten entirely, just in case > this helps: >=20 >=20 >=20 > 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, and > once added this tends to be supported for a long time. Crypto freedom > taken to vanity extremes. >=20 > Downside is weakness of deprecation; weak ciphers stick around = forever. > As algorithms are the component of choice, protocol errors tend to > impact many algorithms. Lots of 'downgrade' possibility, lots of user > confusion or ignorance, waste in maintenance of too many components. >=20 >=20 > 2. primary + extras. Everyone must implement the central chosen set, > and any others they desire. Most instances will prefer/negotiate the > primary, only in specialised instances will the alternates be chosen. >=20 > Downside is that there is no clear alternate choice. >=20 >=20 > 3. Primary + secondary MUSTs. As there are two MUST suites, there is > always a fallback, by config. >=20 >=20 > 4. Odds and evens. Each version has two suites, a primary and a > secondary, initially numbered 1 and 2. In each succeeding version, = the > last version's primary is dropped, and secondary moves up to primary. = A > new secondary is added (numbered 3, etc). Fallback / switchover can = be > done by configuration and by version upgrade. >=20 >=20 > 5. one true cipher suite. No config fall back available, a failure = in > the suite triggers a requirement to upgrade the entire version. = Simpler > to implement, no negotiation woes. >=20 >=20 > 6. parallel twinned suites, where the protocol duplicates every > component. Ciphers are CTR/XOR'd in parallel, HMACs are serialised, = etc. >=20 > This involves a performance hit that many would be annoyed by, and is > sometimes considered to be "inventing your own ciphers." No = particular > upgrade path but not particularly vulnerable to any component = weakness. >=20 >=20 >=20 >=20 >=20 > I'm sure there are more. And the thoughts above are very scrappy, by = no > means suitable for a draft. But maybe a useful approach? >=20 > iang >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Apr 10 16:57:18 2015 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 36A171B2EA0 for ; Fri, 10 Apr 2015 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm48UZN9sJXo for ; Fri, 10 Apr 2015 16:57:15 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7721C1B2E24 for ; Fri, 10 Apr 2015 16:57:15 -0700 (PDT) Received: from dummy.name; Fri, 10 Apr 2015 23:57:14 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Crocker In-Reply-To: <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> Date: Fri, 10 Apr 2015 19:57:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2C2E58-1724-4B13-8BD6-F316B60398F2@shinkuro.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> To: Russell Housley X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Stephen D. Crocker" , saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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, 10 Apr 2015 23:57:17 -0000 Russ, RFC 6975, =93Signaling Cryptographic Algorithm Understanding in DNS = Security Extensions (DNSSEC)=93 speaks to the issue of when servers can = stop supporting older algorithms. It=92s intended to facilitate = withdrawing algorithms from the suite when there has been sufficient = uptake of replacement algorithms. Perhaps it would be appropriate to = include a reference to this RFC and to include some discussion about how = to withdraw algorithms when their time has come. Also, I believe you want =93led=94 instead of =93lead=94. Steve Steve On Apr 10, 2015, at 5:24 PM, Russ Housley wrote: > I am working on -03 of the crypto-alg-agility document, and I went = back to your message as part of that work. >=20 > I have tried to put together some words that show that both extremes = can be problematic. I hope that you and the others on this list will = review and comment. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D >=20 > 4. Cryptographic Algorithm Specifications >=20 > 4.1. Too Many Choices Can Be Harmful >=20 > When it is too easy to specify the use of arbitrary cryptographic > algorithms, the algorithms get implemented and deployed. Some = people > say that the freedom to specify algorithms independently from the > rest of the protocol has lead to the specifications of vanity > cryptographic algorithms. Once deployed, it is quite difficult to > remove algorithms because interoperability with some party will be > impacted. As a result, weak ciphers stick around far too long. > Sometimes implementors are forced to maintain cryptographic > algorithm implementation well beyond their useful lifetime. >=20 > All implementors are expected to support the mandatory-to-implement > cryptographic algorithm, and they can include any others algorithms > that they desire. The mandatory-to-implement algorithms are chosen > to be highly secure, following the guidance in RFC 1984 [RFC1984]. > Generally, the mandatory-to-implement algorithms ought to be > preferred, and the other algorithms ought to be selected only in > special situations. However, it can be very difficult for a skilled > system administer to determine the proper configuration to achieve > these preferences. >=20 > In some cases, more than one mandatory-to-implement cryptographic > algorithm has been specified. The is intended to ensure that a > secure cryptographic algorithm will be available, even if one of the > mandatory-to-implement algorithms is broken. There is always a > fallback. However, this adds to the difficult decision for a = skilled > system administer to determine the proper configuration to achieve > their preferences. >=20 > 4.2. Picking One True Cipher Suite Can Be Harmful >=20 > After great study and evaluation, the protocol designer could select > the one true cipher suite. This has at least two desirable > consequences. First, the protocol is simpler since there is no need > for algorithm negotiation. Second, system administrators do not = need > to make any algorithm-related configuration decisions. However, the > only way to respond to news that the one true algorithm has been > broken is to update the protocol specification to the next version, > implement the new specification, and then get it deployed. > Experience with the transition from SHA-1 to SHA-256 indicates that > this cycle takes more than five years. >=20 >=20 > On Jul 4, 2014, at 3:21 PM, ianG wrote: >=20 >> I wonder if it is is possible to list the potential strategies for = alg >> agility? And perhaps add their pros&cons? Here's a strawman list of >> possibilities, with full intent to be rewritten entirely, just in = case >> this helps: >>=20 >>=20 >>=20 >> 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, = and >> once added this tends to be supported for a long time. Crypto = freedom >> taken to vanity extremes. >>=20 >> Downside is weakness of deprecation; weak ciphers stick around = forever. >> As algorithms are the component of choice, protocol errors tend to >> impact many algorithms. Lots of 'downgrade' possibility, lots of = user >> confusion or ignorance, waste in maintenance of too many components. >>=20 >>=20 >> 2. primary + extras. Everyone must implement the central chosen = set, >> and any others they desire. Most instances will prefer/negotiate the >> primary, only in specialised instances will the alternates be chosen. >>=20 >> Downside is that there is no clear alternate choice. >>=20 >>=20 >> 3. Primary + secondary MUSTs. As there are two MUST suites, there = is >> always a fallback, by config. >>=20 >>=20 >> 4. Odds and evens. Each version has two suites, a primary and a >> secondary, initially numbered 1 and 2. In each succeeding version, = the >> last version's primary is dropped, and secondary moves up to primary. = A >> new secondary is added (numbered 3, etc). Fallback / switchover can = be >> done by configuration and by version upgrade. >>=20 >>=20 >> 5. one true cipher suite. No config fall back available, a failure = in >> the suite triggers a requirement to upgrade the entire version. = Simpler >> to implement, no negotiation woes. >>=20 >>=20 >> 6. parallel twinned suites, where the protocol duplicates every >> component. Ciphers are CTR/XOR'd in parallel, HMACs are serialised, = etc. >>=20 >> This involves a performance hit that many would be annoyed by, and is >> sometimes considered to be "inventing your own ciphers." No = particular >> upgrade path but not particularly vulnerable to any component = weakness. >>=20 >>=20 >>=20 >>=20 >>=20 >> I'm sure there are more. And the thoughts above are very scrappy, by = no >> means suitable for a draft. But maybe a useful approach? >>=20 >> iang >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Apr 11 03:41:20 2015 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 CFA0C1ACE35 for ; Sat, 11 Apr 2015 03:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66d2Pe5SOuIN for ; Sat, 11 Apr 2015 03:41:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A59A1ACE34 for ; Sat, 11 Apr 2015 03:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1428748874; x=1460284874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1UdSE6/KuGv5LM5MU7yCb6XuBDmAsmyeiYGghE6weL8=; b=hPd4NHK2B8BKF0T9jjL5Q5CqXxXsgdH5mEpjUOicT5r4Ncz8HktpE0YT Pd1h0kPKzO1m53KpRToD1uGNvtmlGmKMHmb5SHRd5tHyLUHzBVwsHpx9V 9QHdUbYqmiDEKn6RENDNM6/6crQZdHAqKcNxzTuJwbSAXK1jxO40IyWzM I=; X-IronPort-AV: E=Sophos;i="5.11,561,1422874800"; d="scan'208";a="319968627" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Apr 2015 22:41:11 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sat, 11 Apr 2015 22:41:10 +1200 From: Peter Gutmann To: Russ Housley , ianG Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AQHQc9TMi1Ntop+3akuJXb4mFhIuSJ1Hn7w2 Date: Sat, 11 Apr 2015 10:41:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org>, <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> In-Reply-To: <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Sat, 11 Apr 2015 10:41:19 -0000 Russ Housley =FD writes:=0A= =0A= > All implementors are expected to support the mandatory-to-implement=0A= > cryptographic algorithm,=0A= >[...]=0A= > The mandatory-to-implement algorithms are chosen=0A= > to be highly secure, following the guidance in RFC 1984 [RFC1984].=0A= > Generally, the mandatory-to-implement algorithms ought to be=0A= > preferred, and the other algorithms ought to be selected only in=0A= > special situations.=0A= =0A= Hmm, is this meant to be a sort of abstract best-practice thing, or a recor= d=0A= of what actually happens? I'm thinking of X9.42 DH and DSA in CMS, where t= he=0A= MUST MTI's were really a SHOULD NOT (X9.42) and, at best, MAY (DSA) while t= he=0A= MAY (RSA) was actually a MUST.=0A= =0A= > However, the=0A= > only way to respond to news that the one true algorithm has been=0A= > broken is to update the protocol specification to the next version,=0A= > implement the new specification, and then get it deployed.=0A= > Experience with the transition from SHA-1 to SHA-256 indicates that=0A= > this cycle takes more than five years.=0A= =0A= That implies that there's another option, that not going with 1TCS avoids= =0A= these problems, when in fact pretty much all existing implementations don't= go=0A= with 1TCS and yet still have the problems ascribed to 1TCS above. So I'm n= ot=0A= sure if the above text is an accurate characterisation of the situation,=0A= you're damned if you do and damned if you don't, but more damned if you don= 't=0A= do 1TCS.=0A= =0A= Peter.= From nobody Sun Apr 12 12:46:56 2015 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 BF0121B384E for ; Sun, 12 Apr 2015 12:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] 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 jlPrWvJQKe6O for ; Sun, 12 Apr 2015 12:46:53 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 806D61A1B8D for ; Sun, 12 Apr 2015 12:46:53 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E6557F240E9; Sun, 12 Apr 2015 15:46:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id qZVgKhamcwDg; Sun, 12 Apr 2015 15:46:22 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2542BF240AD; Sun, 12 Apr 2015 15:46:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <1A2C2E58-1724-4B13-8BD6-F316B60398F2@shinkuro.com> Date: Sun, 12 Apr 2015 15:46:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <1A2C2E58-1724-4B13-8BD6-F316B60398F2@shinkuro.com> To: Steve Crocker X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Sun, 12 Apr 2015 19:46:54 -0000 Steve: > RFC 6975, =93Signaling Cryptographic Algorithm Understanding in DNS = Security Extensions (DNSSEC)=93 speaks to the issue of when servers can = stop supporting older algorithms. It=92s intended to facilitate = withdrawing algorithms from the suite when there has been sufficient = uptake of replacement algorithms. Perhaps it would be appropriate to = include a reference to this RFC and to include some discussion about how = to withdraw algorithms when their time has come. I'll take a look. > Also, I believe you want =93led=94 instead of =93lead=94. Thanks. Fixed. Russ From nobody Sun Apr 12 13:13:18 2015 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 C79401A8787 for ; Sun, 12 Apr 2015 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] 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 GZSfEAKjd-Bo for ; Sun, 12 Apr 2015 13:13:15 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 302FB1A8769 for ; Sun, 12 Apr 2015 13:13:15 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id C04E69A4016; Sun, 12 Apr 2015 16:13:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id nR7ivFIvmO3k; Sun, 12 Apr 2015 16:12:43 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7D77E9A4015; Sun, 12 Apr 2015 16:12:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 12 Apr 2015 16:12:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org>, <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Sun, 12 Apr 2015 20:13:16 -0000 Peter: >> All implementors are expected to support the mandatory-to-implement >> cryptographic algorithm, >> [...] >> The mandatory-to-implement algorithms are chosen >> to be highly secure, following the guidance in RFC 1984 [RFC1984]. >> Generally, the mandatory-to-implement algorithms ought to be >> preferred, and the other algorithms ought to be selected only in >> special situations. >=20 > Hmm, is this meant to be a sort of abstract best-practice thing, or a = record > of what actually happens? I'm thinking of X9.42 DH and DSA in CMS, = where the > MUST MTI's were really a SHOULD NOT (X9.42) and, at best, MAY (DSA) = while the > MAY (RSA) was actually a MUST. CMS does not have any MTI algorithms. Rather, the applications that = make use of CMS specify the MTI algorithms for that application, so I = assume your comments are about the MTI algorithms for S/MIME before the = RSA patent expired. There was a lot of reluctance to make RSA the MUST = implement algorithm before its patent expired. >> However, the >> only way to respond to news that the one true algorithm has been >> broken is to update the protocol specification to the next version, >> implement the new specification, and then get it deployed. >> Experience with the transition from SHA-1 to SHA-256 indicates that >> this cycle takes more than five years. >=20 > That implies that there's another option, that not going with 1TCS = avoids > these problems, when in fact pretty much all existing implementations = don't go > with 1TCS and yet still have the problems ascribed to 1TCS above. So = I'm not > sure if the above text is an accurate characterisation of the = situation, > you're damned if you do and damned if you don't, but more damned if = you don't > do 1TCS. I think there are many things going on that lead to your observation, = and I am trying to tease them apart and discuss them separately. First, when there is more than one MTI algorithm, there needs to be = adequate diversity, otherwise a cryptoanalytic advance that weakens one = will also weaken the other. I added some text on diversity: In some cases, more than one mandatory-to-implement cryptographic algorithm has been specified. The is intended to ensure that a secure cryptographic algorithm will be available, even if one of the mandatory-to-implement algorithms is broken. To achieve this goal, the selected algorithms must be diverse, so that a cryptoanalytic advance against one of the algorithms does not also impact the other selected algorithms. The idea is to have an implemented and deployed algorithm as a fallback. However, the additional algorithm choices adds to the difficult decision for a skilled system administer to determine the proper configuration to achieve their preferences. Second, some attacks are against the manner in which the MTI algorithm = is used, not the algorithm itself. I have some text in the security = considerations on that: In some cases, the cryptographic algorithm remains strong, but an attack is found against the way that the strong algorithm is used in a particular protocol. In these cases, a protocol change will probably be needed. For example, the order of cryptographic operations in the TLS protocol has evolved as various attacks have been discovered. Originally, TLS performed encryption prior to computation of the message authentication code (MAC). This order of operations is called encrypt-then-MAC, and it is no longer considered secure [BN][K]. As a result, a mechanism was specified to use MAC- then-encrypt instead [RFC7366]. Future versions of TLS are expected to use exclusively authenticated encryption algorithms [RFC5166], which should resolve the ordering discussion altogether. After discovery of such attacks, updating the cryptographic algorithms is not likely to be sufficient to thwart the new attack. It may necessary to make significant changes to the protocol. Are there any other aspects? Russ= From nobody Mon Apr 13 02:21:55 2015 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 85CC81B3045 for ; Mon, 13 Apr 2015 02:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVUzcaRL2UOU for ; Mon, 13 Apr 2015 02:21:50 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC9E1B3024 for ; Mon, 13 Apr 2015 02:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1428916911; x=1460452911; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=pHf6FvbXP7UXs5SBNkn0lmK7PWAAaaPv2gb3/pkqRvQ=; b=SeOkVuoB22rqeXXjoELK3dyJioZSMnkwQv/W2EY124wymBcQpvpiM0hp AWiVuXy52p3hZFzei8oN+z7Je5WzoYTlSwhAG/1fKNT8udPumGrYD2TsL +/jAtozezHoQpjOK9rvYxC3kYuqzaTZZxAJpsuhC//pAmdVt2crlWZFud I=; X-IronPort-AV: E=Sophos;i="5.11,568,1422874800"; d="scan'208";a="320268951" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Apr 2015 21:21:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Mon, 13 Apr 2015 21:21:47 +1200 From: Peter Gutmann To: Russ Housley Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB1y0PAB6Mgp4lzS6KYdWqZc0TQxw== Date: Mon, 13 Apr 2015 09:21:46 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFED509@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 09:21:54 -0000 Russ Housley writes:=0A= =0A= >CMS does not have any MTI algorithms.=0A= =0A= Ah, sure, I was meaning S/MIME. My issue was more with algorithms specifie= d=0A= for political reasons (and not just the obvious RSA-patent issue, I chose t= hat=0A= because it was a long time ago and I doubt anyone cares any more, but more= =0A= recently stuff like the NIST curves vs. 25519 et al, where the NIST curves= =0A= seem to have been chosen purely because they came from NIST), in which case= =0A= the MTIs aren't always the best to use.=0A= =0A= (Admittedly that does make it a bit difficult to be precise over what to do= =0A= when the MTI isn't necessarily the best-TI).=0A= =0A= >First, when there is more than one MTI algorithm, there needs to be adequa= te=0A= >diversity, otherwise a cryptoanalytic advance that weakens one will also= =0A= >weaken the other. I added some text on diversity:=0A= =0A= Sounds good.=0A= =0A= (In particular the current obsession with ECC for everything makes me, and = a=0A= few other crypto engineers I've talked to at various points, rather nervous= ).=0A= =0A= >Are there any other aspects?=0A= =0A= Nope, I think that's it.=0A= =0A= Peter.=0A= From nobody Mon Apr 13 08:11:48 2015 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 738881AC439 for ; Mon, 13 Apr 2015 08:11:41 -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_40=-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 f1FBMTCZptjG for ; Mon, 13 Apr 2015 08:11:39 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161071ACD10 for ; Mon, 13 Apr 2015 08:11:39 -0700 (PDT) Received: from Agent86.local (host-2-99-64-116.as13285.net [2.99.64.116]) by virulha.pair.com (Postfix) with ESMTPSA id B886F6D70D; Mon, 13 Apr 2015 11:11:37 -0400 (EDT) Message-ID: <552BDCA8.5090003@iang.org> Date: Mon, 13 Apr 2015 16:11:36 +0100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , Russ Housley References: <9A043F3CF02CD34C8E74AC1594475C73AAFED509@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFED509@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 15:11:41 -0000 On 13/04/2015 10:21, Peter Gutmann wrote: > (In particular the current obsession with ECC for everything makes me, and a > few other crypto engineers I've talked to at various points, rather nervous). Concur - if there is a reason for multiple public key algorithms it is that EC makes me nervous and I'd be almost happy to see RSA alongside EC. However, EC doesn't make me nervous enough to insist on keeping RSA. I think if cryptographers have been bashing at EC for a decade now, and haven't found a weakness, that's good enough. The benefits of just one EC algorithm for all overwhelm any FUDish nervousness about that rarest of beasts, cryptographic advances. iang From nobody Mon Apr 13 08:43:10 2015 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 91BD71ACDC1 for ; Mon, 13 Apr 2015 08:43:08 -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 ISJXKAF2C1P4 for ; Mon, 13 Apr 2015 08:43:06 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3371ACD9C for ; Mon, 13 Apr 2015 08:43:06 -0700 (PDT) Received: by wgin8 with SMTP id n8so85633280wgi.0 for ; Mon, 13 Apr 2015 08:43:05 -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:content-transfer-encoding; bh=m5rUKU9DpzBrSHueJgtbvcM9SxqUOI92LpkgwWUFDu4=; b=QV6eJgSJDI8PLyxxhIO0PIh6nQoeXKiNudvJllGMqjwi7knEOlOdmuQowq4aFp3TQd 4rw0zUMP4wxrztoReZGDXxnWbcdvpBmQadly37cn5P1xSvhV4kpUrW179c0VszeLsHSd 1lCu+BRL0NLlJ+Yt7IbxRnmQZ/D2WmNJzZxjoSNOJAFF25XW4SGlJufmFq5u0nCjdPlZ 5NqgsJ8XUH+/KbvUiHSVrxygiFDFMp89AAU860PJlwSj2x2AKV992h5YpZJfdsqKNtRx eE49VcXLsRZ6LOpw3ohVUgK9NlaI65CdlZ1Tc4AFCyvYj1TKEJk/lMO3s36YsNjQJkuF MZTg== MIME-Version: 1.0 X-Received: by 10.180.82.97 with SMTP id h1mr9622366wiy.26.1428939785017; Mon, 13 Apr 2015 08:43:05 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Mon, 13 Apr 2015 08:43:04 -0700 (PDT) In-Reply-To: <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> Date: Mon, 13 Apr 2015 08:43:04 -0700 Message-ID: From: Watson Ladd To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 15:43:08 -0000 On Apr 12, 2015 3:13 PM, "Russ Housley" wrote: > > Peter: > > >> All implementors are expected to support the mandatory-to-implement > >> cryptographic algorithm, > >> [...] > >> The mandatory-to-implement algorithms are chosen > >> to be highly secure, following the guidance in RFC 1984 [RFC1984]. > >> Generally, the mandatory-to-implement algorithms ought to be > >> preferred, and the other algorithms ought to be selected only in > >> special situations. > > > > Hmm, is this meant to be a sort of abstract best-practice thing, or a r= ecord > > of what actually happens? I'm thinking of X9.42 DH and DSA in CMS, whe= re the > > MUST MTI's were really a SHOULD NOT (X9.42) and, at best, MAY (DSA) whi= le the > > MAY (RSA) was actually a MUST. > > CMS does not have any MTI algorithms. Rather, the applications that make= use of CMS specify the MTI algorithms for that application, so I assume yo= ur comments are about the MTI algorithms for S/MIME before the RSA patent e= xpired. There was a lot of reluctance to make RSA the MUST implement algor= ithm before its patent expired. > > >> However, the > >> only way to respond to news that the one true algorithm has been > >> broken is to update the protocol specification to the next version, > >> implement the new specification, and then get it deployed. > >> Experience with the transition from SHA-1 to SHA-256 indicates that > >> this cycle takes more than five years. > > > > That implies that there's another option, that not going with 1TCS avoi= ds > > these problems, when in fact pretty much all existing implementations d= on't go > > with 1TCS and yet still have the problems ascribed to 1TCS above. So I= 'm not > > sure if the above text is an accurate characterisation of the situation= , > > you're damned if you do and damned if you don't, but more damned if you= don't > > do 1TCS. > > I think there are many things going on that lead to your observation, and= I am trying to tease them apart and discuss them separately. > > First, when there is more than one MTI algorithm, there needs to be adequ= ate diversity, otherwise a cryptoanalytic advance that weakens one will als= o weaken the other. I added some text on diversity: Let's consider actual cryptanalytic weaknesses in TLS. Would adding more MTI algorithms have solved any of them? Because the fact is AES, not RC4, was MTI in TLS. > > In some cases, more than one mandatory-to-implement cryptographic > algorithm has been specified. The is intended to ensure that a > secure cryptographic algorithm will be available, even if one of the > mandatory-to-implement algorithms is broken. To achieve this goal, > the selected algorithms must be diverse, so that a cryptoanalytic > advance against one of the algorithms does not also impact the other > selected algorithms. The idea is to have an implemented and deployed > algorithm as a fallback. However, the additional algorithm choices > adds to the difficult decision for a skilled system administer to > determine the proper configuration to achieve their preferences. Why are we kicking configuration decisions to administrators? Do they know how to evaluate the impact of biases in the RC4 keystream vs. clique attacks on AES? Obviously no: RC4 wouldn't still be an issue if they did. Nor would they have kept TLS 1.0 alive for decades after vulnerabilities were found and fixed. > > Second, some attacks are against the manner in which the MTI algorithm is= used, not the algorithm itself. I have some text in the security consider= ations on that: > > In some cases, the cryptographic algorithm remains strong, but an > attack is found against the way that the strong algorithm is used in > a particular protocol. In these cases, a protocol change will > probably be needed. For example, the order of cryptographic > operations in the TLS protocol has evolved as various attacks have > been discovered. Originally, TLS performed encryption prior to > computation of the message authentication code (MAC). This order of > operations is called encrypt-then-MAC, and it is no longer considered > secure [BN][K]. As a result, a mechanism was specified to use MAC- > then-encrypt instead [RFC7366]. Future versions of TLS are expected > to use exclusively authenticated encryption algorithms [RFC5166], > which should resolve the ordering discussion altogether. After > discovery of such attacks, updating the cryptographic algorithms is > not likely to be sufficient to thwart the new attack. It may > necessary to make significant changes to the protocol. > > Are there any other aspects? Can you point to any weakness in TLS that multiple MTI algorithms would have prevented, or made the amelioration of easier? What about other protocols? That's leaving aside that removing weak algorithms, not adding strong ones, improves security. The argument for negotiation is that we can switch to strong algorithms while weak ones gradually get used less and less, and the argument for multiple MTI algorithms is that we all switch in the same direction. But this runs against having per-site policies on what to use. Sincerely, Watson Ladd > > Russ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Apr 13 09:31:12 2015 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 AF9E81ACE80 for ; Mon, 13 Apr 2015 09:31:10 -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 8YeJnIs6QUIJ for ; Mon, 13 Apr 2015 09:31:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286C61ACE53 for ; Mon, 13 Apr 2015 09:31:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C96C6283031; Mon, 13 Apr 2015 16:31:07 +0000 (UTC) Date: Mon, 13 Apr 2015 16:31:07 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150413163107.GN17637@mournblade.imrryr.org> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> 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: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 16:31:10 -0000 On Mon, Apr 13, 2015 at 08:43:04AM -0700, Watson Ladd wrote: > Can you point to any weakness in TLS that multiple MTI algorithms > would have prevented, or made the amelioration of easier? Much of this discussion misses the point about multiple algorithms in TLS. In practice their purpose is not insurance against compromise of an algorithm. Rather, as I see it, the main reason for the multitude of algorithms in TLS is that TLS is a general-purpose building block for secure data transport that is used in many diverse environments. TLS is not just a browser security mechanism. Different hardware platforms and applications using TLS have different needs. A single cipher-suite in TLS would not serve those different needs. The cost of the spectacular success of TLS as a foundation for communication security in many different environments is its diversity of features. If we were to redesign TLS anew for each application, specifying the supported cipher suite (per version) for the application-specific TLS variant in the appropriate application protocol standard, then we might begin to tease apart cases in which cipher suites are for cryptographic diversity rather than application diversity. I don't think the above is likely to happen, so I see TLS continuing to offer broad range of cryptographic primitives. Progress would be removing aging features as the protocol is revised, so that newer versions of the protocol leave weaker options behind. Each protocol version should still offer a variety of primitives to serve the various constituencies that need them. -- Viktor. From nobody Mon Apr 13 10:00:12 2015 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 C091D1A09C9 for ; Mon, 13 Apr 2015 10:00:10 -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 cwH3sykltl2X for ; Mon, 13 Apr 2015 10:00:09 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB531A07BD for ; Mon, 13 Apr 2015 10:00:08 -0700 (PDT) Received: by wgsk9 with SMTP id k9so88185884wgs.3 for ; Mon, 13 Apr 2015 10:00:07 -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=7qMsfP590gvoVtroJXfdeWHpW06VirClPZ0f5eMz5FQ=; b=BwXUqJUa0zCFzOjt+82g49RehO50BPGv0STETlcREALmddjgL+CqjP2xzTtAYw7XRM WUJdttAoQ7+EHrmx3nwjleYz04vNaX7gBIkFt19i6JCbUmYAPD/AdVxMRoxBssw7Czlm QSQtclNRD+Lx/pWSeziaDC0V7YUsfAeqSpwQPi3xQMfKqOVUynLDVryYPkj8r+gFvMj7 V+XqA5YgXDH+4D8zqgMJmv6A5CsSz7AtX94J3/f2LTaKb+vDG/KMho9ik0+0EalVhUil AXOpHDbqZBKEt0q1fgsM1kDg85u7UzGiSNKMM6LuTddDGpkQUToBtW9rBmC7M4Yz8+v5 b5ZA== X-Received: by 10.180.99.166 with SMTP id er6mr6506864wib.58.1428944407229; Mon, 13 Apr 2015 10:00:07 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ub1sm12274137wjc.43.2015.04.13.10.00.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:00:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Mon, 13 Apr 2015 20:00:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4017C24F-5AC8-4887-B7B6-A35F939C443C@gmail.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> To: Watson Ladd X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 17:00:10 -0000 > On Apr 13, 2015, at 6:43 PM, Watson Ladd = wrote: >=20 > On Apr 12, 2015 3:13 PM, "Russ Housley" wrote: >>=20 >> Peter: >>=20 >>>> All implementors are expected to support the mandatory-to-implement >>>> cryptographic algorithm, >>>> [...] >>>> The mandatory-to-implement algorithms are chosen >>>> to be highly secure, following the guidance in RFC 1984 [RFC1984]. >>>> Generally, the mandatory-to-implement algorithms ought to be >>>> preferred, and the other algorithms ought to be selected only in >>>> special situations. >>>=20 >>> Hmm, is this meant to be a sort of abstract best-practice thing, or = a record >>> of what actually happens? I'm thinking of X9.42 DH and DSA in CMS, = where the >>> MUST MTI's were really a SHOULD NOT (X9.42) and, at best, MAY (DSA) = while the >>> MAY (RSA) was actually a MUST. >>=20 >> CMS does not have any MTI algorithms. Rather, the applications that = make use of CMS specify the MTI algorithms for that application, so I = assume your comments are about the MTI algorithms for S/MIME before the = RSA patent expired. There was a lot of reluctance to make RSA the MUST = implement algorithm before its patent expired. >>=20 >>>> However, the >>>> only way to respond to news that the one true algorithm has been >>>> broken is to update the protocol specification to the next version, >>>> implement the new specification, and then get it deployed. >>>> Experience with the transition from SHA-1 to SHA-256 indicates that >>>> this cycle takes more than five years. >>>=20 >>> That implies that there's another option, that not going with 1TCS = avoids >>> these problems, when in fact pretty much all existing = implementations don't go >>> with 1TCS and yet still have the problems ascribed to 1TCS above. = So I'm not >>> sure if the above text is an accurate characterisation of the = situation, >>> you're damned if you do and damned if you don't, but more damned if = you don't >>> do 1TCS. >>=20 >> I think there are many things going on that lead to your observation, = and I am trying to tease them apart and discuss them separately. >>=20 >> First, when there is more than one MTI algorithm, there needs to be = adequate diversity, otherwise a cryptoanalytic advance that weakens one = will also weaken the other. I added some text on diversity: >=20 > Let's consider actual cryptanalytic weaknesses in TLS. Would adding > more MTI algorithms have solved any of them? Because the fact is AES, > not RC4, was MTI in TLS. It would have solved things if the cryptanalytic advances were against = AES. As it is, the fact that a non-RC4 algorithm was MTI made if far = safer to disable RC4 on servers and clients. An attack now against AES = leaves all of us scrambling to implement ChaCha while turning on 3DES. >> In some cases, more than one mandatory-to-implement cryptographic >> algorithm has been specified. The is intended to ensure that a >> secure cryptographic algorithm will be available, even if one of = the >> mandatory-to-implement algorithms is broken. To achieve this goal, >> the selected algorithms must be diverse, so that a cryptoanalytic >> advance against one of the algorithms does not also impact the = other >> selected algorithms. The idea is to have an implemented and = deployed >> algorithm as a fallback. However, the additional algorithm choices >> adds to the difficult decision for a skilled system administer to >> determine the proper configuration to achieve their preferences. >=20 > Why are we kicking configuration decisions to administrators? Do they > know how to evaluate the impact of biases in the RC4 keystream vs. > clique attacks on AES? Obviously no: RC4 wouldn't still be an issue if > they did. Nor would they have kept TLS 1.0 alive for decades after > vulnerabilities were found and fixed. They kept TLS 1.0 alive because until not too long ago most clients did = not support anything better than TLS 1.0. They made a rational choice. = Even now, there=E2=80=99s a lot of those clients around. >>=20 >> Second, some attacks are against the manner in which the MTI = algorithm is used, not the algorithm itself. I have some text in the = security considerations on that: >>=20 >> In some cases, the cryptographic algorithm remains strong, but an >> attack is found against the way that the strong algorithm is used = in >> a particular protocol. In these cases, a protocol change will >> probably be needed. For example, the order of cryptographic >> operations in the TLS protocol has evolved as various attacks have >> been discovered. Originally, TLS performed encryption prior to >> computation of the message authentication code (MAC). This order = of >> operations is called encrypt-then-MAC, and it is no longer = considered >> secure [BN][K]. As a result, a mechanism was specified to use MAC- >> then-encrypt instead [RFC7366]. Future versions of TLS are = expected >> to use exclusively authenticated encryption algorithms [RFC5166], >> which should resolve the ordering discussion altogether. After >> discovery of such attacks, updating the cryptographic algorithms is >> not likely to be sufficient to thwart the new attack. It may >> necessary to make significant changes to the protocol. >>=20 >> Are there any other aspects? >=20 > Can you point to any weakness in TLS that multiple MTI algorithms > would have prevented, or made the amelioration of easier? What about > other protocols? That's leaving aside that removing weak algorithms, > not adding strong ones, improves security. The argument for > negotiation is that we can switch to strong algorithms while weak ones > gradually get used less and less, and the argument for multiple MTI > algorithms is that we all switch in the same direction. But this runs > against having per-site policies on what to use. You can=E2=80=99t remove old, weak algorithms unless everyone has = implemented acceptable ones. If we had some kind of counter mode MTI = algorithm years ago, the impact of attacks against CBC like BEAST would = have been much less. Yoav From nobody Mon Apr 13 10:04:05 2015 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 EC82A1A1AB9 for ; Mon, 13 Apr 2015 10:04:03 -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_05=-0.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 RXOJqltCtXW0 for ; Mon, 13 Apr 2015 10:04:02 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022D11A1A1C for ; Mon, 13 Apr 2015 10:04:02 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A87E56D776; Mon, 13 Apr 2015 13:03:57 -0400 (EDT) Message-ID: <552BF6FC.5050002@iang.org> Date: Mon, 13 Apr 2015 18:03:56 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> <20150413163107.GN17637@mournblade.imrryr.org> In-Reply-To: <20150413163107.GN17637@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 17:04:04 -0000 On 13/04/2015 17:31 pm, Viktor Dukhovni wrote: > On Mon, Apr 13, 2015 at 08:43:04AM -0700, Watson Ladd wrote: > >> Can you point to any weakness in TLS that multiple MTI algorithms >> would have prevented, or made the amelioration of easier? > > Much of this discussion misses the point about multiple algorithms > in TLS. In practice their purpose is not insurance against compromise > of an algorithm. I don't believe that "reason" is met in practice, so I concur that there has to be another motive. > Rather, as I see it, the main reason for the multitude of algorithms > in TLS is that TLS is a general-purpose building block for secure > data transport that is used in many diverse environments. > > TLS is not just a browser security mechanism. Different hardware > platforms and applications using TLS have different needs. > > A single cipher-suite in TLS would not serve those different needs. Can you give a for-instance of these features that relate to the choice of algorithms? Are there significant usages out there that would not be served by, say, hypothetically, tls1.4 using a single 25519 + chacha/poly combination? > The cost of the spectacular success of TLS as a foundation for > communication security in many different environments is its > diversity of features. It may be just me, but I can't think of a feature that both exists in algorithm diversity and should be trusted to users to choose. Examples? I agree that historically, there was the 'export' feature. But I argue that this was not something we should be pandering too. We should be working for a reasonable security level for all users, not just some users we're told we're allowed to work with. > If we were to redesign TLS anew for each application, specifying > the supported cipher suite (per version) for the application-specific > TLS variant in the appropriate application protocol standard, then > we might begin to tease apart cases in which cipher suites are for > cryptographic diversity rather than application diversity. > > I don't think the above is likely to happen, so I see TLS continuing > to offer broad range of cryptographic primitives. > > Progress would be removing aging features as the protocol is revised, > so that newer versions of the protocol leave weaker options behind. > Each protocol version should still offer a variety of primitives > to serve the various constituencies that need them. iang ps; TLS represents a really good slice of history. If we can show it for TLS, that's something. If we can't show it for TLS, that's ... the converse of something. From nobody Mon Apr 13 10:21:42 2015 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 DF54C1ACEF3 for ; Mon, 13 Apr 2015 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=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 HyxXCWW943uT for ; Mon, 13 Apr 2015 10:21:39 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B672C1AD068 for ; Mon, 13 Apr 2015 10:20:12 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 967056D77E; Mon, 13 Apr 2015 13:20:11 -0400 (EDT) Message-ID: <552BFACA.4020404@iang.org> Date: Mon, 13 Apr 2015 18:20:10 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Russ Housley References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> In-Reply-To: <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 17:21:41 -0000 Some comments! On 10/04/2015 22:24 pm, Russ Housley wrote: > I am working on -03 of the crypto-alg-agility document, and I went back to your message as part of that work. > > I have tried to put together some words that show that both extremes can be problematic. I hope that you and the others on this list will review and comment. > > Russ > > = = = = = = = > > 4. Cryptographic Algorithm Specifications What seems to be missing in this section is the subsection: 4.x A few choices can be harmful The anti-factors in considering a few choices are: * does not cover protocol bugs * opens up downgrade bugs and complexity bugs * allows hair splitting between 2 and 3 choices * permits individual communities to add new choices * still does not cover the process of switching * has not delivered any historical advantage I'm sure there are more... > 4.1. Too Many Choices Can Be Harmful > > When it is too easy to specify the use of arbitrary cryptographic > algorithms, the algorithms get implemented and deployed. Some people > say that the freedom to specify algorithms independently from the > rest of the protocol has lead to the specifications of vanity > cryptographic algorithms. Once deployed, it is quite difficult to > remove algorithms because interoperability with some party will be > impacted. As a result, weak ciphers stick around far too long. > Sometimes implementors are forced to maintain cryptographic > algorithm implementation well beyond their useful lifetime. This is a bit of a jump. Perhaps insert: In order to manage the proliferation of choices, and the consequent explosion of negotiation possibilities leading to failure to agree and insecurity from downgrade attacks, many protocols have implemented mandatory-to-implement algorithms. ... > All implementors are expected to support the mandatory-to-implement > cryptographic algorithm, and they can include any others algorithms > that they desire. The mandatory-to-implement algorithms are chosen > to be highly secure, following the guidance in RFC 1984 [RFC1984]. > Generally, the mandatory-to-implement algorithms ought to be > preferred, and the other algorithms ought to be selected only in > special situations. However, it can be very difficult for a skilled > system administer to determine the proper configuration to achieve > these preferences. > > In some cases, more than one mandatory-to-implement cryptographic > algorithm has been specified. The is intended to ensure that a > secure cryptographic algorithm will be available, even if one of the > mandatory-to-implement algorithms is broken. There is always a > fallback. However, this adds to the difficult decision for a skilled > system administer to determine the proper configuration to achieve > their preferences. And, the manner or protocol in which system administrators are advised to switch is at best ad hoc, and at worst absent entirely. > 4.2. Picking One True Cipher Suite Can Be Harmful I think, if you want to stick to that title, you might want to find some examples of actual harm ;) For example, there were the various WIFI and mobile phone adventures, but I'd argue there that they chose them to be weak in the first place, so I argue that doesn't count. > After great study and evaluation, the protocol designer could select > the one true cipher suite. This has at least two desirable > consequences. First, the protocol is simpler since there is no need > for algorithm negotiation. Second, system administrators do not need > to make any algorithm-related configuration decisions. However, the > only way to respond to news that the one true algorithm has been > broken is to update the protocol specification to the next version, > implement the new specification, and then get it deployed. So, in practice, when an algorithm had to be changed, how was that deployed? My understanding of all the TLS breaks was that in practice, most people upgraded their software to the next release... thus amounting to the same thing. > Experience with the transition from SHA-1 to SHA-256 indicates that > this cycle takes more than five years. That's pretty thin. In practice, the reason was that the various parties basically didn't bother to start the work when they got the chance. SHA-256 was issued a long time ago and basically everyone ignored the implied deprecation message. They even pretty much dawdled after the 2004 Shandong results. So, applied to the above, the deprecation process that is natural for this business applies to all of the above 3 choices, and a rather perverse advantage of the 1TCS approach is that it perhaps removes the fig leaf of algorithm agility from the process: people actually ought to be prepared with a new protocol, and not hide behind the notion that they can simply swap algorithms if there are any problems. iang > On Jul 4, 2014, at 3:21 PM, ianG wrote: > >> I wonder if it is is possible to list the potential strategies for alg >> agility? And perhaps add their pros&cons? Here's a strawman list of >> possibilities, with full intent to be rewritten entirely, just in case >> this helps: >> >> >> >> 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, and >> once added this tends to be supported for a long time. Crypto freedom >> taken to vanity extremes. >> >> Downside is weakness of deprecation; weak ciphers stick around forever. >> As algorithms are the component of choice, protocol errors tend to >> impact many algorithms. Lots of 'downgrade' possibility, lots of user >> confusion or ignorance, waste in maintenance of too many components. >> >> >> 2. primary + extras. Everyone must implement the central chosen set, >> and any others they desire. Most instances will prefer/negotiate the >> primary, only in specialised instances will the alternates be chosen. >> >> Downside is that there is no clear alternate choice. >> >> >> 3. Primary + secondary MUSTs. As there are two MUST suites, there is >> always a fallback, by config. >> >> >> 4. Odds and evens. Each version has two suites, a primary and a >> secondary, initially numbered 1 and 2. In each succeeding version, the >> last version's primary is dropped, and secondary moves up to primary. A >> new secondary is added (numbered 3, etc). Fallback / switchover can be >> done by configuration and by version upgrade. >> >> >> 5. one true cipher suite. No config fall back available, a failure in >> the suite triggers a requirement to upgrade the entire version. Simpler >> to implement, no negotiation woes. >> >> >> 6. parallel twinned suites, where the protocol duplicates every >> component. Ciphers are CTR/XOR'd in parallel, HMACs are serialised, etc. >> >> This involves a performance hit that many would be annoyed by, and is >> sometimes considered to be "inventing your own ciphers." No particular >> upgrade path but not particularly vulnerable to any component weakness. >> >> >> >> >> >> I'm sure there are more. And the thoughts above are very scrappy, by no >> means suitable for a draft. But maybe a useful approach? >> >> iang >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > From nobody Mon Apr 13 10:32:24 2015 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 AE53A1ACF56 for ; Mon, 13 Apr 2015 10:32:22 -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 h0KIfS3SpR8o for ; Mon, 13 Apr 2015 10:32:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C231AD05E for ; Mon, 13 Apr 2015 10:32:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9396A283031; Mon, 13 Apr 2015 17:32:13 +0000 (UTC) Date: Mon, 13 Apr 2015 17:32:13 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150413173213.GR17637@mournblade.imrryr.org> References: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> <20150413163107.GN17637@mournblade.imrryr.org> <552BF6FC.5050002@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552BF6FC.5050002@iang.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 17:32:22 -0000 On Mon, Apr 13, 2015 at 06:03:56PM +0100, ianG wrote: > >TLS is not just a browser security mechanism. Different hardware > >platforms and applications using TLS have different needs. > > Can you give a for-instance of these features that relate to the choice of > algorithms? * Not all systems have hardware AES support. Constant-time software AES is noticeably slower than RC4, thus the historical popularity of RC4. * Not all systems support ECC, but some applications need more compact signatures or higher signing throughput (even if verification is slower than with RSA). * There will be many platforms with fast hardware AES, and others where ChaCha20 in software is more performant. Some folks in .ru will likely want code points for TLS with GOST. (I on the other hand generally disable the GOST engine in OpenSSL as a matter of attack surface mitigation). * Reportedly, many constrained devices implement minimal TLS features with PSK. * Postfix prefers anonymous key agreement when doing opportunistic TLS. Some folks use anon-DH with channel binding to SASL auth. > Are there significant usages out there that would not be served by, say, > hypothetically, tls1.4 using a single 25519 + chacha/poly combination? Hard to say how well that will fit all the use cases, the history of TLS is there was no one-size-fits-all combination. Have we found one yet? Intel's server chips have hardware AES, but not hardware ChaCha20, server operators might not want to sacrifice the performance. Perhaps we're much better at balanced universally applicable secure algorithms now, but I don't know that we're quite there yet. -- Viktor. From nobody Mon Apr 13 11:10:37 2015 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 E9DE41B29CC for ; Mon, 13 Apr 2015 11:10:34 -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 ZDomDRMLGyPe for ; Mon, 13 Apr 2015 11:10:33 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754FA1B29C7 for ; Mon, 13 Apr 2015 11:10:33 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t3DI99VQ011923; Mon, 13 Apr 2015 11:10:32 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0a-0016f401.pphosted.com with ESMTP id 1tpw03wuwd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2015 11:10:32 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([::1]) with mapi; Mon, 13 Apr 2015 11:10:32 -0700 From: Paul Lambert To: Russ Housley , IETF SAAG Date: Mon, 13 Apr 2015 11:10:30 -0700 Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB2FSEs0/5RNp0bQV2zAoBZsCcusQ== Message-ID: References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 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.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_04:2015-04-10,2015-04-13,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-1504130154 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Mon, 13 Apr 2015 18:10:35 -0000 In documenting the requirements for identifying and selecting cryptographic algorithms we should also consider that not having interoperability may be a valuable service for a security protocol. Different domains of communication may be established by mandating the use of different cryptographic algorithms. The need for a protocol to support a =8Cdiversity=B9 of algorithms for community separation is a different use case than =8Cagility=B9 to negotiat= e interoperability. Cryptographic agility assumes that all devices interoperate and that weaker algorithms are replaced over time by better algorithms. Cryptographic diversity allows some communities to select a cryptographic algorithm suite of their own choice for separation of traffic and perceived security benefits of the suite. Diversity implies that variations in exposed identifiers may be sensitive. The easy identification of a unique algorithm identifier readily identifies a particular traffic flow and its mapping to the community using the algorithm suite.=20 The current draft text mandates that a protocol =8CMUST carry=B9 an identif= ier. 2.1. Algorithm Identifiers IETF protocols that make use of cryptographic algorithms MUST carry one or more algorithm identifier. Since this use of an identifier is usually part of the setup of a secure communication flow, the unique identifier is carried in the clear and leaks knowledge to an observer of the accepted algorithms for agility. This is very useful information to profile the communications. Security protocols should be allowed to minimize such profiling. Paul On 6/27/14, 11:47 AM, "Russ Housley" wrote: >Thanks for the lively discussion of the -00 version of this document. >Please review and comment on the updated version. > >Russ > > > >> A new version of I-D, draft-iab-crypto-alg-agility-01.txt >> has been successfully submitted by Russell Housley and posted to the >> IETF repository. >>=20 >> Name: draft-iab-crypto-alg-agility >> Revision: 01 >> Title: Guidelines for Cryptographic Algorithm Agility >> Document date: 2014-06-27 >> Group: iab >> Pages: 8 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-01.txt >> Status: =20 >>https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/ >> Htmlized: =20 >>http://tools.ietf.org/html/draft-iab-crypto-alg-agility-01 >> Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-iab-crypto-alg-agility-01 >>=20 >> Abstract: >> Many IETF protocols may use of cryptographic algorithms to provide >> confidentiality, integrity, or non-repudiation. Communicating peers >> must support the same cryptographic algorithm or algorithms for these >> mechanisms to work properly. This memo provides guidelines for >> ensuring that such a protocol has the ability to migrate from one >> algorithm to another over time. > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Tue Apr 14 06:16:23 2015 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 C0C361A9107 for ; Tue, 14 Apr 2015 06:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao1xcUu6K0XD for ; Tue, 14 Apr 2015 06:16:18 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF761A90ED for ; Tue, 14 Apr 2015 06:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429017378; x=1460553378; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2MExdnCGp4evrsoSUnVWRSiTM+9+h3LCUuVQNhl/DAw=; b=HOlt3YVOXDXbfbG5g4MRnVmPS27M0OnXxy6JeBtPJLCSzCC42/diQO8q 72bveRFsVF4oH1jVhj83dkFRnkRzBM5EzEKYSkRNgef54m6YAr/Inh2BG xkDjtkw9yp+J2oiC3kHcqRnrooEmI/KrfaHfoGgqvgVmgV5/VzrO+V1zC 0=; X-IronPort-AV: E=Sophos;i="5.11,576,1422874800"; d="scan'208";a="320502896" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Apr 2015 01:16:16 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 15 Apr 2015 01:16:15 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB2tS9VJkPX4IPTTH6EMHB5neoMTg== Date: Tue, 14 Apr 2015 13:16:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 13:16:21 -0000 Viktor Dukhovni writes:=0A= =0A= >Much of this discussion misses the point about multiple algorithms in TLS.= =0A= >In practice their purpose is not insurance against compromise of an=0A= >algorithm.=0A= >=0A= >Rather, as I see it, the main reason for the multitude of algorithms in TL= S=0A= >is that TLS is a general-purpose building block for secure data transport= =0A= >that is used in many diverse environments.=0A= =0A= I doubt it's even that, I'd say most of the algorithms were added "because = we=0A= can". Looking at some of the stuff in there, IDEA, RC2, DH-DSS/DH-RSA,=0A= Kerberos, Camellia, SEED, on and on, I mean does anyone really need, or eve= n=0A= want, the likes of TLS_DH_DSS_WITH_AES_256_GCM_SHA384,=0A= TLS_RSA_PSK_WITH_NULL_SHA384, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,=0A= TLS_ECDH_anon_WITH_NULL_SHA (these are all within the last few years or so,= so=0A= no excuse about being present for historical purposes)? Is there any=0A= extension-to-TLS RFC that limits itself to only two or three new suites (th= e=0A= SCSV draft doesn't count)? Everyone just shovels in every combination they= =0A= can think of, because whoever dies with the most cipher suites wins.=0A= =0A= >A single cipher-suite in TLS would not serve those different needs.=0A= =0A= Two or three would cover most situations. We certainly don't need the thre= e=0A= hundred and twenty-nine (!!) suites we currently have defined. Looking at= =0A= Firefox (which I happen to have open at the moment), it negotiates exactly= =0A= eleven suites, and of those half are ECDHE-something ones. Not three hundr= ed,=0A= just eleven.=0A= =0A= (How many TLS implementations are there in existence? 20? 30? There coul= d=0A= well be an order of magnitude more cipher suites than there are TLS=0A= implementations).=0A= =0A= Peter.= From nobody Tue Apr 14 06:43:23 2015 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 02A0A1A9172 for ; Tue, 14 Apr 2015 06:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DGOFvGWAfgY for ; Tue, 14 Apr 2015 06:43:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAD31A9171 for ; Tue, 14 Apr 2015 06:43:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0DB4BEF7; Tue, 14 Apr 2015 14:43:16 +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 njwAjm3bSX6e; Tue, 14 Apr 2015 14:43:16 +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 BEF29BEF3; Tue, 14 Apr 2015 14:43:16 +0100 (IST) Message-ID: <552D1974.9060703@cs.tcd.ie> Date: Tue, 14 Apr 2015 14:43:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , "saag@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 13:43:21 -0000 While I don't agree with all of what Peter said, I do like this bit... On 14/04/15 14:16, Peter Gutmann wrote: > Two or three would cover most situations. We certainly don't need the three > hundred and twenty-nine (!!) suites we currently have defined. Looking at > Firefox (which I happen to have open at the moment), it negotiates exactly > eleven suites, and of those half are ECDHE-something ones. Not three hundred, > just eleven. 300+ TLS ciphersuites is plain dumb though I think I've said that before:-) I hope Russ' draft ends up saying something equivalent. My gut says that Eleven is still too many, even if it's way better than today. I once suggested we'd be fine with a 2 bit ciphersuite field in TLS: 00 meaning current, 01 meaning backup, 10 meaning proprietary (*) and 11 being reserved, just in case. While I would like that, it's probably not possible, given the issues with AES h/w vs. chacha (performance) and with AES GCM vs CCM (work with deployed h/w). I see no reason why TLS1.3 (say) couldn't just pick one best option and a backup for all of ecdh, hash, prf etc (call 'em thing#1 and thing#2). So that'd mean we'd end up with only 2 x 3 = 6 real ciphersuites and then a code point for "proprietary" (for the GOSTs etc of the world which won't go away), so 7 in total. I'd argue we could just deprecate all the rest if we got agreement on that. And we could also agree (in Russ' document) that we only add new ones when we also kick out some old ones. And all that can be done easily enough with e.g. a separate IANA registry for the current preferred cipherssuites which has as a rule that it must always be of size 7 or something. So maybe an interesting question to ask for TLS and other protocols is: "how small is the minimum set of ciphersuites (or equivalent) that meet current real use cases." I'd say Russ' document could have a useful section on such an analysis maybe using some of the above. And I think that that might also apply to other protocols as well as TLS almost without changes. Cheers, S. (*) There are real national alg requirements for some protocols. But if you receive a packet that uses one of those, in almost all cases you (even Rich:-) only support a handful of such national algs, so you could just try them all until one works or all have failed. That would mean national or vanity ciphers no longer even need to get code points, removing a piece of tricky politics from the IETF entirely - whee hee:-) From nobody Tue Apr 14 07:23:51 2015 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 CCF411ABD3A for ; Tue, 14 Apr 2015 07:23:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 Y6ADhmryltMp for ; Tue, 14 Apr 2015 07:23:49 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2295D1AC39C for ; Tue, 14 Apr 2015 07:23:42 -0700 (PDT) Received: by wgyo15 with SMTP id o15so13923071wgy.2 for ; Tue, 14 Apr 2015 07:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=NesqQj9kHEAiqvHMDqTffvNn6CLijSmnlzF85KL7eDs=; b=xgIcPFT73wIkz8ZwQVsBb3t1UA35WSRfiSrABZWIyQdcyLjnbsKWZsCgSZFoxhuchZ fghjc/N7qDJ3mMmib4afPZZuTGRavnGnXoB6kPVNUwEefByT+9Wsu7KjtviE1DA8OqWG kZaiDZwTpfT8wjBoIYVAdyD7ICfjDOHN7inzW2QRHQIH6N4S9JqP0D0EClC/zlEEaAAd ddsunrZBdVxuixWzChf64nG8rdsBDDCRgws02vScFlXouLDAaAv8nNvROruW9tUXrQ/R ThrWKJGA9uz8aKuKW7/uSEEOZMAnr6Tw8xywgZ5Fu1xdMJRmfABSCaYaaLeBGzCkfC0Q T8tQ== X-Received: by 10.180.80.199 with SMTP id t7mr33760974wix.52.1429021420898; Tue, 14 Apr 2015 07:23:40 -0700 (PDT) Received: from aspire.lan (77.49.61.125.dsl.dyn.forthnet.gr. [77.49.61.125]) by mx.google.com with ESMTPSA id w5sm3031198wiz.11.2015.04.14.07.23.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 07:23:39 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <1429021416.11984.14.camel@gnutls.org> From: Nikos Mavrogiannopoulos To: Stephen Farrell Date: Tue, 14 Apr 2015 17:23:36 +0300 In-Reply-To: <552D1974.9060703@cs.tcd.ie> References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 14:23:51 -0000 On Tue, 2015-04-14 at 14:43 +0100, Stephen Farrell wrote: > On 14/04/15 14:16, Peter Gutmann wrote: > > Two or three would cover most situations. We certainly don't need the three > > hundred and twenty-nine (!!) suites we currently have defined. Looking at > > Firefox (which I happen to have open at the moment), it negotiates exactly > > eleven suites, and of those half are ECDHE-something ones. Not three hundred, > > just eleven. > > 300+ TLS ciphersuites is plain dumb though I think I've said > that before:-) I hope Russ' draft ends up saying something > equivalent. I think that this number most indicates two issues. (1) TLS requires a different ciphersuite based on the server's certificate type, so we have 4 ciphersuites for AES-128-CBC-SHA1 to handle DSA, RSA, ECDSA, static DH certificates. (2) For some reason TLS was dragging the never deployed static DH key exchange further increasing the number of potential (but not really used) ciphersuites. > My gut says that Eleven is still too many, even if it's way > better than today. > I once suggested we'd be fine with a 2 bit ciphersuite field > in TLS: 00 meaning current, 01 meaning backup, 10 meaning > proprietary (*) and 11 being reserved, just in case. While I would > like that, it's probably not possible, given the issues with > AES h/w vs. chacha (performance) and with AES GCM vs CCM (work > with deployed h/w). I see no reason why TLS1.3 (say) couldn't > just pick one best option and a backup for all of ecdh, hash, What would that buy? Would the protocol be simpler? Yes. Well it be applicable to more than the use cases the initial author thought? No. We had AES-GCM defined in TLS few years ago. It is a very modern AEAD ciphersuite, heavily optimized in high end CPUs and according to the TLS WG it would have been the only ciphersuite needed. For small systems AES-GCM was ignored and new ciphersuites were defined based on AES-CCM. Chacha was also also defined to reduce CPU and memory usage on high end servers. So what would have been the advantage if TLS had decided to mandate AES-GCM only? It would have been more CPU and memory spent in servers, and more expensive hardware for embedded systems, or we would have a bunch of TLS-like protocols for each use case defined by the entities that now propose new ciphersuites. So, there are clear advantages of having an agile TLS protocol. regards, Nikos From nobody Tue Apr 14 07:41:24 2015 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 6C7511ACAD4 for ; Tue, 14 Apr 2015 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG-YkoD3gAXA for ; Tue, 14 Apr 2015 07:41:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D406C1A802E for ; Tue, 14 Apr 2015 07:41:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3E044BEEB; Tue, 14 Apr 2015 15:41:20 +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 xqRb-RMTWG6P; Tue, 14 Apr 2015 15:41:20 +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 03B80BE98; Tue, 14 Apr 2015 15:41:19 +0100 (IST) Message-ID: <552D270D.2020909@cs.tcd.ie> Date: Tue, 14 Apr 2015 15:41:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org> In-Reply-To: <1429021416.11984.14.camel@gnutls.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 14:41:23 -0000 On 14/04/15 15:23, Nikos Mavrogiannopoulos wrote: > On Tue, 2015-04-14 at 14:43 +0100, Stephen Farrell wrote: >> On 14/04/15 14:16, Peter Gutmann wrote: >>> Two or three would cover most situations. We certainly don't need the three >>> hundred and twenty-nine (!!) suites we currently have defined. Looking at >>> Firefox (which I happen to have open at the moment), it negotiates exactly >>> eleven suites, and of those half are ECDHE-something ones. Not three hundred, >>> just eleven. >> >> 300+ TLS ciphersuites is plain dumb though I think I've said >> that before:-) I hope Russ' draft ends up saying something >> equivalent. > > I think that this number most indicates two issues. (1) TLS requires a > different ciphersuite based on the server's certificate type, so we have > 4 ciphersuites for AES-128-CBC-SHA1 to handle DSA, RSA, ECDSA, static DH > certificates. (2) For some reason TLS was dragging the never deployed > static DH key exchange further increasing the number of potential (but > not really used) ciphersuites. > >> My gut says that Eleven is still too many, even if it's way >> better than today. >> I once suggested we'd be fine with a 2 bit ciphersuite field >> in TLS: 00 meaning current, 01 meaning backup, 10 meaning >> proprietary (*) and 11 being reserved, just in case. While I would >> like that, it's probably not possible, given the issues with >> AES h/w vs. chacha (performance) and with AES GCM vs CCM (work >> with deployed h/w). I see no reason why TLS1.3 (say) couldn't >> just pick one best option and a backup for all of ecdh, hash, > > What would that buy? Would the protocol be simpler? Yes. Well it be > applicable to more than the use cases the initial author thought? No. > > We had AES-GCM defined in TLS few years ago. It is a very modern AEAD > ciphersuite, heavily optimized in high end CPUs and according to the TLS > WG it would have been the only ciphersuite needed. For small systems > AES-GCM was ignored and new ciphersuites were defined based on AES-CCM. > Chacha was also also defined to reduce CPU and memory usage on high end > servers. So what would have been the advantage if TLS had decided to > mandate AES-GCM only? It would have been more CPU and memory spent in > servers, and more expensive hardware for embedded systems, or we would > have a bunch of TLS-like protocols for each use case defined by the > entities that now propose new ciphersuites. I think you're misreading my mail. I described a way of supporting chacha, aes-gcm and aes-ccm, which I do think are all needed going forward. That's three things. If we have one other orthogonal pair of things (probably one based on p256 and one based on 25519) then that's six suites. And I'd add one code point for "proprietary" making 7. So my message was totally consistent with maintaining support for everything you mention above. I just want to kill everything else:-) S. > > So, there are clear advantages of having an agile TLS protocol. > > regards, > Nikos > > > > From nobody Tue Apr 14 07:42:36 2015 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 9C7FF1ACD26 for ; Tue, 14 Apr 2015 07:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMYP3LWx2Y7T for ; Tue, 14 Apr 2015 07:42:33 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3B71ACAD4 for ; Tue, 14 Apr 2015 07:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429022555; x=1460558555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GLdrKIpHOrgAUNSdbP5MkOLInGJdX1/nVpBdXPZfwRw=; b=NGna3ve+e/B2XcZkC/hbWlG412puacAORcLwBCt0sStmlQ79GEoEKyXd mKg0jgKYxo2jhjzZZF2ZUtgOJ1BsYFz24M40ruT4DpJY0VnFUe5ZqcJnY nkEe3rO4XUmpoqhEz0/x+5zOY/xBSw767lx6oVdkUI9ZsQjSVs6Av6Cb4 k=; X-IronPort-AV: E=Sophos;i="5.11,576,1422874800"; d="scan'208";a="320507993" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Apr 2015 02:42:33 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 15 Apr 2015 02:42:31 +1200 From: Peter Gutmann To: Stephen Farrell , Nikos Mavrogiannopoulos Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB2tS9VJkPX4IPTTH6EMHB5neoMTv//PmIAgAALRACAAATxgIAAyVaX Date: Tue, 14 Apr 2015 14:42:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org>,<552D270D.2020909@cs.tcd.ie> In-Reply-To: <552D270D.2020909@cs.tcd.ie> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 14:42:35 -0000 Stephen Farrell writes:=0A= =0A= >I just want to kill everything else:-)=0A= =0A= You shoot, I'll reload.=0A= =0A= Peter.=0A= From nobody Tue Apr 14 07:45:38 2015 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 F3F291ACD40 for ; Tue, 14 Apr 2015 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQJjiR8v5JP6 for ; Tue, 14 Apr 2015 07:45:35 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id A66B91ACD45 for ; Tue, 14 Apr 2015 07:45:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D645A28553; Tue, 14 Apr 2015 14:45:33 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C43A92852E; Tue, 14 Apr 2015 14:45:33 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id BE82F2027; Tue, 14 Apr 2015 14:45:33 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 14 Apr 2015 10:45:33 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Tue, 14 Apr 2015 10:45:33 -0400 From: "Salz, Rich" To: Peter Gutmann , Stephen Farrell Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB2tS9V+fpIUGeWyU6jXdqSeEHfvQAJU1QAAAFonAAAAJ4agAAACuAAAAhXXVA= Date: Tue, 14 Apr 2015 14:45:32 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org>,<552D270D.2020909@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.33.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 14:45:37 -0000 > >I just want to kill everything else:-) >=20 > You shoot, I'll reload. When you consider that many of these are national standards... you're gonna= need a bigger gun. :) Less flippantly, at the Seattle interim I suggested partitioning the space,= like the good old days of network Class A, etc. From nobody Tue Apr 14 08:03:52 2015 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 18C0A1ACE3C for ; Tue, 14 Apr 2015 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 u5hqzrPuwJfV for ; Tue, 14 Apr 2015 08:03:49 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE58A1ACE3E for ; Tue, 14 Apr 2015 08:03:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B029CE2036; Tue, 14 Apr 2015 11:03:46 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27422-03; Tue, 14 Apr 2015 11:03:40 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 6BF7AE2035; Tue, 14 Apr 2015 11:03:40 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3EF3dKm010872; Tue, 14 Apr 2015 11:03:39 -0400 From: Derek Atkins To: ianG References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> <20150413163107.GN17637@mournblade.imrryr.org> <552BF6FC.5050002@iang.org> Date: Tue, 14 Apr 2015 11:03:38 -0400 In-Reply-To: <552BF6FC.5050002@iang.org> (iang@iang.org's message of "Mon, 13 Apr 2015 18:03:56 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 15:03:52 -0000 ianG writes: [snip] >> Rather, as I see it, the main reason for the multitude of algorithms >> in TLS is that TLS is a general-purpose building block for secure >> data transport that is used in many diverse environments. >> >> TLS is not just a browser security mechanism. Different hardware >> platforms and applications using TLS have different needs. >> >> A single cipher-suite in TLS would not serve those different needs. > > > Can you give a for-instance of these features that relate to the > choice of algorithms? Sure. Extremely small (IoT) devices just can't do RSA, and even have trouble with ECC. Had we stuck with RSA-only we'd completely lose the ability to deploy TLS on constrained nodes. > Are there significant usages out there that would not be served by, > say, hypothetically, tls1.4 using a single 25519 + chacha/poly > combination? Possibly, yes. (I haven't tried implementing this yet so I don't have actual numbers to give you, but even seck163 is way too slow in my environments. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 14 08:33:58 2015 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 8F5EE1B2CEB for ; Tue, 14 Apr 2015 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 rXrqtLfXTfCg for ; Tue, 14 Apr 2015 08:33:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5418A1B2CF2 for ; Tue, 14 Apr 2015 08:33:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76569BF57; Tue, 14 Apr 2015 16:33:45 +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 iSjMvs3eqHwb; Tue, 14 Apr 2015 16:33:45 +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 4E5D4BEED; Tue, 14 Apr 2015 16:33:45 +0100 (IST) Message-ID: <552D3359.70900@cs.tcd.ie> Date: Tue, 14 Apr 2015 16:33:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Salz, Rich" , Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org>, <552D270D.2020909@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 15:33:55 -0000 On 14/04/15 15:45, Salz, Rich wrote: >>> I just want to kill everything else:-) >> >> You shoot, I'll reload. > > When you consider that many of these are national standards... you're > gonna need a bigger gun. :) Not if we can in future squeeze 'em all into one codepoint :-) > Less flippantly, at the Seattle interim I suggested partitioning the > space, like the good old days of network Class A, etc. So also more seriously, you're employer (as a big CDN) is maybe one of the hardest cases, so in a TLS1.3 environment, aside from the set of ciphersuites we all want to support, (e.g. my 6 from before or wherever that ends up), how many different suites for national algs (not legacy stuff, just national algs or vanity suites) do you think you might have to support globally? And how many of those are potentially in-play for any given session/connection/client or whatever's appropriate if you'd have to peek and poke about to figure which alg was used for my putative "proprietary" ciphersuite codepoint? My guesses would be that there're about 5 more ciphersuites about which even a big CDN would need to care and that for any connection only one is likely to be worth checking for. And once you have a TLS session or similar, then you have state that tells you which ciphers are in use, so this only impacts in a hopefully minor way on TLS handshakes and equivalent. (If you can't answer in detail, I understand, but in that case if you can say my guess is mad/not-bad that'd be useful too.) Cheers, S. > > From nobody Tue Apr 14 08:49:38 2015 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 7B2F21B2D5A for ; Tue, 14 Apr 2015 08:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 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, J_CHICKENPOX_52=0.6, MANGLED_EMAIL=2.3, 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 kjNVPgDl57H8 for ; Tue, 14 Apr 2015 08:49:35 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961A11B2D69 for ; Tue, 14 Apr 2015 08:49:31 -0700 (PDT) Received: by widdi4 with SMTP id di4so119179075wid.0 for ; Tue, 14 Apr 2015 08:49:30 -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=M1FC5chN3111Cufa1GXMr4pnc7xe8PVka50qQBXjRWw=; b=G0HJ5x4+WUWoiyfMAt2nsl7hT1uzpteXVtKhGpjFXtD2NOuH4y9HQxH6m75IgmnR0Q QKI/p8CKKAXFKUQZqvbQDWmrh3/9eJ85IJ+PSp2qSwQnok4/RKV4mhkEh9sju3nEKXjx quIqN9OTB/pGAf13VUsuwCPch3CBzu1Rbex7KUIjvsS60BQWjOEQlC6rVYzqmZRQoVFw fs3p8msIR1VkQwLphSm/tefNGxOUhZKS9QJDc4ikmjlqGZCxBN7B4v1ApbJA2ATOK7hh MzIRF1XYs9AJXrjAtWvUOoSowr3O7X6wg8gBTodHdMS083uuH/qZpjQya4yhkj2x6uS5 QQ8Q== MIME-Version: 1.0 X-Received: by 10.180.94.100 with SMTP id db4mr33755705wib.26.1429026570415; Tue, 14 Apr 2015 08:49:30 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Tue, 14 Apr 2015 08:49:30 -0700 (PDT) In-Reply-To: <552D3359.70900@cs.tcd.ie> References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org> <552D270D.2020909@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> <552D3359.70900@cs.tcd.ie> Date: Tue, 14 Apr 2015 08:49:30 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 15:49:36 -0000 On Tue, Apr 14, 2015 at 8:33 AM, Stephen Farrell wrote: > > > On 14/04/15 15:45, Salz, Rich wrote: >>>> I just want to kill everything else:-) >>> >>> You shoot, I'll reload. >> >> When you consider that many of these are national standards... you're >> gonna need a bigger gun. :) > > Not if we can in future squeeze 'em all into one codepoint :-) > >> Less flippantly, at the Seattle interim I suggested partitioning the >> space, like the good old days of network Class A, etc. > > So also more seriously, you're employer (as a big CDN) is maybe > one of the hardest cases, so in a TLS1.3 environment, aside from > the set of ciphersuites we all want to support, (e.g. my 6 from > before or wherever that ends up), how many different suites > for national algs (not legacy stuff, just national algs or > vanity suites) do you think you might have to support globally? > > And how many of those are potentially in-play for any given > session/connection/client or whatever's appropriate if you'd > have to peek and poke about to figure which alg was used for > my putative "proprietary" ciphersuite codepoint? What problem does this proposal (blind guessing) solve? Why is it a problem that we have ciphersuites that most people don't use, if there are people who use them? Implementations can avoid the cost of implementing all but the most popular suites if they want. > > My guesses would be that there're about 5 more ciphersuites > about which even a big CDN would need to care and that for > any connection only one is likely to be worth checking for. > > And once you have a TLS session or similar, then you have > state that tells you which ciphers are in use, so this only > impacts in a hopefully minor way on TLS handshakes and > equivalent. > > (If you can't answer in detail, I understand, but in that > case if you can say my guess is mad/not-bad that'd be useful > too.) > > Cheers, > S. > > > >> >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Apr 14 09:08:56 2015 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 B0BF61B2DCC for ; Tue, 14 Apr 2015 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDunfJsYEiEM for ; Tue, 14 Apr 2015 09:08:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2163E1B2DD5 for ; Tue, 14 Apr 2015 09:07:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3758BEE9; Tue, 14 Apr 2015 17:06:58 +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 1b7G6ISEdtjr; Tue, 14 Apr 2015 17:06:58 +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 5A009BEE4; Tue, 14 Apr 2015 17:06:58 +0100 (IST) Message-ID: <552D3B22.6070105@cs.tcd.ie> Date: Tue, 14 Apr 2015 17:06:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org> <552D270D.2020909@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> <552D3359.70900@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 16:08:55 -0000 On 14/04/15 16:49, Watson Ladd wrote: > What problem does this proposal (blind guessing) solve? Why is it a > problem that we have ciphersuites that most people don't use, if there > are people who use them? Implementations can avoid the cost of > implementing all but the most popular suites if they want. I think it'd be easier for implementers and would result in fewer uses of ciphersuites on which we don't have rough consensus as to goodness. Both are good things I think. There is also a lot of (IMO) wasted effort when someone is tasked to get their national alg "into" IETF specs. Someone probably has to translate into English/I-D and get all the required permissions, and that can take years, literally. (And when done, then start over on the next generation of national alg.) Then they need to negotiate all the fun of the baroque IETF and IANA processes we have setup for TLS, IPsec, S/MIME, PGP, SSH, ... in order to get all the relevant code points. (Most countries seem to prefer to want the full set for some reason.) And from the IETF side, doing all that N times makes it very hard for us to sanity check algs, as we can't easily say no to one country having said yes to some (as we have already done) and we're also not in a good position to get cryptographic review on such things as most people don't care (vendors will put these in if paid enough). And the countries concerned can pay folks to contribute to OSS if they want. CFRG also don't want (AFAIK) to be in the biz of telling the IETF that country-X's alg is crap or good. And lastly, some area directors would be saved from having to be all nice and uber-polite dealing with country-level politics, not that that's at all a consideration for me:-) So there's the potential I think to save a bunch of IETF participants a bunch of otherwise wasted effort and to simplify the code we care about. S. PS: The above is somewhat wishful thinking - the fact that TLS1.3+ will have to keep dealing with legacy (i.e. <=TLS1.2) ciphersuites probably forever, means that it's not so likely we get to fix this. Which is a pity. From nobody Tue Apr 14 09:46:49 2015 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 BA0C41B2ECD for ; Tue, 14 Apr 2015 09:46:47 -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 csZ9KcRabhUP for ; Tue, 14 Apr 2015 09:46:45 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2951B2EAE for ; Tue, 14 Apr 2015 09:46:44 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 7FBFA6D80A; Tue, 14 Apr 2015 12:46:42 -0400 (EDT) Message-ID: <552D4471.10804@iang.org> Date: Tue, 14 Apr 2015 17:46:41 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> <20150413163107.GN17637@mournblade.imrryr.org> <552BF6FC.5050002@iang.org> <20150413173213.GR17637@mournblade.imrryr.org> In-Reply-To: <20150413173213.GR17637@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 16:46:47 -0000 Hi Viktor, thanks, that gets me something to sink my teeth into! On 13/04/2015 18:32 pm, Viktor Dukhovni wrote: > On Mon, Apr 13, 2015 at 06:03:56PM +0100, ianG wrote: > >>> TLS is not just a browser security mechanism. Different hardware >>> platforms and applications using TLS have different needs. >> >> Can you give a for-instance of these features that relate to the choice of >> algorithms? > > * Not all systems have hardware AES support. Constant-time > software AES is noticeably slower than RC4, thus the historical > popularity of RC4. So, the performant sector exists because the protocol is successful. There is no 'feature' here. This sector doesn't actually deliver any benefit in and of itself, it solely exists to make the delivered product to the users faster. Such arguments therefore should be entirely completely utterly ignored when considering security and upgrades for the future. (I say "should" in the IETF sense. Of course, hardware suppliers and accelerator builders control substantial funds and they will mob the committees to turn the priorities upside down, and to their advantage. Their overwhelming money doesn't change the fact that these people are the tail, and they shouldn't wag the dog.) > * Not all systems support ECC, Well, ok, so nobody supports the next version. Which means? We all have work to do... > but some applications need more > compact signatures or higher signing throughput (even if > verification is slower than with RSA). Again, these are envelope calculations, at the margin. They aren't features. They literally only exist because *there is a choice*. If there was no choice, I'm pretty sure that they'd figure it out... > * There will be many platforms with fast hardware AES, and > others where ChaCha20 in software is more performant. Ditto. Are we in the business of making old protocols more efficient but less robust through complexity, or...? > Some > folks in .ru will likely want code points for TLS with GOST. > (I on the other hand generally disable the GOST engine in > OpenSSL as a matter of attack surface mitigation). The national champions argument. I agree that this is a 'feature'. But it isn't a feature that we should encourage, IMHO, and in this post-Snowden era I would have thought that plain: Yes, we know that the Russians will balk, but the flip side of that is that the NSA managed to push through export ciphers, and they oh-so-desperately want us to demonstrate our keenness for a neoclipper 'feature'. Meanwhile, nobody wants to particularly hand the Chinese the 'great feature of algorithm agility', even the Chinese! > * Reportedly, many constrained devices implement minimal TLS > features with PSK. Right, there definitely should be better support for opportunistic TLS, and there should be much better support for shared keys. But that's outside the question of algorithm agility? > * Postfix prefers anonymous key agreement when doing opportunistic > TLS. Some folks use anon-DH with channel binding to SASL auth. My understanding of the use of Anon-DH in this context is that it is for PFS or protocol forward security (PFS), but this is better for all and should be a standard feature. >> Are there significant usages out there that would not be served by, say, >> hypothetically, tls1.4 using a single 25519 + chacha/poly combination? > > Hard to say how well that will fit all the use cases, the history > of TLS is there was no one-size-fits-all combination. I'd say the history of TLS is that a lot of people have fiddled around at the margin, but if they'd been given only one suite, then there wouldn't have been anyone left off the boat. > Have we > found one yet? Intel's server chips have hardware AES, but not > hardware ChaCha20, server operators might not want to sacrifice > the performance. Right, any rollout period of N to N+1 is going to have to be planned with TLS quite carefully if it involves hardware changes. And Intel people are going to need to be warmed up in advance. But again, this is just business, just performance issues, not 'features'. > Perhaps we're much better at balanced universally applicable secure > algorithms now, but I don't know that we're quite there yet. :) I'm not sure we have tried in committee. To be frank, I really doubt the TLS group will decide to go for 1TCS. They are going to shrink their algorithms over the next 2 cycles until they are at a point where they are arguing about 3 versus 4. Bitterly, to the death. Then, half the group will be arguing for 1TCS and the other half will hold the line against them so they can get back to the critical 3 v. 4. The real win is everyone else. Establishing the better practice is going to take one of the other emerging protocols to pick this path, and see how we go. Eg, our old whipping horse Bitcoin is a successful protocol that doesn't 'feature' agility, and seems to be doing fine, more or less, overall. iang From nobody Tue Apr 14 09:54:08 2015 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 756921B2F24 for ; Tue, 14 Apr 2015 09:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 369rcDcrweGd for ; Tue, 14 Apr 2015 09:54:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4401B2EFA for ; Tue, 14 Apr 2015 09:53:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34D4CBE58; Tue, 14 Apr 2015 17:53:52 +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 NWOEI75UVzyf; Tue, 14 Apr 2015 17:53:52 +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 97AC4BF57; Tue, 14 Apr 2015 17:53:51 +0100 (IST) Message-ID: <552D461F.2040002@cs.tcd.ie> Date: Tue, 14 Apr 2015 17:53:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> <4713D527-4083-4C4F-96B7-E9A7C4F67F79@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AAFEB902@uxcn10-5.UoA.auckland.ac.nz> <801F9C8C-4743-4859-9B5C-A471228AB853@vigilsec.com> <20150413163107.GN17637@mournblade.imrryr.org> <552BF6FC.5050002@iang.org> <20150413173213.GR17637@mournblade.imrryr.org> <552D4471.10804@iang.org> In-Reply-To: <552D4471.10804@iang.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 16:54:05 -0000 On 14/04/15 17:46, ianG wrote: > > > So, the performant sector exists because the protocol is successful. > There is no 'feature' here. I don't think that is correct. The number of concurrent sessions a server can handle is, I believe, an important feature for folks who develop or deploy. And I'm pretty sure I've been told that the AES h/w vs. RC4 (and in future chacha) thing is impactful there. (Be good if someone could confirm that or even quantify it.) S. From nobody Tue Apr 14 09:55:10 2015 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 B35D31B2EF4 for ; Tue, 14 Apr 2015 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkx8BVlh_8IR for ; Tue, 14 Apr 2015 09:55:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id C98BF1B2EEB for ; Tue, 14 Apr 2015 09:55:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F125628509; Tue, 14 Apr 2015 16:55:06 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DE35A28504; Tue, 14 Apr 2015 16:55:06 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A2CB52026; Tue, 14 Apr 2015 16:55:06 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 14 Apr 2015 12:55:06 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Tue, 14 Apr 2015 12:55:05 -0400 From: "Salz, Rich" To: Stephen Farrell , Peter Gutmann Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB2tS9V+fpIUGeWyU6jXdqSeEHfvQAJU1QAAAFonAAAAJ4agAAACuAAAAhXXVD//8uWgIAALN+w Date: Tue, 14 Apr 2015 16:55:04 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAFEFE7D@uxcn10-5.UoA.auckland.ac.nz> <552D1974.9060703@cs.tcd.ie> <1429021416.11984.14.camel@gnutls.org>,<552D270D.2020909@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AAFEFFDE@uxcn10-5.UoA.auckland.ac.nz> <552D3359.70900@cs.tcd.ie> In-Reply-To: <552D3359.70900@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.33.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Tue, 14 Apr 2015 16:55:09 -0000 PiBNeSBndWVzc2VzIHdvdWxkIGJlIHRoYXQgdGhlcmUncmUgYWJvdXQgNSBtb3JlIGNpcGhlcnN1 aXRlcyBhYm91dCB3aGljaA0KPiBldmVuIGEgYmlnIENETiB3b3VsZCBuZWVkIHRvIGNhcmUgYW5k IHRoYXQgZm9yIGFueSBjb25uZWN0aW9uIG9ubHkgb25lIGlzDQo+IGxpa2VseSB0byBiZSB3b3J0 aCBjaGVja2luZyBmb3IuDQoNCklmIHlvdSBkb3VibGVkIHRoYXQgSSdkIGZlZWwgY29tZm9ydGFi bGUgd2l0aCB0aGF0IGFzIGEgZ29vZCBndWVzcy4NCg0K From nobody Tue Apr 14 11:34:42 2015 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 168721A9110; Tue, 14 Apr 2015 11:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU9VFke0ZbVJ; Tue, 14 Apr 2015 11:34:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379481A9120; Tue, 14 Apr 2015 11:34:33 -0700 (PDT) Received: from [192.168.2.105] ([79.246.54.63]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcSWg-1Z86k73KMQ-00ju4D; Tue, 14 Apr 2015 20:34:30 +0200 Message-ID: <552D5DB2.3050707@gmx.net> Date: Tue, 14 Apr 2015 20:34:26 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org, kathleen.moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x/hiVNx6GnGPLAu5C8KUv8pA5EqzqgnpDi3627X0H/qlLZ8IM1K wBip/iZhxLU5AbfAgANFTPChfIjYnKXs6G4iX67fn9DJTX3sOCEz0qRagkQ/wmKAi3GYUZF 0/fI1I6e68f6HIaTSXHPTmFR5tm0yu9GpLX8sM3XAqClePHMlr8gH5/GBNlgila8t8oNg81 IM8MoV4R9CO0qNeCZRQJw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] Review: Internet Draft: draft-boesch-idxp-idpef-01.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: Tue, 14 Apr 2015 18:34:38 -0000 Dear Community, after posting of version 00 of the approach for Standardized Parameterization of Intrusion Detection Entities I got positive feedback and some suggestions to improve the interoperability with other standards. So I update the Internet Draft and post a new version. I am looking forward to your suggestions, feedback, notations, hints, recommendations, etc. to improve the Internet Draft for standardized Intrusion Detection Parametrization. The updated version of the Internet Draft could be found at: http://www.ietf.org/id/draft-boesch-idxp-idpef-01.txt I looking forward to a lively discussion. Kind regards, B.-C. Boesch From nobody Wed Apr 15 01:56:10 2015 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 88CFB1B3360 for ; Wed, 15 Apr 2015 01:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7e9EbevHyTm for ; Wed, 15 Apr 2015 01:56:04 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08CD1B3356 for ; Wed, 15 Apr 2015 01:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429088165; x=1460624165; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=O6TFkY5CdlDNEj0hV39ksRQmu/XNYjbC5IbC336LbG4=; b=iBBRAuDKBRoHSmARFUNhlh3wJ1tiVUOXU7vKS5Vg/UKseVkPCWXRx/7W bdRKPG2/SPBsJ4iZ4v5EaZK2EkIApZvAsIrRZQM0m40B2/fBhSTTL5WgI XgpHPAB2kdelZ0mxyXP+qQzzKNg/gAWrJVHVy1QjwSngSFbSc2xWCIhua 0=; X-IronPort-AV: E=Sophos;i="5.11,581,1422874800"; d="scan'208";a="320712156" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Apr 2015 20:56:02 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 15 Apr 2015 20:56:00 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB3Wf4N3H8NJWkAQy225VCkN33BAg== Date: Wed, 15 Apr 2015 08:55:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF0F6A@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 08:56:09 -0000 Stephen Farrell writes:=0A= =0A= >There is also a lot of (IMO) wasted effort when someone is tasked to get= =0A= >their national alg "into" IETF specs. Someone probably has to translate in= to=0A= >English/I-D and get all the required permissions, and that can take years,= =0A= >literally. (And when done, then start over on the next generation of natio= nal=0A= >alg.)=0A= >=0A= >Then they need to negotiate all the fun of the baroque IETF and IANA=0A= >processes we have setup for TLS, IPsec, S/MIME, PGP, SSH, ... in order to = get=0A= >all the relevant code points.=0A= =0A= Isn't that a feature? If it wasn't for that, we'd have TLS cipher suites f= or=0A= the national ciphers of Lesotho, Tuvalu, Burkina Faso, and Bhutan.=0A= =0A= Peter.= From nobody Wed Apr 15 01:59:42 2015 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 08F8E1B336C for ; Wed, 15 Apr 2015 01:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYFHFfm_YfkX for ; Wed, 15 Apr 2015 01:59:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F841B3370 for ; Wed, 15 Apr 2015 01:59:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A4F2BF04; Wed, 15 Apr 2015 09:59:35 +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 Yg01ApnzoNdr; Wed, 15 Apr 2015 09:59:34 +0100 (IST) Received: from [192.168.1.140] (unknown [31.216.237.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 553AFBF02; Wed, 15 Apr 2015 09:59:34 +0100 (IST) Message-ID: <552E2874.1060309@cs.tcd.ie> Date: Wed, 15 Apr 2015 09:59:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , "saag@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C73AAFF0F6A@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF0F6A@uxcn10-5.UoA.auckland.ac.nz> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 08:59:41 -0000 b On 15/04/15 09:55, Peter Gutmann wrote: >> >Then they need to negotiate all the fun of the baroque IETF and IANA >> >processes we have setup for TLS, IPsec, S/MIME, PGP, SSH, ... in order to get >> >all the relevant code points. > Isn't that a feature? If it wasn't for that, we'd have TLS cipher suites for > the national ciphers of Lesotho, Tuvalu, Burkina Faso, and Bhutan. Yes, it currently is a feature IMO. (Where we treat 'em all the same and it's equally onerous.) But I figure if we (and they) didn't have to even bother, (if all such used one "proprietary" codepoint) that might be a better feature. That is of course speculation for now, it'd need more thought before we took that route. S. From nobody Wed Apr 15 02:05:18 2015 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 0F5FD1B3381 for ; Wed, 15 Apr 2015 02:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IdTZjiJY80T for ; Wed, 15 Apr 2015 02:05:16 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C2F1B337F for ; Wed, 15 Apr 2015 02:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429088717; x=1460624717; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6CS80gOk4AVrKO8loo3IMb3ZuZwQJb2TWbiXF6Kz3LQ=; b=epso1kAScoTDM8nSoeGPjOishMsLoHjKmatZ2hq4XHBOnkfsu7mG41nl bNTygKrE2lBoqjJzSkueyUjWA7TTvZG20egn8pSYS2ZSR/oKkFzbaExLA /GWiARrK/rUzYg6ivrW/Sq0RTM8E1Ttfq8Iz/qucVb7z9bFpIqe9vYkpT M=; X-IronPort-AV: E=Sophos;i="5.11,581,1422874800"; d="scan'208";a="320712851" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Apr 2015 21:05:00 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.163]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 15 Apr 2015 21:04:59 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB3Wz89u0UvhhcMTtegG0vD+ZuAbA== Date: Wed, 15 Apr 2015 09:04:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF0FA3@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 09:05:17 -0000 ianG writes:=0A= =0A= >Again, these are envelope calculations, at the margin. They aren't featur= es.=0A= >They literally only exist because *there is a choice*. If there was no=0A= >choice, I'm pretty sure that they'd figure it out...=0A= =0A= That's an interesting point, what's the tail and what's the dog? Tell user= s=0A= that they can choose, among other things, options like=0A= TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPIN= NERS=0A= and they'll discover they have an absolutely mission-critical requirement f= or=0A= just that. Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it" an= d=0A= they'll say "yeah, that'll do".=0A= =0A= Peter.= From nobody Wed Apr 15 07:28:27 2015 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 83AC81B356E for ; Wed, 15 Apr 2015 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_EMAIL=2.3] 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 pw34uuY-AZCp for ; Wed, 15 Apr 2015 07:28:24 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08BA1B3563 for ; Wed, 15 Apr 2015 07:28:24 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 3DE396D803; Wed, 15 Apr 2015 10:28:23 -0400 (EDT) Message-ID: <552E7585.9060703@iang.org> Date: Wed, 15 Apr 2015 15:28:21 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFF0F6A@uxcn10-5.UoA.auckland.ac.nz> <552E2874.1060309@cs.tcd.ie> In-Reply-To: <552E2874.1060309@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:28:26 -0000 On 15/04/2015 09:59 am, Stephen Farrell wrote: > b > > On 15/04/15 09:55, Peter Gutmann wrote: >>>> Then they need to negotiate all the fun of the baroque IETF and IANA >>>> processes we have setup for TLS, IPsec, S/MIME, PGP, SSH, ... in order to get >>>> all the relevant code points. >> Isn't that a feature? If it wasn't for that, we'd have TLS cipher suites for >> the national ciphers of Lesotho, Tuvalu, Burkina Faso, and Bhutan. > > Yes, it currently is a feature IMO. (Where we treat 'em all the > same and it's equally onerous.) The feature is called 'barrier to entry' in economics, following from Porter's 5 forces model of industrial competition. The quick story is that the incumbents build up a variety of barriers to slow new entrants into the market, then they are all more able to raise prices for their own benefit in a coordinated fashion. The incumbents in this case can be the corporates who ship hardware, the browsers, the governments who want their special GOST protocols, etc, whoever. In effect, you can be an incumbent if you have the capital to muscle in. The good part of this is that IETF WG process forces open entry, so that at least we can see the muscle-bound in action. The bad part is that it is still a battle of capital/resources, and it can settle into a stability of little forward action, as might be critiqued of TLS WG. Or, worse, it can slide into a behind-the-scenes capture into a full-scale cartel, as happened with CABForum. Another difficulty is that barriers are as much a natural defence against bad ideas as well as new entrants (with good ideas?), which incumbents trumpet loudly. > But I figure if we (and they) didn't have to even bother, (if all > such used one "proprietary" codepoint) that might be a better > feature. That is of course speculation for now, it'd need more > thought before we took that route. The question or perspective may revert to, what is your mission? If your mission is to preserve the security of the wider internet public, then reducing the power of the incumbents is an important element, because they will extract, and extraction typically means doing more of the same, but for them not for us (the net). E.g., what Peter calls "PKI-me-harder." Recent debates have surfaced the argument that a 'feature' we wish to preserve is hardware AES. Actually this is as much an incumbency plea, and is only end-user benefit if we can show more coverage. It's pretty clear that Intel and other chip manufacturers will be most pleased if AES remains the sole MTI for the longest time, and if hardware is embedded in the infra. OTOH, some people see the mission as serving the incumbents. This has the merit that the incumbents pay the salaries of a lot of people who drive the committees. Such groups as the IETF cannot function without large doses of time donated by owners of that time. Large companies are needed to be able to employ enough people to provide the manpower to make the consensus system work, small companies can't handle the contribution, and lone wolfs aren't sufficient because there are too few of them. The problem with the encumbency process should now be obvious -- after time it becomes security of own revenue -- of both the people in the groups and also the companies paying their salaries -- not security of the net. Hence, (eg) AES in chips becomes a plaything for their revenue not our security. There are no easy answers. The notion of "serving the incumbents" has further merit if we assume that the world is full of naturally emerging bullies a.k.a. champions, and we need a way to at least limit their power. E.g., the NSA is an obvious partner that we don't want, because they always drift into NOBUS-exploitability rather than joint security. E.g., as was the case when IETF was formed, in a war against the telco-dominated OSI/ISO world. It's not as if that industrial structure of the world has changed markedly, we all know who the big brands are. Serving the incumbents should not be cast off lightly. Out of all that: stricter rules or protocols in how we choose the suites could be *a really powerful way of neutering the competition*, and freeing up all that lost energy into better things. (Of course, choosing that approach would have to be done adroitly otherwise we're setting ourselves up for a food fight.) iang From nobody Wed Apr 15 07:30:43 2015 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 28BD41A00E0 for ; Wed, 15 Apr 2015 07:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, MANGLED_EMAIL=2.3] 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 0vL6BXjh7W_v for ; Wed, 15 Apr 2015 07:30:40 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0690A1A006F for ; Wed, 15 Apr 2015 07:30:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E0800E2035; Wed, 15 Apr 2015 10:30:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02051-09; Wed, 15 Apr 2015 10:30:37 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 79107E2034; Wed, 15 Apr 2015 10:30:37 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3FEUZuY014520; Wed, 15 Apr 2015 10:30:35 -0400 From: Derek Atkins To: Stephen Farrell References: <9A043F3CF02CD34C8E74AC1594475C73AAFF0F6A@uxcn10-5.UoA.auckland.ac.nz> <552E2874.1060309@cs.tcd.ie> Date: Wed, 15 Apr 2015 10:30:34 -0400 In-Reply-To: <552E2874.1060309@cs.tcd.ie> (Stephen Farrell's message of "Wed, 15 Apr 2015 09:59:32 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:30:42 -0000 Stephen Farrell writes: > b > > On 15/04/15 09:55, Peter Gutmann wrote: >>> >Then they need to negotiate all the fun of the baroque IETF and IANA >>> >processes we have setup for TLS, IPsec, S/MIME, PGP, SSH, ... in >>> > order to get >>> >all the relevant code points. >> Isn't that a feature? If it wasn't for that, we'd have TLS cipher suites for >> the national ciphers of Lesotho, Tuvalu, Burkina Faso, and Bhutan. > > Yes, it currently is a feature IMO. (Where we treat 'em all the > same and it's equally onerous.) > > But I figure if we (and they) didn't have to even bother, (if all > such used one "proprietary" codepoint) that might be a better > feature. That is of course speculation for now, it'd need more > thought before we took that route. Then how do you differentiate the various potential proprietary ciphers? Let's say that you need to support a dozen. Do you need to include additional OIDs in the handshake? Or is there some other "proprietary identifier" to allow differentiation of the proprietary ciphers? > S. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 15 07:31:42 2015 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 A8C721B3596 for ; Wed, 15 Apr 2015 07:31: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 pibPiE8DZEVG for ; Wed, 15 Apr 2015 07:31:39 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4862E1B359D for ; Wed, 15 Apr 2015 07:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D3545E2035; Wed, 15 Apr 2015 10:31:37 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02420-01; Wed, 15 Apr 2015 10:31:36 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id E9AACE2034; Wed, 15 Apr 2015 10:31:35 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3FEVZIF014606; Wed, 15 Apr 2015 10:31:35 -0400 From: Derek Atkins To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFF0FA3@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 15 Apr 2015 10:31:34 -0400 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF0FA3@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 15 Apr 2015 09:04:58 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:31:40 -0000 Peter Gutmann writes: > ianG writes: > >>Again, these are envelope calculations, at the margin. They aren't features. >>They literally only exist because *there is a choice*. If there was no >>choice, I'm pretty sure that they'd figure it out... > > That's an interesting point, what's the tail and what's the dog? Tell users > that they can choose, among other things, options like > TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPINNERS > and they'll discover they have an absolutely mission-critical requirement for > just that. Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it" and > they'll say "yeah, that'll do". ... except when it doesn't. :) > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 15 07:37:28 2015 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 9E0491B357F for ; Wed, 15 Apr 2015 07:37:26 -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_40=-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 YcnlGUVyxf9Q for ; Wed, 15 Apr 2015 07:37:25 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC151B3571 for ; Wed, 15 Apr 2015 07:37:25 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1DD6D6D836; Wed, 15 Apr 2015 10:37:24 -0400 (EDT) Message-ID: <552E779D.7000700@iang.org> Date: Wed, 15 Apr 2015 15:37:17 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFF0FA3@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF0FA3@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:37:26 -0000 On 15/04/2015 10:04 am, Peter Gutmann wrote: > ianG writes: > >> Again, these are envelope calculations, at the margin. They aren't features. >> They literally only exist because *there is a choice*. If there was no >> choice, I'm pretty sure that they'd figure it out... > > That's an interesting point, what's the tail and what's the dog? Tell users > that they can choose, among other things, options like > TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPINNERS > and they'll discover they have an absolutely mission-critical requirement for > just that. Secure spinners, hell yeah! > Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it" and > they'll say "yeah, that'll do". So, could most users cope with that? I'd say yes, in principle. If we were to get more concrete and go look at say the TLS WG (which isn't this group, it's another) then we could have more arguments about performance. As Derik has rightly brought up. But I would suggest that if we look at the other 99 groups -- the consensus across all IETF as this current draft is about -- most of them have less performance envelope to worry about. In which case a criticism of the 1TCS approach is that in a successful protocol that covers a wide swathe of performance territory, there will occur a tension between providing a highly efficient but just-secure-enough suite versus a less efficient but highly-efficient suite. But this criticism should really only be applied/reserved for those protocols that have achieved remarkable penetration across the spectrum. It can also be seen as a nice problem to have. iang From nobody Wed Apr 15 07:37:38 2015 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 71DDC1B35AC for ; Wed, 15 Apr 2015 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyti11zVVWdg for ; Wed, 15 Apr 2015 07:37:24 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368061B3567 for ; Wed, 15 Apr 2015 07:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429108646; x=1460644646; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gOVNyL76jXqvdxDu8Fj0Zg4nEI+rdflkI0r6e2Dy0es=; b=DusrMLBvjRnWTD95uAubICmvAkhceifH7C2mXdSX0RY4bJMdz2NfoZ7t pbur2Nzs6A7R0c7g+5bBL40K703HA0kK3sgJiuIiFncp0Kh9EKWBVVpaW wDQmQPVv2CXfkOAgbOYFK2H5DE+Qo+cvopWz6sBF6MEwX9cqz1+CDmtRY k=; X-IronPort-AV: E=Sophos;i="5.11,582,1422874800"; d="scan'208";a="320751737" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 02:37:24 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Thu, 16 Apr 2015 02:37:20 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB3ia2V6b7EQ4M5TbmUt5dlcXviJA== Date: Wed, 15 Apr 2015 14:37:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:37:29 -0000 Derek Atkins writes:=0A= >Peter Gutmann writes:=0A= >> ianG writes:=0A= >>=0A= >>>Again, these are envelope calculations, at the margin. They aren't feat= ures.=0A= >>>They literally only exist because *there is a choice*. If there was no= =0A= >>>choice, I'm pretty sure that they'd figure it out...=0A= >>=0A= >> That's an interesting point, what's the tail and what's the dog? Tell u= sers=0A= >> that they can choose, among other things, options like=0A= >> TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_S= PINNERS=0A= >> and they'll discover they have an absolutely mission-critical requiremen= t for=0A= >> just that. Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it"= and=0A= >> they'll say "yeah, that'll do".=0A= >=0A= >... except when it doesn't. :)=0A= =0A= Well it's going to have to do because they won't be given a choice. Any su= ite=0A= you like as long as it's TLS_DHE_RSA_WITH_AES_SHA256.=0A= =0A= Ref: http://psycnet.apa.org/psycinfo/2000-16701-012=0A= =0A= (http://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20%26%20Leppe= r%20(2000).pdf =0A= for the non-paywalled version)=0A= =0A= Peter.= From nobody Wed Apr 15 07:47:30 2015 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 D7A061A00B7 for ; Wed, 15 Apr 2015 07:47: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 kJDJuZSrxmev for ; Wed, 15 Apr 2015 07:47:28 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9C41A0030 for ; Wed, 15 Apr 2015 07:47:28 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9843C6D830; Wed, 15 Apr 2015 10:47:27 -0400 (EDT) Message-ID: <552E79FE.8030203@iang.org> Date: Wed, 15 Apr 2015 15:47:26 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:47:30 -0000 On 15/04/2015 15:37 pm, Peter Gutmann wrote: > Derek Atkins writes: >> Peter Gutmann writes: >>> ianG writes: >>> >>>> Again, these are envelope calculations, at the margin. They aren't features. >>>> They literally only exist because *there is a choice*. If there was no >>>> choice, I'm pretty sure that they'd figure it out... >>> >>> That's an interesting point, what's the tail and what's the dog? Tell users >>> that they can choose, among other things, options like >>> TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPINNERS >>> and they'll discover they have an absolutely mission-critical requirement for >>> just that. Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it" and >>> they'll say "yeah, that'll do". >> >> ... except when it doesn't. :) Yup. At the margin, there will always be losers. Case A. If you choose TLS_DHE_RSA_WITH_AES_SHA256, there will be losers that can't do it. Case B. In the alternate, if you choose the current brain-destroying situation of httpd config files, there are all the losers who failed to get it going because it is so complicated, and all the losers who got it going but left a stupid suite in there because they didn't understand. How to pick your losers? Getting the most users with some security trumps. > Well it's going to have to do because they won't be given a choice. Any suite > you like as long as it's TLS_DHE_RSA_WITH_AES_SHA256. > > Ref: http://psycnet.apa.org/psycinfo/2000-16701-012 > > (http://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20%26%20Lepper%20(2000).pdf > for the non-paywalled version) Priceless! And we feel better and do better work with less choice! iang From nobody Wed Apr 15 07:56:59 2015 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 A01B71B355E for ; Wed, 15 Apr 2015 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF9g10IPXOOH for ; Wed, 15 Apr 2015 07:56:56 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7921F1B3571 for ; Wed, 15 Apr 2015 07:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429109813; x=1460645813; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=A+LzDsQPXG3Dx9cayjDUdRkH3Dmfn/r0DE0IJjt8+oQ=; b=Fmc0p3ze/Ll6WBH/skvUbie+eUGm2oKxXHXY0TXHUx6G/1sx2BjkxFJK 3mjobhSg7QW1y9jrwfRoiuc/HtPxP+Sgpi4iSZoeiIBebaEQD9qW4pYuV MgUmXfEzQ45TNm5sOOCgJ8ptejMee2DzgTiJfFFYWbps2DicOjnYnFzTG k=; X-IronPort-AV: E=Sophos;i="5.11,582,1422874800"; d="scan'208";a="320753056" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 02:56:52 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 16 Apr 2015 02:56:52 +1200 From: Peter Gutmann To: ianG , "saag@ietf.org" Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB3ia2V6b7EQ4M5TbmUt5dlcXviJP//OacAgADKyFA= Date: Wed, 15 Apr 2015 14:56:51 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF96B6@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz>, <552E79FE.8030203@iang.org> In-Reply-To: <552E79FE.8030203@iang.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 14:56:57 -0000 ianG writes:=0A= =0A= >Priceless! And we feel better and do better work with less choice!=0A= =0A= Yup. Every time I go to dinner with Apple-enabled friends and we spend lon= ger=0A= on i-whatever-it-is choosing a film to watch than it takes to actually watc= h=0A= the film, I think of that, and other work done by Iyengar on the psychology= of=0A= choice, and why less is more (or at least better).=0A= =0A= (If you want a more accessible version, try "The Art of Choosing", same aut= hor).=0A= =0A= Peter.= From nobody Wed Apr 15 08:20:18 2015 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 72E841B35DC for ; Wed, 15 Apr 2015 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 GrgDUeyqSc_0 for ; Wed, 15 Apr 2015 08:20:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AE71B35DB for ; Wed, 15 Apr 2015 08:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7A2ACE2034; Wed, 15 Apr 2015 11:20:11 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02585-08; Wed, 15 Apr 2015 11:20:09 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 3E8A9E2035; Wed, 15 Apr 2015 11:20:09 -0400 (EDT) Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 15 Apr 2015 11:20:09 -0400 Message-ID: <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 15 Apr 2015 11:20:09 -0400 From: "Derek Atkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 15:20:17 -0000 On Wed, April 15, 2015 10:37 am, Peter Gutmann wrote: > Derek Atkins writes: >>Peter Gutmann writes: >>> ianG writes: >>> >>>>Again, these are envelope calculations, at the margin. They aren't >>>> features. >>>>They literally only exist because *there is a choice*. If there was no >>>>choice, I'm pretty sure that they'd figure it out... >>> >>> That's an interesting point, what's the tail and what's the dog? Tell >>> users >>> that they can choose, among other things, options like >>> TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPINNERS >>> and they'll discover they have an absolutely mission-critical >>> requirement for >>> just that. Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave >>> it" and >>> they'll say "yeah, that'll do". >> >>... except when it doesn't. :) > > Well it's going to have to do because they won't be given a choice. Any > suite > you like as long as it's TLS_DHE_RSA_WITH_AES_SHA256. Okay, so you have effectively written off IoT. If that is the answer then I'm sure another solution will be created to handle them. Personally I'd prefer a TLS that enables IoT support instead of requiring IoT to be completely incompatible. For example, I can't use GCM, nor can I use RSA, and frankly even ECC is a stretch. > Ref: http://psycnet.apa.org/psycinfo/2000-16701-012 > > (http://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20%26%20Lepper%20(2000).pdf > for the non-paywalled version) > > Peter. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 15 08:28:29 2015 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 8412B1B35ED for ; Wed, 15 Apr 2015 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZAIk3ZZP90e for ; Wed, 15 Apr 2015 08:28:26 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8142F1B35EA for ; Wed, 15 Apr 2015 08:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1429111705; x=1460647705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IQMvrmImY1ZAX4XnvmfS2s/jIOoo+a1vf/QYdVUHZ2w=; b=UZxkOhPGIBZJ7t2Y0G24P9sdH1+7O0OGWorM0QDwcX0L5qaRx+A+N6oc 6p5L7q6HAAUjPnjSwfrvc9q4xfdp5Twg2yPDtMME8ggNDOXV0Hs3MNpcB 9ij8v29LS0PlruAa//APlkGeeqAZ3uIpiqWwYBkQgGgnYV0G16CzkkZYi E=; X-IronPort-AV: E=Sophos;i="5.11,582,1422874800"; d="scan'208";a="320755043" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 03:28:20 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 16 Apr 2015 03:28:20 +1200 From: Peter Gutmann To: Derek Atkins Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AdB3ia2V6b7EQ4M5TbmUt5dlcXviJP//QsyAgADK0kg= Date: Wed, 15 Apr 2015 15:28:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF982B@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz>, <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> In-Reply-To: <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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: Wed, 15 Apr 2015 15:28:27 -0000 Derek Atkins =FD writes:=0A= =0A= >Okay, so you have effectively written off IoT. =0A= =0A= What Things? All the embedded stuff I've worked with that talks TLS manage= s=0A= (somehow, it's pretty ugly in many cases) to talk at least=0A= TLS_RSA_WITH_AES_SHA1 (if not _DHE), because they have to do what all the= =0A= browsers do, and that's the most common one.=0A= =0A= If you're really space-constrained then you don't run TLS in the first plac= e,=0A= because it's a huge resource hog. OTOH if you need to be controllable via = a=0A= browser/web services/AJAX/whatever then you run the most common denominator= =0A= spoken by the other side, which is typically RSA + AES + SHA1 (I used DHE a= nd=0A= SHA256 to avoid getting sidetracked into a discussion over hash algorithms = and=0A= whatnot).=0A= =0A= >Personally I'd prefer a TLS that enables IoT support instead of requiring = IoT=0A= >to be completely incompatible.=0A= =0A= See above, either the IoT device will speak the most common implementation,= or=0A= it won't do TLS at all.=0A= =0A= Peter.= From nobody Thu Apr 16 07:27:35 2015 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 941C41B320D for ; Thu, 16 Apr 2015 07:27: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 mJ0QI3ioWMBH for ; Thu, 16 Apr 2015 07:27:31 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE2E1B3208 for ; Thu, 16 Apr 2015 07:27:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E9AC5E2035; Thu, 16 Apr 2015 10:27:29 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09028-02; Thu, 16 Apr 2015 10:27:28 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2A247E2034; Thu, 16 Apr 2015 10:27:28 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GERRQA014747; Thu, 16 Apr 2015 10:27:27 -0400 From: Derek Atkins To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73AAFF982B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Thu, 16 Apr 2015 10:27:26 -0400 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF982B@uxcn10-tdc05.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 15 Apr 2015 15:28:19 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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, 16 Apr 2015 14:27:33 -0000 Peter, Peter Gutmann writes: > Derek Atkins =E2=80=8E writes: > >>Okay, so you have effectively written off IoT.=20=20 > > What Things? All the embedded stuff I've worked with that talks TLS mana= ges > (somehow, it's pretty ugly in many cases) to talk at least > TLS_RSA_WITH_AES_SHA1 (if not _DHE), because they have to do what all the > browsers do, and that's the most common one. All I'm suggesting is that there are other algorithms that exist that would better support these devices, so I'd prefer we don't rule out supporting those algorithms. > If you're really space-constrained then you don't run TLS in the first pl= ace, > because it's a huge resource hog. OTOH if you need to be controllable vi= a a > browser/web services/AJAX/whatever then you run the most common denominat= or > spoken by the other side, which is typically RSA + AES + SHA1 (I used DHE= and > SHA256 to avoid getting sidetracked into a discussion over hash algorithm= s and > whatnot). There are different kinds of contraints on IoT; space is one knob. Power and CPU is another. Many of the devices I work with are more constrained with Power and CPU than with Space (although they are still relatively space constrained, certainly compared to a laptop or mobile phone). >>Personally I'd prefer a TLS that enables IoT support instead of requiring= IoT >>to be completely incompatible. > > See above, either the IoT device will speak the most common implementatio= n, or > it won't do TLS at all. And I'm only suggesting that we keep our options open for algorithms that could be out there and enable support (albeit in a future implementation). Keep in mind we're talking TLS1.3, which *nobody* supports ;) > Peter. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 18:42:15 2015 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 7D5701A8A60 for ; Thu, 16 Apr 2015 18:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgMCRbCmblBc for ; Thu, 16 Apr 2015 18:42:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C9C1A8A59 for ; Thu, 16 Apr 2015 18:42:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YivIG-0003Ix-MZ; Fri, 17 Apr 2015 01:42:09 +0000 Date: Fri, 17 Apr 2015 10:42:06 +0900 Message-ID: From: Randy Bush To: Derek Atkins In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73AAFF982B@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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, 17 Apr 2015 01:42:14 -0000 [ as discussed privately ] there will always be massive machines at the 'top' and what we think of as 'tiny' ones at the bottom. we should let neither drive our concepts of architecture. randy From nobody Fri Apr 17 06:27:31 2015 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 7060F1B2C31 for ; Fri, 17 Apr 2015 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 1sH51ge2wwVC for ; Fri, 17 Apr 2015 06:27:28 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CF61A88B6 for ; Fri, 17 Apr 2015 06:27:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1FEBBE2040; Fri, 17 Apr 2015 09:27:27 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15759-06; Fri, 17 Apr 2015 09:27:25 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 13070E203A; Fri, 17 Apr 2015 09:27:25 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3HDRN5g012336; Fri, 17 Apr 2015 09:27:23 -0400 From: Derek Atkins To: Randy Bush References: <9A043F3CF02CD34C8E74AC1594475C73AAFF9666@uxcn10-tdc05.UoA.auckland.ac.nz> <3407dfda68cdf38661d4709bc92996d0.squirrel@mail2.ihtfp.org> <9A043F3CF02CD34C8E74AC1594475C73AAFF982B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Fri, 17 Apr 2015 09:27:23 -0400 In-Reply-To: (Randy Bush's message of "Fri, 17 Apr 2015 10:42:06 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-01.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, 17 Apr 2015 13:27:29 -0000 Randy Bush writes: > [ as discussed privately ] > > there will always be massive machines at the 'top' and what we think of > as 'tiny' ones at the bottom. we should let neither drive our concepts > of architecture. I'm not suggesting it drive our architecture. The architecture *works* as designed. I'm just suggesting that we not limit our choices of ciphers to only those that work at the top or middle, and to consider also including ciphers that enable us to work at the bottom. I.e., I'm suggesting that we keep an open mind on parameter selection, which is IMHO completely separate from the architecture selection. > randy -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Apr 18 13:34:35 2015 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 AF0B71A9026 for ; Sat, 18 Apr 2015 13:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z5z-Za-HgFl for ; Sat, 18 Apr 2015 13:34:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75011A900B for ; Sat, 18 Apr 2015 13:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D25DABEDB for ; Sat, 18 Apr 2015 21:34:28 +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 p7tQwHIOl57L for ; Sat, 18 Apr 2015 21:34:27 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8EE18BEB0 for ; Sat, 18 Apr 2015 21:34:27 +0100 (IST) Message-ID: <5532BFD3.8010505@cs.tcd.ie> Date: Sat, 18 Apr 2015 21:34:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "saag@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Proposal for Privacy Enhanced RTP Conferencing (PERC) WG 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, 18 Apr 2015 20:34:33 -0000 Hi all, Please see [1] which follows up from Ekr's quick presentation at the saag session in Dallas. [2] This proposed WG could do with some significant security and privacy clue. As of now, I think the plan is for this to be a RAI (or soon to be ART) area WG and not a security area WG which is fine, but would be even finer if we knew some folks on here were going to help out on the security stuff. If you're interested in working actively on this, or able to review drafts now and then, it'd be great if you could let Kathleen or I know. Comments on the charter here will also be useful, though probably commenting on the dispatch list [3] is even better. Thanks in advance, S. [1] https://www.ietf.org/mail-archive/web/dispatch/current/msg05871.html [2] https://www.ietf.org/proceedings/92/slides/slides-92-saag-6.pdf [3] https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 21 10:26:13 2015 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 CD02B1A8718 for ; Tue, 21 Apr 2015 10:26:11 -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 8qZyjRzf4l7J for ; Tue, 21 Apr 2015 10:26:09 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234FD1A8712 for ; Tue, 21 Apr 2015 10:26:09 -0700 (PDT) Received: by layy10 with SMTP id y10so156516365lay.0 for ; Tue, 21 Apr 2015 10:26: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 :cc:content-type; bh=OvBNIlXt9gSZ1zUDGmqeMeTjsGFrXC/oITM86Mdz6VM=; b=fgmkCgE9rAFrhcloM+5r3cbbjwxo98joYLi6a+YaiYQNp5Hi2kaPukT2dXkGTwGnEv /EQwTEptaqucJkQ06++KL9AVPEY6ZD9gMNyv5bIkWVJcH0OtzNhgCRDt4nvfNIlVCwwq LXTTS+WEntK8BZqHfhuOyWGQ33NykWa61LT3TG7pRZuOuCWu74zCzG4tgwzzrYO167rh DAi8fkqs61saXlVCEzdcICst9XiZBgp1FDjHLfoO/d8xSulQ0rQJoq3XEgY7SEhSTBWb b0UntOBIpYgJ4nv5fBXo3UZIZODQ1fMeqWa/x7/x3fl+m7E7j1yLeymibVUXlAsP3MRC ++PQ== MIME-Version: 1.0 X-Received: by 10.112.166.37 with SMTP id zd5mr14234645lbb.75.1429637167554; Tue, 21 Apr 2015 10:26:07 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Tue, 21 Apr 2015 10:26:07 -0700 (PDT) In-Reply-To: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 21 Apr 2015 13:26:07 -0400 Message-ID: From: Kathleen Moriarty To: "" Content-Type: multipart/alternative; boundary=001a11c382d087a50f05143f5789 Archived-At: Cc: "saag@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [saag] Request for guidance regarding E2E security over Diameter 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, 21 Apr 2015 17:26:12 -0000 --001a11c382d087a50f05143f5789 Content-Type: text/plain; charset=UTF-8 Hello, A few weeks have past and I don't see any response to this request on-list. Are there any volunteers that would like to assist DIME with e2e encryption for Diameter as described in Lionel's message? Thanks, Kathleen On Thu, Mar 26, 2015 at 12:24 PM, wrote: > Hi, > > As currently specified, the Diameter Base protocol (RFC6733) only offers > transport level protection between neighboring Diameter peers, using either > TLS/TCP, DTLS/SCTP, or IPsec as last resort. However, no mechanism has been > defined to ensure E2E security for data (in the conveyed (in the form of > Attribute-Value Pairs (AVPs)) in Diameter messages between two endpoints. > Early 2000, at the beginning of the work on Diameter, CMS (Cryptographic > Message Syntax) was identified as solution to provide AVP-level E2E > security but this work was not completed due to lack of deployment interest > (at least at that time) and the foreseen complexity of the developed > solution for Diameter. > > Due to the renewed interest for E2E security over Diameter, mainly for > inter-domain signaling in the mobile network environment, the DIME WG has > decided to reactivate the work on E2E security for Diameter. The first step > is almost completed, with a document (draft-ietf-dime-e2e-sec-req-02) > defining the requirements for an AVP-level E2E security solution. The > second step will be work on the specification of such mechanism. An early > proposal was to derive a solution from JOSE, encapsulating JOSE objects for > integrity protection and AVP encryption. It is however expected that other > mechanisms could be proposed as candidate solutions. And we know already > that there are existing discussions on alternative to JOSE (e.g. COSE). > > Whatever the proposed solution(s),the DIME WG has not (and will not have) > the expertise required to evaluate and select the more appropriate security > mechanism for E2E security over Diameter. We are therefore interested by > any guidance and support from SAAG regarding the development of a solution > for E2E security over Diameter, based on the requirements collected in > draft-ietf-dime-e2e-sec-req-02. > > Regards, > > Lionel > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen --001a11c382d087a50f05143f5789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

A few weeks have past and I don&= #39;t see any response to this request on-list.=C2=A0 Are there any volunte= ers that would like to assist DIME with e2e encryption for Diameter as desc= ribed in Lionel's message?

Thanks,
K= athleen

On Thu, Mar 26, 2015 at 12:24 PM, <lionel.morand@orange.com&= gt; wrote:
Hi,

As currently specified, the Diameter Base protocol (RFC6733) only offers tr= ansport level protection between neighboring Diameter peers, using either T= LS/TCP, DTLS/SCTP, or IPsec as last resort. However, no mechanism has been = defined to ensure E2E security for data (in the conveyed (in the form of At= tribute-Value Pairs (AVPs)) in Diameter messages between two endpoints. Ear= ly 2000, at the beginning of the work on Diameter, CMS (Cryptographic Messa= ge Syntax) was identified as solution to provide AVP-level E2E security but= this work was not completed due to lack of deployment interest (at least a= t that time) and the foreseen complexity of the developed solution for Diam= eter.

Due to the renewed interest for E2E security over Diameter, mainly for inte= r-domain signaling in the mobile network environment, the DIME WG has decid= ed to reactivate the work on E2E security for Diameter. The first step is a= lmost completed, with a document (draft-ietf-dime-e2e-sec-req-02) defining = the requirements for an AVP-level E2E security solution. The second step wi= ll be work on the specification of such mechanism. An early proposal was to= derive a solution from JOSE, encapsulating JOSE objects for integrity prot= ection and AVP encryption. It is however expected that other mechanisms cou= ld be proposed as candidate solutions. And we know already that there are e= xisting discussions on alternative to JOSE (e.g. COSE).

Whatever the proposed solution(s),the DIME WG has not (and will not have) t= he expertise required to evaluate and select the more appropriate security = mechanism for E2E security over Diameter. We are therefore interested by an= y guidance and support from SAAG regarding the development of a solution fo= r E2E security over Diameter, based on the requirements collected in draft-= ietf-dime-e2e-sec-req-02.

Regards,

Lionel

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

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



--

Best regards,
Kath= leen
--001a11c382d087a50f05143f5789-- From nobody Tue Apr 21 10:51:21 2015 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 61A771A066C for ; Tue, 21 Apr 2015 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u8d84HO0Nws for ; Tue, 21 Apr 2015 10:51:11 -0700 (PDT) Received: from BLU004-OMC2S28.hotmail.com (blu004-omc2s28.hotmail.com [65.55.111.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1EB1A035F for ; Tue, 21 Apr 2015 10:51:08 -0700 (PDT) Received: from BLU181-W54 ([65.55.111.72]) by BLU004-OMC2S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 21 Apr 2015 10:51:07 -0700 X-TMN: [vzg0HqoSYju6aTF+bllptLnK7G4aZk8i] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_dfed88d6-5b1b-41ab-9ba3-b365f6d5c24a_" From: Bernard Aboba To: Kathleen Moriarty , "lionel.morand@orange.com" Date: Tue, 21 Apr 2015 10:51:06 -0700 Importance: Normal In-Reply-To: References: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup>, MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2015 17:51:07.0736 (UTC) FILETIME=[BEB84580:01D07C5B] Archived-At: Cc: "saag@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [saag] Request for guidance regarding E2E security over Diameter 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, 21 Apr 2015 17:51:19 -0000 --_dfed88d6-5b1b-41ab-9ba3-b365f6d5c24a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In practice=2C as I understand it=2C Diameter implementations utilize no tr= ansport security at all - TLS=2C DTLS=2C Ipsec=2C etc. are not being used.= Since Diameter has no application security either=2C the only security de= ployed in the wild is firewalls. Since an unprotected Diameter session car= ries information relating to user privacy such as usernames=2C location=2C = etc. this makes it easy for an attacker snooping on the network to reap a b= onanza of personal information about you - including your location at every= moment.=20 As the former AAA WG Chair who closed work on e2e security due to lack of i= nterest from implementers=2C I am gratified to hear that work on e2e securi= ty is once again being considered. However=2C it is a bit like having an = illiterate express interest in reading Proust -- an admirable sentiment=2C = but there are a few hurdles to get over first... Date: Tue=2C 21 Apr 2015 13:26:07 -0400 From: kathleen.moriarty.ietf@gmail.com To: lionel.morand@orange.com CC: saag@ietf.org=3B dime-chairs@tools.ietf.org Subject: Re: [saag] Request for guidance regarding E2E security over Diamet= er Hello=2C A few weeks have past and I don't see any response to this request on-list.= Are there any volunteers that would like to assist DIME with e2e encrypti= on for Diameter as described in Lionel's message? Thanks=2CKathleen On Thu=2C Mar 26=2C 2015 at 12:24 PM=2C wrote: Hi=2C =0A= =0A= As currently specified=2C the Diameter Base protocol (RFC6733) only offers = transport level protection between neighboring Diameter peers=2C using eith= er TLS/TCP=2C DTLS/SCTP=2C or IPsec as last resort. However=2C no mechanism= has been defined to ensure E2E security for data (in the conveyed (in the = form of Attribute-Value Pairs (AVPs)) in Diameter messages between two endp= oints. Early 2000=2C at the beginning of the work on Diameter=2C CMS (Crypt= ographic Message Syntax) was identified as solution to provide AVP-level E2= E security but this work was not completed due to lack of deployment intere= st (at least at that time) and the foreseen complexity of the developed sol= ution for Diameter. =0A= =0A= Due to the renewed interest for E2E security over Diameter=2C mainly for in= ter-domain signaling in the mobile network environment=2C the DIME WG has d= ecided to reactivate the work on E2E security for Diameter. The first step = is almost completed=2C with a document (draft-ietf-dime-e2e-sec-req-02) def= ining the requirements for an AVP-level E2E security solution. The second s= tep will be work on the specification of such mechanism. An early proposal = was to derive a solution from JOSE=2C encapsulating JOSE objects for integr= ity protection and AVP encryption. It is however expected that other mechan= isms could be proposed as candidate solutions. And we know already that the= re are existing discussions on alternative to JOSE (e.g. COSE). =0A= =0A= Whatever the proposed solution(s)=2Cthe DIME WG has not (and will not have)= the expertise required to evaluate and select the more appropriate securit= y mechanism for E2E security over Diameter. We are therefore interested by = any guidance and support from SAAG regarding the development of a solution = for E2E security over Diameter=2C based on the requirements collected in dr= aft-ietf-dime-e2e-sec-req-02. =0A= =0A= Regards=2C =0A= =0A= Lionel =0A= =0A= ___________________________________________________________________________= ______________________________________________ =0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc =0A= pas etre diffuses=2C exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur=2C veuillez le signaler =0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration=2C =0A= Orange decline toute responsabilite si ce message a ete altere=2C deforme o= u falsifie. Merci. =0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law=3B =0A= they should not be distributed=2C used or copied without authorisation. =0A= If you have received this email in error=2C please notify the sender and de= lete this message and its attachments. =0A= As emails may be altered=2C Orange is not liable for messages that have bee= n modified=2C changed or falsified. =0A= Thank you. =0A= =0A= _______________________________________________ =0A= saag mailing list =0A= saag@ietf.org =0A= https://www.ietf.org/mailman/listinfo/saag =0A= --=20 Best regards=2CKathleen=0A= =0A= _______________________________________________=0A= saag mailing list=0A= saag@ietf.org=0A= https://www.ietf.org/mailman/listinfo/saag = --_dfed88d6-5b1b-41ab-9ba3-b365f6d5c24a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In practice=2C as I understand i= t=2C Diameter implementations utilize no transport security at all -  = =3BTLS=2C DTLS=2C Ipsec=2C etc. are not being used.  =3BSince Diameter = has no application security either=2C the only security deployed in the wil= d is firewalls.  =3BSince an unprotected Diameter session carries infor= mation relating to user privacy such as usernames=2C location=2C etc. this = makes it easy for an attacker snooping on the network to reap a bonanza of = personal information about you - including your location at every moment.&n= bsp=3B

As the former AAA WG Chair who closed work o= n e2e security due to lack of interest from implementers=2C I am gratified = to hear that work on e2e security is once again being considered.  =3B = However=2C it is a bit like having an illiterate express interest in readin= g Proust -- an admirable sentiment=2C but there are a few hurdles to get ov= er first...

Date: Tue=2C 21 Apr 2015 13= :26:07 -0400
From: kathleen.moriarty.ietf@gmail.com
To: lionel.morand= @orange.com
CC: saag@ietf.org=3B dime-chairs@tools.ietf.org
Subject: = Re: [saag] Request for guidance regarding E2E security over Diameter
Hello=2C

A few weeks have past and I d= on't see any response to this request on-list. =3B Are there any volunt= eers that would like to assist DIME with e2e encryption for Diameter as des= cribed in Lionel's message?

Thanks=2C
Ka= thleen

On Thu=2C Mar 26=2C 2015 at 12:24 PM=2C <=3Blionel.morand@or= ange.com>=3B wrote:
Hi=2C
=0A=
=0A= As currently specified=2C the Diameter Base protocol (RFC6733) only offers = transport level protection between neighboring Diameter peers=2C using eith= er TLS/TCP=2C DTLS/SCTP=2C or IPsec as last resort. However=2C no mechanism= has been defined to ensure E2E security for data (in the conveyed (in the = form of Attribute-Value Pairs (AVPs)) in Diameter messages between two endp= oints. Early 2000=2C at the beginning of the work on Diameter=2C CMS (Crypt= ographic Message Syntax) was identified as solution to provide AVP-level E2= E security but this work was not completed due to lack of deployment intere= st (at least at that time) and the foreseen complexity of the developed sol= ution for Diameter.
=0A=
=0A= Due to the renewed interest for E2E security over Diameter=2C mainly for in= ter-domain signaling in the mobile network environment=2C the DIME WG has d= ecided to reactivate the work on E2E security for Diameter. The first step = is almost completed=2C with a document (draft-ietf-dime-e2e-sec-req-02) def= ining the requirements for an AVP-level E2E security solution. The second s= tep will be work on the specification of such mechanism. An early proposal = was to derive a solution from JOSE=2C encapsulating JOSE objects for integr= ity protection and AVP encryption. It is however expected that other mechan= isms could be proposed as candidate solutions. And we know already that the= re are existing discussions on alternative to JOSE (e.g. COSE).
=0A=
=0A= Whatever the proposed solution(s)=2Cthe DIME WG has not (and will not have)= the expertise required to evaluate and select the more appropriate securit= y mechanism for E2E security over Diameter. We are therefore interested by = any guidance and support from SAAG regarding the development of a solution = for E2E security over Diameter=2C based on the requirements collected in dr= aft-ietf-dime-e2e-sec-req-02.
=0A=
=0A= Regards=2C
=0A=
=0A= Lionel
=0A=
=0A= ___________________________________________________________________________= ______________________________________________
=0A=
=0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
=0A= pas etre diffuses=2C exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur=2C veuillez le signaler
=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration=2C
=0A= Orange decline toute responsabilite si ce message a ete altere=2C deforme o= u falsifie. Merci.
=0A=
=0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law=3B
=0A= they should not be distributed=2C used or copied without authorisation.
= =0A= If you have received this email in error=2C please notify the sender and de= lete this message and its attachments.
=0A= As emails may be altered=2C Orange is not liable for messages that have bee= n modified=2C changed or falsified.
=0A= Thank you.
=0A=
=0A= _______________________________________________
=0A= saag mailing list
=0A= saag@ietf.org
=0A= ht= tps://www.ietf.org/mailman/listinfo/saag
=0A=



--

Best regards=2C
Kathleen
=0A=
=0A=
_______________________________________________=0A= saag mailing list=0A= saag@ietf.org=0A= https://www.ietf.org/mailman/listinfo/saag
= --_dfed88d6-5b1b-41ab-9ba3-b365f6d5c24a_-- From nobody Tue Apr 21 13:09:24 2015 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 39AEE1A1B69 for ; Tue, 21 Apr 2015 13:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2JXjzOonSFW for ; Tue, 21 Apr 2015 13:09:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87501A1A2D for ; Tue, 21 Apr 2015 13:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72DDABEDA; Tue, 21 Apr 2015 21:09:19 +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 3V9JW8PGiqAb; Tue, 21 Apr 2015 21:09:17 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6CD62BED0; Tue, 21 Apr 2015 21:09:17 +0100 (IST) Message-ID: <5536AE6D.4000202@cs.tcd.ie> Date: Tue, 21 Apr 2015 21:09:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bernard Aboba , Kathleen Moriarty , "lionel.morand@orange.com" References: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup>, In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [saag] Request for guidance regarding E2E security over Diameter 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, 21 Apr 2015 20:09:23 -0000 On 21/04/15 18:51, Bernard Aboba wrote: > In practice, as I understand it, Diameter implementations utilize no > transport security at all - TLS, DTLS, Ipsec, etc. are not being > used. Since Diameter has no application security either, the only > security deployed in the wild is firewalls. Since an unprotected > Diameter session carries information relating to user privacy such as > usernames, location, etc. this makes it easy for an attacker snooping > on the network to reap a bonanza of personal information about you - > including your location at every moment. As the former AAA WG Chair > who closed work on e2e security due to lack of interest from > implementers, I am gratified to hear that work on e2e security is > once again being considered. However, it is a bit like having an > illiterate express interest in reading Proust -- an admirable > sentiment, but there are a few hurdles to get over first... Heh. Yeah, I remember the previous Diameter e2e thing and how it fizzled. I'm not up to speed on whether or not deployments are turning on security, but in terms of RFC text things have gotten better - I think the security stuff in RFC6733 shouldn't be too hard to deploy at all. Of course, if it's only paper and not in use, then yeah, things aren't really better. I would have thought though that the likes of the Belgacom and Gemalto incidents might have finally convinced AAA deployments that they do need to turn this stuff on. If not, then I guess we'll have to wait until some legislator or insurance company forces 'em to do the right thing maybe. But, maybe Lionel can say some more about the current state of play? S. > > Date: Tue, 21 Apr 2015 13:26:07 -0400 From: > kathleen.moriarty.ietf@gmail.com To: lionel.morand@orange.com CC: > saag@ietf.org; dime-chairs@tools.ietf.org Subject: Re: [saag] Request > for guidance regarding E2E security over Diameter > > Hello, A few weeks have past and I don't see any response to this > request on-list. Are there any volunteers that would like to assist > DIME with e2e encryption for Diameter as described in Lionel's > message? Thanks,Kathleen On Thu, Mar 26, 2015 at 12:24 PM, > wrote: Hi, > > > > As currently specified, the Diameter Base protocol (RFC6733) only > offers transport level protection between neighboring Diameter peers, > using either TLS/TCP, DTLS/SCTP, or IPsec as last resort. However, no > mechanism has been defined to ensure E2E security for data (in the > conveyed (in the form of Attribute-Value Pairs (AVPs)) in Diameter > messages between two endpoints. Early 2000, at the beginning of the > work on Diameter, CMS (Cryptographic Message Syntax) was identified > as solution to provide AVP-level E2E security but this work was not > completed due to lack of deployment interest (at least at that time) > and the foreseen complexity of the developed solution for Diameter. > > > > Due to the renewed interest for E2E security over Diameter, mainly > for inter-domain signaling in the mobile network environment, the > DIME WG has decided to reactivate the work on E2E security for > Diameter. The first step is almost completed, with a document > (draft-ietf-dime-e2e-sec-req-02) defining the requirements for an > AVP-level E2E security solution. The second step will be work on the > specification of such mechanism. An early proposal was to derive a > solution from JOSE, encapsulating JOSE objects for integrity > protection and AVP encryption. It is however expected that other > mechanisms could be proposed as candidate solutions. And we know > already that there are existing discussions on alternative to JOSE > (e.g. COSE). > > > > Whatever the proposed solution(s),the DIME WG has not (and will not > have) the expertise required to evaluate and select the more > appropriate security mechanism for E2E security over Diameter. We are > therefore interested by any guidance and support from SAAG regarding > the development of a solution for E2E security over Diameter, based > on the requirements collected in draft-ietf-dime-e2e-sec-req-02. > > > > Regards, > > > > Lionel > > > > _________________________________________________________________________________________________________________________ > > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without > authorisation. > > If you have received this email in error, please notify the sender > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Apr 22 03:00:49 2015 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 C2C9C1B3148 for ; Wed, 22 Apr 2015 03:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4i6c1frng4Kk for ; Wed, 22 Apr 2015 03:00:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EB11B33A8 for ; Wed, 22 Apr 2015 03:00:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6D33D2DC499; Wed, 22 Apr 2015 12:00:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 480634C0AD; Wed, 22 Apr 2015 12:00:36 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 22 Apr 2015 12:00:36 +0200 From: To: Stephen Farrell , Bernard Aboba , Kathleen Moriarty Thread-Topic: [saag] Request for guidance regarding E2E security over Diameter Thread-Index: AdBn4UO6eeHIiYWPTtOuFgAIOEZrZAUZjjyAAADfXwAABNN0gAAgVc4A Date: Wed, 22 Apr 2015 10:00:35 +0000 Message-ID: <8137_1429696836_55377144_8137_810_1_6B7134B31289DC4FAF731D844122B36E01049080@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <26716_1427387066_551432BA_26716_9790_2_6B7134B31289DC4FAF731D844122B36EEAF5B8@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5536AE6D.4000202@cs.tcd.ie> In-Reply-To: <5536AE6D.4000202@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.13.120621 Archived-At: Cc: "saag@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [saag] Request for guidance regarding E2E security over Diameter 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, 22 Apr 2015 10:00:47 -0000 SGkgU3RlcGhlbiwNCg0KV2hlbiBEaWFtZXRlciB3YXMgdXNlZCBpbiBNb2JpbGUgbmV0d29ya3Mg Zm9yIEFBQS1saWtlIHByb2NlZHVyZXMgKHVzZXIgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRp b24gcHJvZmlsZSBtYW5hZ2VtZW50LCBldGMuKSwgdGhlIGV4aXN0aW5nIGhvcC1ieS1ob3Agc2Vj dXJpdHkgd2FzIHF1aXRlIE9LLCB0aGUgb3ZlcmFsbCBzZWN1cml0eSByZWx5aW5nIG9uIHRydXN0 IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG1vYmlsZSBvcGVyYXRvcnMsIHRocm91Z2ggcGVlcmluZyBh Z3JlZW1lbnRzIG9yIHZpYSBHU01BIHJvYW1pbmcgYWdyZWVtZW50cy4gRXNwZWNpYWxseSBpbiB0 aGUgZWFybHkgZGVwbG95bWVudCBvZiA0RyBuZXR3b3JrcyBpbiB3aGljaCBmZXcgcGxheWVycyB3 ZXJlIGluIHRoZSBnYW1lIHdoZW4gY29uc2lkZXJpbmcgcm9hbWluZyB1c2UgY2FzZXMuDQoNCk5v dywgdGhlIG51bWJlciBvZiByb2FtaW5nIHBhcnRuZXJzIGlzIGluY3JlYXNpbmcgYW5kIG5ldyBt b2RlbHMgbGlrZSByb2FtaW5nIGh1YiBhcmUgZGVwbG95ZWQuIE1vcmVvdmVyLCBEaWFtZXRlciBp cyBub3cgdXNlZCBhbHNvIGZvciBvdGhlciBwdXJwb3Nlcywgc3VjaCBhcyB0cmFuc3BvcnQgb2Yg U01TLiBGaW5hbGx5LCBEaWFtZXRlciBoYXMgYmVlbiBlbmhhbmNlZCB0byBzdXBwb3J0IG92ZXJs b2FkIGNvbnRyb2wgbWVjaGFuaXNtIGluIHdoaWNoIG92ZXJsb2FkIGluZGljYXRpb24gaXMgZXhj aGFuZ2VkIEUyRSBiZXR3ZWVuIG1vYmlsZSBuZXR3b3Jrcy4gDQpJbiBhbGwgdGhlc2UgdXNlIGNh c2VzLCB0aGUgcHJpbWFyeSBzZWN1cml0eSByZXF1aXJlbWVudCBpcyByZWxhdGVkIHRvIGRhdGEg b3JpZ2luIGF1dGhlbnRpY2F0aW9uIHdoZW4gcmVxdWVzdHMgYXJlIGNvbnZleWVkIHNvbWV0aW1l cyB0aHJvdWdoIG9uZSBvciBtb3JlIGludGVybWVkaWFyaWVzLg0KVGhlcmUgbWF5IGJlIG90aGVy IHJlcXVpcmVtZW50cyAoSSBoYXZlIHRvIGRvdWJsZSBjaGVjaykgYnV0IEkgdGhpbmsgdGhhdCB0 aGUgdXNlIGNhc2VzIGdpdmVuIGFib3ZlIGFyZSBlbm91Z2ggdG8gcmVhY3RpdmF0ZSB0aGUgd29y ayBvbiBFMkUgc2VjdXJpdHkgZm9yIERpYW1ldGVyLiBPYnZpb3VzbHksIHRoZSBmaW5hbCBFMkUg c2VjdXJpdHkgZnJhbWV3b3JrIHdvdWxkIGhhdmUgdG8gc3VwcG9ydCBvdGhlciBwb3NzaWJsZSAo ZnV0dXJlKSB1c2UgY2FzZXMuIA0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KDQotLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWVdIA0KRW52b3nDqcKgOiBtYXJkaSAyMSBhdnJpbCAyMDE1IDIyOjA5 DQrDgMKgOiBCZXJuYXJkIEFib2JhOyBLYXRobGVlbiBNb3JpYXJ0eTsgTU9SQU5EIExpb25lbCBJ TVQvT0xODQpDY8KgOiBzYWFnQGlldGYub3JnOyBkaW1lLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K T2JqZXTCoDogUmU6IFtzYWFnXSBSZXF1ZXN0IGZvciBndWlkYW5jZSByZWdhcmRpbmcgRTJFIHNl Y3VyaXR5IG92ZXIgRGlhbWV0ZXINCg0KDQoNCk9uIDIxLzA0LzE1IDE4OjUxLCBCZXJuYXJkIEFi b2JhIHdyb3RlOg0KPiBJbiBwcmFjdGljZSwgYXMgSSB1bmRlcnN0YW5kIGl0LCBEaWFtZXRlciBp bXBsZW1lbnRhdGlvbnMgdXRpbGl6ZSBubyANCj4gdHJhbnNwb3J0IHNlY3VyaXR5IGF0IGFsbCAt ICBUTFMsIERUTFMsIElwc2VjLCBldGMuIGFyZSBub3QgYmVpbmcgDQo+IHVzZWQuICBTaW5jZSBE aWFtZXRlciBoYXMgbm8gYXBwbGljYXRpb24gc2VjdXJpdHkgZWl0aGVyLCB0aGUgb25seSANCj4g c2VjdXJpdHkgZGVwbG95ZWQgaW4gdGhlIHdpbGQgaXMgZmlyZXdhbGxzLiAgU2luY2UgYW4gdW5w cm90ZWN0ZWQgDQo+IERpYW1ldGVyIHNlc3Npb24gY2FycmllcyBpbmZvcm1hdGlvbiByZWxhdGlu ZyB0byB1c2VyIHByaXZhY3kgc3VjaCBhcyANCj4gdXNlcm5hbWVzLCBsb2NhdGlvbiwgZXRjLiB0 aGlzIG1ha2VzIGl0IGVhc3kgZm9yIGFuIGF0dGFja2VyIHNub29waW5nIA0KPiBvbiB0aGUgbmV0 d29yayB0byByZWFwIGEgYm9uYW56YSBvZiBwZXJzb25hbCBpbmZvcm1hdGlvbiBhYm91dCB5b3Ug LSANCj4gaW5jbHVkaW5nIHlvdXIgbG9jYXRpb24gYXQgZXZlcnkgbW9tZW50LiBBcyB0aGUgZm9y bWVyIEFBQSBXRyBDaGFpciANCj4gd2hvIGNsb3NlZCB3b3JrIG9uIGUyZSBzZWN1cml0eSBkdWUg dG8gbGFjayBvZiBpbnRlcmVzdCBmcm9tIA0KPiBpbXBsZW1lbnRlcnMsIEkgYW0gZ3JhdGlmaWVk IHRvIGhlYXIgdGhhdCB3b3JrIG9uIGUyZSBzZWN1cml0eSBpcw0KPiBvbmNlIGFnYWluIGJlaW5n IGNvbnNpZGVyZWQuICAgSG93ZXZlciwgaXQgaXMgYSBiaXQgbGlrZSBoYXZpbmcgYW4NCj4gaWxs aXRlcmF0ZSBleHByZXNzIGludGVyZXN0IGluIHJlYWRpbmcgUHJvdXN0IC0tIGFuIGFkbWlyYWJs ZSANCj4gc2VudGltZW50LCBidXQgdGhlcmUgYXJlIGEgZmV3IGh1cmRsZXMgdG8gZ2V0IG92ZXIg Zmlyc3QuLi4NCg0KSGVoLiBZZWFoLCBJIHJlbWVtYmVyIHRoZSBwcmV2aW91cyBEaWFtZXRlciBl MmUgdGhpbmcgYW5kIGhvdyBpdCBmaXp6bGVkLiBJJ20gbm90IHVwIHRvIHNwZWVkIG9uIHdoZXRo ZXIgb3Igbm90IGRlcGxveW1lbnRzIGFyZSB0dXJuaW5nIG9uIHNlY3VyaXR5LCBidXQgaW4gdGVy bXMgb2YgUkZDIHRleHQgdGhpbmdzIGhhdmUgZ290dGVuIGJldHRlciAtIEkgdGhpbmsgdGhlIHNl Y3VyaXR5IHN0dWZmIGluIFJGQzY3MzMgc2hvdWxkbid0IGJlIHRvbyBoYXJkIHRvIGRlcGxveSBh dCBhbGwuIE9mIGNvdXJzZSwgaWYgaXQncyBvbmx5IHBhcGVyIGFuZCBub3QgaW4gdXNlLCB0aGVu IHllYWgsIHRoaW5ncyBhcmVuJ3QgcmVhbGx5IGJldHRlci4NCg0KSSB3b3VsZCBoYXZlIHRob3Vn aHQgdGhvdWdoIHRoYXQgdGhlIGxpa2VzIG9mIHRoZSBCZWxnYWNvbSBhbmQgR2VtYWx0byBpbmNp ZGVudHMgbWlnaHQgaGF2ZSBmaW5hbGx5IGNvbnZpbmNlZCBBQUEgZGVwbG95bWVudHMgdGhhdCB0 aGV5IGRvIG5lZWQgdG8gdHVybiB0aGlzIHN0dWZmIG9uLiBJZiBub3QsIHRoZW4gSSBndWVzcyB3 ZSdsbCBoYXZlIHRvIHdhaXQgdW50aWwgc29tZSBsZWdpc2xhdG9yIG9yIGluc3VyYW5jZSBjb21w YW55IGZvcmNlcyAnZW0gdG8gZG8gdGhlIHJpZ2h0IHRoaW5nIG1heWJlLg0KDQpCdXQsIG1heWJl IExpb25lbCBjYW4gc2F5IHNvbWUgbW9yZSBhYm91dCB0aGUgY3VycmVudCBzdGF0ZSBvZiBwbGF5 Pw0KDQpTLg0KDQo+IA0KPiBEYXRlOiBUdWUsIDIxIEFwciAyMDE1IDEzOjI2OjA3IC0wNDAwIEZy b206DQo+IGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIFRvOiBsaW9uZWwubW9yYW5k QG9yYW5nZS5jb20gQ0M6DQo+IHNhYWdAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQHRvb2xzLmlldGYu b3JnIFN1YmplY3Q6IFJlOiBbc2FhZ10gUmVxdWVzdCANCj4gZm9yIGd1aWRhbmNlIHJlZ2FyZGlu ZyBFMkUgc2VjdXJpdHkgb3ZlciBEaWFtZXRlcg0KPiANCj4gSGVsbG8sIEEgZmV3IHdlZWtzIGhh dmUgcGFzdCBhbmQgSSBkb24ndCBzZWUgYW55IHJlc3BvbnNlIHRvIHRoaXMgDQo+IHJlcXVlc3Qg b24tbGlzdC4gIEFyZSB0aGVyZSBhbnkgdm9sdW50ZWVycyB0aGF0IHdvdWxkIGxpa2UgdG8gYXNz aXN0IA0KPiBESU1FIHdpdGggZTJlIGVuY3J5cHRpb24gZm9yIERpYW1ldGVyIGFzIGRlc2NyaWJl ZCBpbiBMaW9uZWwncyANCj4gbWVzc2FnZT8gVGhhbmtzLEthdGhsZWVuIE9uIFRodSwgTWFyIDI2 LCAyMDE1IGF0IDEyOjI0IFBNLCANCj4gPGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4gd3JvdGU6 IEhpLA0KPiANCj4gDQo+IA0KPiBBcyBjdXJyZW50bHkgc3BlY2lmaWVkLCB0aGUgRGlhbWV0ZXIg QmFzZSBwcm90b2NvbCAoUkZDNjczMykgb25seSANCj4gb2ZmZXJzIHRyYW5zcG9ydCBsZXZlbCBw cm90ZWN0aW9uIGJldHdlZW4gbmVpZ2hib3JpbmcgRGlhbWV0ZXIgcGVlcnMsIA0KPiB1c2luZyBl aXRoZXIgVExTL1RDUCwgRFRMUy9TQ1RQLCBvciBJUHNlYyBhcyBsYXN0IHJlc29ydC4gSG93ZXZl ciwgbm8gDQo+IG1lY2hhbmlzbSBoYXMgYmVlbiBkZWZpbmVkIHRvIGVuc3VyZSBFMkUgc2VjdXJp dHkgZm9yIGRhdGEgKGluIHRoZSANCj4gY29udmV5ZWQgKGluIHRoZSBmb3JtIG9mIEF0dHJpYnV0 ZS1WYWx1ZSBQYWlycyAoQVZQcykpIGluIERpYW1ldGVyIA0KPiBtZXNzYWdlcyBiZXR3ZWVuIHR3 byBlbmRwb2ludHMuIEVhcmx5IDIwMDAsIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIA0KPiB3b3Jr IG9uIERpYW1ldGVyLCBDTVMgKENyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXgpIHdhcyBpZGVu dGlmaWVkIGFzIA0KPiBzb2x1dGlvbiB0byBwcm92aWRlIEFWUC1sZXZlbCBFMkUgc2VjdXJpdHkg YnV0IHRoaXMgd29yayB3YXMgbm90IA0KPiBjb21wbGV0ZWQgZHVlIHRvIGxhY2sgb2YgZGVwbG95 bWVudCBpbnRlcmVzdCAoYXQgbGVhc3QgYXQgdGhhdCB0aW1lKSANCj4gYW5kIHRoZSBmb3Jlc2Vl biBjb21wbGV4aXR5IG9mIHRoZSBkZXZlbG9wZWQgc29sdXRpb24gZm9yIERpYW1ldGVyLg0KPiAN Cj4gDQo+IA0KPiBEdWUgdG8gdGhlIHJlbmV3ZWQgaW50ZXJlc3QgZm9yIEUyRSBzZWN1cml0eSBv dmVyIERpYW1ldGVyLCBtYWlubHkgZm9yIA0KPiBpbnRlci1kb21haW4gc2lnbmFsaW5nIGluIHRo ZSBtb2JpbGUgbmV0d29yayBlbnZpcm9ubWVudCwgdGhlIERJTUUgV0cgDQo+IGhhcyBkZWNpZGVk IHRvIHJlYWN0aXZhdGUgdGhlIHdvcmsgb24gRTJFIHNlY3VyaXR5IGZvciBEaWFtZXRlci4gVGhl IA0KPiBmaXJzdCBzdGVwIGlzIGFsbW9zdCBjb21wbGV0ZWQsIHdpdGggYSBkb2N1bWVudA0KPiAo ZHJhZnQtaWV0Zi1kaW1lLWUyZS1zZWMtcmVxLTAyKSBkZWZpbmluZyB0aGUgcmVxdWlyZW1lbnRz IGZvciBhbiANCj4gQVZQLWxldmVsIEUyRSBzZWN1cml0eSBzb2x1dGlvbi4gVGhlIHNlY29uZCBz dGVwIHdpbGwgYmUgd29yayBvbiB0aGUgDQo+IHNwZWNpZmljYXRpb24gb2Ygc3VjaCBtZWNoYW5p c20uIEFuIGVhcmx5IHByb3Bvc2FsIHdhcyB0byBkZXJpdmUgYSANCj4gc29sdXRpb24gZnJvbSBK T1NFLCBlbmNhcHN1bGF0aW5nIEpPU0Ugb2JqZWN0cyBmb3IgaW50ZWdyaXR5IA0KPiBwcm90ZWN0 aW9uIGFuZCBBVlAgZW5jcnlwdGlvbi4gSXQgaXMgaG93ZXZlciBleHBlY3RlZCB0aGF0IG90aGVy IA0KPiBtZWNoYW5pc21zIGNvdWxkIGJlIHByb3Bvc2VkIGFzIGNhbmRpZGF0ZSBzb2x1dGlvbnMu IEFuZCB3ZSBrbm93IA0KPiBhbHJlYWR5IHRoYXQgdGhlcmUgYXJlIGV4aXN0aW5nIGRpc2N1c3Np b25zIG9uIGFsdGVybmF0aXZlIHRvIEpPU0UgDQo+IChlLmcuIENPU0UpLg0KPiANCj4gDQo+IA0K PiBXaGF0ZXZlciB0aGUgcHJvcG9zZWQgc29sdXRpb24ocyksdGhlIERJTUUgV0cgaGFzIG5vdCAo YW5kIHdpbGwgbm90DQo+IGhhdmUpIHRoZSBleHBlcnRpc2UgcmVxdWlyZWQgdG8gZXZhbHVhdGUg YW5kIHNlbGVjdCB0aGUgbW9yZSANCj4gYXBwcm9wcmlhdGUgc2VjdXJpdHkgbWVjaGFuaXNtIGZv ciBFMkUgc2VjdXJpdHkgb3ZlciBEaWFtZXRlci4gV2UgYXJlIA0KPiB0aGVyZWZvcmUgaW50ZXJl c3RlZCBieSBhbnkgZ3VpZGFuY2UgYW5kIHN1cHBvcnQgZnJvbSBTQUFHIHJlZ2FyZGluZyANCj4g dGhlIGRldmVsb3BtZW50IG9mIGEgc29sdXRpb24gZm9yIEUyRSBzZWN1cml0eSBvdmVyIERpYW1l dGVyLCBiYXNlZCBvbiANCj4gdGhlIHJlcXVpcmVtZW50cyBjb2xsZWN0ZWQgaW4gZHJhZnQtaWV0 Zi1kaW1lLWUyZS1zZWMtcmVxLTAyLg0KPiANCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gDQo+ IA0KPiBMaW9uZWwNCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gDQo+IA0KPiANCj4g Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIA0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYw0KPiANCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiANCj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IA0KPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgDQo+IG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gDQo+IE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCAN Cj4gZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiANCj4gDQo+IFRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciANCj4gcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiANCj4g dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQo+IA0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIA0KPiBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IA0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgDQo+IGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiANCj4gVGhhbmsgeW91Lg0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4g c2FhZyBtYWlsaW5nIGxpc3QNCj4gDQo+IHNhYWdAaWV0Zi5vcmcNCj4gDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNhYWcgbWFpbGlu ZyBsaXN0IA0KPiBzYWFnQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FhZw0KPiANCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Apr 29 07:41:17 2015 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 EAD5F1A9302; Wed, 29 Apr 2015 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQpfwHWUPanh; Wed, 29 Apr 2015 07:41:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896361A92FC; Wed, 29 Apr 2015 07:41:13 -0700 (PDT) Received: from [192.168.2.100] ([79.246.0.185]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M2WgT-1Z6EPT3GuD-00sLJa; Wed, 29 Apr 2015 16:41:11 +0200 Message-ID: <5540ED82.5060905@gmx.net> Date: Wed, 29 Apr 2015 16:41:06 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org, Kathleen Moriarty Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4DcQihFGmy8BHMyzut72DzFwrrscnBtvP9t1dsdx1Yb/gZCz1sm fliv5NzKv4ffuyEKs0Ostm+RboG1wEdT42zlnYhYObFhqOUWObTK/QElc3oYDRV1eEauuSK 0tkQZCoyksr6Z3Tye4smX21WJvpKg75fPncJv8d555eUFMM0mjK4rGKX8O+jBSgoFsnFZgs J5u3NQMA3scJOo27OvKcA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) 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, 29 Apr 2015 14:41:16 -0000 Dear community, I have post the attached draft and looking for feedback from people with security management and / or security (IDS) operations expertise (including IDS developer). I am particularly interested in your opinions on the communication proceedings, the parametrization methodology and the provided attributes (and such I did not think of). If the text needs updating by your point of view, please let me know that as well. Here is the link to the new draft: http://www.ietf.org/id/draft-boesch-idxp-idpef-01.txt At the first view the draft looks very long but after page 44 a lot of examples and definitions are included for better understanding. So the first 43 pages are primary in scope for feedback but feedback for the other pages is welcome, too. Abstract The Intrusion Detection Parametrization Exchange Format (IDPEF) defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from an independent central Manager to any Analyzer. The IDPEF enables a combination of different (vendor and analyzing technique) IDS Analyzers under one independent central Manager. A separate operations of IDS is not longer needed. Base is a new parametrization methodology where IDS operating parameters (configurations) are separated in an environmental parametrization part and a vendor-specific analyzing part. This Internet-Draft describes a data model to represent parametrization information of intrusion detection system entities, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, a XML Document Type Definition is developed, and parametrization examples are provided. I am looking forward to your suggestions, feedback, notations, hints, recommendations, etc. to improve the Internet Draft. Also native speaker feedback with scope on wording and typo is welcome. Kind regards, Bjoern-C. From nobody Thu Apr 30 00:55:54 2015 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 29AAB1ACEDC for ; Thu, 30 Apr 2015 00:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wulk_StYvxb for ; Thu, 30 Apr 2015 00:55:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFA41ACEDA for ; Thu, 30 Apr 2015 00:55:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E27CBDD8 for ; Thu, 30 Apr 2015 08:55:49 +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 YK2rgodOxx4l for ; Thu, 30 Apr 2015 08:55:47 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.22]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 786A7BE2F for ; Thu, 30 Apr 2015 08:55:47 +0100 (IST) Message-ID: <5541E003.4040202@cs.tcd.ie> Date: Thu, 30 Apr 2015 08:55:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <43A6F50F-A9F2-4708-ADD1-879309ABB386@mnot.net> In-Reply-To: <43A6F50F-A9F2-4708-ADD1-879309ABB386@mnot.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <43A6F50F-A9F2-4708-ADD1-879309ABB386@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: [apps-discuss] Fwd: First Public Working Draft: Web Payments Use Cases 1.0 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, 30 Apr 2015 07:55:53 -0000 FYI'ing and FYI:-) I think (not 100% sure) that if this work within W3C proceeded there might well be a need to deploy an associated digital signature mechanism. So if that's of interest to you, you may want to check this out. Cheers, S. -------- Forwarded Message -------- Subject: [apps-discuss] Fwd: First Public Working Draft: Web Payments Use Cases 1.0 Date: Thu, 30 Apr 2015 10:13:59 +1000 From: Mark Nottingham To: IETF Apps Discuss FYI - W3C is beginning work on Web Payments. > Begin forwarded message: > > Web Payments Use Cases 1.0 > W3C First Public Working Draft 16 April 2015 > > http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/ > > Abstract > > This document is a prioritized list of Web payments use cases. Guided by these use cases, the W3C Web Payments Interest Group plans to derive architecture and associated technology requirements to integrate payments into the Open Web Platform. That work will form the basis of conversations with W3C groups and the broader payments industry about what standards (from W3C or other organizations) will be necessary to fulfill the use cases and make payments over the Web easier and more secure. > > Status > > The Web Payments IG has only had the opportunity to review a handful of the 40+ use cases, 120+ requirements, hundreds of pages of payments research submitted to the group via various other standards group output such as ISO20022, research documents from X9 and the US Federal Reserve, documents from the Web Payments Community Group, and input from the general public. Our desire is to align with the larger payments industry when it's possible to do so. Expect this document to be rapidly iterated upon with that desire in mind. > [...] > If you wish to make comments regarding this document, please send them to public-webpayments-comments@w3.org -- Mark Nottingham https://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss