From nobody Tue Mar 4 06:43:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748F41A0264 for ; Tue, 4 Mar 2014 06:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 OAVGQTrM3qdp for ; Tue, 4 Mar 2014 06:43:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BB3011A0274 for ; Tue, 4 Mar 2014 06:43:42 -0800 (PST) Received: from [192.168.10.253] ([31.133.156.1]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M6jIK-1X5wyM3T1w-00wUXr for ; Tue, 04 Mar 2014 15:43:39 +0100 Message-ID: <5315E699.4060605@gmx.net> Date: Tue, 04 Mar 2014 15:43:37 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CCIAplkgXLp3LpFNHILSvHp8LFQDowFm6" X-Provags-ID: V03:K0:VHpPhNsLsxzTIERO+6aKu91Il/xHm57vMcLwJ8t53bEAI+k4Ef5 afvvbmQQR/nwJ1xu3q+v8h9IgBY5SljLwnCZyTWEWLGvgLk3I0SASQrfDkkY7yx+jeWYmUV jTPoq5q2m7WrPqIWrw+lPWDieolfOXWQ0FhRjLPKp07IjCRc2V/2Y4liuWowq+XOE/VbZnW 4N8MnazVC9n64UZBre55A== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JqT0uhWyiuda1Gj75btxs6OhjcU Subject: [saag] BOF about Authentication and Authorization for Constrained Environments (ace) 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, 04 Mar 2014 14:43:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CCIAplkgXLp3LpFNHILSvHp8LFQDowFm6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, on Wednesday, March 5, 9:00am - 11:30am the ACE BOF will take place in the Balmoral room. Although the BOF is in the applications area I believe it has lots of security relevant content. The IETF security community has worked on a number of technologies that could be applicable for the IoT environment. It would be great if some of you have time to join and give us feedback. Ciao Hannes --CCIAplkgXLp3LpFNHILSvHp8LFQDowFm6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFeaZAAoJEGhJURNOOiAtd5UH/iQ4HStTUmIKzqK5CDnbU3la O+p5zs/AednI2/3xGy33bkNOw2EK6O9DvDPJNY9+6mAFFr5VfH+ujRAaJhV2/WOh LQUf1M4X11eeotZuv5S0Yg0bi34NgYTmuXYaxflSVq02dsfvjyoo2nalJLKxNKoX u35aiolqRTgqj96g3I8g0bWqzbywKd9lZsfLXSNf15pMJCSvxdA/qXbeJyxiUAC4 MPzzoLruG8NgaWbyRwY/+CntTKOOBPu+FzUj6+AvQFQoNhGLtWv1bY9YBoel5lj/ dFbt/SG2XJXNTxgnxtleV1lzA4B8aM8apvn1Id6GPbHltkgJTugGRia9/Q051HQ= =XWee -----END PGP SIGNATURE----- --CCIAplkgXLp3LpFNHILSvHp8LFQDowFm6-- From nobody Tue Mar 4 08:59:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46C1A01A8 for ; Tue, 4 Mar 2014 08:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 bzX-uWLlcTMB for ; Tue, 4 Mar 2014 08:59:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1001A00F5 for ; Tue, 4 Mar 2014 08:59:06 -0800 (PST) Received: from [192.168.10.253] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lkwc9-1WtO9T0lJl-00ajzV for ; Tue, 04 Mar 2014 17:59:02 +0100 Message-ID: <53160654.3030708@gmx.net> Date: Tue, 04 Mar 2014 17:59:00 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DQaUFBv6s9mtnTTTv6g0NpCEwREXQ0WXe" X-Provags-ID: V03:K0:WEUQcFOPUh1W7uW7wKGu6SKmZj+i68MMGJx8WlCitoFCFKNjs/E U8TtF8vMaIaaSaQbr2AQvkIoJYuUgYWWz7BW+D+YE+8mxQifKstbarP66crBICwWsxX2R0v Bfssgh5Zy6qTY8hQ+H2sTfSFY8VdaMbukY+tv+Tsw7bqTw340Qj9flsHXAQtKSBiDP0RKl3 T0RTv//zDqLH8C7NPZe0w== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qsrdnvT_0dFKEutgOoIGP_6g6zE Subject: [saag] IETF#89 OAuth Meeting Summary 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, 04 Mar 2014 16:59:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DQaUFBv6s9mtnTTTv6g0NpCEwREXQ0WXe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This morning we had our OAuth working group meeting and here is a short summary of the discussion. * JSON Web Token (JWT)=09 Mike Jones, specification editor, has updated the specification to incorporate the remaining WGLC review comments. The reviewers will have to check whether their feedback has been addresses appropriately. The document is then ready to be forwarded to the IESG for publication but the completion will depend on the finalization of the work in the JOSE WG. The chairs will work on the shepherd write-up. * Assertions The group worked on the use of assertions for client authentication as well as an authorization grant type. The work is documented in three specifications (draft-ietf-oauth-assertions-14, draft-ietf-oauth-jwt-bearer-07, and draft-ietf-oauth-saml2-bearer-18). The assertion framework and the SAML bearer specification are completed and waiting for a publication request by the chairs. During the meeting we decided to put the third document, draft-ietf-oauth-jwt-bearer-07, forward to the IESG at the same time as the other two documents for easier readability. Since draft-ietf-oauth-jwt-bearer-07 depends on the completion of the JWT specification, and that furthermore depends on the work in the JOSE WG to complete there might be a little bit of delay. * Dynamic Client Registration A large part of the time was used to discuss this topic. There are currently three document: - Core: draft-ietf-oauth-dyn-reg-16 - Meta-data: draft-ietf-oauth-dyn-reg-metadata-00 - Management: draft-ietf-oauth-dyn-reg-management-00 The core and meta-data was seen as rather uncontroversial but these two documents will require reviews and several persons volunteered. The management specification, however, raised questions. Concerns were raised about the maturity of the work and suggestions were to add text to the draft to highlight that it is only one possible solution. Changing the document to an Informational or Experimental document was also suggested. The chairs will schedule an informal discussion during this IETF week to get a better understanding of the software development lifecyle and the associated requirements for management of credentials and configuration parameters. * Security The chairs presented a summary of the current state of the work for developing mechanisms that provide security properties beyond bearer tokens. The bearer token concept is described in RFC 6750. Currently, the solutions are documented in draft-ietf-oauth-v2-http-mac-05, and draft-tschofenig-oauth-hotk-03. Based on a discussion last Sunday morning the existing documents will be re-structured and the f2f meeting was used to solicit feedback. We hope to have text within the next few weeks so that those who are deploying solutions already today can be involved in the work. A charter and a milestone update will be necessary to accommodate for the document split. --DQaUFBv6s9mtnTTTv6g0NpCEwREXQ0WXe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFgZUAAoJEGhJURNOOiAtw/YIAKVMmtHQCaUYdUzhGL7NxpNe fSKZkecdK4r3HeU/KBlr4txmA+Bt5F/b8Q3QPX5D3EYtAtIW6ZIKHY7z/rS4Y3PM B+8PpGNUpq7AdhecJoy0hI4xf3lDgAzJLBrPpefy90mUiWxwB11lSjyjw9RUzyJR g0a7eNlL5HmuqWXo557WSuYW5VHaBznr41c9nPhoXDIVjfn18xwgZlAn5zWKNQ3R 1rFrvQb6nCP39oVvd8cVrM5aQCTGDn6sl7jU1ToGb8vqhcxm1MdqUcjHCFgDVYHy 5p2THImZJQ+LbqjaK6yskDIVC9ccqiF0QGbZdsSM6M+kb8wpd48HeXPrdGKpquI= =22Zz -----END PGP SIGNATURE----- --DQaUFBv6s9mtnTTTv6g0NpCEwREXQ0WXe-- From nobody Wed Mar 5 03:30:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F641A0545 for ; Wed, 5 Mar 2014 03:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OLoCBimLP1j4 for ; Wed, 5 Mar 2014 03:30:03 -0800 (PST) Received: from out49-ams.mf.surf.net (out49-ams.mf.surf.net [145.0.1.49]) by ietfa.amsl.com (Postfix) with ESMTP id 23F151A0503 for ; Wed, 5 Mar 2014 03:30:02 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s25BTw9A023310 for ; Wed, 5 Mar 2014 12:29:58 +0100 Received: from dhcp-9b0e.meeting.ietf.org ([31.133.155.14]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WL9we-000EPN-Sm for saag@ietf.org; Wed, 05 Mar 2014 12:25:05 +0100 From: Klaas Wierenga Content-Type: multipart/signed; boundary="Apple-Mail=_6B3ACCD0-B18D-4522-9784-77220944C9CF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Wed, 5 Mar 2014 12:29:56 +0100 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vLxLtW8n - d506932a71e6 - 20140305 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/B-oDJ-zTWZCkpAl0greQxzeFSzs Subject: [saag] Abfab@IETF89 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, 05 Mar 2014 11:30:05 -0000 --Apple-Mail=_6B3ACCD0-B18D-4522-9784-77220944C9CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Abfab will not meet until Friday. Abfab is finishing up its charter = items, with AAA-SAML and UI-considerations being the last ones. Abfab = will discuss the possible use of ephemeral keying in abfab. Klaas & Leif --Apple-Mail=_6B3ACCD0-B18D-4522-9784-77220944C9CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlMXCrQACgkQH2Wy/p4XeFIgZwCfWyjQh6ZD8BOL5bLbSYHkV9Nj h2AAnj5lOr2RYIaHD+Om92VS9AFswEfe =Tu3Z -----END PGP SIGNATURE----- --Apple-Mail=_6B3ACCD0-B18D-4522-9784-77220944C9CF-- From nobody Wed Mar 5 05:53:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988631A01C0 for ; Wed, 5 Mar 2014 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 2wmyYnPYDSN5 for ; Wed, 5 Mar 2014 05:53:21 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id D48021A0100 for ; Wed, 5 Mar 2014 05:53:20 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s25DrGxi017263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Mar 2014 08:53:16 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s25DrGxi017263 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394027596; bh=VMyHeR+568UL5ebS46x1VZfTB0Q=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZNFW/hNgHCTfOagcU/cClouzHMZEDruoTOgTvacbmUmAz8ERddfK6+9rAMRksfOAC P08WVrzu96TWKcAPQOdZYlpKqSh6ssEq2KPvoJko4eO2CCIwvZWbvaOz+2rTbKk1ZH qXy590YxlSqJ7MGNmErz+LWEtNHn++M5MKNX3cew= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s25DrGxi017263 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Wed, 5 Mar 2014 08:53:07 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s25Dr7a7012931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 08:53:07 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Wed, 5 Mar 2014 08:53:06 -0500 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Wed, 5 Mar 2014 08:53:05 -0500 Thread-Topic: MILE Summary Thread-Index: AQHPOHo7hUWu5B5StkGfEQiJ6sbngQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Vae4fbH2a6kWaXBlah7nKk2deeY Subject: [saag] MILE Summary 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, 05 Mar 2014 13:53:23 -0000 The MILE working group is approaching last call for IODEF v2. It's a littl= e late, but the WG is actively working through consensus questions for the = data model. There will be some proposed work presented including: o An extension for cyber physical systems o PLASMA for MILE There will also be a presentation on JOSE use in MILE with potential issues= discussed. MILE meets Friday at 11:50. Kathleen and Brian will both need to step down as chairs, Alexey has agreed= to chair the group. A second chair will be appointed and Dave Waltermire = agreed to assist as a secretary for the group. Thanks, Kathleen= From nobody Wed Mar 5 06:38:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368E1A0636 for ; Wed, 5 Mar 2014 06:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 39oP773t0vJv for ; Wed, 5 Mar 2014 06:38:36 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3FC1A023C for ; Wed, 5 Mar 2014 06:38:35 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s25EcU8P031233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Mar 2014 14:38:31 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s25EcT2p005965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Mar 2014 14:38:30 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s25EcT7F023238 for ; Wed, 5 Mar 2014 14:38:29 GMT Received: from dhcp-a4a7.meeting.ietf.org (/10.175.58.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Mar 2014 06:38:29 -0800 Message-ID: <531736E4.6060906@oracle.com> Date: Wed, 05 Mar 2014 07:38:28 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <527A8565.6010403@oracle.com> In-Reply-To: <527A8565.6010403@oracle.com> X-Forwarded-Message-Id: <527A8565.6010403@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iIIewnsRo2dWj47YFMOQqJQXTqw Subject: [saag] kitten Summary - IETF 89 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, 05 Mar 2014 14:38:37 -0000 *Steps back out of time machine* Co-chairs: Sam Hartman, Shawn Emery, and Josh Howlett (DNA) The WG met for the Thursday Afternoon Session II (after the SAAG meeting) I've included the high-lighted topics on the agenda that were discussed: GS2 Updates Discussed updates to the SASL-GS2 specification to remove the requirement for mechanisms that do not provide mutual authentication. Updates to OAuth Discussed updates to the OAuth draft to remove GS2 related text. AES-SHA2 Discussed consensus results of draft-ietf-kitten-aes-cbc-hmac-sha2 to use CTS mode and the RFC 3961/3962 confounder algorithm. RFC 6112 and 4402 Issues Discussed issues with the associated RFCs: 6112: KeyExchange -> KEYEXCHANGE Anonymous KDC option MUST, not SHOULD, be set when using an anonymous ticket 4402: PRF starts counter at 1, however some implementations start at 0 Per-user Host-based Services and S4U2Proxy Improvements Discussed new drafts submitted: draft-dukhovni-using-wildcard-a-rrsets-00 draft-williams-kitten-impersonation-naming-attr-00 RFC 5653 Update Discussed proposal to update the RFC to include GSSException that provides an error token. Open mic There were no dissenting comments. Shawn. -- kitten co-chair From nobody Wed Mar 5 08:04:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16721A0041 for ; Wed, 5 Mar 2014 05:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 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, SUBJ_ALL_CAPS=1.506] 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 dS_LIjOoDFfZ for ; Wed, 5 Mar 2014 05:35:40 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0B81A002A for ; Wed, 5 Mar 2014 05:35:40 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id k14so1219408wgh.35 for ; Wed, 05 Mar 2014 05:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=BEkGGiBjmVM+tnB4W9Df15tkUDrYl5yOFUKIspNs9Fc=; b=RskFXMuHL6rKUAsLUCl2dOhfG91LQawDRr2FBHK918JUAEnyIf3Sn2euARnUbYKqoa 71LQkTWjHfOHD+o9O9ZHtdDgwbcRBZj3D9rbSbIHmNX/UbHNIporAUhGfeXqogPEYBmH d59mALnJ4J9MOKpgvtNWFHbiY5wllJPE6gwi7g/BZ/ZMIkbjhtsDaDtTp6EO6cp/I7KU a5U9ln0giRBUL+939i+pKE8AoFdiKOjRtqhbpPomF4BsiR7EndpWNqrS4oMdoPxq2Fvn cr/q7Hk9vP9W5qUoWvXprZlC01sCjqgFWHXTR6TvNfEpdDhZilqIVPZgjYLYAltfgKKQ kv0Q== MIME-Version: 1.0 X-Received: by 10.194.57.77 with SMTP id g13mr1093491wjq.42.1394026536174; Wed, 05 Mar 2014 05:35:36 -0800 (PST) Received: by 10.217.120.194 with HTTP; Wed, 5 Mar 2014 05:35:36 -0800 (PST) Date: Wed, 5 Mar 2014 08:35:36 -0500 Message-ID: From: Matthew Lepinski To: saag@ietf.org Content-Type: multipart/alternative; boundary=047d7bacc0fa7f088f04f3dc1815 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZkW-zmNy8WOeNZU3mo3coIegAtY X-Mailman-Approved-At: Wed, 05 Mar 2014 08:04:24 -0800 Cc: Yoav Nir Subject: [saag] HTTPAUTH @ IETF 89 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, 05 Mar 2014 13:35:42 -0000 --047d7bacc0fa7f088f04f3dc1815 Content-Type: text/plain; charset=ISO-8859-1 HTTPAUTH met on Monday at IETF 89. The working group is preparing an update to Basic and Digest authentication. These documents will obsolete RFC 2617. The primary goal of this work is to support non-ASCII (i.e., UTF-8) characters in usernames (and passwords), and to provide hash-function agility for Digest authentication. Work on these documents is progressing well, and we expect to have a working group last call on Digest-bis (and perhaps even both documents) before Toronto in July. In addition to updating Basic and Digest authentication, the group is working on four experimental drafts that specify brand new HTTP-layer authentication mechanisms that have security properties that cannot be obtained via Basic or Digest authentication. At IETF 89 we had focused discussion on issues in the SCRAM (Salted Challenge Response Authentication Mechanism) [draft-ietf-httpauth-scram-auth]. The group is also working on the following experimental mechanisms (which were discussed only briefly at IETF 89): -- Draft-ietf-http-mutual (a password authenticated key exchange) -- Draft-ietf-http-hoba (origin-bound authentication for HTTP) -- Draft-ietf-http-rest-auth (restful authentication pattern for HTTP) The four experimental documents in the working group have not received sufficient review. If you believe that is valuable for the IETF to specify something better than Basic/Digest for HTTP-layer authentication, then please read one of the above documents and provide feedback on our list. If we can get sufficient review on (at least some) of these documents, then we will publish experimental RFCs -- implementation experience with which would hopefully inform future standards track work on improved HTTP-layer authentication. If we do not get sufficient review of these documents, then we will declare victory after publishing updates to Basic and Digest and close the group. --047d7bacc0fa7f088f04f3dc1815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HTTPAUTH met on Monday at IETF 89.

The = working group is preparing an update to Basic and Digest authentication. Th= ese documents will obsolete RFC 2617. The primary goal of this work is to s= upport non-ASCII (i.e., UTF-8) characters in usernames (and passwords), and= to provide hash-function agility for Digest authentication. Work on these = documents is progressing well, and we expect to have a working group last c= all on Digest-bis (and perhaps even both documents) before Toronto in July.=

In addition to updating Basic and Digest authentication= , the group is working on four experimental drafts that specify brand new H= TTP-layer authentication mechanisms that have security properties that cann= ot be obtained via Basic or Digest authentication.

At IETF 89 we had focused discussion on issues in the S= CRAM (Salted Challenge Response Authentication Mechanism) [draft-ietf-httpa= uth-scram-auth]. The group is also working on the following experimental me= chanisms (which were discussed only briefly at IETF 89):=A0
-- Draft-ietf-http-mutual (a password authenticated key exchange)
-- Draft-ietf-http-hoba (origin-bound authentication for HTTP)
<= div>-- Draft-ietf-http-rest-auth (restful authentication pattern for HTTP)= =A0

The four experimental documents in the working group ha= ve not received sufficient review. If you believe that is valuable for the = IETF to specify something better than Basic/Digest for HTTP-layer authentic= ation, then please read one of the above documents and provide feedback on = our list.=A0

If we can get sufficient review on (at least some) of t= hese documents, then we will publish experimental RFCs -- implementation ex= perience with which would hopefully inform future standards track work on i= mproved HTTP-layer authentication. If we do not get sufficient review of th= ese documents, then we will declare victory after publishing updates to Bas= ic and Digest and close the group.
--047d7bacc0fa7f088f04f3dc1815-- From nobody Wed Mar 5 08:57:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782F11A014D; Wed, 5 Mar 2014 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 oB3IjI0JMIlK; Wed, 5 Mar 2014 08:57:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F20B51A0179; Wed, 5 Mar 2014 08:57:23 -0800 (PST) Received: from [192.168.10.133] ([31.133.156.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJByE-1WMtoy300Y-002mSN; Wed, 05 Mar 2014 17:57:18 +0100 Message-ID: <5317576C.6090400@gmx.net> Date: Wed, 05 Mar 2014 17:57:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM" X-Provags-ID: V03:K0:kiDWCHk4d7y7EV13i4sr91IATfQ0ToNtgW8+odv+G5cURJs9uNq XcHBZGD7pXKcaH51gtjN4ycNychhrD3rWOHLVdPLLVcFKnPPUNaAM3ZgaJqrbMxwXccUvJd LTqJaiNalinmCdeyYoOoJKV3Ybq3hqRpw96g0tn96smmY6TfQkhQQsbUYwxf67o439euUbR HdkE25h2cWLJvxjEa4DrQ== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/c0Sz4O5LlYnYKt2z9nwOQe7LNB8 Subject: [saag] IETF#89 ACE Summary 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, 05 Mar 2014 16:57:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We held the ACE BOF this morning from 9am to 11:30am. We started with a presentation about what constrained node networks are, explained use cases & requirements and discussed design choices. We concluded with a gap analysis. There was good support for doing the work in the IETF and there was a fair amount of feedback from the audience regarding the charter text. About 30 persons indicated that they are willing to review specifications and 15 persons said that they will be contributing documents. The feedback from the audience included: - Scope of the work Should it be focused on CoAP / DTLS only? In particular, the question about the suitability of the developed solutions for HTTP and SMS transport was raised. - Assumptions What assumptions are being made by the use cases in terms of requirement for a clock, interworking with existing infrastructure, interaction with proxies, and intermittent connectivity of different parties (off-line use cases). - Provisioning of credentials and other configuration parameters Participants suggested to consider looking at the entire life cycle of these IoT devices to prevent problems later with provisioning. While those do not necessarily be standardized in this group there was a desire to avoid later problems. As next steps the charter discussions will have to continue to resolve some of the raised questions. The BOF chairs encouraged the audience to develop strawman proposals to gain further experience about the underlying assumptions. Ciao Hannes --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTF1dsAAoJEGhJURNOOiAtoawH/38WQ7V9LeUTNpYgdffi2hoL iQRvFj4zdIUoOzDytpQElvlJdHHxnBlKuLnJgdbQgts6XRqBpFUM5nYq/IX5X/Au +ZfYIDV2rqn1wL4qC8cI0TeMiUFUprBjk3JgeXeZX7h6Z+Y78bOIab2E9YrCJTju NanG6r4eydQSBxEMWwu7t4llQQPy67CmC4YevTaE3fH8Gcy3tywQHWuctCL665g8 RQPeNTnPZ7inDz8nhzZnbOMB+9AiuYdmcZcTVAfmX4OW/aIQBdTIMg+T2jkw4Dg2 Q0znMWmVdE6rBiaz7zHaVTQK7SQGpxYZTXVPLDrC70V8PWpjPRRfMrKUC+ufcFI= =/dtW -----END PGP SIGNATURE----- --hRvbN1uFQCPqbbC04pa0aAG2t3QTJt4pM-- From nobody Wed Mar 5 09:40:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184C81A0191 for ; Wed, 5 Mar 2014 09:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiqV66bM5xlV for ; Wed, 5 Mar 2014 09:40:10 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 532391A05C3 for ; Wed, 5 Mar 2014 09:40:10 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id l18so1167468wgh.28 for ; Wed, 05 Mar 2014 09:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WPHvhRC0VNnkmd4m+IOYcpbseWsSlA0aD4CRdaAtha0=; b=nWkkhhVBWWzo/S2AKDq8ziEsGj4uIoaZFF2s/pwQUK2sJcDyc2eTHDlXG1w/HwlgnJ liiniBXf3W/udOhadB/r6/0hfnW+iiJjFN8J40NiYfnCB5zkPSyClIkTfGfER+TzrvJe PcdhIBf7VVCxnpzEjt6v7/H1QnUJRmNFjJcJZI4A9KqZ14wsQ6GZVqhN7XxGHlqxg675 CnviNzHatZPK/3j7slRdzNdbYAG8+s4tq0POk4AyOfS0Fd7N0qW5bwNgYrXBms+Xr4RX fpJ+GhMNmsmvZO0FEBfOFmYpq/TC7sFrs6DJQTyXjVOqwlxagzl+/LITQMmse+GJdtzc gNkw== X-Received: by 10.194.76.143 with SMTP id k15mr2893712wjw.96.1394041206304; Wed, 05 Mar 2014 09:40:06 -0800 (PST) Received: from ?IPv6:2001:67c:1232:152:3445:a9ee:1896:f382? ([2001:67c:1232:152:3445:a9ee:1896:f382]) by mx.google.com with ESMTPSA id q15sm3325447wjw.18.2014.03.05.09.40.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 09:40:05 -0800 (PST) Message-ID: <53176174.9020105@gmail.com> Date: Wed, 05 Mar 2014 17:40:04 +0000 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KK8CDaIVbGts0DOGDlIcvO_I1Kc Subject: [saag] IETF #89, trans summary 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, 05 Mar 2014 17:40:12 -0000 The newly-formed trans working group met for the first time, with the primary business being booting up the working group. We already have a working group document (draft-ietf-trans-rfc6962-bis) and settled on a milestone date for wglc. We discussed splitting up the document (for which there seems to be support - it's being taken to the mailing list) and walked through the open issues in the issue tracker. Tony Nadalin gave a presentation on work at Microsoft on certificate reputation. That work is out of scope for trans, but is appropriate for discussion on therightkey mailing list. Melinda From nobody Wed Mar 5 10:48:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC9D1A011E for ; Wed, 5 Mar 2014 10:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2I6sXJuxPU5 for ; Wed, 5 Mar 2014 10:47:56 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC8F1A01FC for ; Wed, 5 Mar 2014 10:47:56 -0800 (PST) Received: from dhcp-bc61.meeting.ietf.org (dhcp-bc61.meeting.ietf.org [31.133.188.97]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s25IllCq011695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Mar 2014 11:47:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 5 Mar 2014 18:47:46 +0000 To: saag Group Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/q3Sd3j6cDDCyyHBVaS1hkMOwiOk Subject: [saag] IPsecME WG, IETF 89 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, 05 Mar 2014 18:47:57 -0000 There was a good discussion at the beginning of the meeting about the = outcome of the AD VPN work, particularly the fact that there was no = consensus on which proposal the WG should move forwards. There was a = request for an interim virtual meeting, possibly a design team meeting, = to facilitate discussion of possible areas of agreement. We also had = presentations on recent drafts relating IPsec in constrained = environments (IoT), a non-AES AEAD, opportunistic encryption, and = context changes. --Paul Hoffman= From nobody Wed Mar 5 10:56:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA11A0162 for ; Wed, 5 Mar 2014 10:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjPKMe5Q1Uep for ; Wed, 5 Mar 2014 10:56:28 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD21A011E for ; Wed, 5 Mar 2014 10:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1394045785; x=1395255385; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=J1HH29hTg3MGwdJ4H0nCnou31Xvxp4w1D9aIdn/7jVY=; b=JSg4IcAo30+L4rmnKiqKVudgTaYDTHbr3o3B37Dpiyu3RP5MaAym7M0P O87vauHB+tOfK/8oBe0o58rq15aMJH8sp0zUa2M7xbxtE8zE7uge+U5Vf ZzpfqccuRkGL2C3VrEXylL++/5OqmKLDrat96boLV+RoklRjKxBbaXbiv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABdzF1OtJV2b/2dsb2JhbABagwY7V8InFnSCLDpRAT5CJwSIDJ8Yr0QXkXyBFASYPZIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="25166266" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 05 Mar 2014 18:56:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25IuOYG001292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 18:56:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 12:56:24 -0600 From: "Joseph Salowey (jsalowey)" To: "saag@ietf.org" Thread-Topic: IETF 89 TLS meeting Summary Thread-Index: AQHPOKSaEbNDdCbc7UOzbYcd4X9ABw== Date: Wed, 5 Mar 2014 18:56:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.204.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <57312D7B100AE74784CF7D0D20D7686B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/P9gHlWJ-gwFx4jUKQSfRxYm1Yj8 Subject: [saag] IETF 89 TLS meeting Summary 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, 05 Mar 2014 18:56:31 -0000 TLS met Tuesday afternoon Discussion Summary: + draft-ietf-tls-encrypt-then-mac - draft will be submitted as working grou= p item and should shortly be ready for working group last call + draft-moeller-tls-downgrade-scsv - The Chairs believe this is something t= he WG wants, so will approach the ADs about adding it to the charter + draft-mavrogiannopoulos-chacha-tls - merged draft on using ChaCha in TLS.= Needs review from TLS and CFRG groups. Working towards a candidate that = can be accepted as a working group item. + Explicit IVs in ChaCha - presentation on recommending use of explicit IVs= in ChaCha ciphers. This will be discussed on the list.=20 + Update from CFRG - TLS and CFRG chairs to coordinate on requests for CFRG= evaluation + Session Resumption Issues - attacks involving session resumption - http:= //secure-resumption.com + TLS 1.3 - Presentation describing 1 RTT and 0 RTT flows. Looked at poss= ible deprecating some features - There was support in the room for deprecating compression, to be verified= on the list - There was mixed response for the need to protect the SNI, to be discussed= on the list - There seemed to be support for supporting only AEAD algorithms, to be ver= ified on the list - There seemed to be support for removing static RSA ciphersuites (TLS-RSA-= WITH-*) from 1.3, to be discussed and verified on the list - Mixed response on removing renegotiation, to be discussed on the list= From nobody Thu Mar 6 01:23:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADB1A0178; Thu, 6 Mar 2014 01:23:31 -0800 (PST) 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 iw7TOtBtsx-y; Thu, 6 Mar 2014 01:23:28 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 871231A0189; Thu, 6 Mar 2014 01:23:27 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf5so1549770lab.35 for ; Thu, 06 Mar 2014 01:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jFbYMBmDPSk/cZ2XQuBNbkpCX4E57uDJDRQ0ZYPC88Q=; b=LjYHQAuhDtE88s5DeVyawSu4O25lb5me/WBHvSSw5FTT4YM7M6/9ATqWVs7tty5DnO EPcmFKzGcolFSH2OXNdHT/SnklAr+MQZYRt5Nlg6VzmCCcM3XnlxKZjEGSQIq7+upObo 0jI8LXkNC2HhJ/9+XgcZ+NGno7BMRT2O7rygNe3ZDPlP3zYkMwV9o5NB17aOOEXfYXzZ W6FuyNHdhqgVQk3f1iPd5yVv8ryVsXFDNyAVXjh/Y0l5DexTV1dxB27Fg8cc3o1vKKzZ 4nYeOOob9zJ8zJtihCky4S58uqItJWb8tA6eyMKYLio1N59WgP/sIM7hG5W6wxUJkDtb nWuA== MIME-Version: 1.0 X-Received: by 10.112.161.133 with SMTP id xs5mr723319lbb.51.1394097803060; Thu, 06 Mar 2014 01:23:23 -0800 (PST) Received: by 10.112.37.168 with HTTP; Thu, 6 Mar 2014 01:23:23 -0800 (PST) Date: Thu, 6 Mar 2014 09:23:23 +0000 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" , "dane@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3c042556c1004f3ecb03d Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lMmZB0Wjqa0D3i8Q0HBXAM1h4Cg Subject: [saag] Need better opportunistic terminology 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, 06 Mar 2014 09:23:31 -0000 --001a11c3c042556c1004f3ecb03d Content-Type: text/plain; charset=ISO-8859-1 The term opportunistic has become the new synonym for 'Good' but it is being used for many different things. A) Unauthenticated key exchange B) Upgrade from plaintext to encrypted without controlling security policy requiring use of encryption. C) Silent-fail on bad credentials D) Silent-success on bad credentials There are arguments for all of these but I am just watching a presentation on 'opportunistic encryption' in DANE and I think the term is selling DANE short. DNS is an authoritative path for statements about DNS labels. Ergo authenticated DNS RRs are authenticated statements about them. DANE provides authenticated statements about security policy and keys. Ergo DANE cannot support opportunistic encryption because it is policy directed encryption (i.e. better). -- Website: http://hallambaker.com/ --001a11c3c042556c1004f3ecb03d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The term opportunistic has become the new synonym for '= ;Good' but it is being used for many different things.

A) Unauthenticated key exchange

B) Upgrade from= plaintext to encrypted without controlling security policy requiring use o= f encryption.

C) Silent-fail on bad credentials

<= div>D) Silent-success on bad credentials

There are= arguments for all of these but I am just watching a presentation on 'o= pportunistic encryption' in DANE and I think the term is selling DANE s= hort.

DNS is an authoritative path for statements about DNS l= abels. Ergo authenticated DNS RRs are authenticated statements about them. = DANE provides authenticated statements about security policy and keys. Ergo= DANE cannot support opportunistic encryption because it is policy directed= encryption (i.e. better).
--001a11c3c042556c1004f3ecb03d-- From nobody Thu Mar 6 05:34:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA951A0302; Thu, 6 Mar 2014 05:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 gpOTzPMYdSwc; Thu, 6 Mar 2014 05:34:42 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 22C661A0129; Thu, 6 Mar 2014 05:34:42 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3744228B003A; Thu, 6 Mar 2014 08:34:38 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id EBA7E1F8036; Thu, 6 Mar 2014 08:34:37 -0500 (EST) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Mar 2014 08:34:37 -0500 Message-Id: <5C51DB59-2494-407F-9E0D-4FB369FCF5D4@tislabs.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FcbOOVtWObEymJ1xLzlKkhwMrxI Cc: "sidr-chairs@ietf.org" Subject: [saag] SIDR report 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, 06 Mar 2014 13:34:43 -0000 SIDR met on Tue morning. We had three discussions of changes to existing documents. Two were = expansion/correction to RFCs, one an expansion to existing draft. = [Details: multiple publication points for trust anchor locators, correct = mandated signature algorithm for signed objects to match CMS mandated = signature algorithm, expand router certificate to authorize for multiple = AS numbers which could reduce deployment burden). We had an energetic discussion of a change to semantics of certificate = validity. This is a basic part of the architecture but might help make = the system more resilient to errors. Not really sure how the wg wants = to go with this - it has cone up in three meetings now, with energetic = discussions, but no progress in between. THere were two discussions of mechanisms that might ease concerns about = hierarchical control and autonomy. There was a discussion of some testing of rsync and its vulnerabilities. There was a discussion of a deployment experience in Ecuador (an IXP = with national coverage). They have committed to a 15 Mar date for = starting to drop invalid BGP routes. --Sandy, speaking as SIDR co-chair= From nobody Thu Mar 6 06:00:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF61A02CA for ; Thu, 6 Mar 2014 06:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F3xcfpY7gvQt for ; Thu, 6 Mar 2014 05:59:59 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id DF25A1A02A7 for ; Thu, 6 Mar 2014 05:59:58 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E798F9A4366 for ; Thu, 6 Mar 2014 08:59:45 -0500 (EST) 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 A0QFCtwKPcj2 for ; Thu, 6 Mar 2014 08:59:24 -0500 (EST) Received: from dhcp-b45b.meeting.ietf.org (dhcp-b45b.meeting.ietf.org [31.133.180.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 160C59A436D for ; Thu, 6 Mar 2014 08:59:24 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Mar 2014 08:59:11 -0500 Message-Id: <2036CE6A-BB74-428D-AED2-BEFB01B08FB3@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KXavpTGF5x6kEJ5A8UMcd4a10BU Subject: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:00:06 -0000 I gave a presentation in the SAAG session today. Once we get the = content right, the Security ADs have agreed to sponsor it for BCP. So, = please review and comment so that we can get the content right soon. Thanks, Russ From nobody Thu Mar 6 07:47:06 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC761A006B for ; Thu, 6 Mar 2014 07:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 1oZBPoI2aL36 for ; Thu, 6 Mar 2014 07:47:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 553FD1A0030 for ; Thu, 6 Mar 2014 07:47:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1018BBE68; Thu, 6 Mar 2014 15:46:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKwOcmTRA5KG; Thu, 6 Mar 2014 15:46:57 +0000 (GMT) Received: from [31.133.184.115] (dhcp-b873.meeting.ietf.org [31.133.184.115]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A4601BE62; Thu, 6 Mar 2014 15:46:57 +0000 (GMT) Message-ID: <53189871.6040200@cs.tcd.ie> Date: Thu, 06 Mar 2014 15:46:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Russ Housley , IETF SAAG References: <2036CE6A-BB74-428D-AED2-BEFB01B08FB3@vigilsec.com> In-Reply-To: <2036CE6A-BB74-428D-AED2-BEFB01B08FB3@vigilsec.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HuLScH8HxNMHYOuvxiQRsT_R5J4 Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:47:05 -0000 On 03/06/2014 01:59 PM, Russ Housley wrote: > I gave a presentation in the SAAG session today. Once we get the > content right, the Security ADs have agreed to sponsor it for BCP. > So, please review and comment so that we can get the content right > soon. And its short! S > > Thanks, Russ > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag > > From nobody Thu Mar 6 09:05:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315B1A0083; Thu, 6 Mar 2014 09:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 9doIQzhl3oGy; Thu, 6 Mar 2014 09:05:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E1D441A01FB; Thu, 6 Mar 2014 09:05:18 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s26H3pcC028049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 09:04:01 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Message-Id: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> X-Mailer: iPhone Mail (11B651) From: Joe Touch Date: Thu, 6 Mar 2014 09:03:52 -0800 To: Phillip Hallam-Baker X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3z9MplCiKaFfrVgOWDgmjlzri-Q Cc: "saag@ietf.org" , "dane@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 06 Mar 2014 17:05:23 -0000 --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker wrote:= >=20 > The term opportunistic has become the new synonym for 'Good' but it is bei= ng used for many different things. >=20 > A) Unauthenticated key exchange Fwiw, this is IMO an error since I first introduced BTNS, and I had to clear= it up on Wikipedia multiple times. I see nothing opportunistic about this m= ode as a stand-alone concept.=20 I personally don't this the term applies to the modes listed below either.=20= One mode you didn't include - that I recall as one of tho first uses of the t= erm opportunistic, and remains the only one I associate with the term. - is t= he use of a key before either the key or encryption in general has been nego= tiated and is not the protocol default. (I.e., a little like B but more just= start using it then an 'upgrade'. ) Joe > B) Upgrade from plaintext to encrypted without controlling security policy= requiring use of encryption. >=20 > C) Silent-fail on bad credentials >=20 > D) Silent-success on bad credentials >=20 > There are arguments for all of these but I am just watching a presentation= on 'opportunistic encryption' in DANE and I think the term is selling DANE s= hort. >=20 > DNS is an authoritative path for statements about DNS labels. Ergo authent= icated DNS RRs are authenticated statements about them. DANE provides authen= ticated statements about security policy and keys. Ergo DANE cannot support o= pportunistic encryption because it is policy directed encryption (i.e. bette= r). >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Mar 6, 2014, at 1= :23 AM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:

The term opportunistic has become the new synonym for 'Good' but i= t is being used for many different things.

A) Unauthentic= ated key exchange

Fwiw, th= is is IMO an error since I first introduced BTNS, and I had to clear it up o= n Wikipedia multiple times. I see nothing opportunistic about this mode as a= stand-alone concept. 

I personally don't this= the term applies to the modes listed below either. 

One mode you didn't include - that I recall as one of tho first uses o= f the term opportunistic, and remains the only one I associate with the term= . - is the use of a key before either the key or encryption in general has b= een negotiated and is not the protocol default. (I.e., a little like B but m= ore just start using it then an 'upgrade'. )

Joe

B) Up= grade from plaintext to encrypted without controlling security policy requir= ing use of encryption.

C) Silent-fail on bad credentials

D) Silent-success on bad credentials

There are a= rguments for all of these but I am just watching a presentation on 'opportun= istic encryption' in DANE and I think the term is selling DANE short.

DNS is an authoritative path for statements about DNS la= bels. Ergo authenticated DNS RRs are authenticated statements about them. DA= NE provides authenticated statements about security policy and keys. Ergo DA= NE cannot support opportunistic encryption because it is policy directed enc= ryption (i.e. better).
____________________= ___________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman= /listinfo/saag
= --Apple-Mail-198B2FEE-28D9-4138-AC58-E3CF0FC363E1-- From nobody Fri Mar 7 01:35:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE21A017B; Fri, 7 Mar 2014 01:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 Rjx5X2yZdTNT; Fri, 7 Mar 2014 01:35:12 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 551F81A0159; Fri, 7 Mar 2014 01:35:12 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 048D12002B; Fri, 7 Mar 2014 05:53:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4B7E1647C9; Fri, 7 Mar 2014 04:35:06 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 366F6647C8; Fri, 7 Mar 2014 04:35:06 -0500 (EST) From: Michael Richardson To: dane@ietf.org, saag@ietf.org In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HfuPy6OtEe-vftaJtuZtOQuI0kU Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 07 Mar 2014 09:35:16 -0000 --=-=-= Viktor Dukhovni wrote: > So you might ask what was the word "opportunistic" doing in our > avant-garde use of the term "opportunistic DANE TLS"? The answer is > that as with (pre-DANE) opportunistic TLS, the client is willing to > send in the clear to any server for which no "secure" TLSA records are > available. > Thus, until the happy future when a significant fraction of domains are > DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated > "secure" TLSA records, in practice the protocol is essentially the same > as with (pre-DANE) opportunistic TLS. The client employs the best > security level available (including cleartext). And, in particular, I think that "opportunistics TLS" interoperates with "opportunistics DANE TLS". The two sides don't have to have to known each other's policies. > So Phillip is quite right that DANE gets us stronger semantics, but I > would argue, that because the actual security posture is *conditional* > on published receiving system capabilities, from the perspective of the > sending system, this is just a "hardened" version of opportunistic TLS > where, for just some destinations not known to the sender in advance, > MITM attacks cannot trivially downgrade senders to plaintext or > compromise transport integrity or confidentiality. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUxmSyoqHRg3pndX9AQKgpQQAgKbTzlCQ/FHl742S9UFn1kwhUb7zfTkQ JmQsKLY9sTgkbGu+/XaOsQe3B9/6OQdRwLNrOsBfWbo5kMR7iqql5inim93ODdmd eY5c2NAM5reg2pugCWGABZZz6tSqhw0uHwuffRojDFKlYZQa+7dSZ9omJ34e3A3b Lu1lFDlRwuM= =60eZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 7 03:08:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A591A012B for ; Fri, 7 Mar 2014 03:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gJQtxzqCVJbQ for ; Fri, 7 Mar 2014 03:08:12 -0800 (PST) Received: from smtp152.ord.emailsrvr.com (smtp152.ord.emailsrvr.com [173.203.6.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDAA1A019F for ; Fri, 7 Mar 2014 03:08:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 33E5D198B3A for ; Fri, 7 Mar 2014 06:08:08 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.ord1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B2639198B34 for ; Fri, 7 Mar 2014 06:08:07 -0500 (EST) From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <79820492-CB56-4448-991A-B2D84C89AB56@ogud.com> Date: Fri, 7 Mar 2014 11:08:06 +0000 To: "saag@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hIuYLz5cdgGQpSlnjHfevd6bpsA Subject: [saag] DANE-89 summary 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, 07 Mar 2014 11:08:14 -0000 Dane met on Thursday at 9:00 we had an overflow situation many people = could not fit in our room. The first part of the meeting was dedicated to discussion on the = specifications and implementation experience of two protocols=20 SMTP and XMPP =20 -- http://tools.ietf.org/html/draft-ietf-dane-srv-05 -- http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07 We had productive discussion and the documents will be entering WGLC = soon Second topic of the meeting was the "The philosophy of DANE:"=20 a lively discussion that needs to be documented to prevent future = instances of this discussion.=20 The group is also taking on DANE for email users as in support for SMIME = and OPENPGP.=20 There are proposals to attempt to apply DANE technologies to IPSEC but = those have not been adopted.=20 The group will be recharging to reflect success and new challenges.=20 Olafur From nobody Fri Mar 7 05:04:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DE91A0283 for ; Fri, 7 Mar 2014 05:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 KQYpwBGDjbII for ; Fri, 7 Mar 2014 05:04:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 65D161A0281 for ; Fri, 7 Mar 2014 05:04:38 -0800 (PST) Received: from dhcp-ac71.meeting.ietf.org (2001:67c:370:168:20f3:8d84:6b09:16b) by BLUPR06MB577.namprd06.prod.outlook.com (10.141.206.18) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 13:04:32 +0000 Message-ID: <5319C3D5.3000205@isoc.org> Date: Fri, 7 Mar 2014 08:04:21 -0500 From: Karen ODonoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:67c:370:168:20f3:8d84:6b09:16b] X-ClientProxiedBy: AM3PR04CA010.eurprd04.prod.outlook.com (10.242.16.30) To BLUPR06MB577.namprd06.prod.outlook.com (10.141.206.18) X-Forefront-PRVS: 014304E855 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(81816001)(94316002)(80316001)(83322001)(50986001)(85306002)(85852003)(47446002)(31966008)(74502001)(47976001)(65956001)(65806001)(95666003)(56776001)(49866001)(54316002)(97186001)(83072002)(47736001)(80022001)(63696002)(42186004)(94946001)(54356001)(47776003)(74876001)(76482001)(64126003)(4396001)(92566001)(93136001)(86362001)(33656001)(97336001)(87976001)(23756003)(56816005)(76796001)(90146001)(80976001)(76786001)(69226001)(77096001)(92726001)(74706001)(76176001)(79102001)(51856001)(74366001)(95416001)(83506001)(53806001)(74662001)(81686001)(93516002)(81542001)(77982001)(59766001)(81342001)(59896001)(46102001)(36756003)(50466002)(3826001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB577; H:dhcp-ac71.meeting.ietf.org; CLIP:2001:67c:370:168:20f3:8d84:6b09:16b; FPR:D0FEFA9B.BCCC9FE1.5F01FB7.C8E3FE39.2015C; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: isoc.org does not designate permitted sender hosts) X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DhR7Z_nztgae9-QHQOXem4x5bE4 Subject: [saag] JOSE wg summary 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, 07 Mar 2014 13:04:40 -0000 The JOSE working group met at 17:00 on Thursday, 6 March. The four core specifications (JWE, JWS, JWK, and JWA) have gone through WG LC. It is expected that they will be forwarded to the IESG within the next week or two. Matt Miller discussed the cookebook draft that is intended to provide examples of how implementers would use the four specs. This document will be updated based on the latest drafts. A request was made for implementers to verify the examples in the document during the review process. The plan is for this document to go to the IESG shortly after the four core specifications to help in the IESG and IETF reviews of the documents. From nobody Fri Mar 7 14:27:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165621A0128 for ; Fri, 7 Mar 2014 14:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.547] 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 Ux13Y3mQIRK2 for ; Fri, 7 Mar 2014 14:27:21 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.106]) by ietfa.amsl.com (Postfix) with ESMTP id 943CA1A011C for ; Fri, 7 Mar 2014 14:27:21 -0800 (PST) Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 02722D17C4A; Fri, 7 Mar 2014 23:27:16 +0100 (CET) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id E0C5BD175A8; Fri, 7 Mar 2014 23:27:15 +0100 (CET) X-Disclaimed: 1 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: kristof.teichel@ptb.de To: saag@ietf.org, housley@vigilsec.com Message-ID: Date: Fri, 7 Mar 2014 23:27:14 +0100 X-Mailer: Lotus Domino Web Server Release 9.0.1HF198 January 23, 2014 X-MIMETrack: Serialize by Notes Server on ROSE/PTB(Release 9.0.1HF198 | January 23, 2014) at 03/07/2014 23:27:14, Serialize complete at 03/07/2014 23:27:14, Itemize by Notes Server on ROSE/PTB(Release 9.0.1HF198 | January 23, 2014) at 03/07/2014 23:27:14, Serialize by Router on ROSE/PTB(Release 9.0.1HF198 | January 23, 2014) at 03/07/2014 23:27:15, Serialize complete at 03/07/2014 23:27:15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sp3qk8uR6w7qtNPBdWlWbRJ1i-k Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:27:24 -0000 Hello Russ, hel= lo all,

I guess my first question is: does feedback on the draft go here, i= n the general saag mailing list? (I am a first time participant with mailin= g list feedback...)
I'd like to say that I think this topic is very relevant a= nd would like it if this could be "made official" as a BCP document soon.

=
No= w, moving on to my feedback (WARNING: pretty much all of this concerns form= al aspects or structure, not content).

All the content so far looks good to = me, I'm just not sure I understand the structure:
 - Section 3 is named "= Algorithm Agility Considerations", is that a default section name like "Sec= urity Considerations"? If not, how is this distinguished from the rest of t= he document?
 - Section 2 is named "Guidelines". It feels to me like sect= ion 3 might be giving guidelines as well. Or does the distinction lie in th= e fact that section 2 contains "SHOULD" etc. statements and section 3 does = not? 
&= nbsp;- If this is the case (and indeed it kind of looks like 2.1 and 2= .2 give advice on problems described in 3.1 and 3.2, respectively; 2.1 and = 3.1 even share the same name), then I feel like perhaps section 3 should co= me first. What are your thoughts on that?
 - At the end of subsect= ion 2.2 (Mandatory to Implement Algorithms), there are three paragraphs abo= ut key sizes. should these go into their own subsection (which might for ex= ample be named "Key Sizes")? Or does this really apply only to algorithms w= hich are mandatory to implement?

On a side note, I think I spotted a few typ= os (stuff between underscores denotes stuff that is there in the document, = but shouldn't be there in my opinion):
Section 1:
 - there is a comma withou= t a space afterwards ("properly,communicating")
Subsection 2.2: 
 - "bu= t others allow=5Fs=5F"
Subsection 3.1:
 - "but it may still necessary to han= dle" is missing a "be"
 - "the transition =5Fto=5F from unprotected to pr= otected"
Subsection 3.3:
 - "some environments will restrict=5Fion=5F the ke= y management approaches"

That's it, at least for today. I hope some of this = is helpful, although none of it is directly content-related. 
I need to g= et some sleep now.
Good night/safe travels (for those who still need to fly ba= ck home).

Kristof



On 03/0= 6/2014 01:59 PM, Russ Housley wrote:
> I gave a presentation in the S= AAG session today.  Once we get the
> content right, the Securit= y ADs have agreed to sponsor it for BCP.
> So, please review and comm= ent so that we can get the content right
> soon.

And its short= !

S

>
> Thanks, Russ
From nobody Sun Mar 9 05:29:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174C81A0360 for ; Sun, 9 Mar 2014 05:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.461 X-Spam-Level: * X-Spam-Status: No, score=1.461 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.547, 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 0PsnQQMRaw8N for ; Sun, 9 Mar 2014 05:29:05 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id D392E1A035F for ; Sun, 9 Mar 2014 05:29:04 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s29CSweB010066 for ; Sun, 9 Mar 2014 21:28:58 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s29CSvVw012812 for ; Sun, 9 Mar 2014 21:28:57 +0900 (JST) From: "Takeshi Takahashi" To: Date: Sun, 9 Mar 2014 21:28:59 +0900 Message-ID: <01c201cf3b93$25b6ec10$7124c430$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C3_01CF3BDE.959F5760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac87kvyh1YsW6N6vTTGxMJlz0HvYfQ== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cjD4VHG28GZib_OVLPd1J7EAzFI Subject: [saag] MILE wg summary @ IETF 89 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, 09 Mar 2014 12:29:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C3_01CF3BDE.959F5760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The MILE working group met at 11:50 on Friday, 7 March. Here are the summary of the discussion. 1. Working Group leadership has completely changed - Sean Turner (AD), Kathleen Moriarty (chair), Brian Trammell (chair) are departing - Kathleen Moriarty (New AD for WG), Alexey Melnikov and Takeshi Takahashi (new chairs), David Waltermire (new Secretary) are entering 2. RFC5070-bis needs to change the milestone, and the authors are currently reflecting feedbacks - Lots of discussion after last WG meeting on the mailing list, and several open issues still exist (these issues are tracked and managed by the IETF's tracker tool) - Milestone change is proposed (The last call will be around Hawaii meeting) - The issues discussed in the IODEF implementation experience draft will be incorporated 3. IODEF implementation experience draft was appreciated as a useful input to RFC-5070-bis - Daisuke shared his experience of implementing IODEF-capable tools - The findings raised several issues to reconsider inside RFC-5070-bis, but the presentation did not address any specific solution. - How to change the RFC5070-bis is the issue for discussion in the mailing list 4. No presentation was made for Cyber-physical extension, but its discussion is encouraged on the list - The draft extends IODEF to exchange cyber-physical related incident information - The interests to the extension has been expressed by people on the mailing list already by now, thus discussion on the list is encouraged 5. The application of Plasma to IODEF was introduced in the Plasma-based IODEF draft, and feedback on the contents and interests should be posted to the list - Plasma was originally made for email, but its data mode was reused and applied to IODEF - There were no time for the discussion, but the interested people are requested to comment on the list 6. Expertise of using encryption and signature in JOSE WG was shared - The experience of using encryption and signature in JOSE are shared - JOSE can't be used for MILE as it is A bit better formatted document is attached to this email. Thank you. Take ------=_NextPart_000_01C3_01CF3BDE.959F5760 Content-Type: application/pdf; name="SummaryReport_MILE.PDF" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SummaryReport_MILE.PDF" JVBERi0xLjUNJeLjz9MNCjEwNiAwIG9iag08PC9MaW5lYXJpemVkIDEvTCAxOTAzOS9PIDEwOC9F IDEyNTkxL04gMS9UIDE4NzI5L0ggWyA0ODkgMTY4XT4+DWVuZG9iag0gICAgICAgICAgICAgICAg DQoxMjIgMCBvYmoNPDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmls dGVyL0ZsYXRlRGVjb2RlL0lEWzw5RDQ2REEwQTc5QzE5OTRBOURCNjM3MDEwMDEyMDUwND48OEIx MjU5MzNDRkEyMjE0OUExNjg2N0FGNzc4MEI0QkY+XS9JbmRleFsxMDYgMjhdL0luZm8gMTA1IDAg Ui9MZW5ndGggODEvUHJldiAxODczMC9Sb290IDEwNyAwIFIvU2l6ZSAxMzQvVHlwZS9YUmVmL1db MSAyIDFdPj5zdHJlYW0NCmjeYmJkEGBgYmBqBBKM00CEBpBgYQcSzCAuixmIFQkinEHERxChCiLk QUQVSIcykGAIBBJ8ikDiQhEDEyPDT5AYAyPRxH/Gmu8AAQYAndEKJA0KZW5kc3RyZWFtDWVuZG9i ag1zdGFydHhyZWYNCjANCiUlRU9GDQogICAgICAgIA0KMTMzIDAgb2JqDTw8L0MgODUvRmlsdGVy L0ZsYXRlRGVjb2RlL0kgMTA3L0xlbmd0aCA4Mi9TIDM4Pj5zdHJlYW0NCmjeYmBg4GNgYKpnAAI9 DgZUwAjELAwcDchifFDMwBDIwMNbvM0k6KlB0yctpis6jzR5FRjOMtyBaU2cCqFZ18E1szAwVMRD RBkNAQIMAIlGDNcNCmVuZHN0cmVhbQ1lbmRvYmoNMTA3IDAgb2JqDTw8L0xhbmco/v8ARQBOAC0A VQBTKS9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4vTWV0YWRhdGEgMiAwIFIvUGFnZUxheW91dC9P bmVDb2x1bW4vUGFnZXMgMTA0IDAgUi9TdHJ1Y3RUcmVlUm9vdCA2IDAgUi9UeXBlL0NhdGFsb2c+ Pg1lbmRvYmoNMTA4IDAgb2JqDTw8L0NvbnRlbnRzWzExMCAwIFIgMTExIDAgUiAxMTIgMCBSIDEx MyAwIFIgMTE0IDAgUiAxMTUgMCBSIDExNiAwIFIgMTE3IDAgUl0vQ3JvcEJveFswLjAgMC4wIDU5 NS4zMiA4NDEuOTJdL01lZGlhQm94WzAuMCAwLjAgNTk1LjMyIDg0MS45Ml0vUGFyZW50IDEwNCAw IFIvUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCAxMjMgMCBSPj4vRm9udDw8L0MyXzAgMTI4 IDAgUi9UVDAgMTMwIDAgUi9UVDEgMTMyIDAgUj4+Pj4vUm90YXRlIDAvU3RydWN0UGFyZW50cyAw L1R5cGUvUGFnZT4+DWVuZG9iag0xMDkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0 IDc4L0xlbmd0aCA5MzQvTiAxMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3tRVbW/TMBD+K/64CVV+ i+NEQpO6lkElGIgOhlT1Q1hNFyltqiST6L/nzrHdpGtXGEjAh5Pje/Pju/MTLiRhhIuI8BQWRTSH JSYShAtNogT3CYlS9EpJzMFTMpKgXYItRYMURPA0JjM6GY0us9osCOcJJP44f/mSvq8WpsrXy7PJ wqybvNme049mmddNtT0bLsqv5pxOHzabwqzATNjFBcQM6zvcJGlKR5Px1DSQMMWEdJRt3ph8ed8Q rSI6Nq3jQHBOr4psWZOIXpXr5vKy/D5jVg/4VIqp5tZyla3yYnt2C4gWIPV5q80LI+CKzB6Cmuts ZeiH6+sv0w8vgvMAkD8UWWU9pk1lmrt7el1Wq6ywqtsWWsQYnTRZkd8N18vCEEanjVl9Jiph9Ga7 MdYXsVf5pikr+sVfSUh7fawhuhw/H6uyrSHpZP2ttA20xZmMb8rXk/G7bEN9ten4lnAGgPpn2m5j zPTha4OQIBY9EJ7YgaS3MyjKTHI5n19czHA2XFtPY2ybs8iguuBX24HCE1+t70r0DBAHbwIKPBhq VH5a5+BkIIbbmACoOx6cqbg7EDzeDYTUsRsIKXYTMYhhmNFGBJTEJuhNxbDKs+J813+7H1yWxeLd zYme6yM95zJ+sueKp/2e984MtYLyDtd1HvZXeVU3o/usIgc62z6Vt5nzEErtClw9mBtfadfifNHc 1zOtGPmbInRCpJQk0hFRKraSJCk8CqAX2dqsgE4lUfDHFcXHnBKfB3N4iYEmUq3sWV2JY21tGvJb HO4cawN9AnmsL+jR1/uFOPedRlGrc3qPO+BwuHBFe3dFPX6jdO+KK9bH27zY+nTiLN5ufWDw0Uck LNRSQv1tjOuD90Pi6BXOKvAWYYMh9ljFQrhNgZHOjtGts4/y+bAw1sOlDUXZaxqC9TFawvHa4ULw TqeUQOYlKkp3w4K5dL/xVmLVDpiMgviGHRILOnS2I/66XkIQfu8JgtVdn+6Uuck4NrWJ6+qjwuyd vz8NXcHCHNTvpm3e59eIHeVXoQ7yK9QVbZ5fI3aaX09S67HfaZI8g1mfS6qS/6+kat+UUr1RwnHj Kf9jpBr8O6Tavnquwnw/yaqOANpH+TxW7b6DKE57rOoZrQs4fCMGELTjmhwgIJuH9dlRu5hAdUAi Im7XR6yKvl0S/UVWdRBDvw6zqtv8NKvGv8mqUv8Uq+6Tppd/g1U7zTjGqk+Ov2PVR3qflzFg1R8C DABklzQjDQplbmRzdHJlYW0NZW5kb2JqDTExMCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDg0Nz4+c3RyZWFtDQpIiXxV204bMRB936/wo12xju29VwgJCCBaIlVlJR6gqqJkISlk g7IByt93zjibTUjKA9mxZzyXM2eGkzLo/RCHh73B6WVfGHF0dNI/FUHv9NqIUUMXohnVQa8sjbCi vA9Co40laSRIMJEo34R1ZGbwsWmui1RkSaqjVJSz4Fb+VFZWKkzks7JGzhcqdHKprJNifs+fpXJy Al2lEikgXKowkmcqleU5jmJAFpcqk1e4E+pX+Y2zMHGbRcxZWO0ySqMcB/LmQpV/AsN61ulWI6Dg GlJo2Y+DidEu9Ta3sqGEKXDTTFWYyznlVaMCwcea0ww5T0dphoUs6eocFnnB2XWBfbyzARDtULZr lMvSelit0UnqYWQpiXSeiyzKdeYA5H5HrnW02RVnEdlZXWSZCKn0qPBlHatcPhGE1V8AX70z/ANl E4LeWlbVEKYkPM5f10B7qFbCm8i0Na6F6oDa27XEuc0UDOWetYYltdLI4SMhR4Ro6NmE4LTU0C3N cDJc6dbRc+/T5ky2XJu8Cx4ieugi2R+qMJOv1IjpGJK4UWEqhyqmssho6QkWywVhMAO/ENzxsfrQ s1y7PN6ky0fUo13UWcrwOqSOmWQL9z5xd0gZZLL6CgYPKI8hgF6QMEIXJiI7gMbh1lj8xjtZwe0n WcXrrOJU283Ob9pfnczH7+s32QYR98239X1kXynJ/UBavT1a1OQi2T9ca8ZYbYuobdqxcrHkHs2w C6bU7RqnKYBoMEVLdGyhCta9Ei74Dj/gkWpT2M/wsGZ3ykJmD6ohLP//0u6HxW3tm/ILFXOD6aGl lshHLIIp0al+YCLTJpMXIBqU85fn9tKBkBGRzlFJTo4rvINNw3sw5PnL5Yb9BHYNzOBzRIf5TCUr iycmMOmWGGwI7J5mO1qbe6/wUj8g7viTJbXNDxt3/w/c7xUUng7obD84NCbLj+h1hzFN/x5CrKcE wIMRaceIa64BKdZCRQmtijiSLwtAy/uowpygmDuJO6wxjNSdomseG6D0nW79kE3aZVax0xovB6s+ 0e8U08gSIPNL0Ptuh5FT8YuQ2Ijgq1DknGOd+L6ys3Qra77ktzN6gb/Vas04o66I0U4UuuQwHMEn WNFmFf8EGAAFwKp5DQplbmRzdHJlYW0NZW5kb2JqDTExMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDc1MT4+c3RyZWFtDQpIiZRV227TQBB9z1fM466Et3ux12upqtQmgCgUIbDE Q0HIJG4aLk6VFNr8PTOztpvYEYiXzXpvc+bMOZPycpJopa2Fcg7t5AGcVq4IoKFcTK7For6rZGKM 2MgkF/fSi5VMMtEs5efycqL5Jt0SIMtvk+dXU5icvLlYL3ZwenpyNX01AxPg7OxiRhtT+0WDgfJm kjirXPCQGJW7gkKdap2HM3zjpCxNPKSVLbIIJD5PaI2JaG1Ea5QvXAf2tQyiupcmF7cSIf8gpDXN eGjgSppMrDc0rmQuqo1MOaXdIJlc5d7sB9YqDUW78En0UEILxeR0C3nTeQflLZKGYZGzB5rBuTRi hjMr4IYW1rSFnDoMYJ34KJNUi5cjHJkPXVjZhe3qZZ1rw5q+XM8oZZAY5pzeRgZSUT9yAWsed4gD ecBVZqdZ0YnvvLXm8TcdqJoFf0CJxFlRxQP1Fvdu8Ybxg53qNoqkPXCYhQnKa/t3Ove4E82QX55Q oplLu0QjtcChjog4yqo9OydUVcRNJd8OAFqVZfmI5nF1D2hGcmYVgUDC0BQLfHcPje/QeLqLtVUF Zvyk9museCEqFCGWoUARWq5PJjY/mcgVrW7qAdBUeZMeNwTPWqC2E+81sYuPNqz/B4wGH9Ai9ZwE QkzUbBb2wY5kiNlTGlxStkkN0Tp8ru6dM7K/scqkYR9abAXv+jZgTd8GyrLrAsRQh15zkRNTcEpE FabBSZQyaLYRmhfa343MSLYFwgkIB5Ztk8KtX3dRu4t+qaKDN2h0MvuWPoCXaK/mz4NXB6llqvC+ TS3pTdhp04aBOsSKBfz0gFYhs6P7nV61H/UOwu8QnCNLWrGkAVsFFm67jamhoLGyadxv+Dit3eMS H6zm0ZdYz8NkwrCzHevYNj3Wsa1XVmdcGOP/v2M/CdSoVPfefI9qeoFWmGJlMpKapiHn8atkJ2DJ II7rBu5Yg2vaWUaFyth37MjWBv8bnP9nsoO/J/gjwABIupQQDQplbmRzdHJlYW0NZW5kb2JqDTEx MiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc4Nj4+c3RyZWFtDQpIiZRVWW/T QBB+z6/Yx12Enb18SVEfmhQEaiWELPEAFXIdpw2kMeSg6r9nZnbXMXZaiYesNnN8nvnmWMXK1SRS JjZWsUjFmSlYuZzMpMzyi/LHZFqWiik0krEuEiZRy5kAVSRjqVNW1sxfnpiKrSyczVe+FJFK+K4S keUrEWnFD+K2/DiR5OLMC+0Row4xD4g5msjYyCwgrgFR8QbOjB9WIzCdqiGaCmhqjPYoIsPXG0AD yCFWlplRZCZEZkZYe0DRvF6PcFQ2okyjGm8ydTg66SeYEpjirNrQv52wvKmWJHsWIKfbGlndOkM6 DyLlD40TfEblO6CczwmCXWGqS4eOhi3Z7USUcfb76LyOzTetk2ECNi7yop/C1c2cTaaf2Gw2vZl/ WDCj2MXF5QKEkTZkfOqivsf1Zbt8PnnZ4AUNJl2DUb1UqJcibggMylouJlzHiHaKTcbZmYbsCq59 AQoT2F0AI5qvgd6U13gcRZQT25k/1y1KtngwQQQZ3257b68Kvhm2cU4tMQjEZUK3zJc5tCfWGSC3 WKBQPJiUB1Hwhu0FtTgc+z2ZtSDeDr6YxqbIX61K1uPXDzAUP04zYlSlr7jm50vj+tZfnlj5BvKA Rku6RrM8kRmlIwfhvjjdNrZJ1/x3xC6UZzhDg1zPBNOfIRwKqFqzxLD8KBHkaeRMLNM82B9gvlry YfUD+lRUmHsHE+pjOema3sQ9YpusYZo2yEKz7yxbtNyezN+injnYpfvSWdTqSMpO7KLaCdNtBD+2 JnjUx85kh9E09I0DzjUF9Sy6aJ2eriunT3lT+zjgPybSS5x5SxuYvCNqSFr/7NN6qpSxcZ7ocVv+ O/q2WxjTuf4eGsxaGiJsTpn81wvkO0GpYvQCXbchvwQohIDbFQ0zw1WYeFZrUBzdFW1osbZ+s1bO Hldm41m0nG3QpNqfsJnQhn8BqeXvwZQ9IqFNg25uT987uPalhU0OlQh7nWrX2/D37pO9oOmzoa/c 24Cbw0f5p7thvP4dYe0vJ9t2L4hjBX9H97ISSeKW/RVgAOBzx9gNCmVuZHN0cmVhbQ1lbmRvYmoN MTEzIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzY0Pj5zdHJlYW0NCkiJnFTJ btswFLz7K3gkD1JIarOAIIfYCeqiQYpCt7goaItu0ziSYMVw8vd9CyXbaYEAPYii+NaZ4VP1eRLp WJupqNZCx8ZkojqIpIgLWwgtqnryIHsVFfJFGS0fVWTkdourgMVIr1L5qjI2BD80LqWKEo75hafo 14MfvoX6XnFVa7mq1jlWjULZyMRFUnJtSIyRWKtXRu497wXs3Y4y4xaKZnIHuR1Z13D0xP3V5NnU Q5SVzxjlmrEJY7AJ3GnC/iDdT0XQYKkpZPWGKxfKARBa8WuhTCFv1FRWqpS38CyttcqWsh98d8pk 0q0x/Mkra6nJwdhiIlq21I0mNrAHm8bThOmXS6Wq3xMdJzoIAvFwcHM3E5OLL9dt/SYuLy/uZou5 SDNxdXU9R8PM/tACkG0mkc3jaWpOWL3UupheQY6LqjLspGNbZqfpz5kxBXZl4lSXw6W4Q2SPyPsW oBBZ/QvyQYAaLwg0cQVkw8qkikdVAD0dEdN2IwN9oBsuDhgqFdmBZ0zvQvo8XDvK7Zi5Ah7oQhyU mUJDOX/iOfuuOI3jivixb7jWJ8xMYZQKOyNA4hlEon48IUIDQwAtzoVKgNTsQ1nKf8mSJHGaZf8h C09NNI7NmSyBuShwHZmc5oZmh0/DANUEtR/nZX8cMh+mhTyaMDm40u33JwcL9LiH0zmO6Q3O/C02 IGhsadI6ksPT3jdjGjfuuMk21PGv9O64Ck4LdeGbdcBEr5pG323QRLPPx4dBwS2W31JisTojo0Gs 7Zi8O26HjrBa/U7mU22/jrpmdtS1qgZZQU7NquaGdFuMuoV/LG0OsLHgEWS7n1N1YBB/JJEp//pL HvW2cZnnQyBe+GeVyA6CEjlwnTDV+Ac+AVaQd4sCsRXY5jgPfPLwhLi1f8eAsXFqP7qJACkbGqux DKVFmQquD0MawUC5XrgO7Vx9h/2yvqSeI19PGVhYFy4tQxF7tPCR3wDC/RG8CGlyhEgFbDBzA7S2 jP4bBtB9nb1DK/4IMABZf5WPDQplbmRzdHJlYW0NZW5kb2JqDTExNCAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDY4Mj4+c3RyZWFtDQpIiZxVyW7bMBC9+yvmSAIVTVKbBRg+xE7Q FA0KBLoFQSFb8tI6khHFTfP35XCoxbLT7WBrTA4fZ96bJ2slVDABCWk+Yh5Pv408KaTWkK7ABa8m 8GVMOQ8slNxTisWSP6afRtImYpIWKkzOgCYN0OQMaGlwErarBzhK+JPI4QDiXN/NYTT+fFXlbzCd ju/mtwsIQ5jNrha4MddfJShI1yMvUELLEDwlYhUhwFTKeDIzGOM0VZQkhU7CPnzXL0YyohoCmTR1 LrgXsGzHvZDVtvXjd/sogH5uM/t45gErchvC1mSryKSbmHJ/mvBAISZatKK0CyuzVdC5am2eMYMd XvnEvZgd9jbTxi7/hUfMJpQbOmW/b83qF/NZYP4193x2MxTI7zF7LjV1fqIQVkbNHbIlFeJupCoq +6vaEzWnt4UiaufqfRmTSzL6SsiAZPSTf5fRbPn+mYop9zTbOuHWWDFpVOZ9LklReEa6G8lVK6tL aeT6wZ2a2d5CQac6fo5FH7KVrupdUSDDtFDiEXtjXrh58mgSwnbPgLtNuMf1G+xpPpQ5vmjE3zna Qsq/dPQpx6eOtlRSwx+wQFiSYVzzuIIUbIseJwdiwtJadomZG3PTc0XLkBM9vbNl1dIKtvjOwp5O ROLr3hQ9sIzO5t2NTpysPaxU8yZQMcIEQuu2v/KNK82gPnCcIk7e1abKiK1ttRFbtUOijbAm2vOY HV+4cfXORHapFAOiJ0LH/p+8EvmXvKKC9pX3P15555X3EXUkbl+tasPpxbklM2XlphhM+Lab0aCZ UQMSnk+Y0iLQwwkbSjD401DOJjUg33VzrSF4a2WBxraavo7cWd4Uj2aFvIPA/VWbVNeNmiQToGJl /wKrOTyh5QkkNvqS8OUGUGpb0wt/hF8CDACF06HEDQplbmRzdHJlYW0NZW5kb2JqDTExNSAwIG9i ag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDczND4+c3RyZWFtDQpIiZxVTW/iMBC98yt8 tKVNGjuJE6Sqh0JXarXd3UNuqFpREkpXNEG4iPLvdz5skgW6hz0kjCfjNzNvnk31MEpEtRDw2gs9 jm1p0K5HUqjq9+jucSJGVz/F9fXV4+R+KqwVNze3U3RWVSK0qJajKIkTYxAErcQiUpRmsdaZiHRc WI14M/ldRbnsVKRTKTYqMnKrolI2rmnJ964yOQdLgxUV8lVZDDaSvwoFH/ZgFnLuKEq8qVTOawxp 2EHvJcBwkq3CbU/VA1WYptQmG3sxkxPYWcjDM/xkHmFL0QM+bFzkno4I6bjUahKnScFBM0l9rSj9 ASvmUl+x8wU3t0ZbNB++U0jNDbpBw1hFGVvgz8N+oU1Yqtx5soAi4cEtLz0tNQWg1y12uIP97ozQ sNnvwzqMXDB3O54PEPxC64ZRxRAAi18N6Q9Um9JTjQawWMZloHGG/WNeR6N8PyU8Tm12rr9vt119 6DU4PmpwYn4FEWZ5PE7GJDhtEeA6SYryBjBAqZqDktiM8yF8P8/jOHWcAYwvtgrj1LIBBcp6i0TP lziOd5oJOI+ztDDLmsn2jGh5D94f8Ewx+k5Fqfwa9Ew7uhAZaPyADwt4OOu8fWn6iAWZICz5/Ilg geogxoFi06Ni80uK5WRGHlwvVJoTSIzPqHdYOqDGj+3SYcjj3JYBmmusBaBqK1vsihIwR6R77WkE fybbZbghsLNMvhHZyBIjdO1Ju59rpEgvacTYOC0taSQd/49GdFL+WyO+1V4QJJjGHR1BGWHdnaxX w7vsL2U5po95oJjVfIj23HhGRS+kzZFLXwKCNMw/XideTQywabrNmhL4GkKes+J4MDTLNQ6OrPaF P/YeNxjwnJGpFFZ23ac/raRlVvYqN/7qI5DVzqnhPaN1EJ8uSNc0WQP2FOZSq3DzOj47Gi9P5IDW r6oA8jEZ9CmoO0UjXCv+83HoExjm8G7UmiE69ST+CDAAIeOcJQ0KZW5kc3RyZWFtDWVuZG9iag0x MTYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3Mjg+PnN0cmVhbQ0KSImMVMlu 2zAQvfsreCSBShFFrYCRQzYgRYPmoFsQFLLFJG5dS7UtGPn7zkJKsp2gPdgakbO+N0/V11kkqqWA v4PQcah1gnYzk72qfs6CKIzimBzYOICRJin7PMmtSmStAq3lq23UczXNJgVmuH24FrOLRzGfXzxc 39+IPBOXl1c3eFhVkdCieuEqrkhSYmygk9BkCTzDPNNcq3qzKiilqFUsu46KrlVg5EoVcglnNd7u VZDSSbshD9G+4Il4hLcY/AuJ4Tt0/a1SjhHkuVeZbNm8x7TfwfcGjVs4k3fiAI/URccuBgttqOQW krVNj31Y+DVcfHQaa7gpPm3oGEQDcBeOkeCMkVQzIybKPSMLFQAUO4sdGOnnyWCcDMdJcBwj7/iW nbbKOBJfgM49dVCEqdY+5xeCsN5gapcXUM2lxSqxK7nkzv2ayF9iaBe7RSMqiFtThqYsiFtTcgXP 1ilKiKe7w1OEdnzbDeuwOcN7EgJOyI71MI+h5IRsvrW926dCNmJBNjfQtUPMKa+8MMS+6/Z4J13g MZ9xFmqTOUInAvl21Tbvo0jKQSTX8Q+vEheLuOkME8yjKC8uIQdISbNTFMZlOk0/7gsxkJHOwyQq PbmP2O8ap6gdHho2EditeZ6DAnM3mbtF0a/AzOTrCjdqU6/xsaajdwgXHN9YjiIFtmRv8UJYvl/h OUfxhi16Byy+cAVHFqZh7Ov92CrXaRWYvtbYshuGTqms7XE09nM81n5x2LvraBDqyzZibKadJJ+I KfViOtFsEZo8/RfHhfmI4wRImkrjfykGsTqKdX5GcaVKXFHCH75h1qOkC2ndyQY3Gcf4aF8yWjiX jCgn4D+j90jExBxzifAv4dfvhkWjZCBwrFyGcW6OPzmsxJ4XYkzr9Ym5eQOncqc+Eml34+FUtp1t O146wAHrah0aXfjC9XYyGtt/ejs0vOfdOPsMqGfxV4ABADQEn+8NCmVuZHN0cmVhbQ1lbmRvYmoN MTE3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTYzPj5zdHJlYW0NCkiJjFRL a9tAEL7rV8ytuwdtdqXVSgLjQxxTYmJSsKCHUIpqyY/SysZ2cPLvOzOrFw6BXqTZ2Xl8830jFYsg VVGcg4aiCl7EWhpx+CvDVPCjbmRojLjIMBFw8AdoXU7sau/4Q9d7tJ04t5c/ikWAJddU9wqZik3m W2B68TuYL2cQ3H2DyeRuOXt8gMzBdHr/QM6i0GCg2AShVjqiEmTojOqE1qrEZRAalTrjEc+xo3iT kTgimlycZOg83r3MEE4k2A0HBrbhQV7P5KL7ZusnqDGuWff579LE4jiMTqHd9CWFVt7u62ybkkwi 5ZWvTjJpG/ORe/mcBeY/43FFuAl8JOC7DDPxFZ1wRUciqAdB98lk7UoPjqpGooIbgmOjcuc+Mvx0 f6jeB5bznuVZ9LOjuc0lTo2jAhOt02yKNVAL44O0ivJkXN4oq9ulEQU5SCRjOrlMSqi0SnLTbRYu S788bL5JHP1IVn2ShkjmfcPzmm5qlMwr5lgxdO2RXg7YQht4kpbEwjoXaVIO4KwGZaJXBW1iKrbs YLeXiVWy2Ie5ZNR5v2454X/hpSbhMtLNom5hJFbzUcbNxJFVNk27kcuhB8PY0bnkYevqRkE7cPW5 gHn8iYCxsywgfsj/KeCAvjWuMNZ08dwHpf5u9JNY4abi5sYCWKmStfhC3BCz8Is1bTVjqSvYkDJE BSzx8UhiPdGNL1OeR5RmPaUjDS70gD1/Lucb6oxV2n38vcyLAP4JMAAUzhV1DQplbmRzdHJlYW0N ZW5kb2JqDTExOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIxNi9OIDE+PnN0 cmVhbQ0KSIliYGCc4eji5MokwMCQm1dS5B7kGBkRGaXAfp6BjYGZAQwSk4sLHAMCfEDsvPy8VAYM 8O0aAyOIvqwLMgtTHi9gTS4oKgHSB4DYKCW1OBlIfwHizPKSAqA4YwKQLZKUDWaD1IlkhwQ5A9kd QDZfSWoFSIzBOb+gsigzPaNEwdDS0lLBMSU/KVUhuLK4JDW3WMEzLzm/qCC/KLEkNQWoFmoHCPC7 FyVWKrgn5uYmKhjpGZHociIAKCwhrM8h4DBiFDuPEEOA5NKiMiiTkcmYgQEgwABJxjgvDQplbmRz dHJlYW0NZW5kb2JqDTExOSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExPj5z dHJlYW0NCkiJagAIMAAAgQCBDQplbmRzdHJlYW0NZW5kb2JqDTEyMCAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDMyNzYvTGVuZ3RoMSA2MTY1Pj5zdHJlYW0NCkiJxFZ9UFTXFT/n 3vexu2BYvo2b6ltfIAYWEdFoUGEju6tAbUAQdrXWXT7MohAJOlSNddZoqz5Ip44kndikIWl0/Nr0 rZgUM7Z+tBhmbLXOxJk4ptoPHG2azSRTrW1nIj3vLVDNjP2373DePR+/d+455967XEAASIIIcJjx bG3hzKILwxpZThLXN3VtUN4tPHQIANMAxJLVHc+1/+b2PB1A+iaAsOq5tk2rfZ4DtwFsRwjfE24J NV/BD29RwDmkPxUmQ1q67Yekt5P+eLh9w8aKhdpu0vcA8F1t65pC2auzVwOkPEpznGsPbezg9VIe gP064ZXnQ+0tw5du/Jz0EcKf7ehs6Xj2wydWAWScIb0OUJ6MPwIRLMIF4QJZssZGaOZKMjke9iyp VRRwf6F8MSLl4ztQJBehHnko+v/8XHqop4ioCf1sG1tO0k+gkd77iJuJX4Ne6GX9CQwUE+skVcJN cQhmQqdpL4Yt9PbAP/Eg/MC0zIdG8jcSepDGUvI10YhmjF7sMcfvwQ6K/SXrZ2fZWdNbRnErDUSC WL84RHYj3nZ4F67hacK8CHvJdwIuGV9R5F6Iwl2cRtSNNzDOqsmKxvwUZy2heynfX8EV+DtmYClq eJIwaWybmUtitghhBokumVEMWoJtuA47cTfFHGaczaao69gu1sd0dpYHhFJxSEqT5shtFAWB0Z5P pQqNaN+CWpq5EV4Yj5qg3yPDGqzDML6KfZTDIMaJbrMCVkZdN+gVHhSShVviWvFtoiFpmfyGRaLY IkgwCRTIgVlUlZfmqKGcm2ENbDbpRaIt1MuX4E3og7fgEMTgAzhjzAlX4Rrcpe6kEBl1zcGnsYEo QNSJW3EH9aP7PnoZX8d+/IDyO4+X2RSqOkFtVH0iy+1sHzvOzrPfsutsmH3KvuTArXwVb+Tr+X5+ mF/kF4XFQp/wlvCJ8ImIom52Kk3KkFZK3UQ9slVeK++Q98hvyO/bpkM21eWiuiqhgaraRJVsgV2g masWIzoO7xENwadGHUQjo5UY9DR60IfLiAK4HIPYjutx43hF7+ABPIjHqZbLRB/jVfwT/g0/N+ku k1gWyx+vr5rVsga2lr3KXmOvsyO0I/vZSfYxu0Y1DrM7VGMST+OZfDL3ch9RHV/BN/LtPMrP8qs8 TuuWLCwQSoVlwkqq/ZwwLNyilWQiF3PE2WIJUVh8Xtwqdos/pR0dF+NSstmVNCldmiftlN6U+qUr 0ldyppwlTyWaLhfJtXKb3CUfloflm5aj1mesrdZOmwsOwwz4xddO73u0u3/NVkqFMAmv0m54gacQ SjHOHkuW26ytrN/ITq7FabRSf4C73ApVwjlo4CugTWzkSfJncBDXC9vwCPfBUdgvd+FJHuRxvl/M keYl+sn28cPyJjko36RMb/O9Yliejs+I3XiQldGJ7sQa+Afege/QzBtYHpyD3bALu8ACvZajOIHO 2iCbgt3i2/yY0Me94lZ8klbQIQ7x78NsyIRkmAZTaa+LkAGie87cObOKZxbNKJxe4MrPe3LaE7k5 j6tTncqUyd94zDHp0YnZWZkZ6Wmp9pRHJiQn2awWWRIFzhBcXtUXVPTcoC7kqosXFxi6GiJD6D5D UFfI5HsQoytBE6Y8iHQTcvXXkO4E0j2ORLsyH+YXuBSvqui/86jKAC6v8ZP8skcNKHrclJeYspBr KhNIcTrpC8U7MexRdAwqXt3XFda8QQ/FiyXZytXyFluBC2K2JBKTSNJ9akcMfaVoCsznLYkxsEyg rPRK1ePVK1SPkYLOc7yhZr26xu/1OJzOQIFLx/ImtVEHdaGekm9CoNycRpfKddmcRmk1yoFuJeY6 rfUM2KExmJ/crDaHvu3XeShgzJGary9SPfqizcMTC1wDeKDOr1vLBxDq/CegciQSq4h4PAFjtrRy /04Tnk3w7M3DDq55J7YqhqppOxW9r8Z/v9dpvAMBClrgqlrqd1LWqrdHMcpY6jcroKA4sZCSNGxG mYmCW1SvYQmuUXSrulANa2uCtFiTNB2WbnIem1TpPjHyR6j0KlqdX3XqZQ41EPI8FssAbemm/gq3 UvGgp8AVs6cmOh17JGVUSJ5wv9Ay7jMlE25IlPVYq9HISK2gLaIrTQpl4ld1ljPXeLXMBa1pLsHo CSB1tJX6F9TsJcZCiDl2VdHuAG0ENf7Zg5bQqEXKsd8BQzS2y/iWI/+YrOfn63l5xk6Ry2lpKbNS U59d4OrSq9QOu6JXUcug2k8fBUoKqeVOp7HK3QNuaCRFj9T4E7oCjY5j4C7MD+gsaHhOj3kylxme yJhn/POgStv5OBiXwEzdkjv+l2LPSveGS3TM+h/uloSfjo9XiQlijlbtzw1p3Y7coNYToKXx0VHU NJ+q+LSgFhoYiTSqil3VYlVVWoc3OFbSwMjpbofu7gmEkZqqFye6oaeX+7mDBRISc/BAAf1TjdDl LkJXCw4yqO4U+SMUPsKf0V10BMQRfgJvABTei9vjUPY5vYtmFKc6U3Ocqc4Ih68iDO6BOPTvuRFh iG6bEGXVeJlvpMtvxi+BYyVYQcLFFCBOf0Uz0mc9VTyTfq8kdWputL50QUPDgtJ6NmyMCxrqzZbQ /XJNzSlpVcr8OxaHxfxN3x/de88Yzyz8axjgXrXtulxEarKJN2YFueheNV2AewBGLtquj9r/+/xZ AKNKumITGzEtpVBpnQa9tlbi01Ap50Kv9SRE+WEYtByFqDwVotaUUV6V4KSdxD0QtQxC1HYKouKP E2xghXXEl8hHFzD5Fai09FHMHSQ7E36TDXkR2YmFfohKfvq+JcHy7gQLzQk28NIpqB9jy18It5hs 52mO98nvIE4i2yyybaMxE3qlCugdm0v81ygPEVPO0gqyZ47mkZfIxeqmWJS3TPEsJ2ik+uTvEu8h vfg/5JdNbBtFFMff2K53koY0DSWyCJAJQVxCPjAiTVVa2Q6kaa2GEFORVBWtY6+dVVNvtLuJVIp6 qSIqINUKJE7QUBVoAg11Gz5CxQEJChy4cKAIyglx5MwBkMp/ZhYTp6EQCS6wq9/+37z3ZnY+nMkO tKTHymdQfwe0QEu17XQygrmT/P4uzOeeVfRWcQw5x1bNxT8MPmEXwwt6zOo9q5nT/FVeROb9sDKH NQSxL2FvWrNtBRtb5Xvmz3P/HnxsFTiacP37vf9m1Ebx+4zqNVfrXt3u1xX7akBQjj5YDX9WU4n/ Uk3F/zRdkcg1VnYSuoLwNcqFb6Mc34UPdaJ7/2d3/3/wlvvr96yOumiW6vEfpAHWNmzEP0YOqkOg 3JtfquzCcb1H4wpTDCVtR2DvCewo7LHANrBTP4VMitSglKefA5tRN3sysENUz04Fdhj+lwM7AvuL wI7C/jWwDZxL71sQ8e7uHrHXyjm2axc80Wc7k7aT9Sy71CmSExNi2CqOe64YNl3TmTbznUODgyOZ ofYnrFIxD9yOYbM4NZF11uuvOITlCtPyxk0HX92OWbRcz3TMvPCcbN48knUOC1tGVhQLa/dXWCWB ZsS+kuWhfsbLeqYrsqV8Fxqw1Qty9lTJcyzT7RS0gANQHIeRbuqBtZcsHIccsskFBfLg64Pl0KR6 ZuGxYJWoE5EkTeAWNAxfkcYRc1XJhJrInsYzj8whGsQ9QhlY7TjAWqhfRESrSx2qTpGm0FoW9apL 6639b+ffmCFgyacJ9TAPcuwCuQIqa8qop7xyPgRsOZN5lI6oFg/DZ1fqrB0trGt1hOqbCHojaB9K luqDfH8GVlaVXPXOErxdQQ/sFSPIoTSFqOyRpbKx6ok66u/Hn1/jZp4YEMuhnksDccgJJey8lre0 LGiZ13JOy1ktZ7TMadmtZUDLLi0pLQktO7U8pGWblqiWiJawFpZ4FPoduAa+BVfBx+A98C64ABbB eTAPzoE5cBq8Ap4HJ0AOHFRtXtBNL2p5U8sbWl7X8pqW01oe1pLUskNLrxZDywYtIS2USEC/AV+B z8Fn4FNwBbwP3gFL4G3wKngBHAX5gfiWmi01W/1lNp3YbfhnDP9Fw581fNvwJwy/YPim4R8w/P2G P2r4I8Y9/G4u+F38Dn47j/EmvoU38gZez+t4Lec8yiM8xPEtUb41nA6lMymWLn+Uo/SYKP+UaVtm tY/tL29oS7FyY5rSj6di5d72cuikOuIus+sXGTs10yxPtx8QY9dnZpsDHR2lpvYbr1hVKT109ENq YVux1bewB5aMlk8M6c3A6yuvL72+8sbYpSGKp7PPHbqT1mj4j4vdNFqV+Yglhzs0cpFTarTvgNal 0MZajOdQc+toqqlhcqca3PbW2PHmyxFi87QRh7y6tlT5FiBDHcmOpAzhZCFD9XBvCkKx49tbmy+z +SDUAPdmTOVvAgwAdw53iQ0KZW5kc3RyZWFtDWVuZG9iag0xMjEgMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAyMzA+PnN0cmVhbQ0KSIlckMFqwzAMhu9+Ch3bQ3HaSzcIgdFtkMO6 sWwP4NhKZlhkoziHvP1kL3QwgQ3y/3/it/SlfWzJJ9BvHGyHCQZPjnEOC1uEHkdP6ngC523aunLb yUSlBe7WOeHU0hBUXYN+F3FOvMLuwYUe90q/skP2NMLu89LtQXdLjN84ISWooGnA4SCDXky8mglB F+zQOtF9Wg/C/Dk+1ohwKv3xN4wNDudoLLKhEVVdSTVQP0s1Csn90zeqH+yX4ew+32V3df9U3Nt7 5uR7cAtlF2bJU3ZQguQInvC2phgiCJWP+hFgALLTb88NCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9i ag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNzc2L0xlbmd0aCAxMzU3L04gOTgvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN7cWF1P20gU/Ssj8bz1fH9IFRKwVGKhFAHVPiAeUuJNo6VOZByp/Ps9 1zMTgnHitUqlFinyeMb3njn33DvjcSzjzDGvmGfSKRaYDJIJzgwPTAjcGcsERoTQTCi0Dh3cSsWZ MGi9ZwImSqPj0AaMY0hrXABhuGWSTI1kEngmYCJAWOBK4DmOceA52EtAeLIHnid74AVwkQRl8Rzs OCbH1JJbzpQAJOwVQVuMK0DDXmm0wFcGUwBf0VRk7zAV2QNKA18Bz8BeA8/AXgPPwl4Dz8JeA8/B XgPPwR4hSg9wDTxvBdPA8wF9oobgdAA1rqAdWiMYfkqAFE0lgGcU2oA+qEqIYgwoYz6iquBkHKgj GOPRmsDwUxrpIOoGYmJKhCGYpZAwmQWegwgUuoOTBZ6DvpZChJgWeKQjpFMBvG1AqEiWo5Dh5EBZ IBikVAskHz8tkWSHkCAUcwYtQBwkABHmHKTAfM6jdegDzyBJHngW9eKBZyG2B54FWVSVdjQOPBfQ B55HcXjgeYjjgecBhhLSAUF6hMy5Z6EtP84CSYiiggQGhcRIOgESkNxIiBMMJOXoW7QQMzhIiyRD AqMRXwCeBqjgpDUeCIhnjKeyJtWp3ihdFoG/f1+cYiFwdllcTOqyaq7rssSieD5wXn5vTstHJorL xX35cbLEgiGL68dlWVw19equNbtcLJr9fYK8wRqCAS2htlGx0bExbRN87LnYxF6IfjI2PlrK6OfT Mxub6OfiDCo+s9FSRT8TMVVsTLTU0VK3KLfFBWtviqviqryL7M9X3x5uOO0GZNEOHVTVopk080VV XC0nVXH0dVI3xYf5bFWXxZ/zyayefFt368XyaLLM3eNqCt+yOKfLByj01Dup7udVefV1AhWT9adV Q2NxFig7/7dcrJrUXX15uKvny3V3WdabA9fI0uHie3EAap+raVk/Ie0d270DvxcC3Rwe7AVbXOzv /58sVav7+3gRtjvwLHMb46Ez0F4k74ymHG8MyF4/1TXT3YEu0+cVsjHueyfopau6dFWXruqlq1Tv aJez6nJWttevG4LqhqB62esue91lr3vZ6w77W6r9dregNXLKONZL2i1mGPZp6bwsr7hq2g0neorR niJ5ytGePHmqkZ4hJEc91tEmRwfH0ON5driYPmZjkyUZq2bQ2XOsmiEnUFBoQe5m6LMOwpM1H7D2 OVFjWXmXPYmVtwPz5BgksfJ6wDoXnhrLyuXoVctqIHqXo1du7Dw5euXHeuZy021saoBhrjdtyHpA N5cXjw5kLXZb26yVGbtKbdbNECtrBubJWhliZQcqxebcW9oB7IA+Nm801o6NIWtliZUJu+cx602C WJmBXcLkrLmxrEzeJVzLaiB6k2PwLauBfOucbz+Wlc759sRKD0SvcwyBWOmd1fGpOJs8toekBoey Exx8qgY71zveHogO7uezqvhr9dDM/3lsR5LFH63J3/W8mVezj4tpWZzV11/i8TW9B2nqfDo8O0kn 20g9cbpdqwCL7Cu3+L4+0TXiS4Dd9q8pVdog0/l6U6pYe6mo+qRSYYvv25RKuRyufyFVPMbFXaFX KrvF941KlV5T6YtuU6r4rkgvgbS79yomt0GkQ3rPo58o5ttKT1707sWij8eRdM5IB4i+9Ei/DSJ9 kfU8etPp+ZF0SjHIuDXZkk6ZXrDpL5bNXPh1pp/l71coQplXcfybaLMI47dE+kjorT65xfcXXa8/ muCcxdBN8E38GExfeX1SibDF9/WJ/o5rR+QXc+i+1Nf/BLzW2nmyP66mP8V2LI8jyFPWPeb/CTAA SCDNBA0KZW5kc3RyZWFtDWVuZG9iag0yIDAgb2JqDTw8L0xlbmd0aCA0MTU5L1N1YnR5cGUvWE1M L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIg eDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4yLWMwMDEgNjMuMTM5NDM5LCAyMDEwLzA5LzI3LTEz OjM3OjI2ICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC8iPgogICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxNC0wMy0wOVQyMToyNjoxOCswOTowMDwv eG1wOk1vZGlmeURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDE0LTAzLTA5VDIxOjI2 OjE1KzA5OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpNZXRhZGF0YURhdGU+MjAx NC0wMy0wOVQyMToyNjoxOCswOTowMDwveG1wOk1ldGFkYXRhRGF0ZT4KICAgICAgICAgPHhtcDpD cmVhdG9yVG9vbD5Xb3JkIOeUqCBBY3JvYmF0IFBERk1ha2VyIDEwLjA8L3htcDpDcmVhdG9yVG9v bD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvbW0vIj4KICAgICAgICAgPHhtcE1NOkRvY3VtZW50SUQ+dXVpZDozM2ZlMmRlYS1kM2YyLTRh MjQtOWEzNC1mOGJiMmQ1NTZjMzI8L3htcE1NOkRvY3VtZW50SUQ+CiAgICAgICAgIDx4bXBNTTpJ bnN0YW5jZUlEPnV1aWQ6ODVhNzQyM2YtMzEzOS00ZDMxLTlhYjMtOWIyNzc3NWJlMzM2PC94bXBN TTpJbnN0YW5jZUlEPgogICAgICAgICA8eG1wTU06c3ViamVjdD4KICAgICAgICAgICAgPHJkZjpT ZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+Njc8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6 U2VxPgogICAgICAgICA8L3htcE1NOnN1YmplY3Q+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpkYz0i aHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8ZGM6Zm9ybWF0PmFw cGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgogICAgICAgICA8ZGM6dGl0bGU+CiAgICAgICAgICAg IDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiLz4K ICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6 ZGVzY3JpcHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxp IHhtbDpsYW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8 L2RjOmRlc2NyaXB0aW9uPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpT ZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+VGFrZTwvcmRmOmxpPgogICAgICAgICAgICA8L3Jk ZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAg ICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZj0i aHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+QWRv YmUgUERGIExpYnJhcnkgMTAuMDwvcGRmOlByb2R1Y2VyPgogICAgICAgICA8cGRmOktleXdvcmRz Lz4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZng9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmeC8x LjMvIj4KICAgICAgICAgPHBkZng6U291cmNlTW9kaWZpZWQ+RDoyMDE0MDMwOTEyMjU1MDwvcGRm eDpTb3VyY2VNb2RpZmllZD4KICAgICAgICAgPHBkZng6Q29tcGFueS8+CiAgICAgICAgIDxwZGZ4 OkNvbW1lbnRzLz4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94Onht cG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag0zIDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCA1Mi9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0K aN4yNDBRMFCwsdF3zi/NK1Ew1PfOTCmONjSwAIoGxeqHVBak6gckpqcW29kBBBgA+ZUMQA0KZW5k c3RyZWFtDWVuZG9iag00IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0 aCAyMTIvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjebI1BS8NAFITnp+ytG4TmbTRipRSCoRct BCx46WWTfeJamyfrLpI/r25ExIO3GWb4PkO1IrVel02KTxL03h65KG/kdOIxvunv+GrHaU6BbfQy tjaybq8rMhd0TqvKVJemPqPVgmjx88qgj088QBDgoNJBQ6HBkKugh0XMvUOLLXa5HcF5UTAgLEFF ecvTuwQ3+3fi/hNe/Qq7IC4NHHTjpGfVtVt15/tgw6QMLTPsXlIYOHP8o2f3B2Sqqq7nQ+qfeYhZ tvfxhXWx2XwJMAAQKUr8DQplbmRzdHJlYW0NZW5kb2JqDTUgMCBvYmoNPDwvRGVjb2RlUGFybXM8 PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0lEWzw5RDQ2REEw QTc5QzE5OTRBOURCNjM3MDEwMDEyMDUwND48OEIxMjU5MzNDRkEyMjE0OUExNjg2N0FGNzc4MEI0 QkY+XS9JbmZvIDEwNSAwIFIvTGVuZ3RoIDUyL1Jvb3QgMTA3IDAgUi9TaXplIDEwNi9UeXBlL1hS ZWYvV1sxIDIgMV0+PnN0cmVhbQ0KaN5iYgACJkZDfQYmBtZ1QEKwB0gwTAASTIZAie3XQVwGxlFi 2BNM84EEIwNAgAEANSIF2w0KZW5kc3RyZWFtDWVuZG9iag1zdGFydHhyZWYNCjExNg0KJSVFT0YN Cg== ------=_NextPart_000_01C3_01CF3BDE.959F5760-- From nobody Mon Mar 10 01:16:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572E11A03F0 for ; Mon, 10 Mar 2014 01:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 1960qCO2nlgN for ; Mon, 10 Mar 2014 01:16:22 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.106]) by ietfa.amsl.com (Postfix) with ESMTP id E74B11A0320 for ; Mon, 10 Mar 2014 01:16:21 -0700 (PDT) Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 403D3D08BFB; Mon, 10 Mar 2014 09:16:16 +0100 (CET) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id 27534D08BF4; Mon, 10 Mar 2014 09:16:16 +0100 (CET) X-KeepSent: 9BFD7880:F9B9E167-C1257C97:002D0622; type=4; name=$KeepSent To: saag@ietf.org, housley@vigilsec.com X-Mailer: Lotus Notes Release 8.5.3FP4 SHF33 April 26, 2013 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 10 Mar 2014 09:16:14 +0100 X-MIMETrack: Serialize by Router on ROSE/PTB(Release 9.0.1HF198 | January 23, 2014) at 03/10/2014 09:16:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/KvMLXB0w9LRbzMBbSPb3bQQqN_w Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 08:16:24 -0000 (I'm re-sending my mail written on friday, because it seems to have had an HTML attachment) Hello Russ, hello all, I guess my first question is: does feedback on the draft go here, in the general saag mailing list? (I am a first time participant with mailing list feedback...) I'd like to say that I think this topic is very relevant and would like it if this could be "made official" as a BCP document soon. Now, moving on to my feedback (WARNING: pretty much all of this concerns formal aspects or structure, not content). All the content so far looks good to me, I'm just not sure I understand the structure: - Section 3 is named "Algorithm Agility Considerations", is that a default section name like "Security Considerations"? If not, how is this distinguished from the rest of the document? - Section 2 is named "Guidelines". It feels to me like section 3 might be giving guidelines as well. Or does the distinction lie in the fact that section 2 contains "SHOULD" etc. statements and section 3 does not? - If this is the case (and indeed it kind of looks like 2.1 and 2.2 give advice on problems described in 3.1 and 3.2, respectively; 2.1 and 3.1 even share the same name), then I feel like perhaps section 3 should come first. What are your thoughts on that? - At the end of subsection 2.2 (Mandatory to Implement Algorithms), there are three paragraphs about key sizes. should these go into their own subsection (which might for example be named "Key Sizes")? Or does this really apply only to algorithms which are mandatory to implement? On a side note, I think I spotted a few typos (stuff between underscores denotes stuff that is there in the document, but shouldn't be there in my opinion): Section 1: - there is a comma without a space afterwards ("properly,communicating") Subsection 2.2: - "but others allow_s_" Subsection 3.1: - "but it may still necessary to handle" is missing a "be" - "the transition _to_ from unprotected to protected" Subsection 3.3: - "some environments will restrict_ion_ the key management approaches" That's it, at least for today. I hope some of this is helpful, although none of it is directly content-related. I need to get some sleep now. Good night/safe travels (for those who still need to fly back home). Kristof On 03/06/2014 01:59 PM, Russ Housley wrote: > I gave a presentation in the SAAG session today. Once we get the > content right, the Security ADs have agreed to sponsor it for BCP. > So, please review and comment so that we can get the content right > soon. > Thanks, Russ From nobody Mon Mar 10 08:54:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4FA1A0265 for ; Mon, 10 Mar 2014 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.146 X-Spam-Level: X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 EbXqy2ILS1tO for ; Mon, 10 Mar 2014 08:54:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 121F11A0495 for ; Mon, 10 Mar 2014 08:54:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFALDfHVOHCzIm/2dsb2JhbABagkIjITtXwTyBHBZ0gicBAQMSG14BFQUQVg8IDwEEGxMHh1cBn0qEVasoF44qg1yBFASfOYs5gy2CKw X-IronPort-AV: E=Sophos; i="4.97,624,1389762000"; d="scan'208,217"; a="52744815" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Mar 2014 11:53:26 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Mar 2014 11:39:51 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 16:53:25 +0100 From: "Romascanu, Dan (Dan)" To: "saag@ietf.org" Thread-Topic: SACM report Thread-Index: Ac88eNwLCkoGQCLxTkivPXdYeLRMVQ== Date: Mon, 10 Mar 2014 15:53:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E44AE98@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E44AE98AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1xPJoEoGl2IYHNQXreUiI-pwgsk Subject: [saag] SACM report 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, 10 Mar 2014 15:54:06 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E44AE98AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SACM met at IETF-89 on Thursday morning. The attendance was about 50 people, with a few remote participants includin= g Adam Montville, co-chair. A few people noticed that the conflict with DANE needs to be avoided in the= future - the chairs will take care about this when requesting scheduling a= t IETF-90 The terminology document is making progress. The participants recommended f= or the document to continue to be open and updated as the WG progresses the= use cases, requirements and architecture work. The open issues in the use cases document were discussed. Next version will= probably be good enough for WGLC. A new proposal for telecom use case was presented. This is out of charter b= y now - the author should work on a revised I-D to mark what can be covered= by the current charter and what would need rechartering Architecture and Requirements are by now one I-D. Architectural diagrams we= re discussed. There is need for help to the current editors, three contribu= tors in the room volunteered. The WG will continue with the interim meetings that seem to have proved to = be efficient. The AD concluded that it's time to start thinking about solutions for proto= col and data model - one source is work in OPS --_000_9904FB1B0159DA42B0B887B7FA8119CA2E44AE98AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SACM met at IETF-89 on Thursday morning. =

 

The attendance was about 50 people, with a few remot= e participants including Adam Montville, co-chair.

 

A few people noticed that the conflict with DANE nee= ds to be avoided in the future – the chairs will take care about this= when requesting scheduling at IETF-90

 

The terminology document is making progress. The par= ticipants recommended for the document to continue to be open and updated a= s the WG progresses the use cases, requirements and architecture work.

 

The open issues in the use cases document were discu= ssed. Next version will probably be good enough for WGLC.

 

A new proposal for telecom use case was presented. T= his is out of charter by now – the author should work on a revised I-= D to mark what can be covered by the current charter and what would need re= chartering

 

Architecture and Requirements are by now one I-D. Ar= chitectural diagrams were discussed. There is need for help to the current = editors, three contributors in the room volunteered.

 

The WG will continue with the interim meetings that = seem to have proved to be efficient.

 

The AD concluded that it’s time to start think= ing about solutions for protocol and data model – one source is work = in OPS

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E44AE98AZFFEXMB04globa_-- From nobody Mon Mar 10 12:09:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED981A06DA for ; Mon, 10 Mar 2014 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEsH0G6YO5jp for ; Mon, 10 Mar 2014 12:09:51 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 48F501A0696 for ; Mon, 10 Mar 2014 12:09:51 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 10 Mar 2014 19:09:45 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Mon, 10 Mar 2014 12:09:51 -0700 From: Zach Shelby To: "saag@ietf.org" Date: Mon, 10 Mar 2014 12:09:40 -0700 Thread-Topic: DICE WG report Thread-Index: Ac88lE+uJLEY5yz5SIeePF+X2m8vCA== Message-ID: <8CD36D87-EFC0-4D59-BD9C-97599E48F24F@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031019094502102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-l7iu9ZEBYuI_Kd12W61T65CLoA Cc: "dtls-iot@ietf.org" Subject: [saag] DICE WG report 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, 10 Mar 2014 19:09:54 -0000 DICE IETF-89 WG Meeting Summary (for SAAG) The DICE group had a compact (one hour), well-attended and productive meeti= ng last week. We had two presentations covering our main work items. Hannes Tschofenig presented an overview of draft-hartke-dice-profil= e-03, on which the authors received good feedback on the need to cover peer= -to-peer DTLS between constrained devices and some of the decisions that ne= ed to be made in the profile draft. We will be calling for WG adoption of t= his draft today. Sandeep Kumar presented the progress on draft-keoh-dice-multicast-s= ecurity-05, which is related to our multicast DTLS record later WG charter = item. Since Vancouver the WG has been debating on the appropriate scope of = this work item, and some have argued that source authentication and public-= keys are needed. In the meeting there was good agreement that draft-keoh-di= ce-multicast-security-05 is a reasonable solution for what we were chartere= d to do, and we should not try to add source authentication to the DTLS rec= ord layer. It was agreed to encourage a straw-man draft to be written explo= ring if an alternative approach would make sense doing this in CoAP includi= ng source authentication. This is not in our charter, but the draft is mean= t to help us determine how to proceed. Sandeep has agreed to work with othe= rs on that draft. Finally, Ekr mentioned the TLS 1.3 effort and the need for input fr= om DICE regarding DTLS 1.3 and IoT support. We're encouraging the WG to giv= e their feedback regarding DTLS 1.3, and Klaus Hartke is at least intereste= d to write that up as a draft. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Mon Mar 10 18:40:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEDF1A06D8 for ; Mon, 10 Mar 2014 18:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 ZrA_t04d06iH for ; Mon, 10 Mar 2014 18:40:32 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 31F391A06D6 for ; Mon, 10 Mar 2014 18:40:31 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2B1ePpW006943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 21:40:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2B1ePpW006943 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394502026; bh=oMFwZpHr3EHCP+sIZQ1ojqCyM7g=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=owy/uNaDmDL8ZoopUpgyMXWqDYO8983wLrIREgOrxuhe0lLzQfaF8PdGzif3mYOE3 hSqzGWvN0LpouAAZ7Cm8NJt9qURHapNbuI020DPwIqBr3Nec5ZPJwkV0l1Tat7kH5o aKuAjj69vmW/h4c5+U5PBGKSIPA1IRXIT2CCiz2Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2B1ePpW006943 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 10 Mar 2014 21:40:12 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2B1eC2m016982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 21:40:12 -0400 Received: from mx15a.corp.emc.com ([169.254.2.60]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Mon, 10 Mar 2014 21:40:12 -0400 From: "Black, David" To: Russ Housley , IETF SAAG Date: Mon, 10 Mar 2014 21:40:10 -0400 Thread-Topic: [saag] Please review draft-iab-crypto-alg-agility-00.txt Thread-Index: Ac85RNYnV72R5/OfRHqhiQdZHQHlmADhJhig Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076B35C616@MX15A.corp.emc.com> References: <2036CE6A-BB74-428D-AED2-BEFB01B08FB3@vigilsec.com> In-Reply-To: <2036CE6A-BB74-428D-AED2-BEFB01B08FB3@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XCpsOofnmYI1I4wYJtv0D8iQfa0 Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:40:35 -0000 The draft generally looks quite good - here are 3 quick comments: -1- Section 2.2: Some cryptographic algorithms are inherently tied to a specific key size, but others allows many different key sizes. When more than one key size is available, the algorithm specification MUST identify the specific sizes that are to be supported. AES CCM and GCM also have multiple sizes of ICVs (Integrity Check Values) for which an analogous MUST should be included, perhaps in the form of a general statement about other aspects of the algorithm, with ICV size as an example.=20 -2- Section 2.3 could be blunter - if the weak algorithm does not provide acceptable security, the protocol needs to be configurable and configured to neither offer, accept nor use that algorithm. -3- Section 3.2 When a protocol specifies a single mandatory-to-implement algorithm for integrity and authentication, What about encryption? The rest of the paragraph appears to be applicable = to encryption algorithms, although the second and final paragraph in that section is specific to integrity.=20 Thanks, --David > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Thursday, March 06, 2014 8:59 AM > To: IETF SAAG > Subject: [saag] Please review draft-iab-crypto-alg-agility-00.txt >=20 > I gave a presentation in the SAAG session today. Once we get the content > right, the Security ADs have agreed to sponsor it for BCP. So, please re= view > and comment so that we can get the content right soon. >=20 > Thanks, > Russ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Mar 11 14:53:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842BD1A063F; Tue, 11 Mar 2014 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 2gdfsCku1caT; Tue, 11 Mar 2014 14:53:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC21A081F; Tue, 11 Mar 2014 14:53:31 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49887) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNUc7-0007aT-Vo; Tue, 11 Mar 2014 17:53:32 -0400 Message-ID: <531F85D5.2070209@bbn.com> Date: Tue, 11 Mar 2014 17:53:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> In-Reply-To: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> Content-Type: multipart/alternative; boundary="------------070101090705030407040800" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wxMP8_JVrusOKMyfpIQQfwF6b90 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 11 Mar 2014 21:53:39 -0000 This is a multi-part message in MIME format. --------------070101090705030407040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe, > On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker > wrote: > >> The term opportunistic has become the new synonym for 'Good' but it >> is being used for many different things. >> >> A) Unauthenticated key exchange > > Fwiw, this is IMO an error since I first introduced BTNS, and I had to > clear it up on Wikipedia multiple times. I see nothing opportunistic > about this mode as a stand-alone concept. The original use of the term appears to be from RFC 4322, Micheal Richardson's document. He describes how to use keys retrieved from the DNS with IPsec/IKE, without prior, bilateral arrangements for access control, via the SPD. He defined OE that way, and noted that it was not an unauthenticated mode of IPsec. I prefer that we stick with that definition of the term, which is IPsec-specific. I have suggested "opportunistic keying" as a preferred term, since its the key management, not the encryption per se, that distinguishes other proposed modes of operation for IPsec, TLS, etc. The breakout group at the STRINT workshop that discussed terminology suggested using the term noted above. Steve --------------070101090705030407040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe,

On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

The term opportunistic has become the new synonym for 'Good' but it is being used for many different things.

A) Unauthenticated key exchange

Fwiw, this is IMO an error since I first introduced BTNS, and I had to clear it up on Wikipedia multiple times. I see nothing opportunistic about this mode as a stand-alone concept.
The original use of the term appears to be from RFC 4322, Micheal Richardson's document.
He describes how to use keys retrieved from the DNS with IPsec/IKE, without prior, bilateral
arrangements for access control, via the SPD. He defined OE that way, and noted that it was
not an unauthenticated mode of IPsec. I prefer that we stick with that definition of the term,
which is IPsec-specific. I have suggested "opportunistic keying" as a preferred term, since
its the key management, not the encryption per se, that distinguishes other proposed modes of
operation for IPsec, TLS, etc. The breakout group at the STRINT workshop that discussed terminology
suggested using the term noted above.

Steve


--------------070101090705030407040800-- From nobody Tue Mar 11 15:13:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675F1A0823; Tue, 11 Mar 2014 15:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 UaItCGUI0cLa; Tue, 11 Mar 2014 15:12:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CA1A063F; Tue, 11 Mar 2014 15:12:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMCZWQ019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:12:35 -0700 (PDT) Message-ID: <531F8A53.1040103@isi.edu> Date: Tue, 11 Mar 2014 15:12:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> In-Reply-To: <531F85D5.2070209@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oP0ui2sSqq_VFh1YomkeFOTUtCI Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 11 Mar 2014 22:12:57 -0000 Hi, Steve, On 3/11/2014 2:53 PM, Stephen Kent wrote: > Joe, > >> On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker > > wrote: >> >>> The term opportunistic has become the new synonym for 'Good' but it >>> is being used for many different things. >>> >>> A) Unauthenticated key exchange >> >> Fwiw, this is IMO an error since I first introduced BTNS, and I had to >> clear it up on Wikipedia multiple times. I see nothing opportunistic >> about this mode as a stand-alone concept. > > The original use of the termappears to be from RFC 4322, Micheal > Richardson's document. He describes how to use keys retrieved from > the DNS with IPsec/IKE, without prior, bilateral arrangements for > access control, via the SPD. He defined OE that way, and noted that > it was not an unauthenticated mode of IPsec. RFC4322 defines OE. Section 1.2 describes "anonymous encryption" which is basically unauthenticated key exchange. From later in that section: Although it is a useful mode, anonymous encryption is not the goal of this project. Michael and I discussed the difference between the two (OE and anonymous encryption) on many occasions, and I don't think either of us ever confused the two (though someone who edited Wikipedia did once). The sentence above confirms that, AFAICT. > I prefer that we stick > with that definition of the term, which is IPsec-specific. I'm not quite sure what term or what definition you're referring to: OE, anonymous encryption, or unauthenticated key exchange. Can you clarify? > I have > suggested "opportunistic keying" as a preferred term, since its the > key management, not the encryption per se, that distinguishes other > proposed modes of operation for IPsec, TLS, etc. I agree if you're replacing OE with OK ;-) > The breakout group at the STRINT workshop that discussed terminology > suggested using the term noted above. Sorry, but to clarify, which term? Joe From nobody Tue Mar 11 15:17:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C2A1A014E; Thu, 6 Mar 2014 16:44:41 -0800 (PST) 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 tevUjjtw6wRg; Thu, 6 Mar 2014 16:44:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F71A00CA; Thu, 6 Mar 2014 16:44:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 954212AB24D; Fri, 7 Mar 2014 00:44:32 +0000 (UTC) Date: Fri, 7 Mar 2014 00:44:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140307004432.GH21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/f3_pXPPIU-0Ltk2Q9hr1k8tE0Sg X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:55 -0700 Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 07 Mar 2014 00:44:41 -0000 On Thu, Mar 06, 2014 at 09:23:23AM +0000, Phillip Hallam-Baker wrote: > The term opportunistic has become the new synonym for 'Good' but it is > being used for many different things. Since I am the primary perpetrator of the thought crime in question, :-) I'd like to explain the term we used, and why, and solicit a better term if the IETF has a better way of expressing the underlying idea. Background: In the Postfix community, we've historically used the term "opportunistic TLS": http://www.postfix.org/TLS_README.html#client_tls_may to refer to a client that employs TLS encryption without any authentication when the server's EHLO response includes STARTTLS. In this case the client is willing to otherwise send in the clear, and, in fact, will fallback to cleartext when the TLS handshake fails. In the (new) DANE SMTP draft the terminology section reserves the term "(pre-DANE) opportunistic TLS" for the above client behaviour. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07#section-1.1 We introduce a new term (also listed in the terminology section) which is "opportunistic DANE TLS". The thought crime in question predates the last summer's pervasive monitoring disclosures. The work on the draft began in March 2013, and the new term was used (correctly or otherwise) from the outset. So you might ask what was the word "opportunistic" doing in our avant-garde use of the term "opportunistic DANE TLS"? The answer is that as with (pre-DANE) opportunistic TLS, the client is willing to send in the clear to any server for which no "secure" TLSA records are available. Thus, until the happy future when a significant fraction of domains are DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated "secure" TLSA records, in practice the protocol is essentially the same as with (pre-DANE) opportunistic TLS. The client employs the best security level available (including cleartext). What DANE does is raise the bar, so that for some destinations, the ones with secure TLSA records, the best available is authenticated TLS, and this status can be determined in a downgrade-resistant manner. I am open to any reasonable terminology that conveys to the user that the security policy is still "best effort", but when DANE is applicable we can do better than unauthenticated TLS with cleartext fallback. So Phillip is quite right that DANE gets us stronger semantics, but I would argue, that because the actual security posture is *conditional* on published receiving system capabilities, from the perspective of the sending system, this is just a "hardened" version of opportunistic TLS where, for just some destinations not known to the sender in advance, MITM attacks cannot trivially downgrade senders to plaintext or compromise transport integrity or confidentiality. So in Postfix documentation, we'll still describe the resulting security as a form of opportunistic TLS (this is how the email administrator should think about this "hardened" best-effort security). http://www.postfix.org/TLS_README.html#client_tls_dane In IETF documents, I'm open to anything that aligns reasonably well with other documents. We do not mean to cause any confusion. If there is a clear precedent or consensus for naming "opportunistic DANE TLS" in some other way, I for one have no objections. -- Viktor. From nobody Tue Mar 11 15:17:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF011A0070 for ; Thu, 6 Mar 2014 06:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-v3syt3UH6W for ; Thu, 6 Mar 2014 06:48:28 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 770881A0002 for ; Thu, 6 Mar 2014 06:48:28 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k15so2610569qaq.29 for ; Thu, 06 Mar 2014 06:48:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bOX23eMl7ewkAwfu6y/Czz74iPDq2qbb3Frmj2OrsG8=; b=HN0Crlp7Z8UVggjyAWecVxQrJiauaqANL7JpWM/md1hGxzQCGXr8u14VTEnvKr6gUL FedtM+mtCwmSbIwhvGzCAM3kzlvTtZ1ggLmd6yQDD+rDCNgdkVIsklQmsFPdXXQgyA6e 7Qndr1rZ/uuP4yNpZ0iG/qDxlGNQmKYOGfHQneyKznv56gByKpWPjEHwP+ymSRAPMyDs XVo6ui2sRoxXC81MUyUHrHJ9AvAh2WrD+nrQsW1Vtpl9hRR9UfiemDS1Y0+e2lq8P0qN wBDTKhGTePR4PcEgLl0HNhWPasCiOf19PJazq9OGu1SYTecdRq71SAMntUkTMXrt07h2 vB/A== X-Gm-Message-State: ALoCoQmgrQZ0xcH1MXA42YNUnUUuH4uF0du1TtPp0QK4wPUG0oZUd+4sPq+emjJJ7AMNZdjsGDaK MIME-Version: 1.0 X-Received: by 10.140.27.12 with SMTP id 12mr13765911qgw.14.1394117304172; Thu, 06 Mar 2014 06:48:24 -0800 (PST) Received: by 10.140.107.180 with HTTP; Thu, 6 Mar 2014 06:48:24 -0800 (PST) Date: Thu, 6 Mar 2014 14:48:24 +0000 Message-ID: From: Chris Bentzel To: saag@ietf.org Content-Type: multipart/alternative; boundary=001a11c14c20b0d32504f3f13add Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eXWFW-Te7P8_E_3Ek2g7tEpUhiE X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:57 -0700 Subject: [saag] NIST test suite 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, 06 Mar 2014 14:48:30 -0000 --001a11c14c20b0d32504f3f13add Content-Type: text/plain; charset=ISO-8859-1 During the Open Mic portion today, someone mentioned that NIST had a certificate verification test suite. Is this the appropriate link (with the PKITS described in it)? http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html --001a11c14c20b0d32504f3f13add Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
During the Open Mic portion today, someone mentioned that = NIST had a certificate verification test suite.

Is this = the appropriate link (with the PKITS described in it)? http://csrc.ni= st.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html
--001a11c14c20b0d32504f3f13add-- From nobody Tue Mar 11 15:17:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE021A0097 for ; Thu, 6 Mar 2014 06:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, 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 Dr6BJLRIJsSY for ; Thu, 6 Mar 2014 06:50:36 -0800 (PST) Received: from nk11p14im-asmtp002.me.com (nk11p14im-asmtp002.me.com [17.158.72.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3C1A0070 for ; Thu, 6 Mar 2014 06:50:36 -0800 (PST) Received: from dhcp-a0aa.meeting.ietf.org (dhcp-a0aa.meeting.ietf.org [31.133.160.170]) by nk11p14im-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2000FFLRW5E420@nk11p14im-asmtp002.mac.com> for saag@ietf.org; Thu, 06 Mar 2014 14:50:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-03-06_04:2014-03-05,2014-03-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1401130000 definitions=main-1403060055 From: David Misell Content-type: multipart/alternative; boundary="Apple-Mail=_83B50794-C8CA-443C-9100-44FD1D21A20D" Date: Thu, 06 Mar 2014 14:50:29 +0000 Message-id: To: "saag@ietf.org" MIME-version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bFCfbX_Qbm0vXvihROXnexUCKps X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:58 -0700 Cc: Dennis Groves Subject: [saag] IETF 89 request App Sensor 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, 06 Mar 2014 14:50:38 -0000 --Apple-Mail=_83B50794-C8CA-443C-9100-44FD1D21A20D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The App Sensore Framework is described in: https://www.owasp.org/index.php/OWASP_AppSensor_Project Dennis as co-founder can point you right Yours Faithfully, Dave Misell MSc CISSP +44 (0)7710 380044 david.misell@bcs.org Skype: misell.dave --Apple-Mail=_83B50794-C8CA-443C-9100-44FD1D21A20D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = App Sensore Framework is described in:

Dennis as co-founder can point you = right




Yours = Faithfully,

Dave Misell MSc = CISSP

+44 (0)7710 380044
david.misell@bcs.org
Skype: = misell.dave




= --Apple-Mail=_83B50794-C8CA-443C-9100-44FD1D21A20D-- From nobody Tue Mar 11 15:17:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE781A0002 for ; Thu, 6 Mar 2014 06:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6t-dg_UZVdM for ; Thu, 6 Mar 2014 06:54:38 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23BD61A0092 for ; Thu, 6 Mar 2014 06:54:38 -0800 (PST) Received: (qmail 19183 invoked from network); 6 Mar 2014 14:54:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=4aed.53188c29.k1403; i=johnl-iecc.com@submit.iecc.com; bh=4FIZqDNrce08hDm772uKCMuSDB9B+X+RuKLRGXaSwGE=; b=FQbdHXaXI2ff6yn1x1pNyzYO9UveG0R47RLREotK8rYd5NqfTBfpCjSWT+VGTXHEMebmxkVSbjL1Padf5563qrovA+9IDRuTV7GVSKSewM7X6+JSjZqyWso5IzWS3NqWrrx5yc4G9onB3K0SyX8Kw6RFelru6ojTd0J9TmYvJpSD8U7rupUPl/4YCgJrLRSw+G7eQ+nyR3nJkmpKNw2be+RCZQZ5cs4tZ9TlZueOggpVIdpQv1y7gcykswqAN6aB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=4aed.53188c29.k1403; olt=johnl-iecc.com@submit.iecc.com; bh=4FIZqDNrce08hDm772uKCMuSDB9B+X+RuKLRGXaSwGE=; b=vmCGXIwVkQ8hdyc4yugXroIdPuhXQ4Np/HvlH4/XEKZuYZgTtBpn0bMDvBAbC+lkZc27rxXpd4EJii8s8JpKOR1vsJ9QfXoueK7XVsW1rwXirWd6ndRdSz5mjcABJHAiZlKvJURBAbhSTLpKwZcw55X7EPISWSkd4mGKSRCbRy9NEhVSXNVWM2StcLdNNJXbC8UJVyoqbInqvrIU6bbSKDat83iAcNgy8yBFK7HkX5tR3/KqWP3RpHk2bDMwSxMI Received: from dhcp-b7d4.meeting.ietf.org ([31.133.183.212]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 06 Mar 2014 14:54:33 -0000 Date: 6 Mar 2014 14:54:31 +0000 Message-ID: From: "John R Levine" To: saag@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zUj7TJbghHenVdd6p_KsS6beXPM X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:58 -0700 Subject: [saag] Fwd: IETF 89 request App Sensor 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, 06 Mar 2014 14:54:40 -0000 David Misell says: > The App Sensore Framework is described in: > https://www.owasp.org/index.php/OWASP_AppSensor_Project > > Dennis as co-founder can point you right > > Yours Faithfully, > > Dave Misell MSc CISSP > > +44 (0)7710 380044 > david.misell@bcs.org > Skype: misell.dave From nobody Tue Mar 11 15:17:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF51A0159; Fri, 7 Mar 2014 02:20:35 -0800 (PST) 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 5PFCN6K_gDyQ; Fri, 7 Mar 2014 02:20:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C00571A012B; Fri, 7 Mar 2014 02:20:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E8D12AB24B; Fri, 7 Mar 2014 10:20:27 +0000 (UTC) Date: Fri, 7 Mar 2014 10:20:27 +0000 From: Viktor Dukhovni To: Michael Richardson Message-ID: <20140307102027.GJ21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> <13236.1394184906@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13236.1394184906@sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-nXCmGlskhTpQPy5UGHwbpiG6pU X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:55 -0700 Cc: saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 07 Mar 2014 10:20:36 -0000 On Fri, Mar 07, 2014 at 04:35:06AM -0500, Michael Richardson wrote: > > Thus, until the happy future when a significant fraction of domains are > > DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated > > "secure" TLSA records, in practice the protocol is essentially the same > > as with (pre-DANE) opportunistic TLS. The client employs the best > > security level available (including cleartext). > > And, in particular, I think that "opportunistics TLS" interoperates with > "opportunistics DANE TLS". The two sides don't have to have to known each > other's policies. Yes. This is quite common. Servers generally don't know how and whether clients perform TLS authentication. The best they can hope for is that clients find their certificates useful. I should however note that opportunistic DANE TLS sends SNI when the server has TLSA records. We don't yet know whether there are MTA implementations which would fail to complete the TLS handshake when they don't have a certificate with an exactly matching name. The draft requires servers to continue with a suitable default certificate if no SNI match is found. Since the draft precedes any significant deployment of SMTP servers with TLSA records, one can hope that server operators will not publish TLSA records if their server is "allergic" to "opportunistic" DANE TLSA clients (really SNI hints that turn out to not match any certificate configured on the server). Thus far no such servers have been observed, but the number of deployed clients and servers is still quite small. I am not aware of any MTAs that support server-side SNI, but this could be mere ignorance. If some do, those might be the ones that get unhappy with unexpected SNI signals from clients. Servers that have completely ignored SNI to date (e.g. Postfix) will continue to do so. Any suggestions for a better name for this mode of operation? -- Viktor. From nobody Tue Mar 11 15:17:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3F1A026F for ; Sat, 8 Mar 2014 11:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 3VQA11eHtknR for ; Sat, 8 Mar 2014 11:19:39 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7C1A0143 for ; Sat, 8 Mar 2014 11:19:39 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 08A4D404AF; Sat, 8 Mar 2014 12:19:32 -0700 (MST) Message-ID: <531B6D43.7030806@stpeter.im> Date: Sat, 08 Mar 2014 12:19:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <20140307004432.GH21390@mournblade.imrryr.org> In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xXSKEBkqK_oUPycB4lI7hDGku3s X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:58 -0700 Cc: saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 08 Mar 2014 19:19:41 -0000 On 3/6/14, 5:44 PM, Viktor Dukhovni wrote: > I am open to any reasonable terminology that conveys to the user that the > security policy is still "best effort", but when DANE is applicable we can > do better than unauthenticated TLS with cleartext fallback. I think the term "opportunistic" is the problem - most people aren't clear on what it means and definitions like this don't really help (from Wiktionary): "taking advantage of situations that arise" "said of people who will take advantage of situations to advance their own interests, without regard for principles" So if regular folks have any mental association for the word "opportunistic", it's something like "selfish and unscrupulous". IMHO, it would be better to use terms liek "best effort security" or "optimistic security" (as in "we're hoping it's secure but we can't make any promises"). Peter From nobody Tue Mar 11 15:17:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB41A0375; Sun, 9 Mar 2014 12:55:20 -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 wYgnB2PcZO8t; Sun, 9 Mar 2014 12:55:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BEEAB1A037E; Sun, 9 Mar 2014 12:55:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CD942AB250; Sun, 9 Mar 2014 19:55:12 +0000 (UTC) Date: Sun, 9 Mar 2014 19:55:12 +0000 From: Viktor Dukhovni To: Peter Saint-Andre Message-ID: <20140309195512.GQ21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531B6D43.7030806@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jF6NFHFMSto3kfHjrf6-oe93wRs X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:56 -0700 Cc: saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 09 Mar 2014 19:55:20 -0000 On Sat, Mar 08, 2014 at 12:19:31PM -0700, Peter Saint-Andre wrote: > >I am open to any reasonable terminology that conveys to the user that the > >security policy is still "best effort", but when DANE is applicable we can > >do better than unauthenticated TLS with cleartext fallback. > > [...] > > So if regular folks have any mental association for the word > "opportunistic", it's something like "selfish and unscrupulous". Perhaps so, but the draft is written for potential implementors and to some extent administrators of SMTP TLS security, not so much "regular folks". By the target audience, "opportunistic TLS" is I think already understood in its proper context. > IMHO, it would be better to use terms like "best effort security" or > "optimistic security" (as in "we're hoping it's secure but we can't > make any promises"). The situation calls for a reasonably clear term for a mode of operation where DANE authenticated TLS is used whenever TLSA records are published via DNSSEC, with fallback to opportunistic TLS otherwise. The result is in a way doubly "opportunistic". Not only is DANE employed when possible (downgrade-resistant modulo DNSSEC compromise), but when DANE is not applicable, unauthenticated TLS is employed when possible (passive attack resistant, but vulnerable to MITM attacks). This said the intent is that the modifier "opportunistic" is to be understood to apply to "DANE". For example, Postfix also implements a "dane-only" security policy that can be used to insist on DANE security. This latter security policy is described as "mandatory" rather than "opportunistic". So while I am quite open to using better terminology, nothing obvious comes to mind. I don't think that "optimistic" is closer to the mark. The optimist might assume there are no attackers and always send in the clear. Doing best effort crypto to the extent of hardening STARTTLS against MITM attacks is, if anything, a somewhat pessimist/realist view of the security of the Internet. -- Viktor. From nobody Tue Mar 11 15:17:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D111C1A0851; Tue, 11 Mar 2014 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 rhgV4EP3-a0W; Tue, 11 Mar 2014 15:14:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D832D1A0843; Tue, 11 Mar 2014 15:13:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 447F2BE4D; Tue, 11 Mar 2014 22:13:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTuJkgCtOkcp; Tue, 11 Mar 2014 22:13:50 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35616BE3F; Tue, 11 Mar 2014 22:13:50 +0000 (GMT) Message-ID: <531F8A9D.2060407@cs.tcd.ie> Date: Tue, 11 Mar 2014 22:13:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , uta@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> In-Reply-To: <531F85D5.2070209@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PxfoecdAaQnn1h5KjYd02QvYJPs X-Mailman-Approved-At: Tue, 11 Mar 2014 15:16:59 -0700 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 11 Mar 2014 22:14:05 -0000 Hiya, (Bcc'ing dane and saag for reasons that'll become obvious:-) On 03/11/2014 09:53 PM, Stephen Kent wrote: > I prefer that we stick with that definition of the term, > which is IPsec-specific. I don't think we need to face any such constraint at all. We might choose to, but there's no reason our definitions need to honor previous ones since any use of the OE term will conflict with someone's understanding. I also don't want us to end up with IPsec (or TLS) specific terminology. > I have suggested "opportunistic keying" as a > preferred term, since > its the key management, not the encryption per se, that distinguishes > other proposed modes of > operation for IPsec, TLS, etc. The breakout group at the STRINT workshop > that discussed terminology > suggested using the term noted above. I agree the OK term is better for the reasons you state. (And Pete Resnick likes the idea of OK protocols:-) If/when we re-do the MPLS thing we'll move to use that and I think it'll be useful if other folks do too. And speaking of terminology, I canvassed a few folks last week and there was reasonable support for doing the draft that defines these terms within the UTA WG. So I'd suggest we move the discussion there if that's ok just to try get it in one place. S. From nobody Tue Mar 11 15:30:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744A81A066A; Tue, 11 Mar 2014 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 u5iyaMw7ZLOl; Tue, 11 Mar 2014 15:30:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 13E7C1A0834; Tue, 11 Mar 2014 15:30:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMTp7Y024410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:29:52 -0700 (PDT) Message-ID: <531F8E5F.8030705@isi.edu> Date: Tue, 11 Mar 2014 15:29:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> In-Reply-To: <531F8A53.1040103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/62PACcuSYUrjliopD3W5UmoZ2lY Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 11 Mar 2014 22:30:16 -0000 On 3/11/2014 3:12 PM, Joe Touch wrote: > Hi, Steve, .... >> I have >> suggested "opportunistic keying" as a preferred term, since its the >> key management, not the encryption per se, that distinguishes other >> proposed modes of operation for IPsec, TLS, etc. > > I agree if you're replacing OE with OK ;-) One clarification: I don't see the use of unauthenticated keying as opportunistic in any sense of the word. Opportunistic would mean making an assumption that might be wrong, but when it's right it saves time/effort. There's no savings here; by using unauthenticated key exchange, you're really just lowering the bar. That said, I don't like the term "anonymous encryption" because it implies identity hiding, which isn't the purpose either. Why not just use the term "unauthenticated encryption", when that's exactly what's happening? Joe From nobody Tue Mar 11 17:21:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF38D1A08A1; Tue, 11 Mar 2014 17:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 gc9eI9wDqxoz; Tue, 11 Mar 2014 17:21:04 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 222151A08A0; Tue, 11 Mar 2014 17:21:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E0D6D20034; Tue, 11 Mar 2014 21:39:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 06C65647C9; Tue, 11 Mar 2014 20:20:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E8F66647C8; Tue, 11 Mar 2014 20:20:57 -0400 (EDT) From: Michael Richardson To: Viktor Dukhovni In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> References: <20140307004432.GH21390@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lL2dmkxiuQFl6__KktnOwn4NdQk Cc: Phillip Hallam-Baker , saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 00:21:05 -0000 --=-=-= Viktor Dukhovni wrote: >> The term opportunistic has become the new synonym for 'Good' but it is >> being used for many different things. > Since I am the primary perpetrator of the thought crime in question, :-) > I'd like to explain the term we used, and why, and solicit a better > term if the IETF has a better way of expressing the underlying idea. > Background: > In the Postfix community, we've historically used the term > "opportunistic TLS": > http://www.postfix.org/TLS_README.html#client_tls_may > to refer to a client that employs TLS encryption without any > authentication when the server's EHLO response includes STARTTLS. > In this case the client is willing to otherwise send in the clear, > and, in fact, will fallback to cleartext when the TLS handshake fails. I think that this term is consistent with rfc4322's use of opportunistic (IPsec) encryption. (I clipped the rest, because I have nothing to add) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUx+oaYqHRg3pndX9AQIJRQQAo18rW9LAHYjZhHuFdYO4m9bKzgadod0P 3Qy4ReuUlUzqRVP/U/F6RRE7+uN83ptyAXiiHM1rUWLcXNeP0Y9uNur6vQd91GTe YKha7NDeIzJNuFZ6Y9yrov90PkjTeeE38UZEUoZk3rjX18NctcIR1UaOxOLmg1rF 779+GJUpblk= =Jr4V -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 11 17:23:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150C31A08A0 for ; Tue, 11 Mar 2014 17:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 HfCUM1Ir266d for ; Tue, 11 Mar 2014 17:23:13 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1A19C1A0899 for ; Tue, 11 Mar 2014 17:23:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15CC120034; Tue, 11 Mar 2014 21:42:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2B44E647C9; Tue, 11 Mar 2014 20:23:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1A36E647C8; Tue, 11 Mar 2014 20:23:07 -0400 (EDT) From: Michael Richardson To: Peter Saint-Andre In-Reply-To: <531B6D43.7030806@stpeter.im> References: <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qssIhCI7lCN0jogtDjIB9XK3FIY Cc: Viktor Dukhovni , saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 00:23:14 -0000 --=-=-= Peter Saint-Andre wrote: >> I am open to any reasonable terminology that conveys to the user that the >> security policy is still "best effort", but when DANE is applicable we can >> do better than unauthenticated TLS with cleartext fallback. > I think the term "opportunistic" is the problem - most people aren't clear on > what it means and definitions like this don't really help (from Wiktionary): > "taking advantage of situations that arise" This definition works just fine. > "said of people who will take advantage of situations to advance their own > interests, without regard for principles" my interest is securing email, and I don't care for any "national security" concerns. Sounds right to me :-) > So if regular folks have any mental association for the word "opportunistic", > it's something like "selfish and unscrupulous". > IMHO, it would be better to use terms liek "best effort security" or > "optimistic security" (as in "we're hoping it's secure but we can't make any > promises"). I accept that maybe the general public needs a friendlier term. s/opportunistic/optimistic" has the nice advantage that many other acronyms might not change... :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUx+o6oqHRg3pndX9AQIJWQQAn39sMfp8/U/rzcKReoVKzhpAx3R5cRyT JUK0QqOPlMZE8ku4EMvrZasmy50Rlb2CdYZ/qqdOTAuB/zwJkJ8TZdmfb/nRvk6b yL9OL0R+6GHw1TKok7/WZNgSAZBUZRRyNcW+WTJvbSHbMKdCsm1UwsFjo5SvL0Zg kED98WsjtL0= =8Dqf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 11 17:27:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14591A0899 for ; Tue, 11 Mar 2014 17:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] 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 WOoAVBCfj6zA for ; Tue, 11 Mar 2014 17:27:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 336D21A04D2 for ; Tue, 11 Mar 2014 17:27:55 -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=1394584069; x=1426120069; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=q0qREU4WaE4OumMIj5wrChAtuvJEKNJPK16+7gixnjE=; b=duGanREM7q03erUsO6VzmMDpu5Vy68Rm+j5ncO0RPBuY4fdWZ0Nb55g9 SOPd1J4bu+0etRlNKlmUsHg2NMsoo2OFWAnL+nrREMwT77Ycr5ZcYmfq9 x4MM2KsCimrcg/VR+c2r+Kr38MuYBcXIBreoTzaFhS+tyHBt8fktS4/8Y g=; X-IronPort-AV: E=Sophos;i="4.97,634,1389697200"; d="scan'208";a="238959846" 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; 12 Mar 2014 13:27:48 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 13:27:48 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] NIST test suite Thread-Index: Ac89ieUwGWcRW38pQoueLT8wxPGlGQ== Date: Wed, 12 Mar 2014 00:27:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C737238A21C@uxcn10-6.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: http://mailarchive.ietf.org/arch/msg/saag/py8aiFi9gkZ_kH1mjqTh_nh1f6w Subject: Re: [saag] NIST test suite 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, 12 Mar 2014 00:27:57 -0000 Chris Bentzel writes:=0A= =0A= >During the Open Mic portion today, someone mentioned that NIST had a=0A= >certificate verification test suite.=0A= >=0A= >Is this the appropriate link (with the PKITS described in it)?=0A= >http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html=0A= =0A= Yes, but be aware of the issues with this that I pointed out on the=0A= cryptography list:=0A= =0A= There's the NIST test suite, but (a) it's about a decade old, (b) there a= re=0A= errors in it, and (c) it tests, among other things, a bunch of crazy stuf= f=0A= that not only no-one cares about but that no sane implementation should= =0A= actually do. It is a reasonably thorough test of your cert-handling code= =0A= though.=0A= =0A= (I can't imagine the amount of therapy the poor person who created all th= e=0A= certs had to go through afterwards to recover).=0A= =0A= Peter.= From nobody Tue Mar 11 17:28:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE891A08A6; Tue, 11 Mar 2014 17:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 JouO2-OaYlC4; Tue, 11 Mar 2014 17:28:03 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C01A08A7; Tue, 11 Mar 2014 17:28:03 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2C0QOp6025498; Tue, 11 Mar 2014 17:27:54 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1jh9xj8gvp-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 17:27:54 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 11 Mar 2014 17:27:53 -0700 From: Paul Lambert To: Joe Touch , Stephen Kent , "dane@ietf.org" , saag Date: Tue, 11 Mar 2014 17:27:52 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac89eXqdh5qFJQD5Q724mDexPHA3zQAB5Ikg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B8660CCD@SC-VEXCH2.marvell.com> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: <531F8E5F.8030705@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-11_07:2014-03-11,2014-03-11,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-1305240000 definitions=main-1403110159 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WwQ2wUGVAeAJjEc5YsA5RMVBlCI Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 00:28:05 -0000 ]On 3/11/2014 3:12 PM, Joe Touch wrote: ]> Hi, Steve, ].... ]>> I have ]>> suggested "opportunistic keying" as a preferred term, since its the ]>> key management, not the encryption per se, that distinguishes other ]>> proposed modes of operation for IPsec, TLS, etc. ]> ]> I agree if you're replacing OE with OK ;-) ] ]One clarification: I don't see the use of unauthenticated keying as ]opportunistic in any sense of the word. ] ]Opportunistic would mean making an assumption that might be wrong, but ]when it's right it saves time/effort. Opportunistic keying does provide authentication, it's just that=20 the authentication is only to the public key and is not tightly bound to any other type of identification (address, name, etc.) The binding of the key to other information useful for access control decisions is deferred. Other mechanisms are used to associate=20 the key with an appropriate access policy. At this point is where it seems to get a little trickier to describe a generic model for multiple protocols. Different applications have different=20 identifiers and binding requirements. I'm assuming the intent generally that the first key discovered=20 for a specific context would be bound to that specific usage. Without some type of pinning of the key to a context we end up with unauthenticated encryption. This implies that we will be creating more applications that display public keys or hashes of public keys. Human validation of key ownership is always a good security check (although not always the best user experience). The definition should be clear on the necessity of the additional binding and possible check of the key ownership. One idea for formalization of such opportunistic mechanisms would be to clearly define the state of the key binding to it's use in a particular context. A key newly discovered and being used for a particular dns address could be in an invalidated state, while one that was explicitly=20 checked in some manner would be in a validated state. Note - I'm working on protocols for bootstrapping P2P security that are very close to these discusions.=20 Basic design is that all devices have a public=20 Key and they are introduced for a particular=20 set of communications (service). In this application out-of-band channels can be used to support the introduction (e.g. NFC, QR Code, label on device, dynamic label on display). I've been calling aspects of this bootstrap process 'key centric' versus opportunistic since we are trying to always have a means to securely bind the key to the specific usage. Keys are the identity and are maintained in ACLs and groups for access control. Usability concerns in products will introduce=20 implementations that are more promiscuous and=20 connect opportunistically with minimal human interaction. The different types of security policies that this creates is a problem in that it lacks clear user oriented definitions. Right now, in the Wi-Fi industry the terminology is=20 either 'open' or 'encrypted' (aka WPA2). Now there will be new modes like: encrypted but=20 anyone can connect (e.g. open printer kiosk). I suspect that that this differentiation in policies will also occur in other uses of opportunistic encryption. Paul ] ]There's no savings here; by using unauthenticated key exchange, you're ]really just lowering the bar. ] ]That said, I don't like the term "anonymous encryption" because it ]implies identity hiding, which isn't the purpose either. ] ]Why not just use the term "unauthenticated encryption", when that's ]exactly what's happening? =09 ] ]Joe ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 12 04:37:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852451A094C; Wed, 12 Mar 2014 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 2AvFBCeNYdfp; Wed, 12 Mar 2014 04:37:25 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) by ietfa.amsl.com (Postfix) with ESMTP id C67901A0969; Wed, 12 Mar 2014 04:37:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58719) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WNhTJ-00089N-kE (Exim 4.82_3-c0e5623) (return-path ); Wed, 12 Mar 2014 11:37:17 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WNhTJ-0008Q1-8H (Exim 4.72) (return-path ); Wed, 12 Mar 2014 11:37:17 +0000 Date: Wed, 12 Mar 2014 11:37:17 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Viktor Dukhovni In-Reply-To: <20140307004432.GH21390@mournblade.imrryr.org> Message-ID: References: <20140307004432.GH21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ct1lgYFS32LRcvZ2lL2oGdpg4RM Cc: saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 11:37:28 -0000 I am inclined to avoid the word "opportunistic". Judging by the confusion over the meaning of the word, and the several possible meanings that people gave at the meeting last week, I don't think its jargon usage is precise enough to be helpful. And its dictionary meaning has some slightly unpleasant overtones. How about the straightforwardly descriptive terms "unauthenticated STARTTLS" and "DANE STARTTLS"? STARTTLS implies this is an upgrade from cleartext, which I think you said last week was one of the concepts you wanted to capture in the phrase. And unauthenticated vs DANE should suggest the key security difference. Tony. -- f.anthony.n.finch http://dotat.at/ German Bight: Variable 3 or 4. Smooth or slight. Fair. Good, occasionally poor later in south. From nobody Wed Mar 12 06:35:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E131A0998; Wed, 12 Mar 2014 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 IkgBGc89cOA8; Wed, 12 Mar 2014 06:35:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D8D621A096E; Wed, 12 Mar 2014 06:35:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39532 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNjJT-0008KP-PQ; Wed, 12 Mar 2014 09:35:15 -0400 Message-ID: <53206293.8020907@bbn.com> Date: Wed, 12 Mar 2014 09:35:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> In-Reply-To: <531F8A53.1040103@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FBgAVMir0XeCAl1nFtVbpr4W6Mk Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 13:35:26 -0000 Joe, > ... >> with that definition of the term, which is IPsec-specific. > > I'm not quite sure what term or what definition you're referring to: > OE, anonymous encryption, or unauthenticated key exchange. Can you > clarify? OE. I argue that OE is defined only for IPsec, because the definition focuses on how to avoid the need to coordinate SPD entries at each end. > >> I have >> suggested "opportunistic keying" as a preferred term, since its the >> key management, not the encryption per se, that distinguishes other >> proposed modes of operation for IPsec, TLS, etc. > > I agree if you're replacing OE with OK ;-) yeah, I like OK (and I like IKE too, for those of us old enough to appreciate that election slogan) > >> The breakout group at the STRINT workshop that discussed terminology >> suggested using the term noted above. > > Sorry, but to clarify, which term? OK vs. OE. Steve From nobody Wed Mar 12 06:44:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4189C1A0722; Wed, 12 Mar 2014 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 wynhn76LWT82; Wed, 12 Mar 2014 06:44:24 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) by ietfa.amsl.com (Postfix) with ESMTP id 8881E1A0715; Wed, 12 Mar 2014 06:44:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35693) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WNjSB-0002RZ-kK (Exim 4.82_3-c0e5623) (return-path ); Wed, 12 Mar 2014 13:44:15 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WNjSB-00045M-91 (Exim 4.72) (return-path ); Wed, 12 Mar 2014 13:44:15 +0000 Date: Wed, 12 Mar 2014 13:44:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Viktor Dukhovni In-Reply-To: <20140309195512.GQ21390@mournblade.imrryr.org> Message-ID: References: <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im> <20140309195512.GQ21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dge2J0cr6bcEZDxjJpXKs3SQcUM Cc: saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 13:44:26 -0000 Viktor Dukhovni wrote: > > The result is in a way doubly "opportunistic". Not only is DANE > employed when possible (downgrade-resistant modulo DNSSEC compromise), > but when DANE is not applicable, unauthenticated TLS is employed > when possible (passive attack resistant, but vulnerable to MITM > attacks). I think what you are describing is just protocol feature negotiation and so it does not need a special term. We don't talk about opportunistic cipher suites, for example. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle: Southwesterly veering westerly 5 to 7, but 4 at first in southeast, perhaps gale 8 later in west. Moderate or rough, occasionally very rough in northwest. Rain later. Moderate or good. From nobody Wed Mar 12 09:50:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921031A0745; Wed, 12 Mar 2014 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 2NxeLdIbM9Oo; Wed, 12 Mar 2014 09:50:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 339ED1A0829; Wed, 12 Mar 2014 09:50:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2CGnGDf017693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 09:49:18 -0700 (PDT) Message-ID: <5320900C.2030007@isi.edu> Date: Wed, 12 Mar 2014 09:49:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> In-Reply-To: <53206293.8020907@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WwTN0VSurN_StkGAriD5kY7VNCE Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 16:50:45 -0000 Steve (et al.), On 3/12/2014 6:35 AM, Stephen Kent wrote: > Joe, > >> ... >>> with that definition of the term, which is IPsec-specific. >> >> I'm not quite sure what term or what definition you're referring to: >> OE, anonymous encryption, or unauthenticated key exchange. Can you >> clarify? > > OE. I argue that OE is defined only for IPsec, because the definition > focuses on how to > avoid the need to coordinate SPD entries at each end. Agreed. >>> I have >>> suggested "opportunistic keying" as a preferred term, since its the >>> key management, not the encryption per se, that distinguishes other >>> proposed modes of operation for IPsec, TLS, etc. >> >> I agree if you're replacing OE with OK ;-) > > yeah, I like OK (and I like IKE too, for those of us old enough to > appreciate that election slogan) I'm still a little hesitant, thinking on it further, about the term "opportunistic" in this sense at all. BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about it. Unsigned authentication is the goal from the start. OE as defined in RFC 4322 isn't about using unsigned key exchange; the "opportunistic" sense is derived from using keys retrieved from DNS without prior agreement. That's not what happens in BTNS. Paul just noted: "Opportunistic keying does provide authentication, it's just that the authentication is only to the public key and is not tightly bound to any other type of identification (address, name, etc.)" I.e., fundamentally, opportunistic approaches are completely different from those that don't ever bother to authenticate. I don't think it's useful (and could be confusing) to confuse the two by overlapping terminology. I don't like the term "optimistic" either; it too implies something that you "hope works". There's no "hope" associated with unsigned key exchange; you do it (IMO) because you know what it is and you know its impact (e.g., raising the bar of an attacker to performing a full key exchange, vs. just tossing single packets like RSTs around). Is there a reason not to just call unauthenticated key exchange what it is - unauthenticated key exchange? If you want something pithy, maybe "Zero-ID security"? >> The breakout group at the STRINT workshop that discussed terminology >>> suggested using the term noted above. >> >> Sorry, but to clarify, which term? > > OK vs. OE. Thanks for the clarification. Joe From nobody Wed Mar 12 10:04:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2081A048A; Wed, 12 Mar 2014 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 VDkYb5asc69J; Wed, 12 Mar 2014 10:04:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B81A0381; Wed, 12 Mar 2014 10:04:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05402BE54; Wed, 12 Mar 2014 17:04:01 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kz4QkdFcQMq; Wed, 12 Mar 2014 17:04:00 +0000 (GMT) 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 CF68BBE56; Wed, 12 Mar 2014 17:04:00 +0000 (GMT) Message-ID: <53209382.3070809@cs.tcd.ie> Date: Wed, 12 Mar 2014 17:04:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: <5320900C.2030007@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/S2kzn7IuLxT2v4x39NFnH9bJINg Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 17:04:15 -0000 (again, I'd suggest one list for this if we can and the UTA wg list, but hopefully that'll settle down when there's an I-D, and since I'm not the boss of us anyway...:-) On 03/12/2014 04:49 PM, Joe Touch wrote: > Steve (et al.), > > On 3/12/2014 6:35 AM, Stephen Kent wrote: >> Joe, >> >>> ... >>>> with that definition of the term, which is IPsec-specific. >>> >>> I'm not quite sure what term or what definition you're referring to: >>> OE, anonymous encryption, or unauthenticated key exchange. Can you >>> clarify? >> >> OE. I argue that OE is defined only for IPsec, because the definition >> focuses on how to >> avoid the need to coordinate SPD entries at each end. > > Agreed. > >>>> I have >>>> suggested "opportunistic keying" as a preferred term, since its the >>>> key management, not the encryption per se, that distinguishes other >>>> proposed modes of operation for IPsec, TLS, etc. >>> >>> I agree if you're replacing OE with OK ;-) >> >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) > > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. I do think we want to define that term even if we do not want to encourage its use. It is being used and with subtly different meanings by different folks. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" > about it. Unsigned authentication is the goal from the start. > > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS > without prior agreement. That's not what happens in BTNS. > > Paul just noted: > "Opportunistic keying does provide authentication, it's just that > the authentication is only to the public key and is not > tightly bound to any other type of identification (address, name, etc.)" > > I.e., fundamentally, opportunistic approaches are completely different > from those that don't ever bother to authenticate. I don't think it's > useful (and could be confusing) to confuse the two by overlapping > terminology. > > I don't like the term "optimistic" either; it too implies something that > you "hope works". There's no "hope" associated with unsigned key > exchange; you do it (IMO) because you know what it is and you know its > impact (e.g., raising the bar of an attacker to performing a full key > exchange, vs. just tossing single packets like RSTs around). > > Is there a reason not to just call unauthenticated key exchange what it > is - unauthenticated key exchange? Yes. "authenticated encryption" is a term of art (AEAD etc) and this would be confusingly close - it'd be inevitable that some would end up saying unauthenticated encryption and thereby would confuse the real crypto folks. I like the OK term myself and would be happy if we landed on encouraging its use, based on a good definition. But I'm fine if we end up calling it squiggle, so long as we all end up calling the same "it" that. > > If you want something pithy, maybe "Zero-ID security"? Too close to zero-touch (which is not ad-hominem, but is a term being used in netconf - Joe you just *have* to get involved in that:-) S. > >>> The breakout group at the STRINT workshop that discussed terminology >>>> suggested using the term noted above. >>> >>> Sorry, but to clarify, which term? >> >> OK vs. OE. > > Thanks for the clarification. > > Joe > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Wed Mar 12 10:06:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6521A04B8; Wed, 12 Mar 2014 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj3WnwFjT4ZN; Wed, 12 Mar 2014 10:06:11 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (agjbgdcfdbed.dreamhost.com [69.163.253.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9E91A04C2; Wed, 12 Mar 2014 10:06:10 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 4A58B2005D102; Wed, 12 Mar 2014 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5oMYqLH9wy6D+fktRX0k rWOyZ6c=; b=SrC99ml8mRdpeNOkNCUcSlg5PhmpPiwPCa1jorcYms6wWMUDWtXF KFbRR6jSCBYsQUu8ZL5TnoT21ol5nK38H9zi0tOBL9rmbVinIsxNIJK+GJP7nr4U z64lLIbUMaKwvAzIK98T1vnyLqPGFBC8E5s2BSSVzTCjTAS2FFLWnwM= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id C9ADF2005D108; Wed, 12 Mar 2014 10:06:03 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so9151123wgh.34 for ; Wed, 12 Mar 2014 10:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s8I3t4SOI2QY6L/4Y3JzvRKhSwgBOqh01jJu4T85tgs=; b=mG1cjGPdfj8cafWOZvOxNcYRe1aSbYSlCaaJT9HJO0eB21p73e18yntW1/61NHeYc3 tnCqq0p670whbkikhRWd0l/jSxYNRsn/gqr7T8NHWJ092ez4Yc1BCG/LSN8i5tPUi8c1 GyouKA86OLgFBRz9MAlzzcty+FxmX4Ndt5OdTiPm7hLXLcdNN/sabVYECZNsxypIramT Q8q1UG0EXoOCOasEudvh2GJheFp5TFDakzjvpetuYlp8PmDxj1AVpp8EcbNJhYYxrJsS gdrzE0gnV/zFp3pPqhKvrMaDeINc2iKH8d3nkK0Eq+c0rpfD7kXeDMoehiFp2+4+05pU vvcA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr8572892wib.5.1394643961958; Wed, 12 Mar 2014 10:06:01 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 10:06:01 -0700 (PDT) In-Reply-To: <5320900C.2030007@isi.edu> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> Date: Wed, 12 Mar 2014 12:06:01 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3cThg-SSYdrft4NT905XDypt-xE Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 17:06:16 -0000 On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch wrote: > On 3/12/2014 6:35 AM, Stephen Kent wrote: >>>> I have >>>> suggested "opportunistic keying" as a preferred term, since its the >>>> key management, not the encryption per se, that distinguishes other >>>> proposed modes of operation for IPsec, TLS, etc. >>> >>> I agree if you're replacing OE with OK ;-) >> >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) OK will present difficulties as an acronym... Otherwise I like "opportunistic keying", but it could cover a large range of behaviors (e.g., TOFU). > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about > it. Unsigned authentication is the goal from the start. For me the goal was to use channel binding at the application layer. But we never got there: no one seems to care much about end-to-end IPsec, sadly. (Well, it's not that no one cares, but that it's too late now; TLS is king.) > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS without > prior agreement. That's not what happens in BTNS. Stephen has it right: OE in the RFC4322 sense is about applying protection even when SPDs don't agree on this, but it still requires a keying infrastructure (i.e., trust paths). Nico -- From nobody Wed Mar 12 10:31:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABF01A0552; Wed, 12 Mar 2014 10:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 DwC5JYu8BVxv; Wed, 12 Mar 2014 10:31:25 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A717B1A0381; Wed, 12 Mar 2014 10:31:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2CHUnnG001614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 10:30:50 -0700 (PDT) Message-ID: <532099C9.6060405@isi.edu> Date: Wed, 12 Mar 2014 10:30:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RaTsTucPyAbqP1s1qrEWHSijs7o Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 17:31:31 -0000 On 3/12/2014 10:06 AM, Nico Williams wrote: > On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch wrote: ... >> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" about >> it. Unsigned authentication is the goal from the start. > > For me the goal was to use channel binding at the application layer. Having unsigned key exchange has two ultimate uses: - raising the bar for attacks above 'send a RST' but below MITM - providing a network-level mechanism that can be linked to security at higher layers App-layer channel binding could be useful for BTNS, or for other approaches too (e.g., where a single key protects a set of ports). > But we never got there: no one seems to care much about end-to-end > IPsec, sadly. (Well, it's not that no one cares, but that it's too > late now; TLS is king.) TLS still doesn't protect the transport or network layers. >> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >> "opportunistic" sense is derived from using keys retrieved from DNS without >> prior agreement. That's not what happens in BTNS. > > Stephen has it right: OE in the RFC4322 sense is about applying > protection even when SPDs don't agree on this, but it still requires a > keying infrastructure (i.e., trust paths). Right, but then "O" isn't quite the right term for security that avoids the need for keying infrastructure altogether. Joe From nobody Wed Mar 12 13:02:42 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7381A04D2; Wed, 12 Mar 2014 13:02:40 -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 w_FwRX4bBfvu; Wed, 12 Mar 2014 13:02:39 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id BCCFC1A0473; Wed, 12 Mar 2014 13:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 19575E2034; Wed, 12 Mar 2014 16:02:33 -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 06205-01; Wed, 12 Mar 2014 16:02:31 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (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 76518E2033; Wed, 12 Mar 2014 16:02:31 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s2CK2UYt016022; Wed, 12 Mar 2014 16:02:30 -0400 From: Derek Atkins To: Joe Touch References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> Date: Wed, 12 Mar 2014 16:02:29 -0400 In-Reply-To: <531F8E5F.8030705@isi.edu> (Joe Touch's message of "Tue, 11 Mar 2014 15:29:51 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PMpIUUSjXZCGYvmDQ4m0eBM5vCg Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 20:02:41 -0000 Joe Touch writes: > Why not just use the term "unauthenticated encryption", when that's > exactly what's happening? Well, it's not necessarily what's happening. The data itself might still have "integrity protection" (which is a form of authentication. You're just not authenticating the endpoint, which means you could be subject to a MitM attack. Alternate terms could be "Unauthenticated Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to what's going on. > Joe -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 12 13:31:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D91A068F; Wed, 12 Mar 2014 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 7H4q69MkluDc; Wed, 12 Mar 2014 13:31:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD3771A0496; Wed, 12 Mar 2014 13:31:05 -0700 (PDT) Received: from [128.9.184.173] ([128.9.184.173]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2CKSdhm009134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 13:28:39 -0700 (PDT) Message-ID: <5320C37A.1000903@isi.edu> Date: Wed, 12 Mar 2014 13:28:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Derek Atkins References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/n-u94UKi2xchQ09tE1YsY6sVu4Y Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 20:31:07 -0000 On 3/12/2014 1:02 PM, Derek Atkins wrote: > Joe Touch writes: > >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? > > Well, it's not necessarily what's happening. The data itself might > still have "integrity protection" (which is a form of authentication. Yes, and might be inaccessible to anyone except the endpoints that negotiated the key too. So you have a protected exchange both in privacy and integrity, but you don't know with whom. > You're just not authenticating the endpoint, which means you could be > subject to a MitM attack. Alternate terms could be "Unauthenticated > Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to > what's going on. Sure - yes, but neither acronym is desirable, unfortunately. Unidentified Security? Joe From nobody Wed Mar 12 13:47:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FCE1A074E; Wed, 12 Mar 2014 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 M6563Sq_s64f; Wed, 12 Mar 2014 13:47:25 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id A8EBD1A074A; Wed, 12 Mar 2014 13:47:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FA712002F; Wed, 12 Mar 2014 18:06:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A4088647C9; Wed, 12 Mar 2014 16:47:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 893F3647C8; Wed, 12 Mar 2014 16:47:17 -0400 (EDT) From: Michael Richardson To: Peter Palfrader In-Reply-To: <20140312062756.GN11878@anguilla.noreply.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Q9OSOVb610RHHmVLQB7jNGg_8Go Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 20:47:27 -0000 --=-=-= Peter Palfrader wrote: >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? > There is such a thing as authenticated encryption[1], as in AES GCM for > instance, and what we're doing here is not its opposite. Thus, I think > calling this "unauthenticated encryption" would be a bad idea. +1 and, the privacy that results from the encryption, while the primary carrot, is simply the result of finding a way to do a DH operation. The part that we are all discussing is determining how (much) to trust the DH results. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyDH1YqHRg3pndX9AQKMlQQA3HKcDhKnxTg4goYXmR1EdgEoBEMHm9jK Xvyi2ofWmC0eZyS4Uy1s5GMaMkS3EJ+A46eQIJjlL+Ds/jGQaHuS6V1MEMfrwzR1 8S5QWKIbTC3kpXRiVaScYN4SyXsM9SPZiqV6ZHDTTOnGZNm9p7HT2F2TRknKoERP 3MjeGWb6B8U= =665o -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 12 13:53:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE2A1A0784; Wed, 12 Mar 2014 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Xzj3nxUE9o-z; Wed, 12 Mar 2014 13:53:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 674621A0664; Wed, 12 Mar 2014 13:53:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DFB2BE51; Wed, 12 Mar 2014 20:53:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUAhZU6HlWF7; Wed, 12 Mar 2014 20:53:07 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7C87DBE33; Wed, 12 Mar 2014 20:53:07 +0000 (GMT) Message-ID: <5320C932.3010107@cs.tcd.ie> Date: Wed, 12 Mar 2014 20:53:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson , Peter Palfrader References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> In-Reply-To: <3454.1394657237@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SBAOiCvGB813vR1VhpRMTXm5Jek Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 20:53:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 03/12/2014 08:47 PM, Michael Richardson wrote: > The part that we are all discussing is determining how (much) to > trust the DH results. I don't think that's a very accurate characterisation to be honest. I think the most relevant (but intertwined) factors are: - - trading off ease of deployment vs. endpoint authentication - - trading off protection against passive vs active attack - - better separating key exchange from endpoint authentication so that traditional authentication or TOFU or whatever can be used before during or after key exchange S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTIMkuAAoJEC88hzaAX42iNbgH/2zx/K+XLC1j17iDnCmK4Kn6 mZGTrtpYf2EiAquYoS0fb2iZ8Ni7G3SV/HeUvohdT2SdhzzJ1nfxX93FHdQi0TV5 /slo1yikxtalAmxOJJQutxeXqQFd8J50uoDHfFt0qa25ph6PU5Nb7ICpONQzbfCM i6oOuh8/qY7746S51DC1a8A0FsqdhWktcEwa+sxmh9aLImmCTrSfx4lHoCMFxowO vE7tYngzifAKV5KWdC6n7UJFgXTniVGgcEpLSplN4oXMJz2Mh8dHg+Yk8aORPCq9 lBE4j3b5BWWi7U1wTcYmPQHy9GwTg2ApzhBoHCKycfmoXVIHvR1EunAo3JrATmk= =Tvs/ -----END PGP SIGNATURE----- From nobody Wed Mar 12 14:13:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17D81A074A; Wed, 12 Mar 2014 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 TPZLHmmq7GAv; Wed, 12 Mar 2014 14:13:49 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75B1A0644; Wed, 12 Mar 2014 14:13:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 552012002F; Wed, 12 Mar 2014 18:32:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 67DFF647C9; Wed, 12 Mar 2014 17:13:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5585C647C8; Wed, 12 Mar 2014 17:13:38 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <5320C932.3010107@cs.tcd.ie> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QGUoUpFoLTvyfRzYUjLhZgLwQio Cc: Peter Palfrader , saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:13:50 -0000 --=-=-= Stephen Farrell wrote: > On 03/12/2014 08:47 PM, Michael Richardson wrote: >> The part that we are all discussing is determining how (much) to >> trust the DH results. > I don't think that's a very accurate characterisation > to be honest. > I think the most relevant (but intertwined) factors are: > - trading off ease of deployment vs. endpoint authentication > - trading off protection against passive vs active attack > - better separating key exchange from endpoint authentication > so that traditional authentication or TOFU or whatever can > be used before during or after key exchange But, you made my point. While the end user sees the overall benefit is: my traffic can not seen The problems and challenges that we have are not in how or even when to apply AES, it's how/when to do the DH. To the end user, having the word "encryption" in the terminology is useful because it tells them why they should pay attention to it. To us, it's a red-herring, because it's not where the issue is. You listed the issues. (BTW: my TLA cache is failing on "TOFU") -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCUAwUBUyDOAoqHRg3pndX9AQKH+gP4kbSFq2q+jiLQrr1MMpUul4TI4ZV9GXvl 9FJYBa9k5Ed6VH5QY4iTyRaNQEZU+clr1Hbwrx+BA/4b1aGCgVoe4ktxwytWY2s5 KazF5oqtE39pY4IMaSs5E2ZAbRhF3tpod8mFIxdlC28JpbK2P1tDPlQBvDONcmX+ puX85oH3aQ== =NCbi -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 12 14:29:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BF31A074A; Wed, 12 Mar 2014 14:28:59 -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 7nmtQdRzngcq; Wed, 12 Mar 2014 14:28:58 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8621A073B; Wed, 12 Mar 2014 14:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 388DDE2033; Wed, 12 Mar 2014 17:28:51 -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 06529-05; Wed, 12 Mar 2014 17:28:49 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 1200DE2038; Wed, 12 Mar 2014 17:28:48 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 12 Mar 2014 17:28:48 -0400 Message-ID: <2b9139a5b1fe14a683ba11c63830bfdb.squirrel@mail2.ihtfp.org> In-Reply-To: <10021.1394658818@sandelman.ca> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> Date: Wed, 12 Mar 2014 17:28:48 -0400 From: "Derek Atkins" To: "Michael Richardson" User-Agent: SquirrelMail/1.4.22-13.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: http://mailarchive.ietf.org/arch/msg/saag/FXm7knRAOWbuphvy0Vb-LJKrUB4 Cc: Peter Palfrader , dane@ietf.org, saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:29:00 -0000 On Wed, March 12, 2014 5:13 pm, Michael Richardson wrote: > > (BTW: my TLA cache is failing on "TOFU") Trust on First Use (aka the SSH Model). A step up from completely unchecked DH, but a step below DANE or Certificate Validation. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 12 14:47:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5491A0685; Wed, 12 Mar 2014 14:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 eMnFudP965WB; Wed, 12 Mar 2014 14:46:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2381A0733; Wed, 12 Mar 2014 14:46:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4F37BE51; Wed, 12 Mar 2014 21:46:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESecBKXOHD61; Wed, 12 Mar 2014 21:46:48 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BFE6BE29; Wed, 12 Mar 2014 21:46:48 +0000 (GMT) Message-ID: <5320D5C8.8030509@cs.tcd.ie> Date: Wed, 12 Mar 2014 21:46:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> In-Reply-To: <10021.1394658818@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7LSGRTB3-nq4VUTq0ufIF4w2nho Cc: Peter Palfrader , saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:46:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 03/12/2014 09:13 PM, Michael Richardson wrote: > > Stephen Farrell wrote: >> On 03/12/2014 08:47 PM, Michael Richardson wrote: >>> The part that we are all discussing is determining how (much) >>> to trust the DH results. > >> I don't think that's a very accurate characterisation to be >> honest. > >> I think the most relevant (but intertwined) factors are: > >> - trading off ease of deployment vs. endpoint authentication - >> trading off protection against passive vs active attack - better >> separating key exchange from endpoint authentication so that >> traditional authentication or TOFU or whatever can be used before >> during or after key exchange > > But, you made my point. Well yes and no, we're agreeing and almost but not quite discussing the same things I figure, let's see if that continues... :-) > While the end user sees the overall benefit is: my traffic can not > seen > > The problems and challenges that we have are not in how or even > when to apply AES, Agreed. > it's how/when to do the DH. "How" to do DH is pretty much the same everywhere or at least the diffs are not relevant for a generic terminology draft. "When" is I think as-soon-as-you-can (modulo amortizing DH over multiple "sessions" or similar). I think our challenges are not in when to do DH but in how that relates to when we might do what forms of endpoint authentication (or none) and the consequences of each of those options. That's why I think a generic terminology draft will be useful, as there are lots of potential combinations. Naming each (or whatever) will make it easier for protocol developers to argue about what's suitable for their particular environments. For example, in the limit, I think it'd be worth thinking about whether a post-facto MITM detection protocol perhaps run a day or two later might have value. That'd be more of a research topic really, but could still represent a form of useful endpoint authentication even if it only detected a MITM with say a 1% probability. Think of Alice and Bob depositing a witness pair derived from the DH secret and some HASH(shared-info + application traffic) some place(s) so someone (else) could detect if there was a Charlie in the middle. (BTW: I'm not sure such a useful generic protocol exists, but it'd be fun to work it out.) > To the end user, having the word "encryption" in the terminology is > useful because it tells them why they should pay attention to it. Good point. Maybe that's why folks keep coming back to OE as a term. > > To us, it's a red-herring, because it's not where the issue is. Also true. Cheers, S. > You listed the issues. > > (BTW: my TLA cache is failing on "TOFU") > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting for hire =- > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTINXHAAoJEC88hzaAX42iuwsH/jG+Iny/Ae5cEJblR09CD9CE oPhLIMQM6eFBHiFFkz185XilNgyCUuWlAsGSEAMxNybKwZmpChf52ljhEXgE7Vx8 ULDHW8NadWp6O6V2CXie4vQM3ZAW58sgGRCqtejja3R2+DrKxgqi5gnWNxOYLt45 fzXjZYwZ1njlKPV1iLkAwrhLMj8HYOd005CNwW4owL746SV95AroZU316VfVVvB/ ehoLCHINcFJ32mFoPynPQwY/oSL89UWhSzswnkNljSC1R9dYs+eX/mEkBgFC/0Am EptcQZ0IwS5nBf4IwWi9V2wD+phS9zMAcOhpT7oJPzguZhChF/ziVH0NwYGsibg= =32vZ -----END PGP SIGNATURE----- From nobody Wed Mar 12 14:47:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96B1A0772; Wed, 12 Mar 2014 14:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 kgEEKg7o1l0g; Wed, 12 Mar 2014 14:47:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2855C1A0479; Wed, 12 Mar 2014 14:47:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49606 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNqzV-000IhX-HF; Wed, 12 Mar 2014 17:47:09 -0400 Message-ID: <5320D5DD.8060204@bbn.com> Date: Wed, 12 Mar 2014 17:47:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> In-Reply-To: <5320900C.2030007@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AFRB4q2ZD49xIihTunaRNKDuKDw Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:47:19 -0000 Joe, > >> yeah, I like OK (and I like IKE too, for those of us old enough to >> appreciate that election slogan) > > I'm still a little hesitant, thinking on it further, about the term > "opportunistic" in this sense at all. > > BTNS uses unsigned key exchanged, and there's nothing "opportunistic" > about it. Unsigned authentication is the goal from the start. > > OE as defined in RFC 4322 isn't about using unsigned key exchange; the > "opportunistic" sense is derived from using keys retrieved from DNS > without prior agreement. That's not what happens in BTNS. agreed. > Paul just noted: > "Opportunistic keying does provide authentication, it's just that > the authentication is only to the public key and is not > tightly bound to any other type of identification (address, name, etc.)" Public keys are not principles. We went through that long and painful discussion during the SPKI days. So, saying that OE provide authentication of a key seems meaningless to me, especially if the key is ephemeral. > I.e., fundamentally, opportunistic approaches are completely different > from those that don't ever bother to authenticate. I don't think it's > useful (and could be confusing) to confuse the two by overlapping > terminology. We'll, we don't have an agreed upon definition for O* yet. My view is that the primary goal of this effort is to remove barriers to using encryption. Since authenticating the identity or a peer or server has tended to be a barrier, we seem willing to make that form of authentication optional. But, we still prefer authentication, because we'd like to avoid MiTM attacks. That suggests that O* refers to techniques that emphasize encryption, prefer that it be authenticated, but are willing to fall back to un-autnenticated encryption if that's thbe best we can do. (And to fall back to plaintext if the peer/server is not capable of our new-fangled O*) > I don't like the term "optimistic" either; it too implies something > that you "hope works". There's no "hope" associated with unsigned key > exchange; you do it (IMO) because you know what it is and you know its > impact (e.g., raising the bar of an attacker to performing a full key > exchange, vs. just tossing single packets like RSTs around). I'm not wedded top either term, but I'd like to emphasize that the encryption process is the same in all cases; it's the key management that's different. > > Is there a reason not to just call unauthenticated key exchange what > it is - unauthenticated key exchange? I think we want more than that, as I described above, hence the desire to coin a new term. Steve From nobody Wed Mar 12 14:54:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97821A0685 for ; Wed, 12 Mar 2014 14:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 JeHxiCkYgEyu for ; Wed, 12 Mar 2014 14:54:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28B1A0479 for ; Wed, 12 Mar 2014 14:54:29 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49656 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNr6V-000Iph-2E for saag@ietf.org; Wed, 12 Mar 2014 17:54:23 -0400 Message-ID: <5320D78F.70908@bbn.com> Date: Wed, 12 Mar 2014 17:54:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <532099C9.6060405@isi.edu> In-Reply-To: <532099C9.6060405@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dkpYJyeFaE1wZkRAwVIDq551-yU Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:54:31 -0000 Joe, ... > Having unsigned key exchange has two ultimate uses: > > - raising the bar for attacks > above 'send a RST' but below MITM whether this feature accrues depends on the layer at which we provide the O* technology. IPsec addresses this issue, TLS does not, tcpcrypt does, ... > > - providing a network-level mechanism that can be linked > to security at higher layers In this case you explicitly say network layer, but the discussion has been broader than that. > App-layer channel binding could be useful for BTNS, or for other > approaches too (e.g., where a single key protects a set of ports). > >> But we never got there: no one seems to care much about end-to-end >> IPsec, sadly. (Well, it's not that no one cares, but that it's too >> late now; TLS is king.) > > TLS still doesn't protect the transport or network layers. right, but that doesn't mean it's not useful. Operating above the transport layer avoids NAT problems, for example. Steve From nobody Wed Mar 12 14:56:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836571A074C; Wed, 12 Mar 2014 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 HeLSBhujBNh0; Wed, 12 Mar 2014 14:56:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 090471A0744; Wed, 12 Mar 2014 14:56:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49659 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNr8D-000Ir4-CA; Wed, 12 Mar 2014 17:56:09 -0400 Message-ID: <5320D7F9.6090504@bbn.com> Date: Wed, 12 Mar 2014 17:56:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Farrell , Joe Touch , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <53209382.3070809@cs.tcd.ie> In-Reply-To: <53209382.3070809@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Mbyp31XY_nF4MMl2PVYK-0Uqfew Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:56:26 -0000 Stephen, > (again, I'd suggest one list for this if we can and the > UTA wg list, but hopefully that'll settle down when there's > an I-D, and since I'm not the boss of us anyway...:-) > This is a broader topic than TLS, as later messages from Joe indicated, so I don't think UTA is the right place for this discussion. Steve From nobody Wed Mar 12 14:57:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52861A074C for ; Wed, 12 Mar 2014 14:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 olPlYqqzq4Jl for ; Wed, 12 Mar 2014 14:57:53 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (agjbgdcfdbeb.dreamhost.com [69.163.253.141]) by ietfa.amsl.com (Postfix) with ESMTP id DEC751A0744 for ; Wed, 12 Mar 2014 14:57:53 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id E19D12005D106 for ; Wed, 12 Mar 2014 14:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=k4rZRMQ3k0XKS9842Sqo /rVgwd4=; b=fYmz6j+fJXRzAr2W9igC+NS4Nc2tpkG8w5xLUoc7JmGITMD1Kw66 tHkm9FyoM0X9zq4U4Fkva6G12zmGNQFrpjfD4a/RJ8sWMEvRUBjPNk4zZUCitu12 tvBcPqyyrsawXotEbTglMbC0YVKxA/NCgPNd5NvJn0gWh5cj+zrxE5Y= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 93FDE2005D105 for ; Wed, 12 Mar 2014 14:57:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n15so2789762wiw.3 for ; Wed, 12 Mar 2014 14:57:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NC8DRvEvpJCYdSfljEiry9XqDgkTRxLoTZ8LSWJ9Jg4=; b=HD50UE/PYX3nut5lXbctCOrkkhp8fUpbPRz1t9PZupxJ28oS4E42WtygFKUKr1ekTz /e1w84hoBzefYk/KwnjzMuCeuckLw8yD+94i8VKujo59VvMqiRr0CVhdEDpruc22AAgR JcbMPq8+aOFoDCjv7fjgNbCVqQp8IVlT29vZqgOEleawhznFdooSMqyfaKfWyaqqBfQ6 5U5Zc0BC+/tg0Xm9qGDz/l03hAV0tgyCbIo438dLwP6vP1V1hKnAuxBgcBniLj1GyRZ1 s+3zWOs/TfvMSEch1UJYoTnC0ifiDiC5bSE98zaETfhDVbE6Cosw4ORFxXKwdOX5H9wB 0ueg== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr20635012wjq.40.1394661466386; Wed, 12 Mar 2014 14:57:46 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 14:57:46 -0700 (PDT) In-Reply-To: <5320D78F.70908@bbn.com> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <532099C9.6060405@isi.edu> <5320D78F.70908@bbn.com> Date: Wed, 12 Mar 2014 16:57:46 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/J2E8oPh3ahYmvCxGHgWe8LChNvM Cc: "saag@ietf.org" Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:57:54 -0000 On Wed, Mar 12, 2014 at 4:54 PM, Stephen Kent wrote: >> TLS still doesn't protect the transport or network layers. > > right, but that doesn't mean it's not useful. Operating above the transport > layer > avoids NAT problems, for example. And mobility, if one is willing to use UDP a-la mosh or DJB's MinimaLT, or frequently reconnect TCP. Either way the app protocol needs reworking to do that, but it's becoming common to do this sort of thing instead of relying on lower layers for security and mobility. Frankly, I can't fault app developers for doing things this way! Nico -- From nobody Wed Mar 12 14:59:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C51A0764; Wed, 12 Mar 2014 14:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 rzjoB-ArRdX4; Wed, 12 Mar 2014 14:59:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54F311A0758; Wed, 12 Mar 2014 14:59:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A84F4BE4D; Wed, 12 Mar 2014 21:59:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG1eRjoJ2xhr; Wed, 12 Mar 2014 21:59:00 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7CF43BE29; Wed, 12 Mar 2014 21:59:00 +0000 (GMT) Message-ID: <5320D8A4.1000709@cs.tcd.ie> Date: Wed, 12 Mar 2014 21:59:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , Joe Touch , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <53209382.3070809@cs.tcd.ie> <5320D7F9.6090504@bbn.com> In-Reply-To: <5320D7F9.6090504@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lWGLRio6ASaWNAHzMWK_8p3ctCM Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 21:59:09 -0000 Sure, that's arguable. My main reason for suggesting UTA is that I figure its drafts will have more/soonest dependencies on the terminology draft. However, if folk prefer saag, for now at least that's fine. But let's drop the cross-posting to dane then please? (Which I bcc'd) S. On 03/12/2014 09:56 PM, Stephen Kent wrote: > Stephen, > >> (again, I'd suggest one list for this if we can and the >> UTA wg list, but hopefully that'll settle down when there's >> an I-D, and since I'm not the boss of us anyway...:-) >> > This is a broader topic than TLS, as later messages from Joe indicated, so > I don't think UTA is the right place for this discussion. > > Steve > > From nobody Wed Mar 12 15:00:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E957F1A074C; Wed, 12 Mar 2014 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 kHmrHYk6FG25; Wed, 12 Mar 2014 15:00:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 74E531A0795; Wed, 12 Mar 2014 15:00:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2CLxYS9009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 14:59:37 -0700 (PDT) Message-ID: <5320D8C6.5070609@isi.edu> Date: Wed, 12 Mar 2014 14:59:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , dane@ietf.org, saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: <5320D5DD.8060204@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VO0hmOuu8cHUC3lP3ZmvbQhHigE Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 22:00:14 -0000 Steve (et al.), On 3/12/2014 2:47 PM, Stephen Kent wrote: ... >> Is there a reason not to just call unauthenticated key exchange what >> it is - unauthenticated key exchange? > I think we want more than that, as I described above, hence the desire > to coin a new term. No disagreement; there seems to be a need then for two terms: 1. unauthenticated key exchange/use 2. security that uses authentication when available, but allows unauthenticated methods as a backup Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity to 'zero-touch' was intentional), and the second "zero-ID fallback". I'm not wed to either term, but "opportunistic" doesn't seem useful because OE seems to me a lot more like "use this key and hope it works", which isn't part of either case above. Joe From nobody Wed Mar 12 15:01:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E31A0781 for ; Wed, 12 Mar 2014 15:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 EIlv0l7cAh8V for ; Wed, 12 Mar 2014 15:01:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B42EE1A0796 for ; Wed, 12 Mar 2014 15:01:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2CM0rAs010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 15:00:54 -0700 (PDT) Message-ID: <5320D915.7090708@isi.edu> Date: Wed, 12 Mar 2014 15:00:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <532099C9.6060405@isi.edu> <5320D78F.70908@bbn.com> In-Reply-To: <5320D78F.70908@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qnInQWgjTkT2z6vBP-Cg3BwyzeQ Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 22:01:43 -0000 Agreed on all points; I was giving an example in the context of BTNS, and I agree that it's useful here to find a term that doesn't assume a particular layer. Joe On 3/12/2014 2:54 PM, Stephen Kent wrote: > Joe, > > ... >> Having unsigned key exchange has two ultimate uses: >> >> - raising the bar for attacks >> above 'send a RST' but below MITM > whether this feature accrues depends on the layer at which we provide the > O* technology. IPsec addresses this issue, TLS does not, tcpcrypt does, ... >> >> - providing a network-level mechanism that can be linked >> to security at higher layers > In this case you explicitly say network layer, but the discussion has > been broader than that. >> App-layer channel binding could be useful for BTNS, or for other >> approaches too (e.g., where a single key protects a set of ports). >> >>> But we never got there: no one seems to care much about end-to-end >>> IPsec, sadly. (Well, it's not that no one cares, but that it's too >>> late now; TLS is king.) >> >> TLS still doesn't protect the transport or network layers. > right, but that doesn't mean it's not useful. Operating above the > transport layer > avoids NAT problems, for example. > > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 12 15:14:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CED1A0781 for ; Wed, 12 Mar 2014 15:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4PXpk4ADTLl for ; Wed, 12 Mar 2014 15:14:28 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id C0FF21A0685 for ; Wed, 12 Mar 2014 15:14:28 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 84D2D59805F for ; Wed, 12 Mar 2014 15:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=x9Nbf2Dl2GIKSF8zQZ8P K7Mjz4Q=; b=UlJiOua+i83U+/m1IkEhZr4Wm/j4P62eC24htQwoCUrNOVpd+z6I 52i+dPxkvp2pdn20nuQ6qtCC3LmcS62Tw0r8GIF5zwCgbVqXuxkbH+hp4i8qvAAJ gT49/ixacNPCkZk9BGzRoPaqwcAWFgrF1H2jLaeJBtEMgiKJFgIUEEY= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 326A3598058 for ; Wed, 12 Mar 2014 15:14:22 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so129236wgg.21 for ; Wed, 12 Mar 2014 15:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNlq7OFW2sGUiB/dyv0Vaf+Pqj61QWJkm9xLWZ6P1Qo=; b=Z/4cx/jil6WO2RmWcQCzryOamMs2JjC7HyBjAwOdBSnmfrcPfgSzDN68jiS6rDNm29 nsQ/tT2qSkljUXBwF6rM38xp6NKRpbLLhy+wtKOoB/Esx+TugYYpY173P+Tlymb8p2jv G9toAXKC91CQUArBXrjBp/yJUoLnVksnWRta6221ce3gWTbRCQGNkOeq2DenjeX91Mmg nP4InLZAykkqXMndeH+6NmUDhg8Nd/MKYsjONdPNRJGTRLKg6BihkTxf+OER/f1GXZWl P4dV5jshegODn+IiBIe3F8e9ZXKuECDVA9aVdKlblfbgR8DBlOWszvJddU2R2QiQuflY k3aw== MIME-Version: 1.0 X-Received: by 10.194.104.39 with SMTP id gb7mr3193709wjb.69.1394662461073; Wed, 12 Mar 2014 15:14:21 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 15:14:20 -0700 (PDT) In-Reply-To: <5320D915.7090708@isi.edu> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <532099C9.6060405@isi.edu> <5320D78F.70908@bbn.com> <5320D915.7090708@isi.edu> Date: Wed, 12 Mar 2014 17:14:20 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LY5uHbBoamg1b2NV_2UfABrdK5s Cc: "saag@ietf.org" Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 22:14:30 -0000 On Wed, Mar 12, 2014 at 5:00 PM, Joe Touch wrote: > Agreed on all points; I was giving an example in the context of BTNS, and I > agree that it's useful here to find a term that doesn't assume a particular > layer. I'm yet to find a term I really like. "Opportunistic" really does fit, and we would reject it only because it conflicts with prior usage. Bummer. There's really a very wide range of behaviors we might be after: - unauthenticated crypto -- defeat passive attackers - unauthenticated crypto + TOFU == pseudonymous authentication - unauthenticated crypto at one layer w/ channel binding from another == privacy protection of identities relative to passive attackers - unauthenticated crypto in which to tunnel (w/ channel binding) further authentication == privacy protection of identities relative to passive attackers (this is the same as the previous item, but in the same layer; i.e., TLS renego) - unauthenticated crypto + attempt to authenticate inside that tunnel w/ fallback on TOFU or not even - ... + cert pinning / TAC / whatever There's probably more. It's a wide range of behaviors and semantics. More than a few such behaviors == confusing to everyone else (and even ourselves). Picking one or two to the exclusion of the others is probably unrealistic. Assigning an evocative English-language name to each (or even just two) of these behaviors is proving difficult. I'd say: assign acronyms or "security levels" to each behavior. Define these well in some RFC. Spread the word, use. Nico -- From nobody Wed Mar 12 17:38:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1541A07C6; Wed, 12 Mar 2014 17:38:02 -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 FwiQ3XW3pyFr; Wed, 12 Mar 2014 17:37:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C69511A07A6; Wed, 12 Mar 2014 17:37:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 470C92AADF5; Thu, 13 Mar 2014 00:37:52 +0000 (UTC) Date: Thu, 13 Mar 2014 00:37:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140313003752.GF21390@mournblade.imrryr.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5320D8C6.5070609@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/t2cyE8yOWIdl9Nh-Nw1Yimowock Cc: saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 00:38:02 -0000 On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote: [ It seems the discussion has moved on beyond the specifics of the title of the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS". So if anyone has a considered proposal for a better name, please start a new thread on the DANE list only, or just send me your suggestions off-list. ] > No disagreement; there seems to be a need then for two terms: > > 1. unauthenticated key exchange/use > > 2. security that uses authentication when available, > but allows unauthenticated methods as a backup Moving beyond the SMTP with DANE use-case, the space for SMTP alone is definitely larger than just two cases. For example, with email, we have: 0. Opportunistic TLS. http://www.postfix.org/TLS_README.html#client_tls_may What's opportunistic here is not the key management (long-term keys are not used or ignored), but the *use* of TLS. If the server EHLO response includes STARTTLS, TLS is attempted, otherwise not. 1. Mandatory unauthenticated TLS (similar to 1. above). http://www.postfix.org/TLS_README.html#client_tls_encrypt Use of TLS is not opportunistic, the transmission channel is always encrypted. However as with "0." there is no authentication. 2. Opportunistic use of authenticated TLS (e.g. via DANE) with fallback to "0." when the destination authentication policy is not available. http://www.postfix.org/TLS_README.html#client_tls_dane (with the "dane" security level) Here when "usable" secure TLSA records are published, the server is always authenticated. But otherwise, we do our best to at least not send in the clear. 3. Mandatory authentication: http://www.postfix.org/TLS_README.html#client_tls_fprint http://www.postfix.org/TLS_README.html#client_tls_secure http://www.postfix.org/TLS_README.html#client_tls_dane (with the "dane-only" security level) Similar to HTTPS, but no user to click OK, so deployment is limited to small set of administrator designated destinations. 4. Audit-only authentication (on the drawing board for Postfix): An attempt is made to authenticate the peer with the administrator selected policy (2 when destination policy is known or one of static policies in 3). Authentication results are logged, but mail delivery proceeds even when authentication fails. The failure mode can be configured to either "0." or "1." There are of course additional models (TOFU, Tack, ...) So perhaps a small list of terms (nouns or noun-phrases) will not cover all the models in a generic way. We can however provide some guidance on the appropriate use of some popular "adjectives", to encourage people to use them in a more appropriate, consistent fashion. My contention is, for example, that the use of "opportunistic" in "opportunistic TLS" to describe TLS in case "0" is a proper use of that adjective. Similarly "opportunistic DANE TLS" for case "2" is also reasonable. By way of contrast one might speak of "mandatory TLS", "mandatory DANE TLS", ... Finally, the terminology is the least of our worries, lets get more of the security protocols deployed! -- Viktor. From nobody Wed Mar 12 17:48:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B331A07D8; Wed, 12 Mar 2014 17:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av7fcrBUH3nu; Wed, 12 Mar 2014 17:48:57 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 558251A07CC; Wed, 12 Mar 2014 17:48:57 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 42871388DD; Wed, 12 Mar 2014 17:48:51 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id F2F1521DE71; Wed, 12 Mar 2014 17:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=07a0pJsed6fh5W2x33GT Iza+PWM=; b=gVlFYG5f/bOXn9SGWIU9lRWhvNm5iqQoS88ONsMrtJJKuZFfkpb/ 7kkrHPPW4d1dqsuJuJ1hGJKfIMDERIWHVPkVDDDUk91DPROFilJ1i+JeQqDd97Uc EDPdFNJhW5BN0PCuatTM0Y8oP8B3usH0WzWIFsT1Knx/73P+06aQfjo= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 744BA21DE57; Wed, 12 Mar 2014 17:48:50 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so235336wgh.8 for ; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZN60Buzgeu0LyEe2I2tfbVpeqH8o/IhSLFM7WGoE/k=; b=BNFm4Ec5/beZqHkzTHDeLMovNK/qCV4qXBBPvbUwx+Lc30/eVvWDlmu2xlWzbv4K4I 2mX2NlbU3XmHE4gPt0NIIXDWU3E41GbGme/T/4XqtdzlSWmxTjV30SgIjPi0qHq1YRhs PUciWOlqi5PwN1S+PQQqD6g/xish7EPRFLvTUDlulbTLJToOQMR1ACO5kD4GKwXrVuf7 HS3uTIBKFz7Jz9b/KwZONFxRZO4olDAegVLp5BdY3ws5iw4D5GBZ/4xP3lFX0awMqiud XbJtEgGP2bFoI51Q9pakHkK98vvxvkcR+Qp0Qm7CU3MN0FMQJiFw8ItHBsw5teDIBNS2 /ndA== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr856967wij.42.1394671726700; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 17:48:46 -0700 (PDT) In-Reply-To: <20140313003752.GF21390@mournblade.imrryr.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <20140313003752.GF21390@mournblade.imrryr.org> Date: Wed, 12 Mar 2014 19:48:46 -0500 Message-ID: From: Nico Williams To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3Ip7oXjGWqPg4fLEpgvs0c-4AG0 Cc: "saag@ietf.org" Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 00:48:58 -0000 On Wed, Mar 12, 2014 at 7:37 PM, Viktor Dukhovni wrote: > On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote: > > [ It seems the discussion has moved on beyond the specifics of the title of > the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS". So > if anyone has a considered proposal for a better name, please start a new > thread on the DANE list only, or just send me your suggestions off-list. ] It has moved beyond SMTP w/ DANE because we actually need general terminology for some of these behaviors. > 2. Opportunistic use of authenticated TLS (e.g. via DANE) with > fallback to "0." when the destination authentication policy > is not available. > > http://www.postfix.org/TLS_README.html#client_tls_dane > (with the "dane" security level) > > Here when "usable" secure TLSA records are published, > the server is always authenticated. But otherwise, we > do our best to at least not send in the clear. Right, we should distinguish "authenticate with TLS server PKI" from authenticate via DANE". > So perhaps a small list of terms (nouns or noun-phrases) will not > cover all the models in a generic way. We can however provide some > guidance on the appropriate use of some popular "adjectives", to > encourage people to use them in a more appropriate, consistent > fashion. > > My contention is, for example, that the use of "opportunistic" in > "opportunistic TLS" to describe TLS in case "0" is a proper use of > that adjective. Similarly "opportunistic DANE TLS" for case "2" > is also reasonable. By way of contrast one might speak of "mandatory > TLS", "mandatory DANE TLS", ... No argument from me. You're right too that we're going to compose two or more words. > Finally, the terminology is the least of our worries, lets get more > of the security protocols deployed! Well, you'd be surprised. Terminology makes a huge difference 'round these here parts. In this particular space we have a chance to define generic terms because a lot of the behaviors in question are new(ish). Sounds like a huge win to me! Nico -- From nobody Wed Mar 12 18:14:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A94D1A07F5; Wed, 12 Mar 2014 18:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 dxR7M-y79DxS; Wed, 12 Mar 2014 18:14:31 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id A82C01A07F2; Wed, 12 Mar 2014 18:14:31 -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 s2D1EMQb027375; Wed, 12 Mar 2014 18:14:22 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1jhd2xw6h8-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 18:14:22 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Wed, 12 Mar 2014 18:14:20 -0700 From: Paul Lambert To: Stephen Kent , Joe Touch , "dane@ietf.org" , saag Date: Wed, 12 Mar 2014 18:14:18 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac8+WY/O2vqrqseDQwKUvwYbLOprFQ== Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: <5320D5DD.8060204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-12_08:2014-03-12,2014-03-12,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-1305240000 definitions=main-1403120167 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TCWm1YCnMfzgmvOLw0s3E0QnIIM Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 01:14:33 -0000 On 3/12/14, 2:47 PM, "Stephen Kent" wrote: >Joe, > > >>> yeah, I like OK (and I like IKE too, for those of us old enough to >>> appreciate that election slogan) >> >> I'm still a little hesitant, thinking on it further, about the term >> "opportunistic" in this sense at all. >> >> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" >> about it. Unsigned authentication is the goal from the start. >> >> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >> "opportunistic" sense is derived from using keys retrieved from DNS >> without prior agreement. That's not what happens in BTNS. >agreed. >> Paul just noted: >> "Opportunistic keying does provide authentication, it's just that >> the authentication is only to the public key and is not >> tightly bound to any other type of identification (address, name, etc.)" >Public keys are not principles. We went through that long and painful >discussion >during the SPKI days. >=20 Your level of pain in a discussion is not a measure of a concepts validity :-)=20 Public keys and the hashes of public keys are the fundamental identifier of a =8Cprincipal=B9 when we are using public key based authentication. The principal is the end user or computer that controls the use of the public key. The public key is authenticated in a key exchange or signature validation process and is the primary connection in the process to the key holder (principal). Other information may be associated with the key locally or through a trusted path (out-of-band, signed, etc.) that can be used for authorization decisions. The other information may even include information associated with the key in a X.509 or other form of certificate. The public key and associated key hash for a principal may change. Changing keys could be viewed as either a new identifier for the same principal or a new principal with the same associated attributes as a previous principal. Either way, the public key (or hash) is a unique identifier of a principal which can then be usefully processed in a security policy. =20 There are several usages of =B3opportunistic=B2 in this thread. Clearly ne= w terms are needed. I=B9m primarily interested in =8Ckeys as identifiers=B9 = where longer term keys are used to identify principals. Security policies are built on hashes of keys and optionally other associated information that may include names, labels, group membership, etc. This may be getting a little far afield of the TLS-DANE or IPsec opportunistic specific usage. Still, the deferred binding and the TOFU model are compatible with a perspective of keys as identifiers of principals. >So, saying that OE provide authentication of a key >seems >meaningless to me, especially if the key is ephemeral. Yes, ephemeral keys do not provide any long term identity. This can also be a feature. A =8Cprincipal identifier=B9 with no associated information would only be authorized for actions that have no restrictions on specific principals. =20 Paul >> I.e., fundamentally, opportunistic approaches are completely different >> from those that don't ever bother to authenticate. I don't think it's >> useful (and could be confusing) to confuse the two by overlapping >> terminology. >We'll, we don't have an agreed upon definition for O* yet. My view is >that the primary goal of >this effort is to remove barriers to using encryption. Since >authenticating the identity or a >peer or server has tended to be a barrier, we seem willing to make that >form of authentication >optional. But, we still prefer authentication, because we'd like to >avoid MiTM attacks. That suggests >that O* refers to techniques that emphasize encryption, prefer that it >be authenticated, but are >willing to fall back to un-autnenticated encryption if that's thbe best >we can do. (And to fall back >to plaintext if the peer/server is not capable of our new-fangled O*) >> I don't like the term "optimistic" either; it too implies something >> that you "hope works". There's no "hope" associated with unsigned key >> exchange; you do it (IMO) because you know what it is and you know its >> impact (e.g., raising the bar of an attacker to performing a full key >> exchange, vs. just tossing single packets like RSTs around). >I'm not wedded top either term, but I'd like to emphasize that the >encryption process is >the same in all cases; it's the key management that's different. >> >> Is there a reason not to just call unauthenticated key exchange what >> it is - unauthenticated key exchange? >I think we want more than that, as I described above, hence the desire >to coin a new term. > >Steve > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 12 19:28:01 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A962F1A0882; Wed, 12 Mar 2014 19:27:57 -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 FTpLbpb_UiNb; Wed, 12 Mar 2014 19:27:56 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75D1A0877; Wed, 12 Mar 2014 19:27:53 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so242542lab.5 for ; Wed, 12 Mar 2014 19:27:46 -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=pWSJJjYuWwwJX8IfEfzo1Cgx/nTk/z7byCap2ZmkXGQ=; b=bQXCbul620IGbGdw7DzKk3mJhli4/hX73QTbLcdSgRYVCH3skBuI13p+Ath0/HmYLW 5QfJm9E8J27yo8i7+Wt4Oa6nV556f/c4F20tXHLXKFCgRVI4614EXdvo+OjFEp7sSTxp a0dxoVwm81vigRQifpFdTiU9Y59FeFKwIbEqR/6fiAn18//Zn6+WweabOBv0uwd0XDMG NS388I6iWhOE9t9daVZ9eaonZJmfBTKMUBr/zS2efeILP66okY3ap2laM97GDsWgq53S wXRqoqF4EJzjo985gTelxxErYYT/WfqxDv4hGq2YTBiHSRaGzwkNOS6sxMe8yCXHsZnm ddRA== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr43388lbb.37.1394677666493; Wed, 12 Mar 2014 19:27:46 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 12 Mar 2014 19:27:46 -0700 (PDT) In-Reply-To: <5320D5C8.8030509@cs.tcd.ie> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> <5320D5C8.8030509@cs.tcd.ie> Date: Wed, 12 Mar 2014 22:27:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b343d68e33ab304f473b2e0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HF-_GdXcYTD1JyDrjqlq9q6Ynlo Cc: Peter Palfrader , Michael Richardson , saag , "dane@ietf.org" Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 02:27:57 -0000 --047d7b343d68e33ab304f473b2e0 Content-Type: text/plain; charset=ISO-8859-1 I don't particularly mind what the definition is, provided I can know what the speaker means by it. Which right now I don't. I am quite happy if we defer the definition of what OE is until we have decided what to do and then decide that that is OE by definition. Some terms that come to mind for encryption using credentials that are not authenticated: Faith-Based Encryption Passive Protection Junk Encryption (cf Junk bonds which are worth a lot more than zero but a lot less than par) --047d7b343d68e33ab304f473b2e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't particularly mind w= hat the definition is, provided I can know what the speaker means by it. Wh= ich right now I don't. I am quite happy if we defer the definition of w= hat OE is until we have decided what to do and then decide that that is OE = by definition.


<= /div>
Some terms that come to mind for encryption= using credentials that are not authenticated:

Faith-Based Encryption
Passive Protection
Junk En= cryption (cf Junk bonds which are worth a lot more than zero but a lot less= than par)


<= div class=3D"gmail_extra">
--047d7b343d68e33ab304f473b2e0-- From nobody Wed Mar 12 19:36:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480051A087B for ; Wed, 12 Mar 2014 19:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 qOSHBzCG9xDI for ; Wed, 12 Mar 2014 19:36:01 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (agjbgdcfdbec.dreamhost.com [69.163.253.142]) by ietfa.amsl.com (Postfix) with ESMTP id DD8831A06A4 for ; Wed, 12 Mar 2014 19:36:01 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id B9D9A2005D90A for ; Wed, 12 Mar 2014 19:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=uA/3h08+5xglMcNVBHWs MbaWEzA=; b=qN71+ibCSBpR822wUj5o9hnYHeNmbos6obuqwve8L1Pe3L11dbrG HTQtsRKFDeSHcFR4HSP7zpkilp3RVhwmYlRqGh1ezVYH+kMl5d/wVTP2cwokmEyj G0l0LS/WQNEVkAZsehAVG/lKVDWH2L2/DXWIjT99l2RyGSrEJ4Pem7A= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 6F70E2005D908 for ; Wed, 12 Mar 2014 19:35:55 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so297297wgg.6 for ; Wed, 12 Mar 2014 19:35:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HayMoT5O6o3T5Tk8zrP8yY1trn5qxFa+T5DBhqcE9f8=; b=LQ0KJYlzoSt75+cPxqJ8VqM2NyzS/7Xk4uYd9udpwaQhJgv7jF2DVhogZb6tV7f1vo UUyo9lAwkI2tjf1yVxj/AS7fFp5rzLP4pBSXuZIlgAiTTrcH7BnhVLLeuE89a6QxUeUW xYtGAQGTsAhvgkjL5sY/9WIJolpcngtK3jKq22mm4NUNd5sfpgLkvrYS2WR+Lc5Zh0p+ oDKrw/rEbeb1/CG4uF25IGcnAPD90/bPAfg+oThqIN9w3B6ni9KgMGLR3SxCmdfEf2Tl bn+rmObflhVZf3JReUK3UKftqfDkol5HIrnA5a5qJ9cuMlC7D9swJdNYOHvLhf/9rB6W ZZ9g== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr1121732wij.42.1394678154361; Wed, 12 Mar 2014 19:35:54 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 19:35:54 -0700 (PDT) In-Reply-To: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca> <5320D5C8.8030509@cs.tcd.ie> Date: Wed, 12 Mar 2014 21:35:54 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OP3SXK8Hm9d5Ovcf0CNMhwzWr3s Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 02:36:03 -0000 [Dropping DANE for now] On Wed, Mar 12, 2014 at 9:27 PM, Phillip Hallam-Baker wrote: > I don't particularly mind what the definition is, provided I can know what > the speaker means by it. Which right now I don't. I am quite happy if we > defer the definition of what OE is until we have decided what to do and then > decide that that is OE by definition. > > > Some terms that come to mind for encryption using credentials that are not > authenticated: > > Faith-Based Encryption > Passive Protection > Junk Encryption (cf Junk bonds which are worth a lot more than zero but a > lot less than par) Hmmm, no, some of the behaviors we need terms for are the DNSSEC/DANE behaviors, which are hardly "faith-based". And anyways, using the TLS server PKI has been a bit of an exercise in faith, hasn't it? Nico -- From nobody Thu Mar 13 05:49:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB501A081D; Thu, 13 Mar 2014 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 hs9WN0-K1-ZU; Thu, 13 Mar 2014 05:48:53 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) by ietfa.amsl.com (Postfix) with ESMTP id DD0321A0848; Thu, 13 Mar 2014 05:48:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42109) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WO541-0005mr-WU (Exim 4.82_3-c0e5623) (return-path ); Thu, 13 Mar 2014 12:48:45 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WO541-0007cE-0E (Exim 4.72) (return-path ); Thu, 13 Mar 2014 12:48:45 +0000 Date: Thu, 13 Mar 2014 12:48:45 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20140313003752.GF21390@mournblade.imrryr.org> Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <20140313003752.GF21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EKID5Cvc5kq93YkOQMDEfPLXFYU Cc: saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 12:48:56 -0000 Viktor Dukhovni wrote: > > My contention is, for example, that the use of "opportunistic" in > "opportunistic TLS" to describe TLS in case "0" is a proper use of > that adjective. I think a better phrase would be "negotiated unauthenticated TLS". (Or "unauthenticated STARTTLS" since STARTTLS implies negotiated TLS). "Opportunistic" implies that someone is taking advantage of someone else to their detriment, whereas SMTP TLS is by mutual agreement. > Similarly "opportunistic DANE TLS" for case "2" is also reasonable. By > way of contrast one might speak of "mandatory TLS", "mandatory DANE > TLS", ... The mandatory cases are where the postmaster has overridden normal protocol negotiation, which implies that they should get a weirder name than the normal negotiated cases. Postfix's use of "opportunistic" is a bit weird. Sendmail and Exim do not use the term, though Microsoft Exchange does. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: South or southeast 3 or 4, veering southwest 4 or 5 later. Moderate or rough. Fair. Moderate or good. From nobody Thu Mar 13 05:54:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421D91A07CD for ; Thu, 13 Mar 2014 05:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 s18pzJE1rNwo for ; Thu, 13 Mar 2014 05:54:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0B1A0848 for ; Thu, 13 Mar 2014 05:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 164C4BE59; Thu, 13 Mar 2014 12:54:17 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9kQz9iYc1SG; Thu, 13 Mar 2014 12:54:16 +0000 (GMT) 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 E50C6BE4D; Thu, 13 Mar 2014 12:54:16 +0000 (GMT) Message-ID: <5321AA78.4070503@cs.tcd.ie> Date: Thu, 13 Mar 2014 12:54:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Lambert , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3ZMsehlVkyDt2j-EFarCmxEXgsg Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 12:54:28 -0000 (dropping dane) Hi Paul, On 03/13/2014 01:14 AM, Paul Lambert wrote: > > > On 3/12/14, 2:47 PM, "Stephen Kent" wrote: > >> Joe, >>> >>>> yeah, I like OK (and I like IKE too, for those of us old enough to >>>> appreciate that election slogan) >>> >>> I'm still a little hesitant, thinking on it further, about the term >>> "opportunistic" in this sense at all. >>> >>> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" >>> about it. Unsigned authentication is the goal from the start. >>> >>> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >>> "opportunistic" sense is derived from using keys retrieved from DNS >>> without prior agreement. That's not what happens in BTNS. >> agreed. >>> Paul just noted: >>> "Opportunistic keying does provide authentication, it's just that >>> the authentication is only to the public key and is not >>> tightly bound to any other type of identification (address, name, etc.)" >> Public keys are not principles. We went through that long and painful >> discussion >> during the SPKI days. > >> > Your level of pain in a discussion is not a measure of a concepts validity > :-) > > Public keys and the hashes of public keys are the fundamental identifier > of a Œprincipal¹ when we are using public key based authentication. In this context we are not always doing public key based endpoint or any authentication. So this is not a thread about spki-like approaches no matter who likes or dislikes those. > The > principal is the end user or computer that controls the use of the public > key. The public key is authenticated in a key exchange or signature > validation process and is the primary connection in the process to the key > holder (principal). Other information may be associated with the key > locally or through a trusted path (out-of-band, signed, etc.) that can be > used for authorization decisions. The other information may even include > information associated with the key in a X.509 or other form of > certificate. > > The public key and associated key hash for a principal may change. > Changing keys could be viewed as either a new identifier for the same > principal or a new principal with the same associated attributes as a > previous principal. Either way, the public key (or hash) is a unique > identifier of a principal which can then be usefully processed in a > security policy. > > There are several usages of ³opportunistic² in this thread. Clearly new > terms are needed. I¹m primarily interested in Œkeys as identifiers¹ where > longer term keys are used to identify principals. Security policies are > built on hashes of keys and optionally other associated information that > may include names, labels, group membership, etc. That's reasonable. Whatever terminology we end up with should be applicable to the above I agree. I'm not sure that that's the most important requirement though, given that we want terms that work well for more immediate needs, e.g. the web and SMTP/TLS between MTAs. > > This may be getting a little far afield of the TLS-DANE or IPsec > opportunistic specific usage. Still, the deferred binding and the TOFU > model are compatible with a perspective of keys as identifiers of > principals. Yes. Cheers, S. > > >> So, saying that OE provide authentication of a key >> seems >> meaningless to me, especially if the key is ephemeral. > Yes, ephemeral keys do not provide any long term identity. This can also > be a feature. A Œprincipal identifier¹ with no associated information > would only be authorized for actions that have no restrictions on specific > principals. > > Paul > > > >>> I.e., fundamentally, opportunistic approaches are completely different >>> from those that don't ever bother to authenticate. I don't think it's >>> useful (and could be confusing) to confuse the two by overlapping >>> terminology. >> We'll, we don't have an agreed upon definition for O* yet. My view is >> that the primary goal of >> this effort is to remove barriers to using encryption. Since >> authenticating the identity or a >> peer or server has tended to be a barrier, we seem willing to make that >> form of authentication >> optional. But, we still prefer authentication, because we'd like to >> avoid MiTM attacks. That suggests >> that O* refers to techniques that emphasize encryption, prefer that it >> be authenticated, but are >> willing to fall back to un-autnenticated encryption if that's thbe best >> we can do. (And to fall back >> to plaintext if the peer/server is not capable of our new-fangled O*) >>> I don't like the term "optimistic" either; it too implies something >>> that you "hope works". There's no "hope" associated with unsigned key >>> exchange; you do it (IMO) because you know what it is and you know its >>> impact (e.g., raising the bar of an attacker to performing a full key >>> exchange, vs. just tossing single packets like RSTs around). >> I'm not wedded top either term, but I'd like to emphasize that the >> encryption process is >> the same in all cases; it's the key management that's different. >>> >>> Is there a reason not to just call unauthenticated key exchange what >>> it is - unauthenticated key exchange? >> I think we want more than that, as I described above, hence the desire >> to coin a new term. >> >> Steve >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Thu Mar 13 05:57:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54F1A07CD for ; Thu, 13 Mar 2014 05:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 SunSKpGzhHJ4 for ; Thu, 13 Mar 2014 05:56:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 740B41A07CB for ; Thu, 13 Mar 2014 05:56:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB953BE4D; Thu, 13 Mar 2014 12:56:47 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz0OOWPP1Br4; Thu, 13 Mar 2014 12:56:47 +0000 (GMT) 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 70587BE3E; Thu, 13 Mar 2014 12:56:47 +0000 (GMT) Message-ID: <5321AB0F.3010908@cs.tcd.ie> Date: Thu, 13 Mar 2014 12:56:47 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FJr-jaBZpW367RRNFY8g9gOpV1k Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 12:56:57 -0000 (dropping dane) On 03/13/2014 07:59 AM, Olle E. Johansson wrote: > > On 12 Mar 2014, at 21:02, Derek Atkins wrote: > >> Joe Touch writes: >> >>> Why not just use the term "unauthenticated encryption", when that's >>> exactly what's happening? >> >> Well, it's not necessarily what's happening. The data itself might >> still have "integrity protection" (which is a form of authentication. >> You're just not authenticating the endpoint, which means you could be >> subject to a MitM attack. Alternate terms could be "Unauthenticated >> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to >> what's going on. > > To get any movement in this area among developers and sysadmins, > we need a language that any sysadmin or developer understands. > I believe we can easily get them to understand "Opportunistic encryption" > but if we go into explaining "keying" or "key exchange" they will be lost in > the OpenSSL documentation maze again. That's maybe a fair point. But our first target here are folks developing protocols I think. If need be, they can figure out good marketing terms on a per-protocol basis. > > We might have to separate a "marketing name" of the overall concept > from a set of technical definitions we can refer to when explaining this in > RFCs. For me, I can happily accept using OE as the unclear marketing > bullshit term for a set of solutions that set up an encrypted communication > channel - regardless of URI or configuration, without any indication to > the user in the phone UI or browser UI - no locks! > > I can understand that this may be hard to accept in a technical community, but > we have a huge educational effort ahead of us in order to get this done. > The general concept has to be easy to explain. > > In summary, I propose that we keep OE as the overall term and define > a set of more precise terminology to explain what goes on in the background. > As Victor pointed out, there may be different solutions in different > protocols. I sort-of agree. I do think we need to say something about OE, even if that's just along the lines of "its vague, but are ways it has been used and section X.Y has more precise terminology that's better" Cheers, S. > > As a side note: > > https://tools.ietf.org/html/rfc5630 > > Use the term "best-effort TLS" to describe that a SIP ua is perfectly > allowed to set up a TLS session based on policy regardless if there > is a "sips:" URI. I don't know where that terminalogy came from. It's > always used with quotation marks in the RFC. This "best-effort TLS" > still requires verification of the certificate though. > > Cheers > /O > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From nobody Thu Mar 13 06:01:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A861A07D9 for ; Thu, 13 Mar 2014 06:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 8-ieVMCRaYpz for ; Thu, 13 Mar 2014 06:01:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C92111A07BE for ; Thu, 13 Mar 2014 06:01:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27DD3BE4D; Thu, 13 Mar 2014 13:01:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyuGNmQXHo9X; Thu, 13 Mar 2014 13:01:27 +0000 (GMT) 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 0BEA5BE3E; Thu, 13 Mar 2014 13:01:27 +0000 (GMT) Message-ID: <5321AC27.4030801@cs.tcd.ie> Date: Thu, 13 Mar 2014 13:01:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tony Finch References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <20140313003752.GF21390@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HzePlD9Qt6N9UBkVndsHZu9zCFs Cc: saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 13:01:35 -0000 (dropping dane) On 03/13/2014 12:48 PM, Tony Finch wrote: > Viktor Dukhovni wrote: >> >> My contention is, for example, that the use of "opportunistic" in >> "opportunistic TLS" to describe TLS in case "0" is a proper use of >> that adjective. > > I think a better phrase would be "negotiated unauthenticated TLS". > (Or "unauthenticated STARTTLS" since STARTTLS implies negotiated TLS). > "Opportunistic" implies that someone is taking advantage of someone else > to their detriment, whereas SMTP TLS is by mutual agreement. > >> Similarly "opportunistic DANE TLS" for case "2" is also reasonable. By >> way of contrast one might speak of "mandatory TLS", "mandatory DANE >> TLS", ... > > The mandatory cases are where the postmaster has overridden normal > protocol negotiation, which implies that they should get a weirder name > than the normal negotiated cases. > > Postfix's use of "opportunistic" is a bit weird. Sendmail and Exim do not > use the term, though Microsoft Exchange does. Just to highlight that this is not only about TLS and IPsec. For example, one of the reasons I'm helping with [1] is to try figure out if/how other protocols can usefully do the "OK" trick. TCPcrypt [2] or whatever that morphs into might also not use IPsec or TLS (or might, who knows). So we want the definitions to not be TLS or IPsec specific. (Or we'll do all this over yet again at some point in the nearish future;-) S. [1] http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt [2] http://tools.ietf.org/html/draft-bittau-tcp-crypt > > Tony. > From nobody Thu Mar 13 06:33:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149941A092A for ; Thu, 13 Mar 2014 06:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 qKOu7JUFC3Gb for ; Thu, 13 Mar 2014 06:33:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8F01A096C for ; Thu, 13 Mar 2014 06:33:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33837 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WO5kz-000LHg-2y for saag@ietf.org; Thu, 13 Mar 2014 09:33:09 -0400 Message-ID: <5321B38E.6020905@bbn.com> Date: Thu, 13 Mar 2014 09:33:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> In-Reply-To: <5320D8C6.5070609@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uk0xHOp8DIWSdItFmXnqaow21G4 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 13:33:13 -0000 Joe, > Steve (et al.), > > On 3/12/2014 2:47 PM, Stephen Kent wrote: > ... >>> Is there a reason not to just call unauthenticated key exchange what >>> it is - unauthenticated key exchange? >> I think we want more than that, as I described above, hence the desire >> to coin a new term. > > No disagreement; there seems to be a need then for two terms: > > 1. unauthenticated key exchange/use Yes, we could refer to this as unauthenticated or anonymous. > 2. security that uses authentication when available, > but allows unauthenticated methods as a backup > > Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity to > 'zero-touch' was intentional), and the second "zero-ID fallback". As I noted earlier, I'm not wedded to using the term "opportunistic" or even "optimistic" but I can't say that "zero-*" conveys the intent to me. > I'm not wed to either term, but "opportunistic" doesn't seem useful > because OE seems to me a lot more like "use this key and hope it > works", which isn't part of either case above. In Michael's RFC, OE isn't a "hope it works" method. It's a combination of two things: - agreeing to establish an authenticated SA with a peer irrespective of SPD entries - using the DNS as a way to acquire the public key for the responder, preferably via DNSSEC Steve From nobody Thu Mar 13 06:33:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EDE1A08F1; Tue, 11 Mar 2014 23:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtbIxutUTZ2Q; Tue, 11 Mar 2014 23:28:03 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [86.59.21.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB51A08E8; Tue, 11 Mar 2014 23:28:03 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 9449C10E7C6; Wed, 12 Mar 2014 07:27:56 +0100 (CET) Date: Wed, 12 Mar 2014 07:27:56 +0100 From: Peter Palfrader To: Stephen Kent , dane@ietf.org, saag Message-ID: <20140312062756.GN11878@anguilla.noreply.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531F8E5F.8030705@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UGe4YnAW6Z0LAH5_giv-5y5r7hc X-Mailman-Approved-At: Thu, 13 Mar 2014 06:33:35 -0700 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 12 Mar 2014 06:28:06 -0000 On Tue, 11 Mar 2014, Joe Touch wrote: > Why not just use the term "unauthenticated encryption", when that's > exactly what's happening? There is such a thing as authenticated encryption[1], as in AES GCM for instance, and what we're doing here is not its opposite. Thus, I think calling this "unauthenticated encryption" would be a bad idea. Cheers, 1: https://en.wikipedia.org/wiki/Authenticated_encryption -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From nobody Thu Mar 13 06:33:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353321A094F; Thu, 13 Mar 2014 00:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 aHR9EsNpaNBL; Thu, 13 Mar 2014 00:59:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4B1A094E; Thu, 13 Mar 2014 00:59:21 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6195793C2A2; Thu, 13 Mar 2014 07:59:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 13 Mar 2014 08:59:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> To: Derek Atkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NzDqO90S0r88t_eoMwYYUsq8e5Q X-Mailman-Approved-At: Thu, 13 Mar 2014 06:33:35 -0700 Cc: dane@ietf.org, saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 07:59:24 -0000 On 12 Mar 2014, at 21:02, Derek Atkins wrote: > Joe Touch writes: >=20 >> Why not just use the term "unauthenticated encryption", when that's >> exactly what's happening? >=20 > Well, it's not necessarily what's happening. The data itself might > still have "integrity protection" (which is a form of authentication. > You're just not authenticating the endpoint, which means you could be > subject to a MitM attack. Alternate terms could be "Unauthenticated > Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to > what's going on. To get any movement in this area among developers and sysadmins,=20 we need a language that any sysadmin or developer understands.=20 I believe we can easily get them to understand "Opportunistic = encryption" but if we go into explaining "keying" or "key exchange" they will be = lost in=20 the OpenSSL documentation maze again. We might have to separate a "marketing name" of the overall concept from a set of technical definitions we can refer to when explaining this = in RFCs. For me, I can happily accept using OE as the unclear marketing bullshit term for a set of solutions that set up an encrypted = communication channel - regardless of URI or configuration, without any indication to the user in the phone UI or browser UI - no locks! I can understand that this may be hard to accept in a technical = community, but we have a huge educational effort ahead of us in order to get this done. The general concept has to be easy to explain. In summary, I propose that we keep OE as the overall term and define a set of more precise terminology to explain what goes on in the = background. As Victor pointed out, there may be different solutions in different protocols. As a side note: https://tools.ietf.org/html/rfc5630 Use the term "best-effort TLS" to describe that a SIP ua is perfectly allowed to set up a TLS session based on policy regardless if there is a "sips:" URI. I don't know where that terminalogy came from. It's always used with quotation marks in the RFC. This "best-effort TLS" still requires verification of the certificate though. Cheers /O From nobody Thu Mar 13 07:15:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002F11A09B5 for ; Thu, 13 Mar 2014 07:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 e761jppWqR1z for ; Thu, 13 Mar 2014 07:15:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E22541A09AA for ; Thu, 13 Mar 2014 07:15:15 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51506 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WO6Pg-000LoA-01; Thu, 13 Mar 2014 10:15:12 -0400 Message-ID: <5321BD64.4050609@bbn.com> Date: Thu, 13 Mar 2014 10:15:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Lambert , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/S1pyRrYgKtMQxFOuw-ky30ZINk8 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 14:15:18 -0000 Paul, > > On 3/12/14, 2:47 PM, "Stephen Kent" wrote: > >> Joe, >>>> yeah, I like OK (and I like IKE too, for those of us old enough to >>>> appreciate that election slogan) >>> I'm still a little hesitant, thinking on it further, about the term >>> "opportunistic" in this sense at all. >>> >>> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" >>> about it. Unsigned authentication is the goal from the start. >>> >>> OE as defined in RFC 4322 isn't about using unsigned key exchange; the >>> "opportunistic" sense is derived from using keys retrieved from DNS >>> without prior agreement. That's not what happens in BTNS. >> agreed. >>> Paul just noted: >>> "Opportunistic keying does provide authentication, it's just that >>> the authentication is only to the public key and is not >>> tightly bound to any other type of identification (address, name, etc.)" >> Public keys are not principles. We went through that long and painful >> discussion >> during the SPKI days. > Your level of pain in a discussion is not a measure of a concepts validity > :-) true, but the idea that a public key is a principal is long dead. > Public keys and the hashes of public keys are the fundamental identifier > of a Œprincipal¹ when we are using public key based authentication. The > principal is the end user or computer that controls the use of the public > key. The public key is authenticated in a key exchange or signature > validation process and is the primary connection in the process to the key > holder (principal). Other information may be associated with the key > locally or through a trusted path (out-of-band, signed, etc.) that can be > used for authorization decisions. The other information may even include > information associated with the key in a X.509 or other form of > certificate. In a word, no. When a public key is used in a cert it is bound to some data, typically for authentication and access control. The usual model calls for the Subject name or SAN to identify the principal. In some cases the cert functions as an authorization credential, as in the RPKI. In that case the relevant data is the RFC 3779 extension. We don't view the public key as the principal in any of these cases. More generally, if we are to use ephemeral keys, as suggested for PFS, then saying that the key is the principal is silly, because the key changes for each new session. > The public key and associated key hash for a principal may change. > Changing keys could be viewed as either a new identifier for the same > principal or a new principal with the same associated attributes as a > previous principal. Either way, the public key (or hash) is a unique > identifier of a principal which can then be usefully processed in a > security policy. not really. If a key changes very frequently, as is the case for ephemeral D-H, then nobody would use these values for access control purposes, because managing constantly changing ACL entries would infeasible. > There are several usages of ³opportunistic² in this thread. Clearly new > terms are needed. I¹m primarily interested in Œkeys as identifiers¹ where > longer term keys are used to identify principals. Security policies are > built on hashes of keys and optionally other associated information that > may include names, labels, group membership, etc. The SPKI WG would have been the right place to pursue this interest, but it died over a decade ago. > This may be getting a little far afield of the TLS-DANE or IPsec > opportunistic specific usage. Still, the deferred binding and the TOFU > model are compatible with a perspective of keys as identifiers of > principals. TOFU assumes an asserted/implied identity that, as the name suggests, is trusted initially, despite the lack of a "high quality" credentials. TOFU is motivated by a threat model in which an adversary is unlikely to be able to act as a MiTM for the initial credential acquisition AND remain as a MiTM for every subsequent crypto-protected session. That's a pretty reasonable threat model in many contexts, especially within an enterprise environment (where SSH is most often used). So, I disagree that TOFU posits the public key as an ID. >> So, saying that OE provide authentication of a key >> seems >> meaningless to me, especially if the key is ephemeral. > Yes, ephemeral keys do not provide any long term identity. This can also > be a feature. A Œprincipal identifier¹ with no associated information > would only be authorized for actions that have no restrictions on specific > principals. Access controls don't usually focus on what a principal is authorized to do when you can't identify the principal. Steve From nobody Thu Mar 13 07:38:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1305A1A09D8 for ; Thu, 13 Mar 2014 07:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 e7eS0mJXj_YU for ; Thu, 13 Mar 2014 07:38:22 -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 E14CB1A09C9 for ; Thu, 13 Mar 2014 07:38:21 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4A5BB285DB; Thu, 13 Mar 2014 14:38:15 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 33722285DA; Thu, 13 Mar 2014 14:38:15 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 2663CFE074; Thu, 13 Mar 2014 14:38:15 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 13 Mar 2014 10:38:14 -0400 From: "Salz, Rich" To: "Olle E. Johansson" , Derek Atkins Date: Thu, 13 Mar 2014 10:38:13 -0400 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac8+wN3v6/MdawzxRomD2w7OW7nPngACPEvA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5A65@USMBX1.msg.corp.akamai.com> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9EMB_sUvwHuxx665OsmJvzGBCm8 Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 14:38:23 -0000 > To get any movement in this area among developers and sysadmins, we need = a language that any sysadmin or developer understands.=20 I believe we can easily get them to understand "Opportunistic encryption" +1! -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Mar 13 07:53:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79111A09E9 for ; Thu, 13 Mar 2014 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGWs9ZVnsJ4B for ; Thu, 13 Mar 2014 07:53:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DB1061A0804 for ; Thu, 13 Mar 2014 07:53:04 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2DEqu5b081131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Mar 2014 07:52:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5321AB0F.3010908@cs.tcd.ie> Date: Thu, 13 Mar 2014 07:52:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6459F834-2798-4D1B-883A-339531355316@vpnc.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> To: saag X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PFbFWwMyOwUmMDKoqv5PDPUfpgM Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 14:53:06 -0000 On Mar 13, 2014, at 5:56 AM, Stephen Farrell = wrote: > On 03/13/2014 07:59 AM, Olle E. Johansson wrote: >> To get any movement in this area among developers and sysadmins,=20 >> we need a language that any sysadmin or developer understands.=20 >> I believe we can easily get them to understand "Opportunistic = encryption" >> but if we go into explaining "keying" or "key exchange" they will be = lost in=20 >> the OpenSSL documentation maze again. >=20 > That's maybe a fair point. But our first target here are > folks developing protocols I think. If need be, they can > figure out good marketing terms on a per-protocol basis. Disagree about the "first target". The first target is to get people to = care about encrypting more: that will put pressure on developers to put = that into their protocols and products. Given that, having a definition = of "opportunistic encryption" that makes sense to users is more = important. >> In summary, I propose that we keep OE as the overall term and define >> a set of more precise terminology to explain what goes on in the = background. >> As Victor pointed out, there may be different solutions in different >> protocols. >=20 > I sort-of agree. I do think we need to say something about OE, > even if that's just along the lines of "its vague, but > are ways it has been used and section X.Y has more precise > terminology that's better" Disagree about us saying "it's vague". It's only vague if we make it = that way. I'm still confused about why we feel that the definition in an old = Informational RFC that was barely deployed should be relevant to our = discussion. We can define the term that everyone is using any way we = want. And it seems we want to define it in a way that will get more OE = everywhere. Let's do that. --Paul Hoffman= From nobody Thu Mar 13 07:58:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2BE1A09EF for ; Thu, 13 Mar 2014 07:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 oG_6ss02goO1 for ; Thu, 13 Mar 2014 07:58:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 570C71A09E9 for ; Thu, 13 Mar 2014 07:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BC64BE4D; Thu, 13 Mar 2014 14:57:57 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVCJyxsb2kUl; Thu, 13 Mar 2014 14:57:57 +0000 (GMT) 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 15AD3BE58; Thu, 13 Mar 2014 14:57:57 +0000 (GMT) Message-ID: <5321C775.9070406@cs.tcd.ie> Date: Thu, 13 Mar 2014 14:57:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> In-Reply-To: <6459F834-2798-4D1B-883A-339531355316@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YeDBW4eP08-GArZAnzKLYwCHVJQ Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 14:58:07 -0000 On 03/13/2014 02:52 PM, Paul Hoffman wrote: > On Mar 13, 2014, at 5:56 AM, Stephen Farrell > wrote: > >> On 03/13/2014 07:59 AM, Olle E. Johansson wrote: >>> To get any movement in this area among developers and sysadmins, >>> we need a language that any sysadmin or developer understands. I >>> believe we can easily get them to understand "Opportunistic >>> encryption" but if we go into explaining "keying" or "key >>> exchange" they will be lost in the OpenSSL documentation maze >>> again. >> >> That's maybe a fair point. But our first target here are folks >> developing protocols I think. If need be, they can figure out good >> marketing terms on a per-protocol basis. > > Disagree about the "first target". The first target is to get people > to care about encrypting more: that will put pressure on developers > to put that into their protocols and products. Given that, having a > definition of "opportunistic encryption" that makes sense to users is > more important. Fair point, but I'm not convinced. Our audience is not users, but implementers and those developing protocols. And for a lot of OK protocols/implementations the user (if there is one) should see nothing at all. >>> In summary, I propose that we keep OE as the overall term and >>> define a set of more precise terminology to explain what goes on >>> in the background. As Victor pointed out, there may be different >>> solutions in different protocols. >> >> I sort-of agree. I do think we need to say something about OE, even >> if that's just along the lines of "its vague, but are ways >> it has been used and section X.Y has more precise terminology >> that's better" > > Disagree about us saying "it's vague". It's only vague if we make it > that way. > > I'm still confused about why we feel that the definition in an old > Informational RFC that was barely deployed should be relevant to our > discussion. IMO, its relevant but not gospel. > We can define the term that everyone is using any way we > want. And it seems we want to define it in a way that will get more > OE everywhere. Let's do that. +1 to the goal whether we use OE or OK or something else. S. > > --Paul Hoffman _______________________________________________ saag > mailing list saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Thu Mar 13 08:01:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA6D1A09E9 for ; Thu, 13 Mar 2014 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 hCuZlK1ZAQuy for ; Thu, 13 Mar 2014 08:01:47 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 855F31A09E0 for ; Thu, 13 Mar 2014 08:01:47 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E3D4E4821E; Thu, 13 Mar 2014 15:01:40 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id D7E634820D; Thu, 13 Mar 2014 15:01:40 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C032B9803D; Thu, 13 Mar 2014 15:01:40 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 13 Mar 2014 11:01:40 -0400 From: "Salz, Rich" To: Stephen Farrell , Paul Hoffman , saag Date: Thu, 13 Mar 2014 11:01:39 -0400 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac8+zKP67Q39Y6OlRaOPs5wszUOxwgAAAxCw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FC6D5A84@USMBX1.msg.corp.akamai.com> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> In-Reply-To: <5321C775.9070406@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r0X1pJkyS74ss9jj8HIRnWlVgHo Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:01:50 -0000 > Our audience is not users, but implementers and those developing protocol= s. And for a lot of OK protocols/implementations the user (if there is one)= should see nothing at all. I think it will be a marketing plus -- we first try to strongly encrypt all= your traffic -- and that therefore it will get out to customers. And that= rather than invent a new term, the developers will toss the RFC to the doc= umentation, marketing, advertising, folks and say "here, this is what we're= doing (leave me alone now)" I don't want to descend into "why joe sixpack= can't encrypt" discussions, but I think you're wrong to think this term wo= n't "escape", and therefore we should spend a little effort on grooming. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Mar 13 08:06:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754F51A09E0 for ; Thu, 13 Mar 2014 08:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 l2hUJA9st_Py for ; Thu, 13 Mar 2014 08:06:01 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7C1A09CD for ; Thu, 13 Mar 2014 08:06:00 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 89A2093C2A1; Thu, 13 Mar 2014 15:05:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5321C775.9070406@cs.tcd.ie> Date: Thu, 13 Mar 2014 16:05:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2H9ow5b57Lt05_SK5FMtHOF_rNo Cc: Paul Hoffman , saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:06:04 -0000 On 13 Mar 2014, at 15:57, Stephen Farrell wrote: > > > On 03/13/2014 02:52 PM, Paul Hoffman wrote: >> On Mar 13, 2014, at 5:56 AM, Stephen Farrell >> wrote: >> >>> On 03/13/2014 07:59 AM, Olle E. Johansson wrote: >>>> To get any movement in this area among developers and sysadmins, >>>> we need a language that any sysadmin or developer understands. I >>>> believe we can easily get them to understand "Opportunistic >>>> encryption" but if we go into explaining "keying" or "key >>>> exchange" they will be lost in the OpenSSL documentation maze >>>> again. >>> >>> That's maybe a fair point. But our first target here are folks >>> developing protocols I think. If need be, they can figure out good >>> marketing terms on a per-protocol basis. >> >> Disagree about the "first target". The first target is to get people >> to care about encrypting more: that will put pressure on developers >> to put that into their protocols and products. Given that, having a >> definition of "opportunistic encryption" that makes sense to users is >> more important. > > Fair point, but I'm not convinced. Our audience is not users, but > implementers and those developing protocols. And for a lot of OK > protocols/implementations the user (if there is one) should see > nothing at all. We are going around in circles. I think we - the larger Internet Community - ned to explain this and get everyone that manages a system, that configures software to get aboard this ship. The IETF may have another audience. We in the IETF needs to explain this to everyone involved in the IETF and then get it out to developers that can change their software. > >>>> In summary, I propose that we keep OE as the overall term and >>>> define a set of more precise terminology to explain what goes on >>>> in the background. As Victor pointed out, there may be different >>>> solutions in different protocols. >>> >>> I sort-of agree. I do think we need to say something about OE, even >>> if that's just along the lines of "its vague, but are ways >>> it has been used and section X.Y has more precise terminology >>> that's better" >> >> Disagree about us saying "it's vague". It's only vague if we make it >> that way. >> >> I'm still confused about why we feel that the definition in an old >> Informational RFC that was barely deployed should be relevant to our >> discussion. > > IMO, its relevant but not gospel. Marketing terms are seldom exact and precise. ;-) "Oppurtunistic encryption is a set of solutions that enable application developers and protocol designers to activate encryption in more communication than before. This will make it harder to monitor communication on privat as well as public networks." Or something like that. > >> We can define the term that everyone is using any way we >> want. And it seems we want to define it in a way that will get more >> OE everywhere. Let's do that. > > +1 to the goal whether we use OE or OK or something else. +1 /O From nobody Thu Mar 13 08:08:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762D31A09CD for ; Thu, 13 Mar 2014 08:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 mer332-tzHgn for ; Thu, 13 Mar 2014 08:08:55 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78C1A09A8 for ; Thu, 13 Mar 2014 08:08:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 11E6D20035; Thu, 13 Mar 2014 12:27:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7FB95647C9; Thu, 13 Mar 2014 11:08:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68EA664655; Thu, 13 Mar 2014 11:08:48 -0400 (EDT) From: Michael Richardson To: Paul Hoffman In-Reply-To: <6459F834-2798-4D1B-883A-339531355316@vpnc.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5tpmEfTFwDwgfroWZ8r8alMXgM4 Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:08:56 -0000 --=-=-= Paul Hoffman wrote: > I'm still confused about why we feel that the definition in an old > Informational RFC that was barely deployed should be relevant to our > discussion. We can define the term that everyone is using any way we > want. And it seems we want to define it in a way that will get more OE > everywhere. Let's do that. As the author of that document, I say: +1. Let "OE" be the vague marketing term, rather like "SSL VPN" is/was. Let's avoid "opportunistic" in our precise terminology, and say exactly what we mean. I didn't know TOFU before, and it's great. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyHKAIqHRg3pndX9AQItbAQAx89WIqa72uSduiKox4EJ60h2oP26O44m iWaUVDJ9FXK7hqbs34zK4Yzqj7d6g2MZlS9tUyBBL9vFIdgJ5SvgQa3B6rLqGtQ1 OQExEeFedXw8bwb+5D2QpbRnksa9i2VdMv2mQneLjT4ovxxHI7z8UPNZdBRnxUkV PPLXe0DZDn4= =LLI2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 13 08:10:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15D1A09E9 for ; Thu, 13 Mar 2014 08:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 NhT7Pu0T1aBd for ; Thu, 13 Mar 2014 08:10:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CBDA01A097D for ; Thu, 13 Mar 2014 08:10:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 22A9CBE4D; Thu, 13 Mar 2014 15:10:22 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8W0OhukX5-I; Thu, 13 Mar 2014 15:10:22 +0000 (GMT) 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 03C98BE3E; Thu, 13 Mar 2014 15:10:22 +0000 (GMT) Message-ID: <5321CA5E.5010303@cs.tcd.ie> Date: Thu, 13 Mar 2014 15:10:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> In-Reply-To: <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rCPr_nTthKnS_pLknF3vLVRLEPg Cc: Paul Hoffman , saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:10:30 -0000 On 03/13/2014 03:05 PM, Olle E. Johansson wrote: > > "Oppurtunistic encryption is a set of solutions that enable application > developers and protocol designers to activate encryption in more > communication than before. This will make it harder to monitor > communication on privat as well as public networks." I like that as a starting point. So if we had a draft that defined good/new/precise terms (e.g. OK), and that included the above text in its intro, and that had some text about the history (4322 etc), would that sound like a plan to folks? Ta, S. From nobody Thu Mar 13 08:11:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D02C1A0A14; Thu, 13 Mar 2014 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 zH1uCCFszHnX; Thu, 13 Mar 2014 08:11:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 521261A0A13; Thu, 13 Mar 2014 08:11:07 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DF8PQN028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 08:08:35 -0700 (PDT) Message-ID: <5321C9EC.8010403@isi.edu> Date: Thu, 13 Mar 2014 08:08:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" , Derek Atkins References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oEnlqwM_WCmM8Sw4B7V8a30xr8g Cc: saag , dane@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:11:10 -0000 On 3/13/2014 12:59 AM, Olle E. Johansson wrote: > > On 12 Mar 2014, at 21:02, Derek Atkins wrote: > >> Joe Touch writes: >> >>> Why not just use the term "unauthenticated encryption", when that's >>> exactly what's happening? >> >> Well, it's not necessarily what's happening. The data itself might >> still have "integrity protection" (which is a form of authentication. >> You're just not authenticating the endpoint, which means you could be >> subject to a MitM attack. Alternate terms could be "Unauthenticated >> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to >> what's going on. > > To get any movement in this area among developers and sysadmins, > we need a language that any sysadmin or developer understands. > I believe we can easily get them to understand "Opportunistic encryption" > but if we go into explaining "keying" or "key exchange" they will be lost in > the OpenSSL documentation maze again. The problem is that OE isn't what's going on when you simply choose not to authenticate keys. Yes, it's a simple term, but it's also an incorrect one. I appreciate the desire to find a cute marketing term, which is why I offered "zero-ID" - which is more accurate and easier to explain to developers and sysadmins (what do you *do* to make OE? it's easy to make zero-ID - you stop using IDs). I'm not wed to that term, but market-speak is your metric, OE fails on multiple counts. > As a side note: > > https://tools.ietf.org/html/rfc5630 > > Use the term "best-effort TLS" to describe that a SIP ua is perfectly > allowed to set up a TLS session based on policy regardless if there > is a "sips:" URI. I don't know where that terminalogy came from. It's > always used with quotation marks in the RFC. This "best-effort TLS" > still requires verification of the certificate though. That's similar reasoning as to why I don't like OE. Joe From nobody Thu Mar 13 08:20:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71D61A09EB for ; Thu, 13 Mar 2014 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 jTLpbUZ-QCrj for ; Thu, 13 Mar 2014 08:20:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7551A0A0B for ; Thu, 13 Mar 2014 08:20:52 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id F0A9893C2A1; Thu, 13 Mar 2014 15:20:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <8492.1394723328@sandelman.ca> Date: Thu, 13 Mar 2014 16:20:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4710CE87-B50B-421A-ACD0-E31A45146270@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <8492.1394723328@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FEEg_tGbvoO52jhDxOzloBFxGjI Cc: Paul Hoffman , saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:20:55 -0000 On 13 Mar 2014, at 16:08, Michael Richardson = wrote: >=20 > Paul Hoffman wrote: >> I'm still confused about why we feel that the definition in an old >> Informational RFC that was barely deployed should be relevant to our >> discussion. We can define the term that everyone is using any way we >> want. And it seems we want to define it in a way that will get more = OE >> everywhere. Let's do that. >=20 > As the author of that document, I say: +1. > Let "OE" be the vague marketing term, rather like "SSL VPN" is/was. >=20 > Let's avoid "opportunistic" in our precise terminology, and say = exactly what > we mean. I didn't know TOFU before, and it's great. +1 /O >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting for hire =3D- >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Mar 13 08:33:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519031A08ED for ; Thu, 13 Mar 2014 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 RFMup-ScLxN3 for ; Thu, 13 Mar 2014 08:33:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EDEE91A0873 for ; Thu, 13 Mar 2014 08:33:48 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DFWoPb025348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 08:32:59 -0700 (PDT) Message-ID: <5321CFA5.7080702@isi.edu> Date: Thu, 13 Mar 2014 08:32:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> In-Reply-To: <5321B38E.6020905@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hZFmwZgizplSOpxszV_zR9D-DIc Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:33:50 -0000 On 3/13/2014 6:33 AM, Stephen Kent wrote: > Joe, > >> Steve (et al.), >> >> On 3/12/2014 2:47 PM, Stephen Kent wrote: >> ... >>>> Is there a reason not to just call unauthenticated key exchange what >>>> it is - unauthenticated key exchange? >>> I think we want more than that, as I described above, hence the desire >>> to coin a new term. >> >> No disagreement; there seems to be a need then for two terms: >> >> 1. unauthenticated key exchange/use > Yes, we could refer to this as unauthenticated or anonymous. Agreed on unauthenticated. Anonymous is a little more complex - it could be inferred as providing anonymity, and proving that is a lot harder. >> 2. security that uses authentication when available, >> but allows unauthenticated methods as a backup >> >> Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity to >> 'zero-touch' was intentional), and the second "zero-ID fallback". > > As I noted earlier, I'm not wedded to using the term "opportunistic" or > even "optimistic" but > I can't say that "zero-*" conveys the intent to me. It depends on what you think the intent is ;-) If it's avoiding identities, zero-ID is fairly direct. If it's fallback that starts with IDs, then the more accurate term might be: zero-ID fallback This has the advantage of a pithy acronym (ZIF). >> I'm not wed to either term, but "opportunistic" doesn't seem useful >> because OE seems to me a lot more like "use this key and hope it >> works", which isn't part of either case above. > > In Michael's RFC, OE isn't a "hope it works" method. It's a combination > of two things: > - agreeing to establish an authenticated SA with a peer > irrespective of SPD entries > - using the DNS as a way to acquire the public key for the > responder, preferably via DNSSEC The "hope it works" part is the use of the DNS to get the keying info rather than the endpoint. The endpoint ID may have changed; rather than verifying that in advance, OE just uses what it finds. The default is to expect that it works - that's the "hopeful" part, IMO. But ZIF ;-) is more about the fallback than the expectation that the first method - whatever it is - works. Joe From nobody Thu Mar 13 08:37:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1073A1A09A3 for ; Thu, 13 Mar 2014 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 nOusB_xXxyCA for ; Thu, 13 Mar 2014 08:37:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 51B241A08ED for ; Thu, 13 Mar 2014 08:37:39 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7E53893C2A2; Thu, 13 Mar 2014 15:37:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5321CFA5.7080702@isi.edu> Date: Thu, 13 Mar 2014 16:37:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ptezmXl6hGt3fRvXyru2qprdy60 Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:37:45 -0000 On 13 Mar 2014, at 16:32, Joe Touch wrote: >=20 >=20 > On 3/13/2014 6:33 AM, Stephen Kent wrote: >> Joe, >>=20 >>> Steve (et al.), >>>=20 >>> On 3/12/2014 2:47 PM, Stephen Kent wrote: >>> ... >>>>> Is there a reason not to just call unauthenticated key exchange = what >>>>> it is - unauthenticated key exchange? >>>> I think we want more than that, as I described above, hence the = desire >>>> to coin a new term. >>>=20 >>> No disagreement; there seems to be a need then for two terms: >>>=20 >>> 1. unauthenticated key exchange/use >> Yes, we could refer to this as unauthenticated or anonymous. >=20 > Agreed on unauthenticated. >=20 > Anonymous is a little more complex - it could be inferred as providing = anonymity, and proving that is a lot harder. >=20 >>> 2. security that uses authentication when available, >>> but allows unauthenticated methods as a backup >>>=20 >>> Personally, I'd call the first "zero-ID" (yes, FWIW, the similarity = to >>> 'zero-touch' was intentional), and the second "zero-ID fallback". > > >> As I noted earlier, I'm not wedded to using the term "opportunistic" = or >> even "optimistic" but >> I can't say that "zero-*" conveys the intent to me. >=20 > It depends on what you think the intent is ;-) >=20 > If it's avoiding identities, zero-ID is fairly direct. >=20 > If it's fallback that starts with IDs, then the more accurate term = might be: >=20 > zero-ID fallback >=20 > This has the advantage of a pithy acronym (ZIF). >=20 >>> I'm not wed to either term, but "opportunistic" doesn't seem useful >>> because OE seems to me a lot more like "use this key and hope it >>> works", which isn't part of either case above. > > >> In Michael's RFC, OE isn't a "hope it works" method. It's a = combination >> of two things: >> - agreeing to establish an authenticated SA with a peer >> irrespective of SPD entries >> - using the DNS as a way to acquire the public key for the >> responder, preferably via DNSSEC >=20 > The "hope it works" part is the use of the DNS to get the keying info = rather than the endpoint. The endpoint ID may have changed; rather than = verifying that in advance, OE just uses what it finds. The default is to = expect that it works - that's the "hopeful" part, IMO. >=20 > But ZIF ;-) is more about the fallback than the expectation that the = first method - whatever it is - works. Zero-ID is one thing we do, but it is not the goal. The goal is more = encryption in an opportunistic way. I think Zero-ID is too far down the stack to use as a marketing term. = It's catchy though. A good name for OTR. :-) /O From nobody Thu Mar 13 08:58:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF81A0A18 for ; Thu, 13 Mar 2014 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 hlHTo16cpj-i for ; Thu, 13 Mar 2014 08:58:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B56C31A073C for ; Thu, 13 Mar 2014 08:58:46 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DFv1I6014948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 08:57:14 -0700 (PDT) Message-ID: <5321D550.9090407@isi.edu> Date: Thu, 13 Mar 2014 08:57:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> In-Reply-To: <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/s20wi3BsNCMYQlIXLmhSg0VCCaQ Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 15:58:50 -0000 On 3/13/2014 8:37 AM, Olle E. Johansson wrote: > Zero-ID is one thing we do, but it is not the goal. The goal is more encryption in an opportunistic way. Again, we're back to "what does 'opportunistic' mean"? Is it: - using keys before they're confirmed (this is how I think of OE) - having a fallback (lots of security protocols do this) - involving a method that doesn't use identities (this is what I proposed as Zero-ID) - involving a method that is anonymous this requires a lot more rigor to show not only a lack of traceability to a given ID, but also lack of traceability to prior uses without an ID - having a fallback that (in specific) doesn't use identities (IMO this is ZIF - Zero-ID fallback) Of the above, IMO OE applies only to the first; I don't think there's anything 'opportunistic' (either in the sense of the English word, or in the sense of prior OE RFCs) about either of the latter. Joe From nobody Thu Mar 13 09:00:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EB41A0873 for ; Thu, 13 Mar 2014 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 YXNiiu1O8XIv for ; Thu, 13 Mar 2014 09:00:44 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9938B1A073C for ; Thu, 13 Mar 2014 09:00:42 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id EEEAC93C2A1; Thu, 13 Mar 2014 16:00:35 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5321D550.9090407@isi.edu> Date: Thu, 13 Mar 2014 17:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ldK-njfu2LgNnKjB29Ny-wQiMyA Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:00:46 -0000 On 13 Mar 2014, at 16:57, Joe Touch wrote: >=20 >=20 > On 3/13/2014 8:37 AM, Olle E. Johansson wrote: >> Zero-ID is one thing we do, but it is not the goal. The goal is more = encryption in an opportunistic way. >=20 > Again, we're back to "what does 'opportunistic' mean"? If I am acting as the marketeer, I would say all of the below mentioned = (and a few more). I would (with my simple marketing way of thinking) just group "all the sessions = that previously was not encrypted and can be without reconfiguration or user action" as = opportunistic. You see, it's fun to be in marketing. Come join the dark side! /O >=20 > Is it: >=20 > - using keys before they're confirmed > (this is how I think of OE) >=20 > - having a fallback > (lots of security protocols do this) >=20 > - involving a method that doesn't use identities > (this is what I proposed as Zero-ID) >=20 > - involving a method that is anonymous > this requires a lot more rigor to show > not only a lack of traceability to a > given ID, but also lack of traceability > to prior uses without an ID >=20 > - having a fallback that (in specific) doesn't use identities > (IMO this is ZIF - Zero-ID fallback) >=20 > Of the above, IMO OE applies only to the first; I don't think there's = anything 'opportunistic' (either in the sense of the English word, or in = the sense of prior OE RFCs) about either of the latter. >=20 > Joe From nobody Thu Mar 13 09:05:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2C1A09F0 for ; Thu, 13 Mar 2014 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgEmL26VbVhw for ; Thu, 13 Mar 2014 09:05:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A53161A088B for ; Thu, 13 Mar 2014 09:05:15 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2DG578F084108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Mar 2014 09:05:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5321CA5E.5010303@cs.tcd.ie> Date: Thu, 13 Mar 2014 09:05:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> To: saag X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/56elQjR7GFY34B3c4daIQ0NijUs Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:05:16 -0000 On Mar 13, 2014, at 8:10 AM, Stephen Farrell = wrote: > So if we had a draft that defined good/new/precise terms (e.g. OK), > and that included the above text in its intro, and that had some > text about the history (4322 etc), would that sound like a plan > to folks? Not to me. The "precise" terms such as OK is a distinction that will = water down what we are trying to do. I would much prefer that we focus = on the term people are already using, give it a general direction like = Olle gave and a mediumly-precise definition that could be used across = all protocols, and then give examples of its use in current usage (TLS = and IPsec), saying that precise definitions might later be added in = other RFCs. This will give people some possible excitement about doing = the work instead of arguing about new terms. --Paul Hoffman= From nobody Thu Mar 13 09:08:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C061A09F7 for ; Thu, 13 Mar 2014 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 2Iy_G74qSFBV for ; Thu, 13 Mar 2014 09:08:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D91451A0A11 for ; Thu, 13 Mar 2014 09:08:42 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 58F1A93C2A1; Thu, 13 Mar 2014 16:08:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> Date: Thu, 13 Mar 2014 17:08:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42BCE5CF-C63C-4CB8-8996-2BB3E54F9069@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VVdN28tskmCbHel3zVqJSy1w_kg Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:08:44 -0000 On 13 Mar 2014, at 17:05, Paul Hoffman wrote: > On Mar 13, 2014, at 8:10 AM, Stephen Farrell = wrote: >=20 >> So if we had a draft that defined good/new/precise terms (e.g. OK), >> and that included the above text in its intro, and that had some >> text about the history (4322 etc), would that sound like a plan >> to folks? >=20 > Not to me. The "precise" terms such as OK is a distinction that will = water down what we are trying to do. I would much prefer that we focus = on the term people are already using, give it a general direction like = Olle gave and a mediumly-precise definition that could be used across = all protocols, and then give examples of its use in current usage (TLS = and IPsec), saying that precise definitions might later be added in = other RFCs. This will give people some possible excitement about doing = the work instead of arguing about new terms. And with all of us and all the protocols and communication methods we = have, defining a COMPLETE and EXACT terminology will take a lot of time. = There's an urgency here too that we should not forget. =46rom the emails we have seen today, I think we have very good input = with a lot of examples on what can be included under the generic = "marketing term" umbrella, examples ranging from SIP and HTTP to IPsec. /O= From nobody Thu Mar 13 09:15:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E651A08ED for ; Thu, 13 Mar 2014 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 jC2L9caogK-n for ; Thu, 13 Mar 2014 09:15:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B79771A0A1E for ; Thu, 13 Mar 2014 09:15:18 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DGDxva004253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 09:14:09 -0700 (PDT) Message-ID: <5321D94A.3020904@isi.edu> Date: Thu, 13 Mar 2014 09:14:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zM2xNNXStFsT3KUNWS6i7PJS890 Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:15:20 -0000 On 3/13/2014 9:00 AM, Olle E. Johansson wrote: > > On 13 Mar 2014, at 16:57, Joe Touch wrote: > >> >> >> On 3/13/2014 8:37 AM, Olle E. Johansson wrote: >>> Zero-ID is one thing we do, but it is not the goal. The goal is more encryption in an opportunistic way. >> >> Again, we're back to "what does 'opportunistic' mean"? > > If I am acting as the marketeer, I would say all of the below mentioned (and a few more). I would > (with my simple marketing way of thinking) just group "all the sessions that previously was not > encrypted and can be without reconfiguration or user action" as opportunistic. Nothing new is going to work without reconfiguration (i.e., use of a new protocol or mode at least). If I start with your definition, I would never guess "opportunistic" as applying, but I would guess "zero-touch" -- what you're describing is they ID management equivalent of network configuration. Joe From nobody Thu Mar 13 09:16:42 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9CD1A08ED for ; Thu, 13 Mar 2014 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0jf5yAjChAN for ; Thu, 13 Mar 2014 09:16:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF41A073C for ; Thu, 13 Mar 2014 09:16:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6DFE52AB22D; Thu, 13 Mar 2014 16:16:30 +0000 (UTC) Date: Thu, 13 Mar 2014 16:16:30 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140313161630.GM21390@mournblade.imrryr.org> References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5321D550.9090407@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CUOX5z5RM-mky0qkLa74hIbrzZc Subject: Re: [saag] [dane] Need better opportunistic terminology 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: Thu, 13 Mar 2014 16:16:39 -0000 On Thu, Mar 13, 2014 at 08:57:04AM -0700, Joe Touch wrote: > Again, we're back to "what does 'opportunistic' mean"? It is an adjective that modifies a noun. The meaning depends on the noun to which it is prepended. The best we can hope for is sane guidance on when this is an appropriate adjective. To me "opportunistic foo" is "foo, when possible", because "foo" is deployed incrementally, and while one would prefer to use "foo" with all destinations, many or most may not yet support "foo". To Tony's point, one could sometimes take the view that this is mere negotiation of features, but when the feature in question is the use vs. not use of a security protocol, rather than say choosing between AES and RC4, I think it deserves a name. The fact that things like "opportunistic TLS" also brush aside authentication is a secondary feature. When you're not even sure the server supports TLS, and are willing to send in the clear, authentication is a luxury. Sometimes some form of authentication is still possible with opportunistic modes, (with SMTP reasonably strong with DANE, none for simple opportunistic TLS) and sometimes it is not. Anyway, you may disagree with the specifics of my interpretation, but I hope most will agree with the higher level viewpoint that we should not attempt to define "opportunistic" as a noun is sound. -- Viktor. From nobody Thu Mar 13 09:17:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BA11A0873 for ; Thu, 13 Mar 2014 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 tIOu9BX2f_zN for ; Thu, 13 Mar 2014 09:17:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B91AA1A073C for ; Thu, 13 Mar 2014 09:17:54 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C068D93C2A2; Thu, 13 Mar 2014 16:17:47 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5321D94A.3020904@isi.edu> Date: Thu, 13 Mar 2014 17:17:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05A2B5A2-589B-45E7-AE0A-56CD7166979D@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <5321D94A.3020904@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DQpe67Cel9Y_UeLiOipPB7FG56U Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:17:56 -0000 On 13 Mar 2014, at 17:14, Joe Touch wrote: >=20 >=20 > On 3/13/2014 9:00 AM, Olle E. Johansson wrote: >>=20 >> On 13 Mar 2014, at 16:57, Joe Touch wrote: >>=20 >>>=20 >>>=20 >>> On 3/13/2014 8:37 AM, Olle E. Johansson wrote: >>>> Zero-ID is one thing we do, but it is not the goal. The goal is = more encryption in an opportunistic way. >>>=20 >>> Again, we're back to "what does 'opportunistic' mean"? > > >> If I am acting as the marketeer, I would say all of the below = mentioned (and a few more). I would >> (with my simple marketing way of thinking) just group "all the = sessions that previously was not >> encrypted and can be without reconfiguration or user action" as = opportunistic. >=20 > Nothing new is going to work without reconfiguration (i.e., use of a = new protocol or mode at least). SIP will work. We can - without changing a single row in the RFCs - = change our software to prefer TLS sessions. That's encrypting sessions that previously was not. No = reconfiguration, just update software and run as before. After that we need to convince server admins = to activate more TLS listeners... >=20 > If I start with your definition, I would never guess "opportunistic" = as applying, but I would guess "zero-touch" -- what you're describing is = they ID management equivalent of network configuration. Maybe.=20 /O= From nobody Thu Mar 13 09:19:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79151A0A1B; Thu, 13 Mar 2014 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 Wyzgh94RZSi1; Thu, 13 Mar 2014 09:19:21 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB31A073C; Thu, 13 Mar 2014 09:19:21 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 088562003B; Thu, 13 Mar 2014 13:38:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 51E16647C9; Thu, 13 Mar 2014 12:19:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D3E764655; Thu, 13 Mar 2014 12:19:13 -0400 (EDT) From: Michael Richardson To: saag , uta@ietf.org In-Reply-To: <42BCE5CF-C63C-4CB8-8996-2BB3E54F9069@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> <42BCE5CF-C63C-4CB8-8996-2BB3E54F9069@edvina.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Nt3bV8MbpnCYlcVoLhJnu6cwOwA Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:19:23 -0000 --=-=-= Let's please start with the protocol(s) and/or mechanism(s). ("running-code") Let them be described precisely, and the terminology can flow. Let's ban "opportunistic" from being a term of precision. If we find that we have general terms, then will flow *afterwards*, not before. So, I'd like to have an ID (Informational, vendor-proprietary, like 4322) document from the postfix authors on what *exactly* they do. If UTA wants to adopt 2.0 of that, great. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyHagYqHRg3pndX9AQLDBwP8DtWbz1m8hF9jhAh79JBbDtz8Sm0mNhsZ fzG6bmwU6A0UuiIhGaDLXEp0mLSbtm9UXrgBCgpbgNE/rO4rcprcB/4eNSFjfNO7 A8YhaPWoNreWqpH3tSyzk0Zxe99RtYNabVy6RHDfm/yEIVt4EVj6a0JtXiR2s+Xe +c6XPJ2yOMw= =vpc8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 13 09:21:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279051A0A1E for ; Thu, 13 Mar 2014 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 nLYQCiLwUJSF for ; Thu, 13 Mar 2014 09:21:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA221A0A27 for ; Thu, 13 Mar 2014 09:21:16 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1441C93C2A1; Thu, 13 Mar 2014 16:21:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <20140313161630.GM21390@mournblade.imrryr.org> Date: Thu, 13 Mar 2014 17:21:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <20140313161630.GM21390@mournblade.imrryr.org> To: saag@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/X_TelM2abvfD7hP5QzBOCTj1w1M Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:21:19 -0000 On 13 Mar 2014, at 17:16, Viktor Dukhovni wrote: > On Thu, Mar 13, 2014 at 08:57:04AM -0700, Joe Touch wrote: > >> Again, we're back to "what does 'opportunistic' mean"? > > It is an adjective that modifies a noun. The meaning depends on > the noun to which it is prepended. The best we can hope for is > sane guidance on when this is an appropriate adjective. > > To me "opportunistic foo" is "foo, when possible", because "foo" > is deployed incrementally, and while one would prefer to use "foo" > with all destinations, many or most may not yet support "foo". > > To Tony's point, one could sometimes take the view that this is > mere negotiation of features, but when the feature in question is > the use vs. not use of a security protocol, rather than say choosing > between AES and RC4, I think it deserves a name. > > The fact that things like "opportunistic TLS" also brush aside > authentication is a secondary feature. When you're not even > sure the server supports TLS, and are willing to send in the > clear, authentication is a luxury. > > Sometimes some form of authentication is still possible with > opportunistic modes, (with SMTP reasonably strong with DANE, none > for simple opportunistic TLS) and sometimes it is not. > > Anyway, you may disagree with the specifics of my interpretation, > but I hope most will agree with the higher level viewpoint that we > should not attempt to define "opportunistic" as a noun is sound. I think Wikipedia made the decision for us. (and no, I'm not involved) http://en.wikipedia.org/wiki/Opportunistic_encryption /O From nobody Thu Mar 13 09:49:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2791A0A47 for ; Thu, 13 Mar 2014 09:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=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 tVm649iqn3kW for ; Thu, 13 Mar 2014 09:49:26 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7A1A0A3C for ; Thu, 13 Mar 2014 09:49:18 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05A6D2003B; Thu, 13 Mar 2014 14:08:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1EEFB647C9; Thu, 13 Mar 2014 12:49:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0BCD064655; Thu, 13 Mar 2014 12:49:12 -0400 (EDT) From: Michael Richardson To: Joe Touch In-Reply-To: <5321D94A.3020904@isi.edu> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <5321D94A.3020904@isi.edu> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Kn6chSXZiDdxizw1DsI2Swp_3rI Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 16:49:28 -0000 --=-=-= Joe Touch wrote: >>> Again, we're back to "what does 'opportunistic' mean"? >> If I am acting as the marketeer, I would say all of the below mentioned (and a few more). I would >> (with my simple marketing way of thinking) just group "all the sessions that previously was not >> encrypted and can be without reconfiguration or user action" as opportunistic. > Nothing new is going to work without reconfiguration (i.e., use of a new > protocol or mode at least). yes/no. the question isn't whether it can happen without (re)configuration. The question is whether it can happen without *coordination*. If I can just turn it on at my and "hope" for the fax effect, then it's what we want. In this sense, "optimistic encryption" is a rather good way to describe the philosophy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyHhh4qHRg3pndX9AQL+xgP7BWShM1R3BxYBMHa3hKHQc371ih1R3dPx x0QN1yxyxJAhnOvnuwhKCA760iMddPh2E462/vGE2/4z5jgSVOeNnFbQ0Trttn8D xpUTnu7LcdXp5QU1aSY6eyAr1ZctjwqzCsv1d52vu545V5Gadw0OgYzuryjBUdu8 aXnPdWUfj1c= =E27Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 13 10:46:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1DC1A0A16 for ; Thu, 13 Mar 2014 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 AC2iv4wCcH8D for ; Thu, 13 Mar 2014 10:46:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE141A0A0F for ; Thu, 13 Mar 2014 10:46:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2DHie6E019830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 10:44:42 -0700 (PDT) Message-ID: <5321EE88.7050606@isi.edu> Date: Thu, 13 Mar 2014 10:44:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <5321D94A.3020904@isi.edu> <05A2B5A2-589B-45E7-AE0A-56CD7166979D@edvina.net> In-Reply-To: <05A2B5A2-589B-45E7-AE0A-56CD7166979D@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4AE45YP9jqHFG9H6N1hybtgOYXU Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 17:46:14 -0000 On 3/13/2014 9:17 AM, Olle E. Johansson wrote: > > On 13 Mar 2014, at 17:14, Joe Touch wrote: ... >> Nothing new is going to work without reconfiguration (i.e., use of a new protocol or mode at least). > > SIP will work. We can - without changing a single row in the RFCs - change our software to prefer > TLS sessions. Until you change the software, nothing will work. > That's encrypting sessions that previously was not. No reconfiguration, Changing defaults IS reconfiguration. It's not custom to each machine, but it's a change. Joe From nobody Thu Mar 13 10:55:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781471A0A23 for ; Thu, 13 Mar 2014 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 xm_1lvpHk72G for ; Thu, 13 Mar 2014 10:55:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EA1A0A0F for ; Thu, 13 Mar 2014 10:55:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2DHt6Ee022180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 10:55:06 -0700 (PDT) Message-ID: <5321F0FA.7030101@isi.edu> Date: Thu, 13 Mar 2014 10:55:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <5321D94A.3020904@isi.edu> <30807.1394729352@sandelman.ca> In-Reply-To: <30807.1394729352@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vdhg14Qsivzqc_woVhFaRZ-tizk Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 17:55:52 -0000 On 3/13/2014 9:49 AM, Michael Richardson wrote: > > Joe Touch wrote: > >>> Again, we're back to "what does 'opportunistic' mean"? > > >> If I am acting as the marketeer, I would say all of the below mentioned (and a few more). I would > >> (with my simple marketing way of thinking) just group "all the sessions that previously was not > >> encrypted and can be without reconfiguration or user action" as opportunistic. > > > Nothing new is going to work without reconfiguration (i.e., use of a new > > protocol or mode at least). > > yes/no. > the question isn't whether it can happen without (re)configuration. > > The question is whether it can happen without *coordination*. Without per-endpoint (or endpoint-specific) (re)configuration. > If I can just > turn it on at my and "hope" for the fax effect, then it's what we want. > > In this sense, "optimistic encryption" is a rather good way to describe the philosophy. It really isn't. OE was truly opportunistic in a few ways: - pre-deploying IDs in the DNS - using those IDs before they were confirmed between ends Unauthenticated keying is not opportunistic in any sense of the term - English or RFC. When I brought the concept to the IETF, I called it "AnonSec", which later was called "BTNS": http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt The point of AnonSec was to avoid the need to deploy IDs or to make any "opportunistic" guess as to what might work. That's exactly the sense in which it's used here. --- So a good term depends on what we consider the important features: - avoiding IDs anonymous or zero-ID - opportunistic but there's no 'opportunistic' aspect to what I've seen discussed so far - fall-back which doesn't seem as notable as whether the 'last resort' is something you "hope" will work (OE) or something you *know* will work (anonymous/zero-ID) - avoiding per-endpoint configuration either at the endpoint or in the network the rest of the community - commercial and RFC - calls this "zero-config" or "zero-touch" I agree we don't need to create a completely new and unfamiliar term, but let's please not apply one that is incorrect just because it's familiar. Joe From nobody Thu Mar 13 11:04:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4951A0A45 for ; Thu, 13 Mar 2014 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 Al6mD7EB4I1K for ; Thu, 13 Mar 2014 11:04:41 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id B704E1A0A56 for ; Thu, 13 Mar 2014 11:04:40 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2DI4VOE029719; Thu, 13 Mar 2014 11:04:31 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1jjhtdqpaa-9 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Mar 2014 11:04:31 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 13 Mar 2014 11:04:28 -0700 From: Paul Lambert To: Stephen Kent , saag Date: Thu, 13 Mar 2014 11:04:25 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac8+5qxXDxyaq+QET4O5bjSqSnb+SQ== Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5321BD64.4050609@bbn.com> In-Reply-To: <5321BD64.4050609@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-13_07:2014-03-13,2014-03-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-1305240000 definitions=main-1403130096 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/a0OZwuTCc0IFnMS3fDz8g7gNZ80 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 18:04:43 -0000 U3RldmUsDQoNCk9uIDMvMTMvMTQsIDc6MTUgQU0sICJTdGVwaGVuIEtlbnQiIDxrZW50QGJibi5j b20+IHdyb3RlOg0KDQo+UGF1bCwNCj4+DQo+PiBPbiAzLzEyLzE0LCAyOjQ3IFBNLCAiU3RlcGhl biBLZW50IiA8a2VudEBiYm4uY29tPiB3cm90ZToNCj4+DQo+Pj4gSm9lLA0KPj4+Pj4geWVhaCwg SSBsaWtlIE9LIChhbmQgSSBsaWtlIElLRSB0b28sIGZvciB0aG9zZSBvZiB1cyBvbGQgZW5vdWdo IHRvDQo+Pj4+PiBhcHByZWNpYXRlIHRoYXQgZWxlY3Rpb24gc2xvZ2FuKQ0KPj4+PiBJJ20gc3Rp bGwgYSBsaXR0bGUgaGVzaXRhbnQsIHRoaW5raW5nIG9uIGl0IGZ1cnRoZXIsIGFib3V0IHRoZSB0 ZXJtDQo+Pj4+ICJvcHBvcnR1bmlzdGljIiBpbiB0aGlzIHNlbnNlIGF0IGFsbC4NCj4+Pj4NCj4+ Pj4gQlROUyB1c2VzIHVuc2lnbmVkIGtleSBleGNoYW5nZWQsIGFuZCB0aGVyZSdzIG5vdGhpbmcg Im9wcG9ydHVuaXN0aWMiDQo+Pj4+IGFib3V0IGl0LiBVbnNpZ25lZCBhdXRoZW50aWNhdGlvbiBp cyB0aGUgZ29hbCBmcm9tIHRoZSBzdGFydC4NCj4+Pj4NCj4+Pj4gT0UgYXMgZGVmaW5lZCBpbiBS RkMgNDMyMiBpc24ndCBhYm91dCB1c2luZyB1bnNpZ25lZCBrZXkgZXhjaGFuZ2U7IHRoZQ0KPj4+ PiAib3Bwb3J0dW5pc3RpYyIgc2Vuc2UgaXMgZGVyaXZlZCBmcm9tIHVzaW5nIGtleXMgcmV0cmll dmVkIGZyb20gRE5TDQo+Pj4+IHdpdGhvdXQgcHJpb3IgYWdyZWVtZW50LiBUaGF0J3Mgbm90IHdo YXQgaGFwcGVucyBpbiBCVE5TLg0KPj4+IGFncmVlZC4NCj4+Pj4gUGF1bCBqdXN0IG5vdGVkOg0K Pj4+PiAiT3Bwb3J0dW5pc3RpYyBrZXlpbmcgZG9lcyBwcm92aWRlIGF1dGhlbnRpY2F0aW9uLCBp dCdzIGp1c3QgdGhhdA0KPj4+PiB0aGUgYXV0aGVudGljYXRpb24gaXMgb25seSB0byB0aGUgcHVi bGljIGtleSBhbmQgaXMgbm90DQo+Pj4+IHRpZ2h0bHkgYm91bmQgdG8gYW55IG90aGVyIHR5cGUg b2YgaWRlbnRpZmljYXRpb24gKGFkZHJlc3MsIG5hbWUsDQo+Pj4+ZXRjLikiDQo+Pj4gUHVibGlj IGtleXMgYXJlIG5vdCBwcmluY2lwbGVzLiBXZSB3ZW50IHRocm91Z2ggdGhhdCBsb25nIGFuZCBw YWluZnVsDQo+Pj4gZGlzY3Vzc2lvbg0KPj4+IGR1cmluZyB0aGUgU1BLSSBkYXlzLg0KPj4gWW91 ciBsZXZlbCBvZiBwYWluIGluIGEgZGlzY3Vzc2lvbiBpcyBub3QgYSBtZWFzdXJlIG9mIGEgY29u Y2VwdHMNCj4+dmFsaWRpdHkNCj4+IDotKQ0KPnRydWUsIGJ1dCB0aGUgaWRlYSB0aGF0IGEgcHVi bGljIGtleSBpcyBhIHByaW5jaXBhbCBpcyBsb25nIGRlYWQuDQoNClBlcmhhcHMgaW4geW91ciB3 b3JsZCB2aWV3IG9mIHB1YmxpYyBrZXkgYXJjaGl0ZWN0dXJlcy4gSSBzdXNwZWN0IHlvdSBtYXkN CmFsc28gb3BlbiB5b3VyIGVnZ3Mgb24gdGhlIGxhcmdlIGVuZC4NCg0KVGhlIGRvZ21hdGljIGRl ZmluaXRpb24gb2YgYSDigJhwcmluY2lwYWzigJkgaXMgbm90IHRoZSBwb2ludCBhbmQgd2UgbWF5 IG5ldmVyDQpyZWFjaCBhZ3JlZW1lbnQgb24gc3VjaCBkZWZpbml0aW9ucyB3aGVuIHRoZXJlIGFy ZSB0d28gZHVhbCBidXQgdmlhYmxlDQp3b3JsZCB2aWV3cy4gIFVuaXF1ZSBpZGVudGlmaWVycyBt YXkgYmUgYXNzaWduZWQgdG8gYSBrZXkgYnkgYW4gYXV0aG9yaXR5DQooZS5nLiBDQSBhbmQgbmFt ZS9pZGVudGlmaWVyIGNlbnRyaWMpIOKApiBvciBhIHVuaXF1ZSBrZXkgbWF5IGhhdmUNCmF0dHJp YnV0ZXMgYXNzaWduZWQgdG8gaXQgYnkgYW4gYXV0aG9yaXR5Lg0KDQpNeSBwcmVmZXJlbmNlIGlz IHRvIHVzZSBhIHB1YmxpYyBrZXkgYXMgYSB1bmlxdWUgaWRlbnRpZmllciBvZiBhDQpwcmluY2lw YWwuICBQdWJsaWMga2V5cyBhcmUgdW5pcXVlIGFuZCBkbyBub3QgcmVxdWlyZSBhIHRoaXJkIHBh cnR5IHRvDQpjb29yZGluYXRlIHRoZSB1bmlxdWVuZXNzIG9mIGEgbmFtZSBzcGFjZS4NCg0KVXNp bmcgYW55IG90aGVyIHVuaXF1ZSBpZGVudGlmaWVyIGZvciBhIHByaW5jaXBhbCB0eXBpY2FsbHkg cmVxdWlyZXMgYQ0KbmFtaW5nIGF1dGhvcml0eS4NCg0KDQo+PiBQdWJsaWMga2V5cyBhbmQgdGhl IGhhc2hlcyBvZiBwdWJsaWMga2V5cyBhcmUgdGhlIGZ1bmRhbWVudGFsIGlkZW50aWZpZXINCj4+ IG9mIGEgxZJwcmluY2lwYWzCuSB3aGVuIHdlIGFyZSB1c2luZyBwdWJsaWMga2V5IGJhc2VkIGF1 dGhlbnRpY2F0aW9uLiBUaGUNCj4+IHByaW5jaXBhbCBpcyB0aGUgZW5kIHVzZXIgb3IgY29tcHV0 ZXIgdGhhdCBjb250cm9scyB0aGUgdXNlIG9mIHRoZQ0KPj5wdWJsaWMNCj4+IGtleS4gIFRoZSBw dWJsaWMga2V5IGlzIGF1dGhlbnRpY2F0ZWQgaW4gYSBrZXkgZXhjaGFuZ2Ugb3Igc2lnbmF0dXJl DQo+PiB2YWxpZGF0aW9uIHByb2Nlc3MgYW5kIGlzIHRoZSBwcmltYXJ5IGNvbm5lY3Rpb24gaW4g dGhlIHByb2Nlc3MgdG8gdGhlDQo+PmtleQ0KPj4gaG9sZGVyIChwcmluY2lwYWwpLiAgT3RoZXIg aW5mb3JtYXRpb24gbWF5IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUga2V5DQo+PiBsb2NhbGx5IG9y IHRocm91Z2ggYSB0cnVzdGVkIHBhdGggKG91dC1vZi1iYW5kLCBzaWduZWQsIGV0Yy4pIHRoYXQg Y2FuDQo+PmJlDQo+PiB1c2VkIGZvciBhdXRob3JpemF0aW9uIGRlY2lzaW9ucy4gIFRoZSBvdGhl ciBpbmZvcm1hdGlvbiBtYXkgZXZlbg0KPj5pbmNsdWRlDQo+PiBpbmZvcm1hdGlvbiBhc3NvY2lh dGVkIHdpdGggdGhlIGtleSBpbiBhIFguNTA5IG9yIG90aGVyIGZvcm0gb2YNCj4+IGNlcnRpZmlj YXRlLg0KPkluIGEgd29yZCwgbm8uIFdoZW4gYSBwdWJsaWMga2V5IGlzIHVzZWQgaW4gYSBjZXJ0 IGl0IGlzIGJvdW5kIHRvDQo+c29tZSBkYXRhLCB0eXBpY2FsbHkgZm9yIGF1dGhlbnRpY2F0aW9u IGFuZCBhY2Nlc3MgY29udHJvbC4NCg0KPiANClNvIHdoYXQuIEkgYW0gZGVzY3JpYmluZyB1c2Ug b2Yga2V5cyB3aXRob3V0IGNlcnRzIGFuZCBjZXJ0cyB3aXRob3V0DQp0cnVzdGVkIGJpbmRpbmdz LiAgV2hlbiBteSBicm93c2VyIGFza3MgbWUgdG8gbWFrZSBhbiBleGNlcHRpb24gZm9yIGENCmNl cnRpZmljYXRlIHRoZXJlIGlzIGFic29sdXRlbHkgbm8gdmFsdWUgaW4gYW55IG9mIHRoZSBpbmZv cm1hdGlvbiBpbiB0aGUNCmNlcnRpZmljYXRlLiAgVGhlIHBpbm5lZCBjZXJ0aWZpY2F0ZSBpcyBi aW5kaW5nIGEgdW5pcXVlIHB1YmxpYyBrZXkgdG8gYQ0Kc3BlY2lmaWMgdXNhZ2UuDQoNCldlIG5l ZWQgYXJjaGl0ZWN0dXJhbCBtb2RlbHMgZm9yIHNlY3VyaXR5IHRoYXQgd29yayB3aXRob3V0IGNl bnRyYWwgbmFtaW5nDQphdXRob3JpdGllcy4gIFguNTA5IHdhcyBjcmVhdGVkIGluIHRoZSA4MOKA mXMgYW5kIHRoZSB3b3JsZCBoYXMgY2hhbmdlZC4NClRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhh dCBtdXN0IHN1cHBvcnQgc3Ryb25nIGF1dGhlbnRpY2F0aW9uIGFuZA0KYXV0aG9yaXphdGlvbiB3 aXRob3V0IG5hbWluZyBhdXRob3JpdGllcy4NCg0KPlRoZSB1c3VhbA0KPm1vZGVsIGNhbGxzIGZv ciB0aGUgU3ViamVjdCBuYW1lIG9yIFNBTiAgdG8gaWRlbnRpZnkgdGhlIHByaW5jaXBhbC4gSW4N Cj5zb21lIGNhc2VzDQo+dGhlIGNlcnQgZnVuY3Rpb25zIGFzIGFuIGF1dGhvcml6YXRpb24gY3Jl ZGVudGlhbCwgYXMgaW4gdGhlIFJQS0kuIEluDQo+dGhhdCBjYXNlDQo+dGhlIHJlbGV2YW50IGRh dGEgaXMgdGhlIFJGQyAzNzc5IGV4dGVuc2lvbi4gV2UgZG9uJ3QgdmlldyB0aGUgcHVibGljDQo+ a2V5IGFzIHRoZQ0KPnByaW5jaXBhbCBpbiBhbnkgb2YgdGhlc2UgY2FzZXMuDQoNCldoYXQgZG8g eW91IG1lYW4gd2Ug4oCmICA6LSkNCg0KWWVzLCBJIGFncmVlIHRoYXQgdGhlIG1vZGVsIEkgZGVz Y3JpYmUgaXMgbm90IGFsaWduZWQgd2l0aCB0aGUNCmFyY2hpdGVjdHVyYWwgY29uY2VwdHMgZG9j dW1lbnRlZCBYLjUwOSBhbmQgdGhlIG1hbnkgcmVsYXRlZCBSRkNzLiAgSQ0KY29uc2lkZXIgdGhp cyBhIGZlYXR1cmUuICBXZSBhcmUgdXNpbmcgY2VydGlmaWNhdGVzIGluIG1hbnkgd2F5cyB0aGF0 DQp2aW9sYXRlIHRoZSBvcmlnaW5hbCB2aXNpb24gb2YgYSBzaW5nbGUgZGlyZWN0b3J5IHNlcnZp Y2UgaW4gdGhlIHNreS4gU2VsZg0Kc2lnbmVkIGNlcnRzLCBjZXJ0IHBpbm5pbmcsIGNlcnRpZmlj YXRlIHRyYW5zcGFyZW5jeSBhcmUgYWxsIGluZGljYXRpb25zDQp0aGF0IHRoZSBYLjUwOSBhcmNo aXRlY3R1cmUgbmVlZHMgcmVleGFtaW5hdGlvbi4NCg0KV2hpbGUgbm90IGFsaWduZWQsIHRoZSBw ZXJzcGVjdGl2ZSBvZiBhIGtleSBhcyBvbmUgdHlwZSBvZiBwcmluY2lwYWwNCmlkZW50aWZpZXIg Y2FuIGJlIG1hcHBlZCBjb25zaXN0ZW50bHkgaW50byB0aGUgdXNlIG9mIFguNTA5LiAgV2UgYXJl DQphbHJlYWR5IHBpbm5pbmcga2V5cyB3aGljaCBlZmZlY3RpdmVseSBpcyB1c2luZyB0aGUganVz dCB0aGUga2V5IGZvciBhDQpwYXJ0aWN1bGFyIGNvbnRleHQuDQoNClRoaXMgbWFwcGluZyB0byA1 MDkgaXMgcG9zc2libGUsIGJ1dCBhcyBtZW50aW9uZWQgYmVmb3JlIG15IGN1cnJlbnQNCnByb2pl Y3QgaXMgbm9uLTUwOSDigJhrZXkgY2VudHJpY+KAmSBzZWN1cml0eSBmb3IgY29uc3VtZXIgZXF1 aXBtZW50LiAgS2V5DQpiaW5kaW5nIGZvciBhIHBhcnRpY3VsYXIgY29udGV4dCBpcyBieSBhIGJv b3RzdHJhcHBpbmcgcHJvY2VzcyB0aGF0DQplbnJvbGxzIG9yIGlkZW50aWZpZXMgYSBwZWVyIGRl dmljZSB3aXRoIGhpZ2ggYXNzdXJhbmNlcy4gIFRoaXMgaXMNCnNvcnQtb2YtYSBUT0ZVKysuICBU aGlzIG1pZ2h0IGJlIGNvbnNpZGVyZWQgdGhlIHVwcGVyIGVuZCBvZiBhc3N1cmFuY2UgZm9yDQpP RS9PSyB3aGVyZSBsb2NhbCBvdXQtb2YtYmFuZCB2YWxpZGF0aW9uIG9mIHRoZSBwZWVyIGJpbmRz IHRoZSBrZXkgdG8gYQ0Kc3BlY2lmaWMgY29udGV4dC4NCg0KPk1vcmUgZ2VuZXJhbGx5LCBpZiB3 ZSBhcmUgdG8gdXNlDQo+ZXBoZW1lcmFsIGtleXMsDQo+YXMgc3VnZ2VzdGVkIGZvciBQRlMsIHRo ZW4gc2F5aW5nIHRoYXQgdGhlIGtleSBpcyB0aGUgcHJpbmNpcGFsIGlzDQo+c2lsbHksIGJlY2F1 c2UNCj50aGUga2V5IGNoYW5nZXMgZm9yIGVhY2ggbmV3IHNlc3Npb24uDQoNClB1cmUgZXBoZW1l cmFsIERIIGhhcyBubyBhdXRoZW50aWNhdGlvbiBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIHdoYXTi gJlzDQpjb25zaWRlcmVkIHRoZSDigJhwcmluY2lwYWzigJkuICBBdXRoZW50aWNhdGVkIGVwaGVt ZXJhbCBESCBoYXMgbXVsdGlwbGUNCnB1YmxpYyBrZXlzLiAgVGhlIGxvbmdlciB0ZXJtIHN0YXRp YyBrZXlzIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uDQoodHlwaWNhbGx5IGluIHRoZSBwYXN0IGNh cnJpZWQgaW4gYSBYLjUwOSBjZXJ0KSBhcmUgdGhlIOKAmHByaW5jaXBhbA0KaWRlbnRpZmllcuKA mSB0aGF0IEkgYW0gZGVzY3JpYmluZy4NCg0KVG8gYmUgbW9yZSBwcmVjaXNlLCB0aGUgcHVibGlj IGtleSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBzZXJ2ZXMgYXMgYQ0KdW5pcXVlIGlkZW50aWZp ZXIgZm9yIHRoZSBwdXJwb3NlIG9mIGNyZWF0aW5nIHNlY3VyaXR5IHBvbGljaWVzLiAgVGhpcw0K ZG9lcyBub3QgZXhjbHVkZSB0aGUgYXNzaWdubWVudCBvZiBvdGhlciBhdHRyaWJ1dGVzIHRoYXQg Y291bGQgYmUgdXNlZCB0bw0KZGVzY3JpYmUgb3RoZXIgdHlwZXMgb2YgaWRlbnRpZmllcyBvciBn cm91cCBtZW1iZXJzaGlwLg0KDQoNCj4+IFRoZSBwdWJsaWMga2V5IGFuZCBhc3NvY2lhdGVkIGtl eSBoYXNoIGZvciBhIHByaW5jaXBhbCBtYXkgY2hhbmdlLg0KPj4gQ2hhbmdpbmcga2V5cyBjb3Vs ZCBiZSB2aWV3ZWQgYXMgZWl0aGVyIGEgbmV3IGlkZW50aWZpZXIgZm9yIHRoZSBzYW1lDQo+PiBw cmluY2lwYWwgb3IgYSBuZXcgcHJpbmNpcGFsIHdpdGggdGhlIHNhbWUgYXNzb2NpYXRlZCBhdHRy aWJ1dGVzIGFzIGENCj4+IHByZXZpb3VzIHByaW5jaXBhbC4gIEVpdGhlciB3YXksIHRoZSBwdWJs aWMga2V5IChvciBoYXNoKSBpcyBhIHVuaXF1ZQ0KPj4gaWRlbnRpZmllciBvZiBhIHByaW5jaXBh bCB3aGljaCBjYW4gdGhlbiBiZSB1c2VmdWxseSBwcm9jZXNzZWQgaW4gYQ0KPj4gc2VjdXJpdHkg cG9saWN5Lg0KPm5vdCByZWFsbHkuIElmIGEga2V5IGNoYW5nZXMgdmVyeSBmcmVxdWVudGx5LCBh cyBpcyB0aGUgY2FzZSBmb3IgZXBoZW1lcmFsDQo+RC1ILCB0aGVuIG5vYm9keSB3b3VsZCB1c2Ug dGhlc2UgdmFsdWVzIGZvciBhY2Nlc3MgY29udHJvbCBwdXJwb3NlcywNCj5iZWNhdXNlDQo+bWFu YWdpbmcgY29uc3RhbnRseSBjaGFuZ2luZyBBQ0wgZW50cmllcyB3b3VsZCBpbmZlYXNpYmxlLg0K SG93IG9mdGVuIGRvIHlvdSBjaGFuZ2UgeW91ciBYLjUwOSBjZXJ0IHVzZWQgZm9yIGF1dGhlbnRp Y2F0aW9uPw0KDQpFcGhlbWVyYWwgdXNhZ2UgaXMgYSByZWQtaGVycmluZyBhbmQgaXJyZWxldmFu dC4gIE90aGVyIGludGVyZXN0aW5nIHVzYWdlcw0Kb2YgY2hhbmdpbmcgcHVibGljIGtleXMgaW4g REggZXhjaGFuZ2VzIHN0aWxsIGhhdmUgbm8gb3RoZXIg4oCYYXR0cmlidXRlc+KAmQ0KdG8gaWRl bnRpZnkgYSBwcmluY2lwYWwgYW5kIHdvdWxkIGJlIGJvdW5kIGluIGEgYWNjZXNzIGNvbnRyb2wg cG9saWN5IHRvDQp0aGUgb3JpZ2luYWwgaW50cm9kdWNpbmcga2V5Lg0KDQo+PiBUaGVyZSBhcmUg c2V2ZXJhbCB1c2FnZXMgb2YgwrNvcHBvcnR1bmlzdGljwrIgaW4gdGhpcyB0aHJlYWQuICBDbGVh cmx5IG5ldw0KPj4gdGVybXMgYXJlIG5lZWRlZC4gIEnCuW0gcHJpbWFyaWx5IGludGVyZXN0ZWQg aW4gxZJrZXlzIGFzIGlkZW50aWZpZXJzwrkNCj4+d2hlcmUNCj4+IGxvbmdlciB0ZXJtIGtleXMg YXJlIHVzZWQgdG8gaWRlbnRpZnkgcHJpbmNpcGFscy4gU2VjdXJpdHkgcG9saWNpZXMgYXJlDQo+ PiBidWlsdCBvbiBoYXNoZXMgb2Yga2V5cyBhbmQgb3B0aW9uYWxseSBvdGhlciBhc3NvY2lhdGVk IGluZm9ybWF0aW9uIHRoYXQNCj4+IG1heSBpbmNsdWRlIG5hbWVzLCBsYWJlbHMsIGdyb3VwIG1l bWJlcnNoaXAsIGV0Yy4NCj5UaGUgU1BLSSBXRyAgd291bGQgaGF2ZSBiZWVuIHRoZSByaWdodCBw bGFjZSB0byBwdXJzdWUgdGhpcyBpbnRlcmVzdCwNCj5idXQgaXQgZGllZCBvdmVyIGEgZGVjYWRl IGFnby4NClllcywgdGhlIHdvcmtpbmcgZ3JvdXAgYW5kIHNwZWNpZmljIHByb3RvY29sIGRpZWQu ICBJdCBsZWZ0IGJlaGluZCB2YWN1dW0NCmZvciBhIHdlbGwgZGVmaW5lZCBwdWJsaWMga2V5IGFy Y2hpdGVjdHVyZSB0aGFuIGlzIG5vdCBiYXNlZCBvbiBYLjUwOS4NClNQS0kgZGlkIGhhdmUgaXTi gJlzIG93biBsaW1pdGF0aW9ucyBhbmQgcHJvYmxlbXMuICBXZSBhcmUgbGVmdCBub3cgd2l0aCBh DQpsYWNrIG9mIGV2ZW4gdGhlIGJhc2ljIHRlcm1pbm9sb2d5IHRvIGRlc2NyaWJlIHRoZSBtZWNo YW5pc21zIHdlIGFyZQ0KYnVpbGRpbmcgKE9LLE9FLCBUT0hVLCB3aGF0ZXZlcikuICBUaGUgYWRh bWFuY3kgdG8gb25seSB1c2UgQ0EgaXNzdWVkDQpuYW1lcyBmb3Ig4oCYcHJpbmNpcGFsc+KAmSBs ZWF2ZXMgdXMgb25seSB3aXRoIGNlbnRyYWwgYXV0aG9yaXR5IGJhc2VkDQphcmNoaXRlY3R1cmVz Lg0KDQo+PiBUaGlzIG1heSBiZSBnZXR0aW5nIGEgbGl0dGxlIGZhciBhZmllbGQgb2YgdGhlIFRM Uy1EQU5FIG9yIElQc2VjDQo+PiBvcHBvcnR1bmlzdGljIHNwZWNpZmljIHVzYWdlLiAgU3RpbGws IHRoZSBkZWZlcnJlZCBiaW5kaW5nIGFuZCB0aGUgVE9GVQ0KPj4gbW9kZWwgYXJlIGNvbXBhdGli bGUgd2l0aCBhIHBlcnNwZWN0aXZlIG9mIGtleXMgYXMgaWRlbnRpZmllcnMgb2YNCj4+IHByaW5j aXBhbHMuDQo+VE9GVSBhc3N1bWVzIGFuIGFzc2VydGVkL2ltcGxpZWQgaWRlbnRpdHkgdGhhdCwg YXMgdGhlIG5hbWUgc3VnZ2VzdHMsIGlzDQo+dHJ1c3RlZA0KPmluaXRpYWxseSwgZGVzcGl0ZSB0 aGUgbGFjayBvZiBhICJoaWdoIHF1YWxpdHkiIGNyZWRlbnRpYWxzLiBUT0ZVIGlzDQo+bW90aXZh dGVkIGJ5DQo+YSB0aHJlYXQgbW9kZWwgaW4gd2hpY2ggYW4gYWR2ZXJzYXJ5IGlzIHVubGlrZWx5 IHRvIGJlIGFibGUgdG8gYWN0IGFzIGENCj5NaVRNIGZvcg0KPnRoZSBpbml0aWFsIGNyZWRlbnRp YWwgYWNxdWlzaXRpb24gQU5EIHJlbWFpbiBhcyBhIE1pVE0gZm9yIGV2ZXJ5DQo+c3Vic2VxdWVu dA0KPmNyeXB0by1wcm90ZWN0ZWQgc2Vzc2lvbi4gVGhhdCdzIGEgcHJldHR5IHJlYXNvbmFibGUg dGhyZWF0IG1vZGVsIGluDQo+bWFueSBjb250ZXh0cywNCj5lc3BlY2lhbGx5IHdpdGhpbiBhbiBl bnRlcnByaXNlIGVudmlyb25tZW50ICh3aGVyZSBTU0ggaXMgbW9zdCBvZnRlbg0KPnVzZWQpLiBT bywgSQ0KPmRpc2FncmVlIHRoYXQgVE9GVSBwb3NpdHMgdGhlIHB1YmxpYyBrZXkgYXMgYW4gSUQu DQoNClRoZSBhc3NlcnRlZCBvciBpbXBsaWVkIElkIG1heSBub3QgYmUgdW5pcXVlIG9yIG1lYW5p bmdmdWwgZm9yIGFueSBwdXJwb3NlDQpidXQgbG9jYWwgYWRtaW5pc3RyYXRpb24uICBUaGUgVE9G VSBtb2RlbCwgZnJvbSBteSB2aWV3IG9mIHRoZSBpZCBtb2RlbCwNCmlzIGEgZXhhbXBsZSBvZiBT UEtJLWxpa2UgbG9jYWwgbmFtaW5nLiAgVGhlIGltcGxpZWQgaWRlbnRpdHkgaXMgbG9jYWwgYW5k DQpjYW4gb25seSBiZSBzaGFyZWQgd2l0aCBvdGhlciBkZXZpY2VzIGluIHRoZSBjb250ZXh0IG9m IGl04oCZcyBvd24gdW5pcXVlDQpuYW1lIHNwYWNlIOKApiBvciBzaW1wbHkgYXMgdGhlIHVuaXF1 ZSBpZGVudGlmaWVyIGluaGVyZW50IGluIHRoZSBrZXkgaXTigJlzDQpzZWxmLiAgSW5mb3JtYXRp b24gYWJvdXQgdGhlIGtleSBjb3VsZCBjb21lIGZyb20gb3RoZXIgc291cmNlcyAoZS5nLiBEQU5F KQ0Kd2hpY2ggd291bGQgc3BlYWsgYWJvdXQgdGhlIGtleSBhbmQgcHJvdmlkZSBhIGJpbmRpbmcg dG8gYWRkaXRpb25hbA0KYXR0cmlidXRlcy4gICANCg0KDQo+Pj4gU28sIHNheWluZyB0aGF0IE9F IHByb3ZpZGUgYXV0aGVudGljYXRpb24gb2YgYSBrZXkNCj4+PiBzZWVtcw0KPj4+IG1lYW5pbmds ZXNzIHRvIG1lLCBlc3BlY2lhbGx5IGlmIHRoZSBrZXkgaXMgZXBoZW1lcmFsLg0KPj4gWWVzLCBl cGhlbWVyYWwga2V5cyBkbyBub3QgcHJvdmlkZSBhbnkgbG9uZyB0ZXJtIGlkZW50aXR5LiBUaGlz IGNhbiBhbHNvDQo+PiBiZSBhIGZlYXR1cmUuICBBIMWScHJpbmNpcGFsIGlkZW50aWZpZXLCuSB3 aXRoIG5vIGFzc29jaWF0ZWQgaW5mb3JtYXRpb24NCj4+IHdvdWxkIG9ubHkgYmUgYXV0aG9yaXpl ZCBmb3IgYWN0aW9ucyB0aGF0IGhhdmUgbm8gcmVzdHJpY3Rpb25zIG9uDQo+PnNwZWNpZmljDQo+ PiBwcmluY2lwYWxzLg0KPkFjY2VzcyBjb250cm9scyBkb24ndCB1c3VhbGx5IGZvY3VzIG9uIHdo YXQgYSBwcmluY2lwYWwgaXMgYXV0aG9yaXplZA0KPnRvIGRvIHdoZW4geW91IGNhbid0IGlkZW50 aWZ5IHRoZSBwcmluY2lwYWwuDQpNeSBleGFtcGxlIGlzIHNwZWNpZmljYWxseSB0aGF0IHRoZSBy ZW1vdGUgcHJpbmNpcGFsIGlzIGlkZW50aWZpZWQgYW5kDQphdXRoZW50aWNhdGVkLCBidXQgdW5r bm93bi4gIEkgc2hvdWxkIG5vdCBoYXZlIG1peGVkIHVzYWdlIG9mIGVwaGVtZXJhbA0KZm9yIHNo b3J0IHRlcm0gaWRlbnRpdHkgdmVyc3VzIFBGUyB1c2FnZSBpbiBhIHByb3RvY29sLg0KDQpQYXVs DQoNCg0KPg0KPlN0ZXZlDQoNCg== From nobody Thu Mar 13 11:05:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911F1A09F0 for ; Thu, 13 Mar 2014 11:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 4GKcH2hqpeLg for ; Thu, 13 Mar 2014 11:05:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF91A0969 for ; Thu, 13 Mar 2014 11:05:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2DI4j2Y024941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 11:04:45 -0700 (PDT) Message-ID: <5321F33D.7090806@isi.edu> Date: Thu, 13 Mar 2014 11:04:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <20140313161630.GM21390@mournblade.imrryr.org> In-Reply-To: <20140313161630.GM21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8K0xQyku7neB4QCIdTdkJnsp4zg Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 18:05:36 -0000 On 3/13/2014 9:16 AM, Viktor Dukhovni wrote: > On Thu, Mar 13, 2014 at 08:57:04AM -0700, Joe Touch wrote: > >> Again, we're back to "what does 'opportunistic' mean"? > > It is an adjective that modifies a noun. I was asking for a definition of the adjective, FWIW. > The meaning depends on > the noun to which it is prepended. Dictionaries include definitions for adjectives too, and only some of the meanings are context-dependent. I don't mind if you want to define the whole term OE or just the O part. ... > To me "opportunistic foo" is "foo, when possible", +1 > because "foo" > is deployed incrementally,... I don't think how 'foo' is deployed matters. It could be incrementally deployed, optionally available, or have a different priority in preference. > To Tony's point, one could sometimes take the view that this is > mere negotiation of features, but when the feature in question is > the use vs. not use of a security protocol, rather than say choosing > between AES and RC4, I think it deserves a name. Agreed - and the name depends on whether we're focusing on the negotiation part, the fallback part, or the specific approach that avoids the need for IDs. > The fact that things like "opportunistic TLS" also brush aside > authentication is a secondary feature. Maybe not... < When you're not even > sure the server supports TLS, and are willing to send in the > clear, authentication is a luxury. If you're a) willing to send in the clear b) willing to accept that when security is running you might still not be talking to who you think you are > Sometimes some form of authentication is still possible with > opportunistic modes, (with SMTP reasonably strong with DANE, none > for simple opportunistic TLS) and sometimes it is not. +1 I.e., the concept of "opportunistic" (as an adjective) is distinct from the particular variants considered. One of those variants is anonymous or zero-ID. (ZID?) Joe From nobody Thu Mar 13 11:07:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131751A0A0F for ; Thu, 13 Mar 2014 11:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 O5gbFXVtqG8i for ; Thu, 13 Mar 2014 11:07:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 50F301A0969 for ; Thu, 13 Mar 2014 11:07:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s2DI6jqZ025619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 11:06:45 -0700 (PDT) Message-ID: <5321F3B5.8020505@isi.edu> Date: Thu, 13 Mar 2014 11:06:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" , saag@ietf.org References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <20140313161630.GM21390@mournblade.imrryr.org> <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> In-Reply-To: <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Mk6Osd2p4UTLV2Hk0ZoeVcEjLzs Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 18:07:21 -0000 On 3/13/2014 9:21 AM, Olle E. Johansson wrote: > >... >> Anyway, you may disagree with the specifics of my interpretation, >> but I hope most will agree with the higher level viewpoint that we >> should not attempt to define "opportunistic" as a noun is sound. > > I think Wikipedia made the decision for us. (and no, I'm not involved) > http://en.wikipedia.org/wiki/Opportunistic_encryption No wikipedia page is known correct. That page at one time also listed BTNS as an example of OE. If there's something there you don't think is correct, edit it and make your case in the comment section of your edits. Joe From nobody Thu Mar 13 11:22:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419631A0492 for ; Thu, 13 Mar 2014 11:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Izr5Bm56dULH for ; Thu, 13 Mar 2014 11:22:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD61A0969 for ; Thu, 13 Mar 2014 11:22:02 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41561 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WOAGQ-0006kx-9f; Thu, 13 Mar 2014 14:21:54 -0400 Message-ID: <5321F741.1010208@bbn.com> Date: Thu, 13 Mar 2014 14:21:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" , saag References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <20140313161630.GM21390@mournblade.imrryr.org> <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> In-Reply-To: <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PTDEDU_nZ2-pHpZyTzpq0zCSsUE Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 18:22:04 -0000 Olle, Since , as you said, you're a marketing guy, let me caution you about viewing Wikipedia as a definitive source of info. In this case there are a number of errors in its article on OE. Kathleen (the new SEC AD) and I have been discussing how to fix it. Steve From nobody Thu Mar 13 11:22:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2C1A0A42 for ; Thu, 13 Mar 2014 11:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 6x6X3J4OaooT for ; Thu, 13 Mar 2014 11:22:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 83AB31A0A6C for ; Thu, 13 Mar 2014 11:22:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45706 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WOAHC-000OZ3-Iz for saag@ietf.org; Thu, 13 Mar 2014 14:22:42 -0400 Message-ID: <5321F76B.2020703@bbn.com> Date: Thu, 13 Mar 2014 14:22:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> In-Reply-To: <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/K8-ER5tyO16NzJM3C2X-g6e9n10 Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 18:22:49 -0000 Paul > On Mar 13, 2014, at 8:10 AM, Stephen Farrell wrote: > >> So if we had a draft that defined good/new/precise terms (e.g. OK), >> and that included the above text in its intro, and that had some >> text about the history (4322 etc), would that sound like a plan >> to folks? > Not to me. The "precise" terms such as OK is a distinction that will water down what we are trying to do. I would much prefer that we focus on the term people are already using, give it a general direction like Olle gave and a mediumly-precise definition that could be used across all protocols, and then give examples of its use in current usage (TLS and IPsec), saying that precise definitions might later be added in other RFCs. This will give people some possible excitement about doing the work instead of arguing about new terms. > Giving a "mediumly precise" definition followed by examples suggests that we're incapable of explaining what we're doing, which sends a bad message (maybe an accurate one, but still bad). Steve From nobody Thu Mar 13 12:10:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF0B1A0757 for ; Thu, 13 Mar 2014 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 XDLTSu31uVKH for ; Thu, 13 Mar 2014 12:10:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 211491A0155 for ; Thu, 13 Mar 2014 12:10:38 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id BF17193C2A2; Thu, 13 Mar 2014 19:10:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5321F741.1010208@bbn.com> Date: Thu, 13 Mar 2014 20:10:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2DA31B-BF57-46BD-AE83-80C806CF14BE@edvina.net> References: <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5320D8C6.5070609@isi.edu> <5321B38E.6020905@bbn.com> <5321CFA5.7080702@isi.edu> <5E64413D-4B44-4941-9A7F-6A821D390CF0@edvina.net> <5321D550.9090407@isi.edu> <20140313161630.GM21390@mournblade.imrryr.org> <4C32BAAC-0D72-4118-B4CC-57D404D16F91@edvina.net> <5321F741.1010208@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VzJAuHpRl4n0KDOIIiRZF8Qx-og Cc: saag Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 19:10:42 -0000 On 13 Mar 2014, at 19:21, Stephen Kent wrote: > Olle, >=20 > Since , as you said, you're a marketing guy, let me caution you about = viewing > Wikipedia as a definitive source of info. In this case there are a = number of > errors in its article on OE. Kathleen (the new SEC AD) and I have been = discussing > how to fix it. I was acting as one :-) And the wikipedia reference was more of a joke, = I'm sorry for forgetting the irony marker. Yes, that page needs some work - but before that I think we should reach = some sort of agreement here. /O= From nobody Thu Mar 13 12:20:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A66D1A066A for ; Thu, 13 Mar 2014 12:20:26 -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 5sZvpxkYJ2BP for ; Thu, 13 Mar 2014 12:20:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5F1A04B8 for ; Thu, 13 Mar 2014 12:20:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E62FF2AB22D; Thu, 13 Mar 2014 19:20:16 +0000 (UTC) Date: Thu, 13 Mar 2014 19:20:16 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140313192016.GA14279@mournblade.imrryr.org> References: <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> <42BCE5CF-C63C-4CB8-8996-2BB3E54F9069@edvina.net> <24256.1394727553@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24256.1394727553@sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iEdcw4AgMm1NifWsIdfM6X5JG_s Subject: Re: [saag] [dane] Need better opportunistic terminology 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: Thu, 13 Mar 2014 19:20:26 -0000 On Thu, Mar 13, 2014 at 12:19:13PM -0400, Michael Richardson wrote: > So, I'd like to have an ID (Informational, vendor-proprietary, like 4322) > document from the postfix authors on what *exactly* they do. > If UTA wants to adopt 2.0 of that, great. Is there a broad desire for such a document? Be careful what you mean when ask for "exactly". I could point you at the source code. The next slightly less verbose level of detail is: http://www.postfix.org/TLS_README.html which is a fairly long document. In terms of this discussion, the 50,000 foot view is a quick list of the security levels with one line descriptions and links to detailed text: http://www.postfix.org/TLS_README.html#client_tls_levels The limitations and reasoning behind the various levels are described in: http://www.postfix.org/TLS_README.html#client_tls_limits The volunteer to write the DANE_README.html tutorial has not yet produced a first draft. The IETF draft for SMTP security via opportunistic DANE TLS is largely complete, but may yet shed some content that is not SMTP specific into the revived DANE SRV draft. git clone https://github.com/vdukhovni/ietf -- Viktor. From nobody Thu Mar 13 12:45:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5811A0492 for ; Thu, 13 Mar 2014 12:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9OnL6JC4aB7 for ; Thu, 13 Mar 2014 12:45:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E78651A03E2 for ; Thu, 13 Mar 2014 12:45:45 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2DJjY1K091871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Mar 2014 12:45:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5321F76B.2020703@bbn.com> Date: Thu, 13 Mar 2014 12:45:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> <5321CA5E.5010303@cs.tcd.ie> <18416A7F-4A64-4C1A-BD16-6177EE0C58AC@vpnc.org> <5321F76B.2020703@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/feoxidOpO38uJurm9tURgNaNM3Q Cc: saag@ietf.org Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 13 Mar 2014 19:45:47 -0000 On Mar 13, 2014, at 11:22 AM, Stephen Kent wrote: > Giving a "mediumly precise" definition followed by examples suggests = that we're incapable of > explaining what we're doing, which sends a bad message (maybe an = accurate one, but still bad). I'm not sure what you mean as "bad message". If we could define OE = protocol-by-protocol, we could do it quite precisely, but the other = Stephen seems quite set against that. I think the message is "if you are = describing this for more than one protocol or environment, it won't be = maximally precise"; I doubt anyone will find that surprising. --Paul Hoffman= From nobody Fri Mar 14 15:56:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031361A01FE for ; Fri, 14 Mar 2014 15:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 T2Tdq8fQs6lb for ; Fri, 14 Mar 2014 15:56:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B21A01F5 for ; Fri, 14 Mar 2014 15:56:38 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BN1PR03MB022.namprd03.prod.outlook.com (10.255.224.40) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 14 Mar 2014 22:56:31 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0893.001; Fri, 14 Mar 2014 22:56:30 +0000 From: "Orit Levin (LCA)" To: "saag@ietf.org" Thread-Topic: Need better opportunistic terminology Thread-Index: Ac8/2C8kkVsUNigZSduEndYLj5uj+A== Date: Fri, 14 Mar 2014 22:56:29 +0000 Message-ID: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(24454002)(199002)(189002)(74876001)(81342001)(2656002)(79102001)(81542001)(80022001)(63696002)(65816001)(81816001)(56816005)(80976001)(83322001)(69226001)(81686001)(19580395003)(90146001)(87936001)(20776003)(33646001)(59766001)(561944002)(47446002)(85306002)(74366001)(31966008)(74662001)(74706001)(74502001)(87266001)(76786001)(76796001)(76576001)(50986001)(76482001)(94946001)(92566001)(46102001)(54356001)(51856001)(76176001)(97186001)(47736001)(49866001)(93516002)(94316002)(54316002)(85852003)(95666003)(86362001)(53806001)(47976001)(95416001)(83072002)(56776001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB022; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:B474C1D4.9ECAC105.6CD31FB8.90DDD1A0.20381; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2J8bRZGUOsFGyFGJiFe9T6U0Pnk Subject: [saag] Need better opportunistic terminology 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, 14 Mar 2014 22:56:42 -0000 Paul et al, The proposal by Stephen F. makes sense to me, but I am having difficulty to= understand why it doesn't work for you. Based on the feedback on the list, "OE" is a loosely defined and broadly us= ed term, while "OK", as was defined at the STRINT break-out session, is muc= h more narrow in scope (while still application/protocol agnostic). There a= re additional to "OK" known techniques that, when being used in different c= ombinations, all work towards the common goal of "activating encryption" un= der different tricky circumstances. We do need to document the spirit of these techniques with their technical = names (and potentially introduce new names where absolutely needed) as prec= isely as possible in an application-agnostic manner and also provide pointe= rs to application specific mechanisms as the known examples. How is it diff= erent from what you are proposing? Cheers, Orit. On Mar 13, 2014, at 8:10 AM, Stephen Farrell = wrote: So if we had a draft that defined good/new/precise terms (e.g. OK), and that included the above text in its intro, and that had some text about the history (4322 etc), would that sound like a plan to folks? On Mar 13, 2014, at 9:05 AM, Paul Hoffman wrote: Not to me. The "precise" terms such as OK is a distinction that will water = down what we are trying to do. I would much prefer that we focus on the ter= m people are already using, give it a general direction like Olle gave and = a mediumly-precise definition that could be used across all protocols, and = then give examples of its use in current usage (TLS and IPsec), saying that= precise definitions might later be added in other RFCs. This will give peo= ple some possible excitement about doing the work instead of arguing about = new terms. On Mar 13, 2014, at 11:22 AM, Stephen Kent wrote: Giving a "mediumly precise" definition followed by examples suggests that w= e're incapable of explaining what we're doing, which sends a bad message (m= aybe an accurate one, but still bad).=20 From nobody Fri Mar 14 16:38:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2221A0218 for ; Fri, 14 Mar 2014 16:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MpMLdawmdvL for ; Fri, 14 Mar 2014 16:38:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 138EF1A0215 for ; Fri, 14 Mar 2014 16:38:02 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2ENbrC3008749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Mar 2014 16:37:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> Date: Fri, 14 Mar 2014 16:37:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> To: "Orit Levin (LCA)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/07AlTRVkVqzaA7_YsKoo1ncW3Vc Cc: "saag@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 14 Mar 2014 23:38:06 -0000 On Mar 14, 2014, at 3:56 PM, Orit Levin (LCA) = wrote: > The proposal by Stephen F. makes sense to me, but I am having = difficulty to understand why it doesn't work for you. I'll try not to reiterate directly, but: - Using a new term like "opportunistic keying" leaves the listener = asking what the difference is between it and the term they already know, = so we are worse off - As others have said, using "keying" is confusing because users don't = care about the keying, they care about the encryption - We cannot have one precise definition that covers protocols that do = mutual authentication (like IPsec) and responder authentication (like = TLS) - Targeting protocol designers assumes that they are the ones driving = implementations, but that hasn't been the case for opportunistic X for = over a decade --Paul Hoffman= From nobody Fri Mar 14 16:43:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE791A021D for ; Fri, 14 Mar 2014 16:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 SecBQ41U0vFo for ; Fri, 14 Mar 2014 16:43:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BEC061A0215 for ; Fri, 14 Mar 2014 16:43:32 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2ENgehI028332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Mar 2014 16:42:50 -0700 (PDT) Message-ID: <532393F4.2040002@isi.edu> Date: Fri, 14 Mar 2014 16:42:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Orit Levin (LCA)" , "saag@ietf.org" References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> In-Reply-To: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Prh13VqOP3IhtXPX1KcvCCB-BPE Subject: Re: [saag] Need better opportunistic terminology 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, 14 Mar 2014 23:43:35 -0000 On 3/14/2014 3:56 PM, Orit Levin (LCA) wrote: > Paul et al, > The proposal by Stephen F. makes sense to me, but I am having difficulty to understand why it doesn't work for you. I'm not sure who specifically you're asking, but if it includes "et al.", for my part any proposal that uses "opportunistic" as primarily referring to the use of zero-ID (i.e., BTNS-style) approaches is broken. There's absolutely nothing "opportunistic" in either the historical or grammatical sense about zero-ID. Joe From nobody Fri Mar 14 17:10:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5991A021C for ; Fri, 14 Mar 2014 17:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6pmvCKoc3cj for ; Fri, 14 Mar 2014 17:10:19 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id DA2461A012B for ; Fri, 14 Mar 2014 17:10:17 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 111C759805F for ; Fri, 14 Mar 2014 17:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=O+o4aauw8o17i/VbnOvh cjULKTM=; b=fHFajAqM/8iP2e7h0o36rQSh2DoTGXGw+2mguY+dz/+Pa/K3N8gK Pl010cqBPIGav/CCUAr9Ij1BtjpkhBJdFEBKV7VBFOGeqop/f59gM2vyC2QPZC05 wCkEXomgF7+uoJ51xDSjEZ2uIt9k7pIAvJCZ8Ha78DNgqhJdmsRzIaY= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id B7075598057 for ; Fri, 14 Mar 2014 17:10:10 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so199078wib.10 for ; Fri, 14 Mar 2014 17:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HmNasgGVTJI/Y+R45O3/V8Jx2HARfZbjeuIjldTNaB0=; b=fqnWWLrii2bCzi15sGcjhc1mS2DlJJkIvpoTS7PumE91XXhV5FqOPOHLH77I2fq4hD GWphpRf/vyJwiR5dD1mMSCoxICohCEeWmdndqK++VKtL0AIkOZKP/eUn997tmCyoISrM tvkULc0qI26AleAHu8O/djGSTnunuKM5RyARERd3pFPf3dtLkVwP5tdsXOdZ2tTT7ZpY BMd6ihukvrrjoV+ax7JHcdPx1m3x6RMxPMrOicJErNNyfWkoj6R0FS4XNEiWj7/QDNKB 7T2om/oNXHx9H4OQ1NNKwcAWMAJsf/2tBm+8UG2Frs2TZdoO4GARVwPdGp7aEy/qnXDd 2Utw== MIME-Version: 1.0 X-Received: by 10.194.60.37 with SMTP id e5mr8777007wjr.32.1394842209510; Fri, 14 Mar 2014 17:10:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 17:10:09 -0700 (PDT) In-Reply-To: <532393F4.2040002@isi.edu> References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> <532393F4.2040002@isi.edu> Date: Fri, 14 Mar 2014 19:10:09 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IPERFAjDaVWAhrMT1DF3uz298gM Cc: "saag@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 15 Mar 2014 00:10:20 -0000 On Fri, Mar 14, 2014 at 6:42 PM, Joe Touch wrote: > I'm not sure who specifically you're asking, but if it includes "et al.", > for my part any proposal that uses "opportunistic" as primarily referring to > the use of zero-ID (i.e., BTNS-style) approaches is broken. > > There's absolutely nothing "opportunistic" in either the historical or > grammatical sense about zero-ID. As far as English is concerned "opportunistic encryption" is meaningful because the "opportunity" taken is that of denying passive attackers their opportunity. You do it when you can. In the IPsec sense opportunistic means "you do it when you can [authenticate the peer]", but the bracketed part really relates to what we now call the PAD, and with the introduction of BTNS you can always do that in a -weak, granted- sense. So I'm of the opinion that "opportunistic encryption" can be repurposed, though I won't claim that it won't cause confusion for at least a few people... Nico -- From nobody Fri Mar 14 17:17:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0776A1A021D for ; Fri, 14 Mar 2014 17:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 C5ujzymn38ZH for ; Fri, 14 Mar 2014 17:17:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFF1A012B for ; Fri, 14 Mar 2014 17:17:03 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2F0GAge027485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Mar 2014 17:16:20 -0700 (PDT) Message-ID: <53239BCE.2030302@isi.edu> Date: Fri, 14 Mar 2014 17:16:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> <532393F4.2040002@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XjXY8bF49CuJKxpyHbvMqbfCDq4 Cc: "saag@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 15 Mar 2014 00:17:05 -0000 On 3/14/2014 5:10 PM, Nico Williams wrote: > On Fri, Mar 14, 2014 at 6:42 PM, Joe Touch wrote: >> I'm not sure who specifically you're asking, but if it includes "et al.", >> for my part any proposal that uses "opportunistic" as primarily referring to >> the use of zero-ID (i.e., BTNS-style) approaches is broken. >> >> There's absolutely nothing "opportunistic" in either the historical or >> grammatical sense about zero-ID. > > As far as English is concerned "opportunistic encryption" is > meaningful because the "opportunity" taken is that of denying passive > attackers their opportunity. You do it when you can. Again, it depends on what your focus is. If it's the "opportunity" to fall-back, then it's about the fallback, not the zero-ID part. And fallback isn't opportunistic - it's just plain conservative. If it's about the zero-ID part, there's no "opportunity" - it always works. Opportunistic is either about pre-deployment or assuming something that *might not work* will, and trying that first. But that isn't part of the narrative I've heard about this mechanism at all. > In the IPsec sense opportunistic means "you do it when you can > [authenticate the peer]", but the bracketed part really relates to > what we now call the PAD, and with the introduction of BTNS you can > always do that in a -weak, granted- sense. Sure. > So I'm of the opinion that "opportunistic encryption" can be > repurposed, though I won't claim that it won't cause confusion for at > least a few people... I've already noted that if this is about PR, then there are far better terms. There's no good reason for reusing a term with baggage incorrectly. Joe From nobody Fri Mar 14 19:24:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD81A0269 for ; Fri, 14 Mar 2014 19:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.547] 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 3hTjBEAkAFFm for ; Fri, 14 Mar 2014 19:24:22 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5BE1A0268 for ; Fri, 14 Mar 2014 19:24:21 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id WAA00472; Fri, 14 Mar 2014 22:23:08 -0400 (EDT) Date: Fri, 14 Mar 2014 22:23:08 -0400 (EDT) From: Mouse Message-Id: <201403150223.WAA00472@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 14 Mar 2014 22:20:10 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <5321AB0F.3010908@cs.tcd.ie> <6459F834-2798-4D1B-883A-339531355316@vpnc.org> <5321C775.9070406@cs.tcd.ie> <4BECEA04-CB55-4C6B-BC00-1F7AAD32085D@edvina.net> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yLqj-kSdYj4Ko-fQndaEpc0EtAI Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 15 Mar 2014 02:24:23 -0000 Perhaps I'm just suffering from insufficient familiarity with something relevant, but... > We are going around in circles. I think we - the larger Internet > Community - ned to explain this and get everyone that manages a > system, that configures software to get aboard this ship. ...I don't think that either will or should happen until encryption is a right choice for every purpose, for every application. I don't think that will ever be the case. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Mon Mar 17 07:42:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17B1A040F for ; Mon, 17 Mar 2014 07:42:43 -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 1aqbxhsD_mWO for ; Mon, 17 Mar 2014 07:42:40 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B43411A041F for ; Mon, 17 Mar 2014 07:42:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr13so3731665lab.17 for ; Mon, 17 Mar 2014 07:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4F9OQL+stOfRv5wv21Bp4Nq+hEyJQ6G8/ZdBxeDOevg=; b=wSxLL7kmKpzKqa62RLS/2vmaDWgQGEigxlHE8bA2Za+AMabGBCS6YkgqHoe7ckApPw yNWyTIm1FkjKABBuVHFCBZuImviX+0INVvHHccjUlTpfvu2VhA98N3svBfMaeqpB67hp 5ssXAl/8zkqdM4dtIrCkUo8ALCtGqtDIOen8Xqk1q5HVsH9WQ3bqHsUuNZggc6UcOnYr wM+nZAuk310j8F1ZZJwIGqHsed3H7v5xM3EIEJHwCf0DG7cffkq3rN2B6QfGK1VsvigI RxXyq5/r2Jmy7/zPxA8/xNiYBmmSSQS87mbPZDejmyF8z1CwCP2oq0CYolAV4fBQjpTL zzbQ== MIME-Version: 1.0 X-Received: by 10.112.160.200 with SMTP id xm8mr16257905lbb.24.1395067351120; Mon, 17 Mar 2014 07:42:31 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 17 Mar 2014 07:42:31 -0700 (PDT) Date: Mon, 17 Mar 2014 10:42:31 -0400 Message-ID: From: Phillip Hallam-Baker To: cfrg@irtf.org, "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11c24896e6c14404f4ce6dc9 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rhbl9ruR7y3vpCKNnMHTsAlIQ-Y Subject: [saag] Cryptographic Algorithm Suite Conformance Criteria 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, 17 Mar 2014 14:42:45 -0000 --001a11c24896e6c14404f4ce6dc9 Content-Type: text/plain; charset=ISO-8859-1 Following the discussion at SECDIR, I have written a draft describing consensus choices of cryptographic algorithms. http://www.ietf.org/id/draft-hallambaker-consensuscrypto-00.txt Rationale: At present each IETF WG specifies Mandatory to Implement crypto algorithm suite choices individually. This approach is unsatisfactory for the following reasons: * The objective of an IETF WG is to shut down having completed its work. So there is no WG to arrive at consensus that an update of crypto algorithms is required. * Different WGs are chartered at different times and the choice of mandatory to implement algorithms tends to vary according to what the community believed to be the case when the documents were published rather than what is considered to be best current practice. * There is an industry trend towards adoption of Elliptic Curve approaches 'at some date in the future'. The choice of crypto should be taken by the security area and crypto community as a whole rather than individually for each protocol. * Security does not come from offering or even using more secure algorithms. Security comes from stopping use of weak algorithms or no-security. We don't currently have a good way to declare compliance with a decision to declare an algorithm obsolete. The objective of this draft is to have something that can be quoted in an RFP or product brochure, RFC-7??? compliant means that it supports this crypto set. If we make RFC7??? obsolete then implementations can't claim to be current. The objective here is to follow consensus, not lead it. So if there is not consensus on a choice I leave it blank. At the moment IETF specs only specify Mandatory to Implement as a rule. There are some earlier specs that required algorithms that are now defunct and recommended the current consensus algs as backup. I am aware that crypto is not exactly plug-and-play. And the documents deliberately avoid issues such as choice of block cipher modes for that reason. As a rule, I don't expect that an algorithm is likely to be considered a consensus choice as Required or Recommended unless there was a document specifying how to apply it in the principle IETF security specs where this is likely to be an issue (IPSEC, TLS, S/MIME, PKIX, OpenPGP, SSH). I am also aware that we now have something of a mess surrounding the choice of EC curves due to Snowdonia. However that might actually accelerate deployment since it may well bring the choice of algorithms and curves to a head. The document specifies a set of Required algorithms which is the usual suspects (SHA-2-256, AES-128, HMAC-SHA256, DH, RSA). There is also a set of Recommended algorithms that is intended to serve as backups. If we care about algorithm agility we should at minimum indicate a best guess for what the replacement algorithms should be. One of the secondary purposes of this exercise is to try to get some discussion going as to what our next generation cipher suite should look like and provide a nucleus around which consensus could emerge. I don't think we necessarily can or should come to consensus on replacement public key algorithms for Version 1 but we can probably do that by version 2. That leaves one major hole in the current draft, there is no backup encryption algorithm. This came up in hallway discussions at STRINT. We could certainly just pick one. But the AES competition was started in 1997, that is getting on for two decades ago. There seemed to be feeling that we are about due for another, although this time we should probably look to sponsorship from outside the US government for a change. The process in which the participants in the process were the ones to vote certainly gave it a lot of credibility. -- Website: http://hallambaker.com/ --001a11c24896e6c14404f4ce6dc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Following the discussion at SECDIR, I have written a = draft describing consensus choices of cryptographic algorithms.
<= br>

Rationale:

At present ea= ch IETF WG specifies Mandatory to Implement crypto algorithm suite choices = individually. This approach is unsatisfactory for the following reasons:

* The objective of an IETF WG is to shut down having co= mpleted its work. So there is no WG to arrive at consensus that an update o= f crypto algorithms is required.

* Different WGs a= re chartered at different times and the choice of mandatory to implement al= gorithms tends to vary according to what the community believed to be the c= ase when the documents were published rather than what is considered to be = best current practice.

* There is an industry trend towards adoption of Ellipt= ic Curve approaches 'at some date in the future'. The choice of cry= pto should be taken by the security area and crypto community as a whole ra= ther than individually for each protocol.

* Security does not come from offering or even using mo= re secure algorithms. Security comes from stopping use of weak algorithms o= r no-security. We don't currently have a good way to declare compliance= with a decision to declare an algorithm obsolete.

The objective of this draft is to have something that c= an be quoted in an RFP or product brochure, RFC-7??? compliant means that i= t supports this crypto set. If we make RFC7??? obsolete then implementation= s can't claim to be current.

The objective here is to follow consensus, not lead it.= So if there is not consensus on a choice I leave it blank. At the moment I= ETF specs only specify Mandatory to Implement as a rule. There are some ear= lier specs that required algorithms that are now defunct and recommended th= e current consensus algs as backup.=A0


I am aware that crypto is not exactly pl= ug-and-play. And the documents deliberately avoid issues such as choice of = block cipher modes for that reason. As a rule, I don't expect that an a= lgorithm is likely to be considered a consensus choice as Required or Recom= mended unless there was a document specifying how to apply it in the princi= ple IETF security specs where this is likely to be an issue (IPSEC, TLS, S/= MIME, PKIX, OpenPGP, SSH).

I am also aware that we now have something of a mess= surrounding the choice of EC curves due to Snowdonia. However that might a= ctually accelerate deployment since it may well bring the choice of algorit= hms and curves to a head.

The document specifies a set of Required algorithms whi= ch is the usual suspects (SHA-2-256, AES-128, HMAC-SHA256, DH, RSA). There = is also a set of Recommended algorithms that is intended to serve as backup= s.

If we care about algorithm agility we should at minimum= indicate a best guess for what the replacement algorithms should be.
=

One of the secondary purposes of this exercise is to tr= y to get some discussion going as to what our next generation cipher suite = should look like and provide a nucleus around which consensus could emerge.=

I don't think we necessarily can or should come to = consensus on replacement public key algorithms for Version 1 but we can pro= bably do that by version 2.

That leaves one major = hole in the current draft, there is no backup encryption algorithm. This ca= me up in hallway discussions at STRINT. We could certainly just pick one. B= ut the AES competition was started in 1997, that is getting on for two deca= des ago. There seemed to be feeling that we are about due for another, alth= ough this time we should probably look to sponsorship from outside the US g= overnment for a change. The process in which the participants in the proces= s were the ones to vote certainly gave it a lot of credibility.=A0

--
Website: http://h= allambaker.com/
--001a11c24896e6c14404f4ce6dc9-- From nobody Mon Mar 17 09:01:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013E91A042A for ; Mon, 17 Mar 2014 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 IdJ_yrgxNMcx for ; Mon, 17 Mar 2014 09:01:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7691A040E for ; Mon, 17 Mar 2014 09:01:27 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2HG15JC025621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Mar 2014 12:01:08 -0400 Received: from bofh.nohats.ca (vpn-56-96.rdu2.redhat.com [10.10.56.96]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2HG0wJV024574 for ; Mon, 17 Mar 2014 12:01:00 -0400 Message-ID: <53271C39.20108@redhat.com> Date: Mon, 17 Mar 2014 12:00:57 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: saag@ietf.org References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> In-Reply-To: <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JN16n1WgIOX4F3BYAJlIZcWcZbk Subject: Re: [saag] Need better opportunistic terminology 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, 17 Mar 2014 16:01:31 -0000 On 03/14/2014 07:37 PM, Paul Hoffman wrote: [Having been sick and reading these 200+ emails in a row - this PaulH's email seems the best starting point] > I'll try not to reiterate directly, but: > > - Using a new term like "opportunistic keying" leaves the listener asking what the difference is between it and the term they already know, so we are worse off I agree. And they are not even interchangable. OE describes an endgoal, while OK describes a technical method. OK's goal could still be OE. Also, OK as an acronym is really awkward. To me, OE meant that if I am instructed to start a non-encrypted connection (say http://) that I am going to see if I can find a way to encrypt that connection anyway. This could be mutual, single or un-authenticated. There is a clear element here of a fallback to plaintext, because the original job was to setup an unencrypted connection. However, once we build infrastructure to support single or mutual authenticated OE, we create the problem of depending on its encryption and not wanting it to fail back to cleartext. It is no longer opportunistic (rather opportune if my interpretation of English is correct) > - As others have said, using "keying" is confusing because users don't care about the keying, they care about the encryption Exactly, people seem to have forgotten that the term Opportunistic Encryption as popularised by FreeS/WAN was meant for endusers, not engineers. > - We cannot have one precise definition that covers protocols that do mutual authentication (like IPsec) and responder authentication (like TLS) I'm not sure if I agree here. If you see the term OE as a goal, not a method, than it does not matter whether the method uses mutual or responder authentication. > - Targeting protocol designers assumes that they are the ones driving implementations, but that hasn't been the case for opportunistic X for over a decade Times are changing? We (libreswan) have also tried and failed to come up with a better term, and stuck with our internal terms for now (either NEW-OE or HDOE which is a honorary reference to Hugh Daniel with a pun to HDTV) Paul From nobody Mon Mar 17 22:06:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2441A0527 for ; Mon, 17 Mar 2014 22:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Mharg8ShBI5q for ; Mon, 17 Mar 2014 22:06:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id EB2811A0505 for ; Mon, 17 Mar 2014 22:06:29 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 05:06:20 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0893.001; Tue, 18 Mar 2014 05:06:21 +0000 From: "Orit Levin (LCA)" To: Paul Hoffman Thread-Topic: [saag] Need better opportunistic terminology Thread-Index: Ac8/2C8kkVsUNigZSduEndYLj5uj+AABjrSAAJX7goA= Date: Tue, 18 Mar 2014 05:06:20 +0000 Message-ID: <20e534a0eb984a9b8f9cc1faa49c1127@BL2PR03MB290.namprd03.prod.outlook.com> References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> In-Reply-To: <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.181.3.94] x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(51704005)(189002)(199002)(13464003)(377454003)(59766001)(83072002)(85306002)(63696002)(65816001)(20776003)(56816005)(54356001)(76482001)(80022001)(95666003)(74876001)(53806001)(54316002)(97186001)(95416001)(2656002)(77982001)(93136001)(87936001)(87266001)(79102001)(4396001)(86612001)(50986001)(49866001)(74366001)(76796001)(47736001)(51856001)(90146001)(66066001)(81686001)(76786001)(56776001)(19580405001)(74706001)(561944002)(81342001)(80976001)(83322001)(69226001)(93516002)(81816001)(81542001)(19580395003)(74316001)(74502001)(47976001)(94946001)(74662001)(92566001)(86362001)(76576001)(47446002)(85852003)(46102001)(33646001)(31966008)(97336001)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB018; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:34767154.95F996CA.7DF315A8.86F1D960.202A7; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/A9wn4Of6nAzHcG7HnpHAcQ4_DwY Cc: "saag@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 18 Mar 2014 05:06:32 -0000 Paul, You summarized clearly your position on why some of the specific names and = protocol design techniques "don't work for you", but the question was diffe= rent: why the proposal for writing a document (or may be a wiki? :-) ) summarizin= g different "conceptual" approaches (loosely called O*) with their pros and= cons is not a good idea. After all, the work in the IETF is contribution-d= riven... Cheers, Orit. > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Friday, March 14, 2014 4:38 PM > To: Orit Levin (LCA) > Cc: saag@ietf.org > Subject: Re: [saag] Need better opportunistic terminology >=20 > On Mar 14, 2014, at 3:56 PM, Orit Levin (LCA) wrote= : >=20 > > The proposal by Stephen F. makes sense to me, but I am having difficult= y to > understand why it doesn't work for you. >=20 > I'll try not to reiterate directly, but: >=20 > - Using a new term like "opportunistic keying" leaves the listener asking= what the > difference is between it and the term they already know, so we are worse = off >=20 > - As others have said, using "keying" is confusing because users don't ca= re about > the keying, they care about the encryption >=20 > - We cannot have one precise definition that covers protocols that do mut= ual > authentication (like IPsec) and responder authentication (like TLS) >=20 > - Targeting protocol designers assumes that they are the ones driving > implementations, but that hasn't been the case for opportunistic X for ov= er a > decade >=20 > --Paul Hoffman From nobody Tue Mar 18 03:03:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1AB1A06A8; Tue, 18 Mar 2014 03:03:51 -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 2UBYsFMnXIYE; Tue, 18 Mar 2014 03:03:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06C1A00A3; Tue, 18 Mar 2014 03:03:49 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so3403766wiv.13 for ; Tue, 18 Mar 2014 03:03:40 -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=jt9lGVlqIBHqWrNALYUq2jOM+7UxyWYa7nF1aSa2jRY=; b=TDx+8j5MkmmibjvTd9zHDzhmdhJFP7OpJCeB5LevBE45uqp7IlToTRYiEu72QS91m4 5Gj5URangkDPb3e6Pzn7Y0SpIZrFGNayci9gOaLflYgAL3/gnNl6+iK9P3fUESyY6xRv xQ4+6xcK/plorAiR7+64PjxU9RwSPgXDBSxGFUB3to8YVvuRONBbxRDOtaAalAIPjm/R ALXEjrhR3+xR71ACnkuDjJ4QNDMlyI7QVu7yMM6g3whJo9TqIaqpLLXuvm59ixXe8JOj FL5rWHUGbThErWWjFfBXcixXBRoPBZd2gOrstyDZjnaIoRlIZ8zqAI3R2gRcoh8i6L/P Mp+g== MIME-Version: 1.0 X-Received: by 10.180.12.14 with SMTP id u14mr14129149wib.0.1395137020535; Tue, 18 Mar 2014 03:03:40 -0700 (PDT) Received: by 10.217.120.132 with HTTP; Tue, 18 Mar 2014 03:03:40 -0700 (PDT) In-Reply-To: <20140317181046.3237.82092.idtracker@ietfa.amsl.com> References: <20140317181046.3237.82092.idtracker@ietfa.amsl.com> Date: Tue, 18 Mar 2014 11:03:40 +0100 Message-ID: From: Jean-Michel Combes To: perpass@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary=001a11c23ed285a7b904f4dea684 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IX4FpC5YOhD9-OhTGslCPUV43lA Subject: [saag] Fwd: New Non-WG Mailing List: dns-privacy 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, 18 Mar 2014 10:03:51 -0000 --001a11c23ed285a7b904f4dea684 Content-Type: text/plain; charset=ISO-8859-1 FYI: as decided during dnse BOF in London, creation of a new mailing list to discuss about DNS privacy. Best regards, JMC. ---------- Forwarded message ---------- From: IETF Secretariat Date: 2014-03-17 19:10 GMT+01:00 Subject: New Non-WG Mailing List: dns-privacy To: IETF Announcement List Cc: pk@denic.de, dns-privacy@ietf.org A new IETF non-working group email list has been created. List address: dns-privacy@ietf.org Archive: http://www.ietf.org/mail-archive/web/dns-privacy/ To subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy Purpose: This list is for the discussion of the problem statement surrounding the addition of privacy to the DNS protocol. For additional information, please contact the list administrators. --001a11c23ed285a7b904f4dea684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI: as decided during dnse BOF in London, creat= ion of a new mailing list to discuss about DNS privacy.

Best r= egards,

JMC.

= ---------- Forwarded message ----------
From: IETF Secretariat = <ietf-sec= retariat@ietf.org>
Date: 2014-03-17 19:10 GMT+01:00
Subject: New Non-WG Mailing List: dns-p= rivacy
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: pk@denic.de, dns-privacy@ietf.org


A new IETF non-working group email list has been created.

List address: dns= -privacy@ietf.org
Archive: http://www.ietf.org/mail-archive/web/dns-privacy/
To subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy
Purpose: This list is for the discussion of the problem statement surroundi= ng the addition of privacy to the DNS protocol.

For additional information, please contact the list administrators.


--001a11c23ed285a7b904f4dea684-- From nobody Tue Mar 18 07:52:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E9E1A044F for ; Tue, 18 Mar 2014 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKudj9CJ9-CT for ; Tue, 18 Mar 2014 07:52:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4640F1A0404 for ; Tue, 18 Mar 2014 07:52:29 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2IEqJvu077275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 07:52:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20e534a0eb984a9b8f9cc1faa49c1127@BL2PR03MB290.namprd03.prod.outlook.com> Date: Tue, 18 Mar 2014 07:52:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ef8f323fb78484a883fe2a571c62086@BL2PR03MB290.namprd03.prod.outlook.com> <4AFEAC84-398F-4FE5-9A1F-CB575FF63F3F@vpnc.org> <20e534a0eb984a9b8f9cc1faa49c1127@BL2PR03MB290.namprd03.prod.outlook.com> To: "Orit Levin (LCA)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Eo8B2ncAD-eEx4sz_iqPCwoj_cY Cc: "saag@ietf.org" Subject: Re: [saag] Need better opportunistic terminology 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, 18 Mar 2014 14:52:30 -0000 On Mar 17, 2014, at 10:06 PM, Orit Levin (LCA) = wrote: > You summarized clearly your position on why some of the specific names = and protocol design techniques "don't work for you", but the question = was different: > why the proposal for writing a document (or may be a wiki? :-) ) = summarizing different "conceptual" approaches (loosely called O*) with = their pros and cons is not a good idea. After all, the work in the IETF = is contribution-driven... Ah, I missed the context. Stephen has made many proposals in this area, = and I misunderstood the specific one you were referring to. I fully = agree that we want a document summarizing the different approaches. = Having that be a wiki will not be helpful to developers because edit = wars can make things much worse. Listing the pros and cons will not be = feasible if we expect the document to be a consensus document. --Paul Hoffman= From nobody Tue Mar 18 15:04:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625C71A03F1 for ; Tue, 18 Mar 2014 15:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ka4rWKrtn_Ap for ; Tue, 18 Mar 2014 15:04:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CAC741A030F for ; Tue, 18 Mar 2014 15:04:43 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54169) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQ27f-000MvL-2p for saag@ietf.org; Tue, 18 Mar 2014 18:04:35 -0400 Message-ID: <5328C2F2.5040204@bbn.com> Date: Tue, 18 Mar 2014 18:04:34 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5_DDYnObLsVJ14tmoTxm-P2KGoM Subject: [saag] better ** terminology 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, 18 Mar 2014 22:04:45 -0000 I have just posted an I-D that does a few things: - it proposes yet another term for the subject of our protracted terminology discussion - it defines what that term means, based on a STRINT workshop breakout group - it argues why "opportunistic encryption" is a poor terminology choice for what we want to describe - it examines some other aspects of terminology for key management that yields authenticated, anonymous, or pseudonymous communications I extracted this text form a bigger document, and made changes based on the debate that has been taking place on SAAG, replacing my preferred "opportunistic keying" with a term that seems tailor made to the problem we're addressing :-). https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/ Steve From nobody Tue Mar 18 15:05:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFB1A0434 for ; Tue, 18 Mar 2014 15:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 VwWtvU5MP63j for ; Tue, 18 Mar 2014 15:05:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 563EC1A030F for ; Tue, 18 Mar 2014 15:05:06 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54170) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQ281-000Mvy-Vd for saag@ietf.org; Tue, 18 Mar 2014 18:04:58 -0400 Message-ID: <5328C309.2010000@bbn.com> Date: Tue, 18 Mar 2014 18:04:57 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5321BD64.4050609@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/C8jvNaw3OEjlCxLavT7kgHxsTCk Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 18 Mar 2014 22:05:07 -0000 Paul, I began generating a point-by-point response to your message, but I think that's a bad use of everyone's time. We will each participate in the WGs that are of interest to use, write I-Ds, and propose mechanisms in support of countering PM. There's not much point to debating the merits of public keys as principal IDs the abstract, vs. in specific proposals. Steve From nobody Tue Mar 18 15:54:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B421A040E for ; Tue, 18 Mar 2014 15:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 srfBcq7pE0Sr for ; Tue, 18 Mar 2014 15:54:39 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id C44891A03F1 for ; Tue, 18 Mar 2014 15:54:38 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2IMsR2L023810; Tue, 18 Mar 2014 15:54:27 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1jpnsdawcn-13 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2014 15:54:27 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 18 Mar 2014 15:54:22 -0700 From: Paul Lambert To: Stephen Kent , saag Date: Tue, 18 Mar 2014 15:54:21 -0700 Thread-Topic: [saag] better ** terminology Thread-Index: Ac9C/QBDxMQoOLuKTzOaEJ9+kfTb+A== Message-ID: References: <5328C2F2.5040204@bbn.com> In-Reply-To: <5328C2F2.5040204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-18_07:2014-03-18,2014-03-18,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-1305240000 definitions=main-1403180130 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/80KGTH0kl0Wth_5I2_k7Hz_WBP8 Subject: Re: [saag] better ** terminology 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, 18 Mar 2014 22:54:40 -0000 On 3/18/14, 3:04 PM, "Stephen Kent" wrote: >I have just posted an I-D that does a few things: Nice well crafted draft/analysis of terms. Comments on : >1. It is invisible to users (so that they do not become confused by the set of security services they are being offered). ... >4. Detection of a man-in-the-middle (MiTM) attacks is a desired, > thought not mandatory, feature. > >5. Authentication is a desired, thought not mandatory, feature. We need to be careful with the combination of =8Cinvisible=B9 to user and optional authentication. It would be desirable to have recommendations that users be able to determine the type of security that they have for a particular connection. This Is a terminolgy draft, so this may or may not be the right place. There is also a statefulness in the models (like LoF and TOFU) that is not fully captured. A connection that starts as LoF could become strongly authenticated later through an out-of-band channel to become =8Cauthenticated=B9. Paul > > - it proposes yet another term for the subject of our protracted >terminology discussion > - it defines what that term means, based on a STRINT workshop >breakout group > - it argues why "opportunistic encryption" is a poor terminology >choice > for what we want to describe > - it examines some other aspects of terminology for key management > that yields authenticated, anonymous, or pseudonymous >communications > >I extracted this text form a bigger document, and made changes based on >the debate >that has been taking place on SAAG, replacing my preferred >"opportunistic keying" >with a term that seems tailor made to the problem we're addressing :-). > >https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/ > >Steve > > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Tue Mar 18 16:09:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC431A049A for ; Tue, 18 Mar 2014 16:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 zfMvC5dKIhrO for ; Tue, 18 Mar 2014 16:09:05 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id D4F151A0479 for ; Tue, 18 Mar 2014 16:09:04 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2IN8n9C003924; Tue, 18 Mar 2014 16:08:54 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1jpnsday77-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2014 16:08:54 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 18 Mar 2014 16:08:53 -0700 From: Paul Lambert To: Stephen Kent , "saag@ietf.org" Date: Tue, 18 Mar 2014 16:08:52 -0700 Thread-Topic: [saag] [dane] Need better opportunistic terminology Thread-Index: Ac9C/weunqWL0UgVQMW4imR/vjQBMQ== Message-ID: References: <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu> <5320D5DD.8060204@bbn.com> <5321BD64.4050609@bbn.com> <5328C309.2010000@bbn.com> In-Reply-To: <5328C309.2010000@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-18_07:2014-03-18,2014-03-18,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-1305240000 definitions=main-1403180133 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oIxnMh2m4oHVrwo_5LkCtGlry5s Subject: Re: [saag] [dane] Need better opportunistic terminology 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, 18 Mar 2014 23:09:06 -0000 On 3/18/14, 3:04 PM, "Stephen Kent" wrote: >Paul, > >I began generating a point-by-point response to your message, but I think >that's a bad use of everyone's time. > >We will each participate in the WGs that are of interest to use, write >I-Ds, >and propose mechanisms in support of countering PM. > >There's not much point to debating the merits of public keys as >principal IDs >the abstract, vs. in specific proposals. Yes - specific usage and proposals have more merit than abstractions. Also, thank you for the discussion .. it has helped me see the subtle impact of the security abstractions we create. =20 Paul > >Steve > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 19 08:20:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF15D1A0781 for ; Wed, 19 Mar 2014 08:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 pRIRYHGVEwVE for ; Wed, 19 Mar 2014 08:20:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7291A077B for ; Wed, 19 Mar 2014 08:20:01 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54463) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQIHV-0006Jy-Mb for saag@ietf.org; Wed, 19 Mar 2014 11:19:49 -0400 Message-ID: <5329B594.9020705@bbn.com> Date: Wed, 19 Mar 2014 11:19:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <5328C2F2.5040204@bbn.com> In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zevOVnJCCWs05aWEKSepsvI8Pvc Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 15:20:05 -0000 Paul, > On 3/18/14, 3:04 PM, "Stephen Kent" wrote: > >> I have just posted an I-D that does a few things: > Nice well crafted draft/analysis of terms. thanks. > > Comments on : > >> 1. It is invisible to users (so that they do not become confused by > the set of security services they are being offered). > ... >> 4. Detection of a man-in-the-middle (MiTM) attacks is a desired, >> thought not mandatory, feature. >> >> 5. Authentication is a desired, thought not mandatory, feature. > We need to be careful with the combination of Œinvisible¹ to user > and optional authentication. It would be desirable > to have recommendations that users be able to determine the type of > security that they have for a particular connection. This > Is a terminolgy draft, so this may or may not be the right place. I was reporting what appeared to be the consensus of the STRINT workshop breakout session, wrt UIs and PE. Folks need to discuss this and come to agreement. I see merit in hiding PE from users so that that don't become confused, but ... > There is also a statefulness in the models (like LoF and TOFU) > that is not fully captured. A connection that starts as > LoF could become strongly authenticated later through an > out-of-band channel to become Œauthenticated¹. Agreed. Additional material discussing LoF/TOFU is needed. Steve From nobody Wed Mar 19 08:50:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5E1A03DD for ; Wed, 19 Mar 2014 08:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJzxONQluDuH for ; Wed, 19 Mar 2014 08:50:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4F321A045C for ; Wed, 19 Mar 2014 08:50:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JFoKrM027821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 08:50:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5328C2F2.5040204@bbn.com> Date: Wed, 19 Mar 2014 08:50:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BB2E0FA-9234-43D7-AD61-19CFF06FE591@vpnc.org> References: <5328C2F2.5040204@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZzcGWKHPz5JLTN5vwTa8BTIURMk Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 15:50:36 -0000 On Mar 18, 2014, at 3:04 PM, Stephen Kent wrote: > I have just posted an I-D that does a few things: >=20 > - it proposes yet another term for the subject of our protracted = terminology discussion The protracted terminology discussion on SAAG seemed to end with more = people wanting to use "opportunistic encryption" with a new definition = rather than making up a new term. > - it defines what that term means, based on a STRINT workshop = breakout group I do like most of the seven points in section 1; they capture what I = think is a likely consensus of the discussion so far. > - it argues why "opportunistic encryption" is a poor terminology = choice > for what we want to describe ...at which point it goes off the rails. It tries too hard to make the = old term have an important meaning. That discussion also skips over some = of the obvious flaws with your new term. For example, there is no = expectation that the adoption of PE will be high enough to justify the = term "pervasive". That kind of overstated marketing is like naming a = protocol "simple". :-) > - it examines some other aspects of terminology for key management > that yields authenticated, anonymous, or pseudonymous = communications No offense, but most of that is just selling well past the agreement. = Many of the definitions in Section 2 are not universally agreed on, and = trying to force those terms down people's throats is likely to cause the = important stuff in the definition to be ignored. > I extracted this text form a bigger document, and made changes based = on the debate > that has been taking place on SAAG, replacing my preferred = "opportunistic keying" > with a term that seems tailor made to the problem we're addressing = :-). Making the jacket to be five sizes too large just in case we gain a lot = of weight is not necessarily good tailoring. Please strongly consider = using the term that we had previously agreed on. --Paul Hoffman= From nobody Wed Mar 19 08:55:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8931A0442 for ; Wed, 19 Mar 2014 08:55:45 -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 2CykKYEknQRZ for ; Wed, 19 Mar 2014 08:55:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 573AE1A040B for ; Wed, 19 Mar 2014 08:55:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 759F82AB26D; Wed, 19 Mar 2014 15:55:35 +0000 (UTC) Date: Wed, 19 Mar 2014 15:55:35 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140319155535.GY24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5329B594.9020705@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5e2iHtE42ZD1IzBDN_Oh2ipDb3A Subject: Re: [saag] better ** terminology 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: Wed, 19 Mar 2014 15:55:46 -0000 On Wed, Mar 19, 2014 at 11:19:48AM -0400, Stephen Kent wrote: > >There is also a statefulness in the models (like LoF and TOFU) > >that is not fully captured. A connection that starts as > >LoF could become strongly authenticated later through an > >out-of-band channel to become ?authenticated?. > > Agreed. Additional material discussing LoF/TOFU is needed. Would it also be appropriate to briefly discuss the use of DANE to harden PE against MITM downgrade attacks? As in the DANE SMTP and SRV drafts, the idea is that when a server has associated TLSA RRs, encryption (via TLS) becomes mandatory, and when some of the TLSA RRs are "usable", authentication is also mandatory. The result is I think not too dissimilar from the original OE in IPSEC, in that what you get is an authenticated connection without prior bilateral arrangement (fax effect and all that). [ Does the PE draft inspire a better name for "opportunistic DANE TLS", or is that name about right. ] -- Viktor. From nobody Wed Mar 19 10:00:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABAF1A06FD for ; Wed, 19 Mar 2014 10:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 5EyG5vnpT49S for ; Wed, 19 Mar 2014 10:00:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5C1A0429 for ; Wed, 19 Mar 2014 10:00:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2JGx4Su002794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 09:59:06 -0700 (PDT) Message-ID: <5329CCD8.7050304@isi.edu> Date: Wed, 19 Mar 2014 09:59:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <5328C2F2.5040204@bbn.com> In-Reply-To: <5328C2F2.5040204@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LwfV6M1doMpszsVA3yI6ax_eyzE Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 17:00:11 -0000 Steve, Interesting document. It's further worth noting in this document that RFC4322 itself indicates a clear distinction between anonymous keying and OE: Opportunistic encryption creates tunnels between nodes that are essentially strangers. This is done without any prior bilateral arrangement. Therefore, there is the difficult question of how one knows to whom one is talking. One possible answer is that since no useful authentication can be done, none should be tried. This mode of operation is named "anonymous encryption". An active man-in-the-middle attack can be used to thwart the privacy of this type of communication. Without peer authentication, there is no way to prevent this kind of attack. Although it is a useful mode, anonymous encryption is not the goal of this project. Simpler methods are available that can achieve anonymous encryption only, but authentication of the peer is a desirable goal. Authentication of the peer is achieved through key ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ distribution in DNS, leveraging upon the authentication of the DNS in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DNSSEC. ^^^^^^ This further underscores that OE is *not* unauthenticated keying. In contrast, unauthenticated keying was the primary goal of BTNS (RFC 5387), which thus should be discussed in this doc as well: To improve the situation, one could either reduce the hurdles to obtain and configure authentication information or remove the requirement for authentication in IPsec. The latter approach is the core idea of BTNS, which provides anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers that do not possess requisite authentication credentials. and includes: BTNS employs a weaker notion of authenticated identity by comparison to most authentication protocols; this weaker notion is bootstrapped from the security association itself. This notion, called "continuity of association", doesn't mean "Bill Smith" or "owner of shared secret X2YQ", but means "the entity with which I have been communicating on connection #23". Joe On 3/18/2014 3:04 PM, Stephen Kent wrote: > I have just posted an I-D that does a few things: > > - it proposes yet another term for the subject of our protracted > terminology discussion > - it defines what that term means, based on a STRINT workshop > breakout group > - it argues why "opportunistic encryption" is a poor terminology > choice > for what we want to describe > - it examines some other aspects of terminology for key management > that yields authenticated, anonymous, or pseudonymous communications > > I extracted this text form a bigger document, and made changes based on > the debate > that has been taking place on SAAG, replacing my preferred > "opportunistic keying" > with a term that seems tailor made to the problem we're addressing :-). > > https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/ > > Steve > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Mar 19 10:24:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369441A0729 for ; Wed, 19 Mar 2014 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcPPmI-X1WgD for ; Wed, 19 Mar 2014 10:24:18 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (agjbgdcfdbhb.dreamhost.com [69.163.253.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE791A070D for ; Wed, 19 Mar 2014 10:24:18 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 7325343812F for ; Wed, 19 Mar 2014 10:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Eigy/sixe4vjx7tgrOjgLpjo6oo=; b=hWMktUTQF+J cMQ91YU4xOEEVtLtesROhocBE80pjLe5bpfsgyqtMaTkCmxwbbwVmPbRNdyBrbB7 KUYKFSe7309QF1rS+v0nM7dFNWoPsb+pqSOWd1fvaYysjrM8uTgw58xafh/xsHHT R4bCJDcR877/tZ3f1cP+/JT3iO8h7PUg= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 27761438128 for ; Wed, 19 Mar 2014 10:24:08 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so7256148wgh.11 for ; Wed, 19 Mar 2014 10:24:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=II0OFf1sy2KPNEdv7SUnEocBxWv02t8jwFkK3BdTVVI=; b=J/oGpJYKVI9nN/t/XMPEa2bnzlJtFlx93JNl92oNQ0RfuqJW8w8TA15VbT/MGQO6tA Qo0jFXRuk81dPq08r4UKKR2cPU/Lls5G56IHwRtymnqS0uAAmStXGWi3FAGaXrVo3kcz lA7qJDO2TimcpQJ7OvdmmLak1rmI9a3N/2DZvqI+itNK2f5cBFrfh6xv4pH5ynb4I8LR pZUAmMmN0s+Zo5NcYuqNxbyxCJbV+juTD++7JX8GmqvaBPR7x7hh7E9d/IB1HysoMGkW wKLsQvsAeeKej4EE4BwwK7MVXQiyZZsDwsz2QmryBe3N3ZgWzUEu/24m0wo2Y9jTJgqA favg== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr20275383wij.42.1395249847963; Wed, 19 Mar 2014 10:24:07 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 10:24:07 -0700 (PDT) In-Reply-To: <5329B594.9020705@bbn.com> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> Date: Wed, 19 Mar 2014 12:24:07 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LhmRBPHGqOWpbJcNKmM3P3fj_BY Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 17:24:19 -0000 On Wed, Mar 19, 2014 at 10:19 AM, Stephen Kent wrote: >> On 3/18/14, 3:04 PM, "Stephen Kent" wrote: >> There is also a statefulness in the models (like LoF and TOFU) >> that is not fully captured. A connection that starts as >> LoF could become strongly authenticated later through an >> out-of-band channel to become =C5=92authenticated=C2=B9. > > Agreed. Additional material discussing LoF/TOFU is needed. Oh man, one term we most certainly can't use is OA =3D=3D opportunistic authentication... Too close to OAuth. Anyways, there's a spectrum of security. The key is to describe that spectrum appropriately -- appropriately for _typical users_ because whatever terminology we settle on will almost certainly find itself into mass consumer consciousness. Alternatively we need a terminology that is explicitly chosen such that it would not be used in marketing materials nor otherwise be likely to come to the attention of mass consumers. The main problem is that explaining MITM attacks is not easy, and yet we need MITM attack resistance/detection in many, many cases (e.g., coffee shop wifi). At one end of the spectrum we have: - no real security progressing through: - security against passive attacks - LoF/TOFU: some security against active attacks if you remember keys for long (i.e., force an MITM to be there the first time and always) - security against passive and active criminal attackers (authentication + encryption) with users _today_ only really being aware of the last one (security against criminal attackers). (I say "criminal" to distinguish from LEO/TLA agency types.) Then we have: - security against passive and active foreign TLA agencies (difficult) - security against passive and active LEO/TLA agenciess whose jurisdiction you're in (exceedingly difficult / impossible at the limit, but possible when you're not interesting) On a different axis: security against traffic analysis (very, very hard -- the most difficult). For mass consumption we don't need the last three, but we do need to cover these three options: - security against passive attacks - LoF/TOFU: some security against active attacks if you remember keys for long (i.e., force an MITM to be there the first time and always) - security against passive and active criminal attackers (authentication + encryption) and I believe we need terminology that mass consumers can understand. For those three items I find "opportunistic" or "qualified" to be really good terms. I particularly like "qualified". Nico -- From nobody Wed Mar 19 10:37:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B091A0713 for ; Wed, 19 Mar 2014 10:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM6kfkKHBhkW for ; Wed, 19 Mar 2014 10:37:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B32291A06E1 for ; Wed, 19 Mar 2014 10:37:38 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JHbPHh031595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 10:37:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5329CCD8.7050304@isi.edu> Date: Wed, 19 Mar 2014 10:37:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <600E347F-9CCA-4C31-BFF7-07C239D59DE3@vpnc.org> References: <5328C2F2.5040204@bbn.com> <5329CCD8.7050304@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QlIzFL2RgaegzPEjyOFu29NWCBc Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 17:37:42 -0000 On Mar 19, 2014, at 9:59 AM, Joe Touch wrote: > This further underscores that OE is *not* unauthenticated keying. It underscored that OE *as defined in RFC 4322* is not unauthenticated = keying. As many people here have said repeatedly, we don't care about = what the authors of that document said: the term has be reappropriated = to mean best-effort keying triggered without the user's knowledge. > In contrast, unauthenticated keying was the primary goal of BTNS (RFC = 5387), which thus should be discussed in this doc as well: Both RFC 4322 and 5387 were barely implemented anywhere. Dredging them = up as examples is actively harmful to trying to get a term that everyone = can agree on. They were well-intentioned failures, like many efforts in = the IETF; let's move on. --Paul Hoffman= From nobody Wed Mar 19 11:02:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947411A07DC for ; Wed, 19 Mar 2014 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 8cmgMi6oUgpa for ; Wed, 19 Mar 2014 11:02:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 49F411A06EA for ; Wed, 19 Mar 2014 11:02:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2JI1MMn009866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 11:01:22 -0700 (PDT) Message-ID: <5329DB72.1010701@isi.edu> Date: Wed, 19 Mar 2014 11:01:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <5328C2F2.5040204@bbn.com> <5329CCD8.7050304@isi.edu> <600E347F-9CCA-4C31-BFF7-07C239D59DE3@vpnc.org> In-Reply-To: <600E347F-9CCA-4C31-BFF7-07C239D59DE3@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/x5mllBDTF-BXtH1bNBRw35WorMo Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 18:02:34 -0000 On 3/19/2014 10:37 AM, Paul Hoffman wrote: > On Mar 19, 2014, at 9:59 AM, Joe Touch wrote: > >> This further underscores that OE is *not* unauthenticated keying. > > It underscored that OE *as defined in RFC 4322* is not > unauthenticatedkeying. As many people here have said repeatedly, we > don't care about what the authors of that document said: the term has > be reappropriated to mean best-effort keying triggered without the > user's knowledge. Best effort keying is not at all the same thing as unauthenticated keying. Unauthenticated keying is one of many possible alternatives that best-effort keying can try and fallback on. Misuse of terms by others is an opportunity :-) to educate, not to be driven by external forces. >> In contrast, unauthenticated keying was the primary goal of BTNS >> (RFC5387), which thus should be discussed in this doc as well: > > Both RFC 4322 and 5387 were barely implemented anywhere. Dredging > themup as examples is actively harmful to trying to get a term that everyone > can agree on. They were well-intentioned failures, like many efforts in > the IETF; let's move on. Why do you think those are failures, but everyone else's misuse of the terms defined in those documents are not? Even failures can define terms, e.g., one of the most popular terms for a commercial failure is an 'Edsel'. Joe From nobody Wed Mar 19 12:08:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CDE1A042B for ; Wed, 19 Mar 2014 12:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 rfsllpruaTNL for ; Wed, 19 Mar 2014 12:08:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D4B681A06FD for ; Wed, 19 Mar 2014 12:08:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 030A92003D; Wed, 19 Mar 2014 16:27:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C8BA563AB2; Wed, 19 Mar 2014 15:08:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B53EA63A9E; Wed, 19 Mar 2014 15:08:15 -0400 (EDT) From: Michael Richardson To: Stephen Kent In-Reply-To: <5328C2F2.5040204@bbn.com> References: <5328C2F2.5040204@bbn.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/I_Abz19ZPvy56zoJkPz2UrWZqoE Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 19:08:30 -0000 --=-=-= Stephen Kent wrote: > - it proposes yet another term for the subject of our protracted > terminology discussion > - it defines what that term means, based on a STRINT workshop breakout > group > - it argues why "opportunistic encryption" is a poor terminology choice > for what we want to describe > - it examines some other aspects of terminology for key management > that yields authenticated, anonymous, or pseudonymous communications Change: The term opportunistic encryption (OE) was coined by Michael Richardson in "Opportunistic Encryption using the Internet Key Exchange (IKE)" an Informational RFC [RFC4322]. In this RFC the term is defined as: To: The term opportunistic encryption (OE) was documented by Michael Richardson et al in "Opportunistic Encryption using the Internet Key Exchange (IKE)" an Informational RFC [RFC4322]. The term was coined by John Gilmore and Hugh Daniel in the mid-1990s. In this RFC the term is defined as: -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUynrH4qHRg3pndX9AQLRMQQAnkLoBGDnuZ4SW0PKs7cSFtIbfUM8MFLp wcOjFbIpyHeBYbE8wtbjaahbqBxkyL7orc9gygFpLweRG7+TIHbRtCWIoa0vjeTj DQfndQzMtA2Ord+Z1YgtDcx0NbU3NYPUjLfbXv9oh0+oyVRE55LQzf99vdSJrkcT fMobRvbDYsk= =TRq9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 19 13:03:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E699B1A07DF for ; Wed, 19 Mar 2014 13:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O5JgtkUqf5e for ; Wed, 19 Mar 2014 13:03:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 43CEC1A07E5 for ; Wed, 19 Mar 2014 13:03:35 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JK3LP5038766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 13:03:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5329DB72.1010701@isi.edu> Date: Wed, 19 Mar 2014 13:03:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EEA8ED1-2C4D-4468-AB02-70980D2A598C@vpnc.org> References: <5328C2F2.5040204@bbn.com> <5329CCD8.7050304@isi.edu> <600E347F-9CCA-4C31-BFF7-07C239D59DE3@vpnc.org> <5329DB72.1010701@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_CXRtxwuZjXMRJpHWzeUQDDLgEk Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 20:03:36 -0000 On Mar 19, 2014, at 11:01 AM, Joe Touch wrote: > On 3/19/2014 10:37 AM, Paul Hoffman wrote: >> On Mar 19, 2014, at 9:59 AM, Joe Touch wrote: >>=20 >>> This further underscores that OE is *not* unauthenticated keying. >>=20 >> It underscored that OE *as defined in RFC 4322* is not >> unauthenticatedkeying. As many people here have said repeatedly, we >> don't care about what the authors of that document said: the term has >> be reappropriated to mean best-effort keying triggered without the >> user's knowledge. >=20 > Best effort keying is not at all the same thing as unauthenticated = keying. Correct. Stephen has already made that clear in his -00 draft. > Unauthenticated keying is one of many possible alternatives that = best-effort keying can try and fallback on. Yep. > Misuse of terms by others is an opportunity :-) to educate, not to be = driven by external forces. The fact that they use the terms differently than you does not mean it = is a misuse; this is a community effort. >>> In contrast, unauthenticated keying was the primary goal of BTNS >>> (RFC5387), which thus should be discussed in this doc as well: >>=20 >> Both RFC 4322 and 5387 were barely implemented anywhere. Dredging >> themup as examples is actively harmful to trying to get a term that = everyone >> can agree on. They were well-intentioned failures, like many efforts = in >> the IETF; let's move on. >=20 > Why do you think those are failures, but everyone else's misuse of the = terms defined in those documents are not? They were failures because they were extremely thinly deployed. We can = argue what the reasons for that is (I believe there were different = reasons for the two technologies), but they are both essentially unused. > Even failures can define terms, e.g., one of the most popular terms = for a commercial failure is an 'Edsel'. Edsels were more widely deployed than BTNS. --Paul hoffman= From nobody Wed Mar 19 13:44:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C5E1A0783 for ; Wed, 19 Mar 2014 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 LNt51eoeKS87 for ; Wed, 19 Mar 2014 13:44:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id B0DCE1A06D3 for ; Wed, 19 Mar 2014 13:44:50 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB421.namprd03.prod.outlook.com (10.141.78.140) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 19 Mar 2014 20:44:40 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0898.005; Wed, 19 Mar 2014 20:44:40 +0000 From: Christian Huitema To: Nico Williams , Stephen Kent Thread-Topic: [saag] better ** terminology Thread-Index: AQHPQvYRiUTr6JIIf0OlJkyioxhzMprndBOAgAETVQCAACK8gIAANmug Date: Wed, 19 Mar 2014 20:44:39 +0000 Message-ID: <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 01559F388D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(87936001)(80022001)(63696002)(2656002)(20776003)(76576001)(47446002)(94946001)(65816001)(87266001)(90146001)(76796001)(56816005)(97336001)(85306002)(79102001)(74706001)(97186001)(74876001)(74366001)(33646001)(74316001)(59766001)(77982001)(92566001)(95666003)(93516002)(86612001)(51856001)(74662001)(46102001)(86362001)(31966008)(54356001)(53806001)(83322001)(95416001)(50986001)(47976001)(85852003)(81342001)(83072002)(47736001)(81542001)(4396001)(69226001)(49866001)(74502001)(81686001)(81816001)(76482001)(80976001)(93136001)(54316002)(56776001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB421; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BFFBF485.AC141425.30F9D147.88ECF200.201AE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/y-_-Q4hleCEQ5Vk09NMikT6eJdY Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 20:44:53 -0000 PiBBbnl3YXlzLCB0aGVyZSdzIGEgc3BlY3RydW0gb2Ygc2VjdXJpdHkuICBUaGUga2V5IGlzIHRv IGRlc2NyaWJlIHRoYXQgc3BlY3RydW0gYXBwcm9wcmlhdGVseSAtLSBhcHByb3ByaWF0ZWx5IGZv ciBfdHlwaWNhbCB1c2Vyc18gYmVjYXVzZSB3aGF0ZXZlciB0ZXJtaW5vbG9neSB3ZSBzZXR0bGUg b24gd2lsbCBhbG1vc3QgY2VydGFpbmx5IGZpbmQgaXRzZWxmIGludG8gbWFzcyBjb25zdW1lciBj b25zY2lvdXNuZXNzLg0KDQpUaGVyZSBkZWZpbml0ZWx5IGlzIGEgc3BlY3RydW0uIE15IHBlcnNv bmFsIGdyYWR1YXRpb24gd291bGQgYmUgc29tZXRoaW5nIGxpa2U6DQoNCjEpIE5vdGhpbmcNCjIp IFByZXZlbnRpb24gb2YgcGFzc2l2ZSBhdHRhY2tzLg0KMykgUHJldmVudGlvbiBvZiBwYXNzaXZl IGF0dGFja3MgYW5kIG5vbi1yZWFsLXRpbWUgZGV0ZWN0aW9uIG9mIGFjdGl2ZSBhdHRhY2tzLg0K NCkgUHJldmVudGlvbiBvZiBib3RoIGFjdGl2ZSBhbmQgcGFzc2l2ZSBhdHRhY2tzIGluIHJlYWwg dGltZS4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlICJub24tcmVhbC10aW1lIGRldGVjdGlvbiIgaXMg YWN0dWFsbHkgdmFsdWFibGUuIFllcywgdGhlIGNvbW11bmljYXRpb24gd2lsbCBiZSBsaXN0ZW5l ZCB0byBhbmQgbWF5YmUgdGFtcGVyZWQgd2l0aC4gQnV0IHRoZSBhY3QgY291bGQgc3RpbGwgYmUg ZGV0ZWN0ZWQgbGF0ZXIsIG1heWJlIG9uIGEgc2Vjb25kIGNvbm5lY3QsIG9yIGEgY29ubmVjdGlv biBmcm9tIGEgZGlmZmVyZW50IGxvY2F0aW9uLiBBbmQgdGhhdCB3aWxsIGF0IGEgbWluaW11bSBj cmVhdGUgYSBQUiBwcm9ibGVtIGZvciB3aG9ldmVyIGlzIGRvaW5nIGl0Li4uDQoNCi0tIENocmlz dGlhbiBIdWl0ZW1hDQoNCg0K From nobody Wed Mar 19 13:50:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740AB1A0464 for ; Wed, 19 Mar 2014 13:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 NbnI_pbqvhWt for ; Wed, 19 Mar 2014 13:50:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DE10B1A07E5 for ; Wed, 19 Mar 2014 13:50:52 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2JKo8Nv025537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 13:50:08 -0700 (PDT) Message-ID: <532A0300.70706@isi.edu> Date: Wed, 19 Mar 2014 13:50:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <5328C2F2.5040204@bbn.com> <5329CCD8.7050304@isi.edu> <600E347F-9CCA-4C31-BFF7-07C239D59DE3@vpnc.org> <5329DB72.1010701@isi.edu> <7EEA8ED1-2C4D-4468-AB02-70980D2A598C@vpnc.org> In-Reply-To: <7EEA8ED1-2C4D-4468-AB02-70980D2A598C@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZBst81mfofPaaY0-A-uVT-WLEJk Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 20:50:54 -0000 On 3/19/2014 1:03 PM, Paul Hoffman wrote: ... > Edsels were more widely deployed than BTNS. Yes, but BTNS foresaw the need for the benefit and utility of unauthenticated keying, which is more than can be said for OE. Co-opting the concept and calling it OE isn't going to change that. Joe From nobody Wed Mar 19 13:54:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A61A07F3 for ; Wed, 19 Mar 2014 13:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhkW4I_dvkdJ for ; Wed, 19 Mar 2014 13:54:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECAAE1A07E5 for ; Wed, 19 Mar 2014 13:54:30 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JKsK3a041274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Mar 2014 13:54:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> Date: Wed, 19 Mar 2014 13:54:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> To: saag X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PkYlSh7EorPvOcjSsd4P7Agi1aQ Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 20:54:31 -0000 On Mar 19, 2014, at 1:44 PM, Christian Huitema = wrote: > There definitely is a spectrum. My personal graduation would be = something like: >=20 > 1) Nothing > 2) Prevention of passive attacks. > 3) Prevention of passive attacks and non-real-time detection of active = attacks. > 4) Prevention of both active and passive attacks in real time. This seems like a short, useful ladder that is easy to understand and = probably easy to design to. --Paul Hoffman= From nobody Wed Mar 19 14:10:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F921A03C2 for ; Wed, 19 Mar 2014 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 B9KAKKTqfzM0 for ; Wed, 19 Mar 2014 14:10:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (unknown [69.163.253.176]) by ietfa.amsl.com (Postfix) with ESMTP id EF8571A0335 for ; Wed, 19 Mar 2014 14:10:03 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 5F6D96B0206 for ; Wed, 19 Mar 2014 14:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UeyWN4S8wssIg0HCfTdi iUJ11uA=; b=XpqZZYAjHOt7mMuQUUXFlfZ8b+qSWTUTb+n/4u9P2Mn1XzoIaNXe hbfU1jQA3ljrfgPpalisoAyO26tqpz5z/BT2LvDYa0vyiZ+VU0gYy/+u+sR99NoB wj/dowKnYNNZRSBIb9PpsZzdhUOtUT6OMHcC20spEb3ON7wbVEx1hBc= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 1452B6B0197 for ; Wed, 19 Mar 2014 14:09:54 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so7575198wes.17 for ; Wed, 19 Mar 2014 14:09:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U/AnvEwN1yXDCtSIi/PtShHfhk66KPp1it3H0RQ3vdg=; b=QxhXj5rrgXlBRbbUcuW+yP1ANL2lsfITd+WWo0QdME+I94XVyf8mUYZ/jHnkE5/arY 4H83M0kn4Hnt6M/py0tDhyXMKF12ltLdNTTGS9bgYbWnsBAvhWBSMmhRXAjobmz3FTie AgjxiazxA8LJusF08RrhNnPmtAUQjAQabrJJS7bdB1uc99GWg/Iqzcp3du+h1HyMbGZX XF9dqr7vIjILbAbIOFDr9jIhITPhKPymW1q/Px99K0oxl1MD+jUmfsk2/qXZKg6Y0fVs 9cMU5VFTrb4bz4UuZVyCCauJ6PEcGJsat8S+3kjoxOFYUOq5ORMIHribvyoJ+IW7CSZK bWtQ== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr3659449wjc.71.1395263393893; Wed, 19 Mar 2014 14:09:53 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 14:09:53 -0700 (PDT) In-Reply-To: <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> Date: Wed, 19 Mar 2014 16:09:53 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/c_ZqpU9V3eje-SryUETXaJ3LOik Cc: saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 21:10:05 -0000 On Wed, Mar 19, 2014 at 3:54 PM, Paul Hoffman wrote: > On Mar 19, 2014, at 1:44 PM, Christian Huitema wrote: > >> There definitely is a spectrum. My personal graduation would be something like: >> >> 1) Nothing >> 2) Prevention of passive attacks. >> 3) Prevention of passive attacks and non-real-time detection of active attacks. >> 4) Prevention of both active and passive attacks in real time. > > This seems like a short, useful ladder that is easy to understand and probably easy to design to. +1. Note that things like MinimaLT, CurveCP, even the old -and very obsolete- NFS AUTH_DH (later mech_dh) protocols can easily provide the basis for (2), (3), and (4). You always do an ECDH exchange using a fixed (for a while) per-origin, per-identity, or per-{origin, identity} key on the client side, and a key that you can hopefully validate with DANE for the server. You get: - always at least (2) - (4) whenever you can validate the peer's public key with DANE or similar or have previously established trust on the given peer's public key or can verify the key out of band - (3) if you can do something like SRP/PAKE/DIGEST/SCRAM/Kerberos/whatever at a higher layer - (3*) when you're willing to LoF/TOFU the peer's key (eventually building trust) (this way you force any MITM to always be in the middle) OTR basically covers this range. Nico -- From nobody Wed Mar 19 14:20:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E51A0538 for ; Wed, 19 Mar 2014 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 5TyHUvh6y-GZ for ; Wed, 19 Mar 2014 14:20:07 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D04661A0761 for ; Wed, 19 Mar 2014 14:20:06 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so9368589qac.27 for ; Wed, 19 Mar 2014 14:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+srjAb7Qmar+aj03byqfONqDEZ/bvFDVwrPjliM6Fw8=; b=cAmgSbkgWMODqn3i9s1NkPPlCU5uiw4lsybgvKob3sL9uuhEj5IBRXnVoDsr1k/aSL D4+mCrbytIAc4Ct0RZJYISYG6QXCFtf+AqRrhkEiYpWUpYFhB3zWTLUQytUreOfCQCb/ yrwQIWaVMQjInlOXU87mCoJGvMYa0cTiZsj6j9vEllMJnacH7PA/lnhC1uuYBeTPi95w 4+PW52S6EfnAE6yvN5IvEh3UHfFNQzWV6r5KjpYf8QyQb6MA942UYhjMoiH6VX2Us7E9 o3xQiL+blhNN+ZUe8vfj7kc/0OCQ347SQHTnQ6Fv5Xsqv30Z4lC3VgLGyHkeB/qvEbYS eZ5g== MIME-Version: 1.0 X-Received: by 10.140.109.132 with SMTP id l4mr18976632qgf.72.1395263997975; Wed, 19 Mar 2014 14:19:57 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Wed, 19 Mar 2014 14:19:57 -0700 (PDT) In-Reply-To: References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> Date: Wed, 19 Mar 2014 21:19:57 +0000 X-Google-Sender-Auth: hPze6u2va0EgGSOxsevOK1v1vh8 Message-ID: From: Ben Laurie To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BaQ2iy0iIhO_XGfC-p-OYhnGaTA Cc: Paul Hoffman , saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 21:20:08 -0000 Whilst I broadly totally agree with this spectrum.... On 19 March 2014 21:09, Nico Williams wrote: > On Wed, Mar 19, 2014 at 3:54 PM, Paul Hoffman wrote: >> On Mar 19, 2014, at 1:44 PM, Christian Huitema wrote: >> >>> There definitely is a spectrum. My personal graduation would be something like: >>> >>> 1) Nothing >>> 2) Prevention of passive attacks. >>> 3) Prevention of passive attacks and non-real-time detection of active attacks. >>> 4) Prevention of both active and passive attacks in real time. >> >> This seems like a short, useful ladder that is easy to understand and probably easy to design to. > > +1. > > Note that things like MinimaLT, CurveCP, even the old -and very > obsolete- NFS AUTH_DH (later mech_dh) protocols can easily provide the > basis for (2), (3), and (4). You always do an ECDH exchange using a > fixed (for a while) per-origin, per-identity, or per-{origin, > identity} key on the client side, and a key that you can hopefully > validate with DANE for the server. You get: > > - always at least (2) > - (4) whenever you can validate the peer's public key with DANE or > similar or have previously established trust on the given peer's > public key or can verify the key out of band ... WTF? "DANE and similar" are perfect systems that cannot be actively attacked? The other two options are vague enough to at least permit perfection. > - (3) if you can do something like > SRP/PAKE/DIGEST/SCRAM/Kerberos/whatever at a higher layer > - (3*) when you're willing to LoF/TOFU the peer's key (eventually > building trust) (this way you force any MITM to always be in the > middle) > > OTR basically covers this range. +1 to the rest. From nobody Wed Mar 19 14:36:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059031A078A for ; Wed, 19 Mar 2014 14:36:42 -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 xIFCdLtEnwgy for ; Wed, 19 Mar 2014 14:36:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB41A04BA for ; Wed, 19 Mar 2014 14:36:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 304D82AB26D; Wed, 19 Mar 2014 21:36:31 +0000 (UTC) Date: Wed, 19 Mar 2014 21:36:31 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140319213630.GF24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Qv3qc_8kODKZ5T4KDpWwsbiKTDw Subject: Re: [saag] better ** terminology 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: Wed, 19 Mar 2014 21:36:42 -0000 On Wed, Mar 19, 2014 at 09:19:57PM +0000, Ben Laurie wrote: > ... WTF? "DANE and similar" are perfect systems that cannot be > actively attacked? "Prevent" was used loosely upthread. I prefer to use terms like "downgrade-resistant", "MITM-resistant", ... which suggest mitigation rather than immunity. My long-term plan for Postfix with DANE is to use DANE for "introduction", and other mechanisms for key-continuity. When key continuity (Tack, or similar) fails, go back to DANE, but log the key continuity failure. Thus MITM resistance on introduction and detection thereafter, unless what's compromised is the peer endpoint or its keys. -- Viktor. From nobody Wed Mar 19 14:39:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60B51A078A for ; Wed, 19 Mar 2014 14:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Niu8fF21mkE for ; Wed, 19 Mar 2014 14:39:40 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (agjbgdcfdbec.dreamhost.com [69.163.253.142]) by ietfa.amsl.com (Postfix) with ESMTP id 01D771A0789 for ; Wed, 19 Mar 2014 14:39:39 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 5273B201D6FCA for ; Wed, 19 Mar 2014 14:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zo37AY+qxM7xbITP4MLh EH58YvU=; b=ZzStbk5D7HhA3a9NTjQAAYjX/qSg07IjAi4UawDiJfl6ftwZ7VWh tITZIn22UBl706BV+W5dHqDsff0Gg5D0Jza24GQ5VxdwMD+q36CbOTTAJgwIHDe0 c3ilO2h/2RThAF5tVYBfEWTC3vCDdWvEnQyl42M6F8m/qyengERY4B0= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 07956201D6FC9 for ; Wed, 19 Mar 2014 14:39:30 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so7756053wgh.32 for ; Wed, 19 Mar 2014 14:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=onl0yW2Ax/AO7rtuFhbs8Dr4He15eMboqoVZ7p4W9Vs=; b=JTvny5nB9sMWSyis0OrIeq8nloWbsY190palGnYPXUjDKRfFfHWRwO5xgBVc1w/Kxr jI2FZmTRE/sKfSP20c6EAomdy/qHXCH2H7KvidLHuPW+F4RIyejVf/TwEKKczb4GG3ll t5tc01gOs1U5Nx6R9uWfzEBsDRptxoulV6QkoWZXTDIHyETnzihBbEITuUsdDLm9ouam 27jYevBKQ+/Loy+PFeIlyB9vYOqhgEY+7QCJlX6vN9okWRu9d1LDu63yC1+wpUid2BZb bTn5xKylarY65VTp+1ptRJvq7OnUtBP+9tOvOhQljbntmD4KzlQY2Fd51vit7tqfpFuL npnw== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr20975327wib.5.1395265169435; Wed, 19 Mar 2014 14:39:29 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 14:39:29 -0700 (PDT) In-Reply-To: References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> Date: Wed, 19 Mar 2014 16:39:29 -0500 Message-ID: From: Nico Williams To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IOh-dJSz2XB51Cyo5oLpsjcHnVU Cc: Paul Hoffman , saag Subject: Re: [saag] better ** terminology 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, 19 Mar 2014 21:39:42 -0000 On Wed, Mar 19, 2014 at 4:19 PM, Ben Laurie wrote: > Whilst I broadly totally agree with this spectrum.... > > On 19 March 2014 21:09, Nico Williams wrote: >> Note that things like MinimaLT, CurveCP, even the old -and very >> obsolete- NFS AUTH_DH (later mech_dh) protocols can easily provide the >> basis for (2), (3), and (4). You always do an ECDH exchange using a >> fixed (for a while) per-origin, per-identity, or per-{origin, >> identity} key on the client side, and a key that you can hopefully >> validate with DANE for the server. You get: >> >> - always at least (2) >> - (4) whenever you can validate the peer's public key with DANE or >> similar or have previously established trust on the given peer's >> public key or can verify the key out of band > > ... WTF? "DANE and similar" are perfect systems that cannot be > actively attacked? Oh come now. No system is perfect. Some systems (or some trust anchors, or ...) will meet the user's "policy", whatever that might be. There's nothing really new here. Yes, no one will want a re-run of the TLS server PKI, with a gzillion trust anchors (and therefore no trust). There's a certain amount of conversation state that has to be assumed if we're to have a complex conversation spanning any realistic amount of time. But it is important to establish that state. The above does a bit of that. > The other two options are vague enough to at least permit perfection. > >> - (3) if you can do something like >> SRP/PAKE/DIGEST/SCRAM/Kerberos/whatever at a higher layer I neglected to mention that the above one gets you (4) if the SRP/PAKE/... gets you (4). >> - (3*) when you're willing to LoF/TOFU the peer's key (eventually >> building trust) (this way you force any MITM to always be in the >> middle) How are any of those any more "perfect" than DANE? There's still a TTP in the Kerberos case, and there *might* be one in the other cases (doing something like "passthrough" authentication). See what I mean? If you question DANE or any other authentication mechanism's value, I can question the rest. If we assume going in that we agree already that the user will have come to decide what's appropriate for them (usually they won't have a lot of choices, if any anyways), then we don't have to pursue this tangent. >> OTR basically covers this range. > > +1 to the rest. Nico -- From nobody Wed Mar 19 21:29:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432151A0359 for ; Wed, 19 Mar 2014 21:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 u1w8DBZyQILr for ; Wed, 19 Mar 2014 21:29:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0890F1A033E for ; Wed, 19 Mar 2014 21:29:14 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2K4T552021670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Mar 2014 00:29:05 -0400 Received: from bofh.nohats.ca (vpn-59-131.rdu2.redhat.com [10.10.59.131]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2K4T4bL009021 for ; Thu, 20 Mar 2014 00:29:05 -0400 Message-ID: <532A6E90.9040002@redhat.com> Date: Thu, 20 Mar 2014 00:29:04 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> <20140319213630.GF24183@mournblade.imrryr.org> In-Reply-To: <20140319213630.GF24183@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Aa4rBiSB2S8vDKqADG4FUHX_cZg Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 04:29:16 -0000 On 03/19/2014 05:36 PM, Viktor Dukhovni wrote: > My long-term plan for Postfix with DANE is to use DANE for > "introduction", and other mechanisms for key-continuity. When key > continuity (Tack, or similar) fails, go back to DANE Because the chance that a registrar/registry is hacked, is greater than the chance of the admin screwing up his TACK ping? I hope you leave an option in for those who are fine with just DANE :P Pinning is the new /etc/hosts Paul From nobody Wed Mar 19 22:20:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AF31A06CC for ; Wed, 19 Mar 2014 22:20:56 -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 rMDbb4oBFwnM for ; Wed, 19 Mar 2014 22:20:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 05C691A07FE for ; Wed, 19 Mar 2014 22:20:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E9B2D2AB22D; Thu, 20 Mar 2014 05:20:43 +0000 (UTC) Date: Thu, 20 Mar 2014 05:20:43 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140320052043.GI24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <5fd58218cf6b4fa5a537acede9fe0390@BLUPR03MB424.namprd03.prod.outlook.com> <77FA2732-8468-40EA-9F84-ABB5974DD0C1@vpnc.org> <20140319213630.GF24183@mournblade.imrryr.org> <532A6E90.9040002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532A6E90.9040002@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4sRnRyqLOtYfEzqNzDwB8-vO7S8 Subject: Re: [saag] better ** terminology 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: Thu, 20 Mar 2014 05:20:56 -0000 On Thu, Mar 20, 2014 at 12:29:04AM -0400, Paul Wouters wrote: > > My long-term plan for Postfix with DANE is to use DANE for > > "introduction", and other mechanisms for key-continuity. When key > > continuity (Tack, or similar) fails, go back to DANE > > Because the chance that a registrar/registry is hacked, is greater > than the chance of the admin screwing up his TACK pin? Because we'll log the public key fingerprint and let the administrator decide whether he cares to contact the remote site to check what happened. Note no interruption of service, just a log entry for those who want to trust, but verify. > I hope you leave an option in for those who are fine with just DANE :P This is not the type of behaviour that I would (or Wietse would let me) hard-code into Postfix. > Pinning is the new /etc/hosts To be fair Tack is intended to be a bit more dynamic than that, we'll see whether it gains any traction. We DANE for re-sync, and just a log entry with DANE verified re-sync, the noise should be fine. Anyway this is all rather tentative, Tack has to first be available in TLS toolkits (OpenSSL in my case), and I'll probably have to wait quite some time before that's the case. -- Viktor. From nobody Thu Mar 20 10:31:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA771A07C1 for ; Thu, 20 Mar 2014 10:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 klVc3pO3c9-u for ; Thu, 20 Mar 2014 10:31:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C59F11A08FE for ; Thu, 20 Mar 2014 10:31:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54314 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQgoP-0001Xd-BR for saag@ietf.org; Thu, 20 Mar 2014 13:31:25 -0400 Message-ID: <532B25EC.803@bbn.com> Date: Thu, 20 Mar 2014 13:31:24 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <8BB2E0FA-9234-43D7-AD61-19CFF06FE591@vpnc.org> In-Reply-To: <8BB2E0FA-9234-43D7-AD61-19CFF06FE591@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/habJvywz-0C5OrvWdsbusMhFrp0 Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 17:31:39 -0000 Paul, > On Mar 18, 2014, at 3:04 PM, Stephen Kent wrote: > >> I have just posted an I-D that does a few things: >> >> - it proposes yet another term for the subject of our protracted terminology discussion > The protracted terminology discussion on SAAG seemed to end with more people wanting to use "opportunistic encryption" with a new definition rather than making up a new term. I assume that the SEC ADs will inform the list when they determine consensus. I didn't see the discussion "end." I tok a break to publish the I-D, as Stephen Farrell requested. >> - it defines what that term means, based on a STRINT workshop breakout group > I do like most of the seven points in section 1; they capture what I think is a likely consensus of the discussion so far. thanks. >> - it argues why "opportunistic encryption" is a poor terminology choice >> for what we want to describe > ...at which point it goes off the rails. It tries too hard to make the old term have an important meaning. That discussion also skips over some of the obvious flaws with your new term. For example, there is no expectation that the adoption of PE will be high enough to justify the term "pervasive". That kind of overstated marketing is like naming a protocol "simple". :-) Gee, that sounds a bit pejorative. I prefer to view the text as a reasoned, scholarly discussion of terminology :-). The term "opportunistic encryption" has a well defined meaning. The deployment status of the design documented there is irrelevant when deciding whether the term is well defined and whether it is meaningfully distinct from other techniques that have different names. One also should note that Paul Wouters has resurrected the notion from 4322 in a revised design (presented to SAAG and IPSECME). The new design avoids what he and Michael determined to be major impediments to use in the old design. Finally, how can you say that whatever we do to counter PM cannot hope to be sufficiently widely deployed to be called "pervasive?" Stephen Farrell's soon-to-be-RFC defines pervasive in a fashion that tempers the term. Certainly our goal is to have easy to use encryption be as widely deployed as the monitoring it hopes to counter, right? >> - it examines some other aspects of terminology for key management >> that yields authenticated, anonymous, or pseudonymous communications > No offense, but most of that is just selling well past the agreement. Many of the definitions in Section 2 are not universally agreed on, and trying to force those terms down people's throats is likely to cause the important stuff in the definition to be ignored. You and I already disagreed on the terms in Section 2 when I asked for you feedback a couple of months ago. I think you even said that nobody cares what RFC 4949 says. We disagree on the utility of 4949, and maybe on the desirability of technically accurate terminology in RFCs. I still believe we are not the IMTF and that good terminology matters. >> I extracted this text form a bigger document, and made changes based on the debate >> that has been taking place on SAAG, replacing my preferred "opportunistic keying" >> with a term that seems tailor made to the problem we're addressing :-). > Making the jacket to be five sizes too large just in case we gain a lot of weight is not necessarily good tailoring. Please strongly consider using the term that we had previously agreed on. "We" previously agreed upon? Not for all values of we :-). Steve From nobody Thu Mar 20 10:34:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E11A0914 for ; Thu, 20 Mar 2014 10:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 VWQ5YBN-v70Y for ; Thu, 20 Mar 2014 10:34:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 82E711A08FA for ; Thu, 20 Mar 2014 10:34:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35413 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQgrR-0001ag-Dj for saag@ietf.org; Thu, 20 Mar 2014 13:34:33 -0400 Message-ID: <532B26A8.2080305@bbn.com> Date: Thu, 20 Mar 2014 13:34:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <20140319155535.GY24183@mournblade.imrryr.org> In-Reply-To: <20140319155535.GY24183@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2dO8mFp95NETZWSuUADw_vBx2bk Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 17:34:44 -0000 Viktor, > On Wed, Mar 19, 2014 at 11:19:48AM -0400, Stephen Kent wrote: > >>> There is also a statefulness in the models (like LoF and TOFU) >>> that is not fully captured. A connection that starts as >>> LoF could become strongly authenticated later through an >>> out-of-band channel to become ?authenticated?. >> Agreed. Additional material discussing LoF/TOFU is needed. > Would it also be appropriate to briefly discuss the use of DANE to > harden PE against MITM downgrade attacks? As in the DANE SMTP and > SRV drafts, the idea is that when a server has associated TLSA RRs, > encryption (via TLS) becomes mandatory, and when some of the TLSA > RRs are "usable", authentication is also mandatory. The result is > I think not too dissimilar from the original OE in IPSEC, in that > what you get is an authenticated connection without prior bilateral > arrangement (fax effect and all that). I had prepared a much longer document, which examines key management options for a variety of security protocols, and it notes the value of using DANE as a way to provide authenticated key management (as opposed to the Web PKI). I agree that DANE-supplied keys for use with IPsec seems to be an accurate example of OE, as pre 4322. > [ Does the PE draft inspire a better name for "opportunistic DANE > TLS", or is that name about right. ] I have not thought about that yet. Steve From nobody Thu Mar 20 10:50:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C541A074D for ; Thu, 20 Mar 2014 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 l47zoe-Pr9Qt for ; Thu, 20 Mar 2014 10:50:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 50A3B1A0406 for ; Thu, 20 Mar 2014 10:50:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46371 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WQh74-0000yW-6B for saag@ietf.org; Thu, 20 Mar 2014 13:50:42 -0400 Message-ID: <532B2A6A.3000205@bbn.com> Date: Thu, 20 Mar 2014 13:50:34 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TbaR1WfIXFE4MBRxccIn0NeaRu4 Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 17:50:46 -0000 Nico, > On Wed, Mar 19, 2014 at 10:19 AM, Stephen Kent wrote: >>> On 3/18/14, 3:04 PM, "Stephen Kent" wrote: >>> There is also a statefulness in the models (like LoF and TOFU) >>> that is not fully captured. A connection that starts as >>> LoF could become strongly authenticated later through an >>> out-of-band channel to become Å’authenticated¹. >> Agreed. Additional material discussing LoF/TOFU is needed. > Oh man, one term we most certainly can't use is OA == opportunistic > authentication... Too close to OAuth. agreed! > Anyways, there's a spectrum of security. The key is to describe that > spectrum appropriately -- appropriately for _typical users_ because > whatever terminology we settle on will almost certainly find itself > into mass consumer consciousness. In part, that's why I like Pervasive Encryption. If we say we're trying to combat pervasive monitoring, the terminology overlap seems to make it natural, no matter what we do :-). On the other hand, one of the precepts Steve Bellovin and other have suggested is that we don't make this visible to users, so that they don't get confused and don't see it as an alternative to authentication sessions. In that case, users don't neer to know exactly what we're doing, or if it's the same for every app. > Alternatively we need a terminology that is explicitly chosen such > that it would not be used in marketing materials nor otherwise be > likely to come to the attention of mass consumers. Internal to the IETF we need terminology that is more precise that PE, so that we can distinguish among different solution options, etc. But it can all be subsumed, for external consumption, under the PE label. > The main problem is that explaining MITM attacks is not easy, and yet > we need MITM attack resistance/detection in many, many cases (e.g., > coffee shop wifi). I agree with the example, but, again, if we, as a community, decide that MiTYM detection is not mandatory and the result is not visible, then ... > At one end of the spectrum we have: > > - no real security > > progressing through: > > - security against passive attacks > - LoF/TOFU: some security against active attacks if you remember keys > for long (i.e., force an MITM to be there the first time and always) > - security against passive and active criminal attackers > (authentication + encryption) > > with users _today_ only really being aware of the last one (security > against criminal attackers). yep. > (I say "criminal" to distinguish from LEO/TLA agency types.) yep. > Then we have: > > - security against passive and active foreign TLA agencies (difficult) > - security against passive and active LEO/TLA agenciess whose > jurisdiction you're in (exceedingly difficult / impossible at the > limit, but possible when you're not interesting) I don't disagree with the bullets above, but what I think we should consider when creating criteria for evaluation of new (and existing) protocols is a prioritized list of attack classes (vs. threats). The list I have in mind is: 1. purely passive attacks (traditional passive wiretapping) against payloads 2. payload wiretapping enabled by an active attack such as DNS response injection (which may yield a MiTM atack) 3. wiretapping enabled by exfiltration of traffic keys or a bad PRNG (the result of malware on a machine at one end pf the other) > On a different axis: security against traffic analysis (very, very > hard -- the most difficult). yes, traffic analysis is a bit orthogonal, because it is a function, in part, of the layer at which the payload is encrypted. So one can rate the severity of TA based in part on the layer at which encryption is offered, then based on the extent to which the encrypted traffic still exposes info about communication. > For mass consumption we don't need the last three, but we do need to > cover these three options: > > - security against passive attacks > - LoF/TOFU: some security against active attacks if you remember keys > for long (i.e., force an MITM to be there the first time and always) I'm concerned that the first bullet is a security goal, while the second is an example of a security mechanism > - security against passive and active criminal attackers > (authentication + encryption) again, a pair of security services > and I believe we need terminology that mass consumers can understand. we need to decide if a user will even know when PE is employed. if not, then it may not be important to communicate the distinctions to the masses. Steve From nobody Thu Mar 20 11:41:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6A1A042C for ; Thu, 20 Mar 2014 11:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 XS4AwLeN7Kgi for ; Thu, 20 Mar 2014 11:41:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 59BF51A07E3 for ; Thu, 20 Mar 2014 11:41:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC0FBBE4C; Thu, 20 Mar 2014 18:41:08 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxsqubRvlOCv; Thu, 20 Mar 2014 18:41:08 +0000 (GMT) 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 8EE32BE38; Thu, 20 Mar 2014 18:41:08 +0000 (GMT) Message-ID: <532B3644.1080704@cs.tcd.ie> Date: Thu, 20 Mar 2014 18:41:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <5328C2F2.5040204@bbn.com> In-Reply-To: <5328C2F2.5040204@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DEuMmpSdgWOvHZcp5q5X6LCosXg Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 18:41:22 -0000 Steve, I like lots of the text in the draft, thanks. However, I don't think the PE term is going to be that useful for us and have a possible concern about direction. I also have a suggestion, just to see how it lands... On PE: I think the term as defined is cute and defensible, but I think it'll cause us problems if we try adopt it broadly, since it'll generate too much opposition from the "but I don't want to encrypt" camp. If however, a strong consensus emerged for the PE term, I could live with that but I don't see it yet, and personally I preferred your previous OK suggestion, or re-defining OE. The word opportunistic really does seem to me to be the best match for what I see most people talking about to be honest. About direction: I think that perhaps the draft overspecifies PE/OK/OE in ways, e.g. your point #2 saying PE is not a substitute. We know that in many cases mutually authenticated crypto can be used, but that it is often not used because its perceived as too heavy-weight. Now you do say that the list are characteristics that PE exhibits, so this might just be a case of worthsmithing being needed, but I don't think it'll be useful if we end up with terminology that just causes more arguments, e.g. "that protocol cannot do PE/OK/OE because it would be possible to do mutual" is not where we want to end up. And a suggestion: given that the word opportunistic is what is being used, how's about we describe ways in which the word opportunistic can sensibly be used when discussing keying and encryption. For example by saying that it means doing key exchange and encryption at the opportune time in an opportune manner? In terms of your text that'd mean something like: OLD: PE (for realtime communication) exhibits the following characteristics: NEW: The term opportunistic when used to describe security mechanisms used in a protocol basically means doing key exchange and encryption at an opportune time in an opportune manner, without tightly coupling that with endpoint authentication. Protocols doing key exchange and encryption can usefully be described as opportunistic if they exhibit characteristics such as the following, when those are relevant for the protocol concerned: And then your list, which (modulo wordsmithing), I like. Lastly, I recognise that probably you and I disagree about it, but I do not think that we need to honour the definition of OE as previously used in RFCs. We do need to note it, and say why we're changing it if we do and how any new definition differs from previous usage. Things move on and if we have consensus to re-define that term, that's just fine. I'd be interested in more opinions on that issue. Cheers, S. On 03/18/2014 10:04 PM, Stephen Kent wrote: > I have just posted an I-D that does a few things: > > - it proposes yet another term for the subject of our protracted > terminology discussion > - it defines what that term means, based on a STRINT workshop > breakout group > - it argues why "opportunistic encryption" is a poor terminology choice > for what we want to describe > - it examines some other aspects of terminology for key management > that yields authenticated, anonymous, or pseudonymous communications > > I extracted this text form a bigger document, and made changes based on > the debate > that has been taking place on SAAG, replacing my preferred > "opportunistic keying" > with a term that seems tailor made to the problem we're addressing :-). > > https://datatracker.ietf.org/doc/draft-kent-pervasive-encryption/ > > Steve > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Mar 20 11:48:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3F41A0720 for ; Thu, 20 Mar 2014 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 PJkmPnj0rm31 for ; Thu, 20 Mar 2014 11:48:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C083B1A08DF for ; Thu, 20 Mar 2014 11:48:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15C9620039; Thu, 20 Mar 2014 16:08:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7957363AB2; Thu, 20 Mar 2014 14:48:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 608CB63A9E; Thu, 20 Mar 2014 14:48:39 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <532B3644.1080704@cs.tcd.ie> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/33aG7RcneAMaoTkfzUynxvoGnjA Cc: saag Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 18:48:53 -0000 --=-=-= Stephen Farrell wrote: > broadly, since it'll generate too much opposition from the > "but I don't want to encrypt" camp. If however, a strong Can you tell me more about this camp? I am not familiar with who they are, and what they say. (And I wasn't at STRINT) > And a suggestion: given that the word opportunistic is > what is being used, how's about we describe ways in which > the word opportunistic can sensibly be used when discussing > keying and encryption. For example by saying that it means > doing key exchange and encryption at the opportune time in > an opportune manner? Maybe we could translate the word opportunistic into another language, and use that term. Probably a non-latin based language, but which has good latin-1 transliteration. Seriously. We seem to all know what we mean here, we are just bikeshedding on a word. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUys4BIqHRg3pndX9AQJBoAP/domIgltvl+f0NVBQ9RG6Ma6KCXyM6PD7 Gp7fIFzVpHkTx9/1bKzjQvgx6OuR6EWwjax+RKfcL3+7+lNOnwfO5v8BEuDU94sP veppobBqIRFEtV0nxpXBfK3N4yd8DP+/1o3op6ygSFbWxG0mEgOhh6sQNVvNuFFo PuAW2tEp0Bo= =wwUf -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 20 12:27:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B471A0410 for ; Thu, 20 Mar 2014 12:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt1Nrc5msvio for ; Thu, 20 Mar 2014 12:27:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6A41A034F for ; Thu, 20 Mar 2014 12:27:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 174022AB22D; Thu, 20 Mar 2014 19:26:53 +0000 (UTC) Date: Thu, 20 Mar 2014 19:26:53 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140320192652.GM24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6861.1395341319@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NnXTFrdUih5_WHSWKG2s9exgUsY Subject: Re: [saag] better ** terminology 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: Thu, 20 Mar 2014 19:27:05 -0000 On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: > Probably a non-latin based language, but which > has good latin-1 transliteration. > > Seriously. This is likely not a fruitful direction. None of French, German, Russian, ... yield anything better, mostly variants of the same latin word. I had to switch to Hebrew to find a reasonably short word that was different, but I doubt that "staglani" (with stress on the "nee") is going to serve us better. http://translate.google.com/#iw/en/%D7%A1%D6%B0%D7%AA%D6%B7%D7%92%D7%9C%D6%B8%D7%A0%D6%B4%D7%99 Nor are we likely to gain much clarity from the Maori "kapo". -- Viktor. From nobody Thu Mar 20 13:11:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC841A086D for ; Thu, 20 Mar 2014 13:10:57 -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 jJBTIaPhPLD4 for ; Thu, 20 Mar 2014 13:10:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C4B971A07BD for ; Thu, 20 Mar 2014 13:10:53 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B0511F984; Thu, 20 Mar 2014 16:10:40 -0400 (EDT) Message-ID: <532B4B34.3040106@fifthhorseman.net> Date: Thu, 20 Mar 2014 16:10:28 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Michael Richardson , Stephen Farrell References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> In-Reply-To: <6861.1395341319@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tAt1s07vOKxpfpMRkdXIkhdlCU0k88B0o" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LMK22OzgCD2yG_GKr6No1H24njk Cc: saag Subject: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 20 Mar 2014 20:10:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tAt1s07vOKxpfpMRkdXIkhdlCU0k88B0o Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/20/2014 02:48 PM, Michael Richardson wrote: > We seem to all know what we mean here, we are just bikeshedding on a wo= rd. Indeed, and so far all the existing candidates have contextual meaning or nuance that causes various people to complain. To be clear, i think we're all talking about a best-effort, "on-by-default" encrypted replacement for cleartext as a way to raise the cost of pervasive monitoring. We're just lacking consensus on what we should call that basic concept. here's my abbreviated take on the major complaints for existing candidate terms: --------------------- "Opportunistic encryption" isn't ideal because it has other historic meanings. "Unauthenticated encryption" is inaccurate because some of these connections might actually be authenticated (and because it appears to contrast with "authenticated encryption" which is a specific term of art in the crypto world, related to message integrity) "Pervasive encryption" is likely to be inaccurate because (sadly) we won't win and get everything to be encrypted (it won't be truly pervasive) any time soon. "Opportunistic keying" seems a bit off because we're not just discussing choosing keys, but also talking about the way those keys are used. --------------------- i'll throw one more candidate term into the ring that i think avoids the problems listed above: "Hygienic encryption" I'm proposing this from a public health analogy (e.g. [0]): a best-effort, on-by-default, encrypted replacement for cleartext as a defense against pervasive monitoring is like washing your hands after using the toilet. Everyone should do it for the social good, and it's also not enough to protect you from disaster or deliberate, targeted compromise. I am not going to passionately advocate for this term. i'm aware of https://xkcd.com/927/ I'm just offering a term that everyone might be willing to settle on (even if it's not your favorite) so we can stop the bikeshedding, get this stuff in place, and (most importantly) maintain our focus on even stronger measures that are still needed. --dkg [0] see "Security as an exercise in public health", from http://www.theguardian.com/technology/2014/mar/11/gchq-national-security-= technology --tAt1s07vOKxpfpMRkdXIkhdlCU0k88B0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTK0s0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcu5wQALKqAsY1nilVF9b0qqux+ucD BYSmJ5Z7/3LrCMOu8TVJ8zCmz4dmhqSVZsDqmVlBsKzPVNRNTWboa2cR1es0A41T bjv21APl3sPkiMsA8oR+zkkoAxPrrhe91ixrDtG8st8P2wuFThyidKU10wKt3mDR 4012orv735GuK4Ob90SXfhP5y7BzrAnLc46PP2kpvAKSkTqh8/4G6gZ0K/gAdTzj 2c8mMdgFYrRGJ7nOCbCv8JHf5t82WpbVeVKv8oxNU/tUNeFTnuq0uSC20QHZudFY /3SeVCAyxP6ht9TpKJrgNeZPuTK2ifB/7r/D/eH77x17jXGALFMMcyR9Sl0G8k8p MOkJVzADy1xuJyjLrXP5uNKG0IRDTAngeszT4WzjH0w+Kf36zgK2L9cBOx/yZK6Q 7zQXrbkk2//JpWo6nairBP9hOJaCLx9xMZKhbhpF+bC07HUSE/V7AvkEbp99R0M9 8W83woV5CgkTVfSuvULgtEGhrsETdXP7kLCNJg2ZifNvcLo8UxJ7MyuKo88mfKg6 aZS3inYETASqgyuh6mlqfhA1qY/Cvrw+U5x83ZUTFnjS8mhQ1aDuvl4UAa1RPtxv 9e43eTFPkbCSHHWUoZIQPxkf6G2fXXoyA4aAYPjaFHl2PVxBkzL4FzELx4lrwnvm lLM5duLM/CE9rOHP1ri0 =zMCw -----END PGP SIGNATURE----- --tAt1s07vOKxpfpMRkdXIkhdlCU0k88B0o-- From nobody Thu Mar 20 14:08:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5971A07C4 for ; Thu, 20 Mar 2014 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdQvXZLqiVLP for ; Thu, 20 Mar 2014 14:08:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (agjbgdcfdbhi.dreamhost.com [69.163.253.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13D1A091D for ; Thu, 20 Mar 2014 14:07:53 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 1718794065; Thu, 20 Mar 2014 14:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=UsrBRaqydaRjwu EomOcNNDK3A/I=; b=Hs77HqekGL0+F700VxqRu7LzocZira4sRTnwywxdYR7wid E49+ur/RKYIoO7DIOj9gQ6FOApjYb2LJWgV0CxbcQdpy95P7/uxA/5Cm8kflcqps sAsuvba0tbFbXnMG4JErNSnX14PJL7sj0Fv9CbfUpPMqHbqXt1xl3BtDUfqlM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id C68B49405C; Thu, 20 Mar 2014 14:07:43 -0700 (PDT) Date: Thu, 20 Mar 2014 16:07:43 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20140320210740.GF3471@localhost> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <532B2A6A.3000205@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532B2A6A.3000205@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9WA6ZIgk6Zc-Z_GeVVpRZCFfNOM Cc: saag@ietf.org Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 21:08:04 -0000 On Thu, Mar 20, 2014 at 01:50:34PM -0400, Stephen Kent wrote: > [...] > In part, that's why I like Pervasive Encryption. If we say we're trying > to combat pervasive monitoring, the terminology overlap seems to make it > natural, no matter what we do :-). Cute. > [...] > > >For mass consumption we don't need the last three, but we do need to > >cover these three options: > > > > - security against passive attacks > > - LoF/TOFU: some security against active attacks if you remember keys > >for long (i.e., force an MITM to be there the first time and always) > > I'm concerned that the first bullet is a security goal, while the second > is an example of a security mechanism Substitute "sometimes works against active attackers" for the mechanism. The mechanism is not the salient fact. Although it can be if it means leaking into UIs (e.g., as in traditional SSH LoF). > [...] > > >and I believe we need terminology that mass consumers can understand. > > we need to decide if a user will even know when PE is employed. > if not, then it may not be important to communicate the distinctions > to the masses. > [...] > > On the other hand, one of the precepts Steve Bellovin and other have > suggested is that we don't make this visible to users, so that they > don't get confused and don't see it as an alternative to > authentication sessions. [...] If users won't be aware of it at all then it should just be unauthenticated key agreement + authenticated symmetric encryption. I'd call that "pervasive", yes, but the term will leak into mainstream use. I think we should plan on users knowing about it even if it were easier if they didn't. DANE and/or TACK could be used but now failures to match expected keys will mean making users aware (and they'll need a way to override, won't they, the usual give-my-money-to-the-bad-guys-OK button on a dialog). > >Alternatively we need a terminology that is explicitly chosen such > >that it would not be used in marketing materials nor otherwise be > >likely to come to the attention of mass consumers. > > Internal to the IETF we need terminology that is more precise that PE, > so that we can distinguish among different solution options, etc. But Agreed. > it can all be subsumed, for external consumption, under the PE label. I thought you didn't want users to be aware of it. Why would we need a "PE" label for them to see? :) (My point is we'll have to try to pin the marketing aspect of this down a bit.) > >At one end of the spectrum we have: > > > >[...] > > I don't disagree with the bullets above, but what I think we should consider > when creating criteria for evaluation of new (and existing) protocols is > a prioritized list of attack classes (vs. threats). The list I have > in mind is: > > 1. purely passive attacks (traditional passive wiretapping) > against payloads > 2. payload wiretapping enabled by an active attack such as DNS > response injection > (which may yield a MiTM atack) > 3. wiretapping enabled by exfiltration of traffic keys or a bad PRNG > (the result of malware on a machine at one end pf the other) We can't help local security from a protocol point of view. On the contrary, we can only have network security if we have local security to start with (I know this is a rather defeatist seeming position! but it's correct). Therefore we should not consider (3). Nico -- From nobody Thu Mar 20 14:20:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF861A0783 for ; Thu, 20 Mar 2014 14:20:48 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] 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 sBnn-rmALIQB for ; Thu, 20 Mar 2014 14:20:46 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (unknown [69.163.253.149]) by ietfa.amsl.com (Postfix) with ESMTP id 359941A042C for ; Thu, 20 Mar 2014 14:20:46 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 4331A2005D901 for ; Thu, 20 Mar 2014 14:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PklYkPc2bHu4j1EVyks8 4LOztY0=; b=EiCi42YbXNqiIidpiBqsvEQr0GWaKUCxvGfn1QcG2/U7mj1UQdJp cLI3ExAC5Pk4oW96n/Gz7zMjAvr2LQmlnAHFI5LkpAiihZ7UIHxDA+hbixrjqXSM rsCoH80Tjpil2ebjMV3BoimUShWJkNC6kVyxkXx4wXKBovmHFLT+khQ= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id EAEDA2005D900 for ; Thu, 20 Mar 2014 14:20:36 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so1026875wgh.17 for ; Thu, 20 Mar 2014 14:20:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TcVxjgJ+NBJSi9c3XMSqofqua7vGA7v2RmIWowFYjMw=; b=ZdJkl8vihwQfMr7uqeBVLp8BYU6En1ake0eH3Axp78+Do8amo8GwDVwoTQo+X7DATp SzQAvG6U24i6Q5ERV7TEtLxQm2lFLWuwAbNVh3ycHrllTYjH1OS8Ls66W6We7BY8WUuk OoufPR4bCMgnOhEfyW/zNCUKISFp1oyGWy0585JR7uVcB7/K4bDrQT6Vf+yBO0kr9EN/ DlWDDUA3Ahj8W6zmSzQybYwBNj7nejLpO7rWJvlxNHktOlMZMd8Y8aFEkttDTVwlp3Jy qx6a4i4xu0wOvNUE/bOG3rSrTKaJh8NKHLXpoJyV0O/98LT+f2C+311GN8x/V49xzRFz cinw== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr25974517wij.42.1395350435533; Thu, 20 Mar 2014 14:20:35 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 20 Mar 2014 14:20:35 -0700 (PDT) In-Reply-To: <20140320210740.GF3471@localhost> References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <532B2A6A.3000205@bbn.com> <20140320210740.GF3471@localhost> Date: Thu, 20 Mar 2014 16:20:35 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4Ho1tJHRpquVuIXUXW_oirTprRo Cc: "saag@ietf.org" Subject: Re: [saag] better ** terminology 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, 20 Mar 2014 21:20:48 -0000 On Thu, Mar 20, 2014 at 4:07 PM, Nico Williams wrote: > On Thu, Mar 20, 2014 at 01:50:34PM -0400, Stephen Kent wrote: >> [...] >> In part, that's why I like Pervasive Encryption. If we say we're trying >> to combat pervasive monitoring, the terminology overlap seems to make it >> natural, no matter what we do :-). > > Cute. Hmm, cute but dangerous. The pervasive monitoring is mostly TLAs/LEOs or their deputized agents, and they have the resources and position to mount active attacks. Therefore PE had better to much better than just protect against passive attacks or we may end up with a major marketing failure in our hands, and badly damaged reputation. Nico -- From nobody Thu Mar 20 14:25:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063721A091E for ; Thu, 20 Mar 2014 14:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTzLilMAjCMP for ; Thu, 20 Mar 2014 14:25:04 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (agjbgdcfdbfg.dreamhost.com [69.163.253.156]) by ietfa.amsl.com (Postfix) with ESMTP id D6A861A091D for ; Thu, 20 Mar 2014 14:25:03 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 003B7B806B for ; Thu, 20 Mar 2014 14:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZcVpYZdEm9bigDmuc+6X mh/VOyo=; b=XS8sIRsjj8sKbrEgWh+LznGXYrveZAgjTXS08hUNJYs+jnpASr6x jRh4vxuFDZUh5CXlw0WFWY/jfoH3gt0dgJmXVkQUMe502Sr1Hl485LbDuRFuPOIW 8mFIrWihm2VnEDB6/MRwIhgw4MIkNlX+sSOBwl++kF8VEjFoFwceHJo= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id A3DEDB8057 for ; Thu, 20 Mar 2014 14:24:54 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so1064753wgg.9 for ; Thu, 20 Mar 2014 14:24:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=90RGGmckOL4o/GY+tji0pWmxo1ba1xsI4vygamRDFmk=; b=M9oOHBSK5M4Hsm+4CAyt2lkFcw20Kp6+KJVcuOuLscu1rgN9NqjhuHxxKeH+aEd7ZU ySqT5kA6cyc+puS+Kphe4rgsv+7revpsgR4Ry3Bgh5TsTrbg2vsFOElPiFbB5Vv8Gj22 Bgb+NrezF/8WhFeidw4x9ayLwEpyeyD86f8vdIvYUXJ9lomq+jYuhS8yLRCIUJ/Nt3ea /uPq1nrAXLa3K+WyxInZ3NT00uyXd8+x4AvXJf4tA2N6t5omIBX7+rfYIG5sKZB6MaDx +fQV7saIcoRAbVSxhzZF2Ls+k9ZRiHuO+SF4AsQ053MM+IPstg5FuwlNWj9iyUCU/oK/ yTWA== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr22483wjz.95.1395350693558; Thu, 20 Mar 2014 14:24:53 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 20 Mar 2014 14:24:53 -0700 (PDT) In-Reply-To: <532B4B34.3040106@fifthhorseman.net> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> Date: Thu, 20 Mar 2014 16:24:53 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NIePTZpHh5QECcy4G_8cwlQhtu0 Cc: Michael Richardson , saag Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 20 Mar 2014 21:25:05 -0000 On Thu, Mar 20, 2014 at 3:10 PM, Daniel Kahn Gillmor wrote: > On 03/20/2014 02:48 PM, Michael Richardson wrote: >> We seem to all know what we mean here, we are just bikeshedding on a word. > > Indeed, and so far all the existing candidates have contextual meaning > or nuance that causes various people to complain. If the whole world will see this bikeshed and measure us by its color, then our color choice will matter. If not, not. I'm not sure yet what the intention is (see Stephen's response to me). > here's my abbreviated take on the major complaints for existing > candidate terms: > --------------------- > > [...] > "Unauthenticated encryption" is inaccurate because some of these > connections might actually be authenticated (and because it appears to > contrast with "authenticated encryption" which is a specific term of art > in the crypto world, related to message integrity) "Lying" in a direction of making the user feel less safe than they are is at least somewhat better than the alternative... >[...] > > i'll throw one more candidate term into the ring that i think avoids the > problems listed above: > > "Hygienic encryption" In so far as it says nothing to me, I like it! Nico -- From nobody Thu Mar 20 15:04:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2731A091D for ; Thu, 20 Mar 2014 15:04:20 -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 Z6Q3lzR6IiM1 for ; Thu, 20 Mar 2014 15:04:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 713001A07E0 for ; Thu, 20 Mar 2014 15:04:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1DE3C2AAD62; Thu, 20 Mar 2014 22:04:08 +0000 (UTC) Date: Thu, 20 Mar 2014 22:04:08 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140320220407.GO24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WbsgBtVaNXe11unUWXzdhDmTOUY Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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: Thu, 20 Mar 2014 22:04:20 -0000 On Thu, Mar 20, 2014 at 04:24:53PM -0500, Nico Williams wrote: > > "Hygienic encryption" > > In so far as it says nothing to me, I like it! In so far as it says nothing to me, I don't see using it. Many messages up-thread multiple people suggested that "OE" works well enough, and ought to be re-purposed (definition broadened). We've been using the adjective "opportunistic" in combination with a few related nouns for some time, and at various administrators and users have a working knowledge of what it means. Nothing I've seen so far fits as well. Even the negative connotations of "opportunistic" are a feature, in the sense that they carry an connotation of going for "all you can get", no ceiling! Which is precisely the goal here: as secure as practically possible. Without raising the bar so high that one is left with no security because one could not attain some notion of absolute security. It would be nice if "opportunistic" security became "pervasive", but naming it so I think focuses on an extrinsic property, the desired scope of its popularity, rather than an intrinsic property like aiming for the most you can get without a set lower or upper bound. Someone might now suggest "unbounded encryption", but that would suggest superior capabilities, rather than achieving the most one can. So bottom line, I am with the folks who say we were already done choosing the term, and it is time to explain it to the world and promote the approach in all relevant protocols and products. -- Viktor. From nobody Thu Mar 20 16:10:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846C71A08FC for ; Thu, 20 Mar 2014 16:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDF6wjV2rDdm for ; Thu, 20 Mar 2014 16:10:18 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (agjbgdcfdbef.dreamhost.com [69.163.253.145]) by ietfa.amsl.com (Postfix) with ESMTP id 35C391A092F for ; Thu, 20 Mar 2014 16:10:14 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 3BFD52007F11B; Thu, 20 Mar 2014 16:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=SHl5Mji/nEPBpaBuIREyJzKNBlM=; b=L0tQntsSavP wWV8v3JY4dbs6RBiFwjxbdjbk5heY1Ejs5iwaET2BkTPP9kBzZET8EmGho0qkK9q TBTatyyB/ch2fNb3J28E/dw7ha7wE4HH3ZV6IxZLxbFoms+7Qd++6btcWwnN/SeF DBx1YYkMkb+y14nB9boVRnGSJUxg1hPg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id DB6BE20054B3C; Thu, 20 Mar 2014 16:10:04 -0700 (PDT) Date: Thu, 20 Mar 2014 18:10:04 -0500 From: Nico Williams To: Michael Richardson Message-ID: <20140320231001.GG3471@localhost> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6861.1395341319@sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hUXDgejK0y0YLu96DGVwTA3ZOzg Cc: saag Subject: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 20 Mar 2014 23:10:19 -0000 On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: > We seem to all know what we mean here, we are just bikeshedding on a > word. This is not bikeshedding. Names matter. Consider BTNS... BTNS failed for many reasons, but one of them was that the name indicated much less utility than it provided. BTNS (_with_ connection latching) is basically what's being proposed today, only not using IKE (nor ESP). It would have made possible the use of DANE, TACK-like mechanisms, and channel binding -- all the things we want for "PE", "HE", "OE", or whatever we end up calling it. So what was wrong with it? I won't make a full list, just two reasons sufficed methinks: 1) In-band key exchange (and any authentication) is better (i.e., more deployable, easier to manage, ...) than out-of-band (read: IKE); 2) visceral reaction to the name. Many people took BTNS as a pejorative and spoke despectively about it. What's in the name matters at least a fair bit, probably a lot. A discussion about naming is warranted even where a discussion of bikeshed paint color wouldn't be. I'm now convinced that "pervasive" as a modifier for "encryption" or similar will denote (to enough people) something very different from what is to be provided, therefore it would be extremely dangerous to settle on "pervasive". We need a name that denotes what we mean to provide. I simply cannot find a better adjective than "opportunistic" for use in " encryption" adjectival phrases. I counsel the use of an adjective at least as appropriate as "opportunistic" and no less. Consider a thesaurus: http://thesaurus.com/browse/opportunistic None of the "synonyms" of opportunistic listed there comes close to being appropriate here. Except, maybe, for "pretentious" (under "as in vaulting") or "blas=E9" (under "as in worldly"), and those bear a much more negative connotation. To be fair, some dictionaries' definitions of opportunistic carry very negative connotations, but I think when attached to a noun that carries possitive connotations the sense of opportunistic is reversed (which in turn is likely the reason that thesauruses are not helping). Nico --=20 From nobody Thu Mar 20 16:17:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D49E1A0453 for ; Thu, 20 Mar 2014 16:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 t6VCPUvrZzOw for ; Thu, 20 Mar 2014 16:17:56 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (agjbgdcfdbgf.dreamhost.com [69.163.253.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF151A0448 for ; Thu, 20 Mar 2014 16:17:56 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 22E2F5405B for ; Thu, 20 Mar 2014 16:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=cxTnypMqNqUBxhcyXze9ZCG7WMI =; b=WhC341yAZRmeDX/9gmobBQltBUaFpDrYGlykM8p2+9qoPAsCWcJ/1gZKDWx w2x0c9UW8llaAlwnAIYALSUYowVkJ0//qT0iwXPu8MFYBra6g8VWuy0Y23ZRDA3Q /lZ6ZMMs5feJ09wkuBG7WSEZQOqGvBho2ugjjoC2n8Jys3ls= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id D8B2754058 for ; Thu, 20 Mar 2014 16:17:46 -0700 (PDT) Date: Thu, 20 Mar 2014 18:17:46 -0500 From: Nico Williams To: saag@ietf.org Message-ID: <20140320231744.GH3471@localhost> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <20140320220407.GO24183@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140320220407.GO24183@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LhoKjA3Tuj66VTqHoaziSLDeFvk Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 20 Mar 2014 23:17:57 -0000 On Thu, Mar 20, 2014 at 10:04:08PM +0000, Viktor Dukhovni wrote: > On Thu, Mar 20, 2014 at 04:24:53PM -0500, Nico Williams wrote: > > > "Hygienic encryption" > > > > In so far as it says nothing to me, I like it! > > In so far as it says nothing to me, I don't see using it. I was being somewhat facetious: if I can't have the adjective of my preference for this ("opportunistic") then I'd rather have an empty vessel into which to pour our meaning. But you've convinced me: it's opportunistic or nothing. Past uses of "opportunistic encryption" with different meanings are not relevant: they're not in widespread use, certainly not in the conciousness of the public, and certainly not likely to ever be as widespread as we want this new thing to be. > We've been using the adjective "opportunistic" in combination with > a few related nouns for some time, and at various administrators > and users have a working knowledge of what it means. Nothing I've > seen so far fits as well. Agreed. > Even the negative connotations of "opportunistic" are a feature, > [...] Yes: because when attached to a noun that has positive connotations the sense of "opportunistic" is reversed from negative to positive! "Opportunistic" is an opportunistic adjective. (ahem, pardon me.) Nico -- From nobody Thu Mar 20 18:36:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66A01A0835 for ; Thu, 20 Mar 2014 18:36:28 -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 hKzVZBxDsGdG for ; Thu, 20 Mar 2014 18:36:26 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DEABC1A0833 for ; Thu, 20 Mar 2014 18:36:25 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so1820553iec.22 for ; Thu, 20 Mar 2014 18:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ExwoaYbv+iX9gGcF2e/w8qGzcQ/QJ+Uk5dqwE6vBjRk=; b=X49kY4lSCgGtdtW+N7g/BY7lUuRiU0XfSHOiibQNKfHroDvXVTGleGxnv8ig1kPtf0 KdKbBSXMxqA2j70TxSOT2ukw0doL8W3RT2m8Sf02o4ZTVGEoEcl+mp2nx0a1erPQLRbA iH5WqMx5gqOxz9tGtJGizjs8VCXoRTId3h7d5VW4E8523p02NG2PnQe8Md4JtA3O71xJ YNtgfBLlwi4vQ3PT67vmQdJOwA1RP3HrmtVDlPHn4QoKe75tPZ107Tct3ZaGp3xbAmbq jgTVPhrnrAqTl9dpQYonZzXab/nUgfJ5bpLrGOSNCDphEAefp8eSp2ioWjJmtCtxHY4U AcoA== X-Received: by 10.50.3.98 with SMTP id b2mr130483igb.23.1395365776762; Thu, 20 Mar 2014 18:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.168.100 with HTTP; Thu, 20 Mar 2014 18:35:55 -0700 (PDT) In-Reply-To: <20140320231744.GH3471@localhost> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <20140320220407.GO24183@mournblade.imrryr.org> <20140320231744.GH3471@localhost> From: Ira McDonald Date: Thu, 20 Mar 2014 21:35:55 -0400 Message-ID: To: Nico Williams , Ira McDonald Content-Type: multipart/alternative; boundary=089e0129464874af4f04f513e966 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DcH6dj2FF9XxpDWpsKI924HmtxE Cc: "saag@ietf.org" Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 01:36:29 -0000 --089e0129464874af4f04f513e966 Content-Type: text/plain; charset=ISO-8859-1 Hi, To be useful, the chosen term should be obvious and meaningful to end users, not just to administrators. In popular usage, the adjective "opportunistic" falls into the same deep hole of probable misunderstanding that Nico noted for BTNS. I suggest that only positive adjectives be considered, for example: "practical encryption" Now please shoot the messenger (smile). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Mar 20, 2014 at 7:17 PM, Nico Williams wrote: > On Thu, Mar 20, 2014 at 10:04:08PM +0000, Viktor Dukhovni wrote: > > On Thu, Mar 20, 2014 at 04:24:53PM -0500, Nico Williams wrote: > > > > "Hygienic encryption" > > > > > > In so far as it says nothing to me, I like it! > > > > In so far as it says nothing to me, I don't see using it. > > I was being somewhat facetious: if I can't have the adjective of my > preference for this ("opportunistic") then I'd rather have an empty > vessel into which to pour our meaning. > > But you've convinced me: it's opportunistic or nothing. > > Past uses of "opportunistic encryption" with different meanings are not > relevant: they're not in widespread use, certainly not in the > conciousness of the public, and certainly not likely to ever be as > widespread as we want this new thing to be. > > > We've been using the adjective "opportunistic" in combination with > > a few related nouns for some time, and at various administrators > > and users have a working knowledge of what it means. Nothing I've > > seen so far fits as well. > > Agreed. > > > Even the negative connotations of "opportunistic" are a feature, > > [...] > > Yes: because when attached to a noun that has positive connotations the > sense of "opportunistic" is reversed from negative to positive! > > "Opportunistic" is an opportunistic adjective. (ahem, pardon me.) > > Nico > -- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --089e0129464874af4f04f513e966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

To be useful, the chosen term should be obvious and meaningful to end u= sers,
not just to administrators.

In popular usage, = the adjective "opportunistic" falls into the same deep hole of probable misunderstanding that Nico noted for BTNS.

I su= ggest that only positive adjectives be considered, for example:

=A0 "practical encryption"

Now please shoot the me= ssenger (smile).

Cheers,
- Ira

Ira McDonald (Musician / Software Arc= hitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Fo= undation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Thu, Mar 20, 2014 at 7:17 PM, Nico Wi= lliams <nico@cryptonector.com> wrote:
On Thu, Mar 20, 2014 at 10:04:08PM +0000, Viktor Dukhovni w= rote:
> On Thu, Mar 20, 2014 at 04:24:53PM -0500, Nico Williams wrote:
> > > =A0"Hygienic encryption"
> >
> > In so far as it says nothing to me, I like it!
>
> In so far as it says nothing to me, I don't see using it.

I was being somewhat facetious: if I can't have the adjective of = my
preference for this ("opportunistic") then I'd rather have an= empty
vessel into which to pour our meaning.

But you've convinced me: it's opportunistic or nothing.

Past uses of "opportunistic encryption" with different meanings a= re not
relevant: they're not in widespread use, certainly not in the
conciousness of the public, and certainly not likely to ever be as
widespread as we want this new thing to be.

> We've been using the adjective "opportunistic" in combin= ation with
> a few related nouns for some time, and at various administrators
> and users have a working knowledge of what it means. =A0Nothing I'= ve
> seen so far fits as well.

Agreed.

> Even the negative connotations of "opportunistic" are a feat= ure,
> [...]

Yes: because when attached to a noun that has positive connotations the
sense of "opportunistic" is reversed from negative to positive!
"Opportunistic" is an opportunistic adjective. =A0(ahem, pardon m= e.)

Nico
--

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

--089e0129464874af4f04f513e966-- From nobody Thu Mar 20 19:57:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F311A0881 for ; Thu, 20 Mar 2014 19:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 SKnbXihVmFoh for ; Thu, 20 Mar 2014 19:57:33 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (agjbgdcfdbfe.dreamhost.com [69.163.253.154]) by ietfa.amsl.com (Postfix) with ESMTP id C71F31A087F for ; Thu, 20 Mar 2014 19:57:33 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id BFD112C806B; Thu, 20 Mar 2014 19:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Ks4VmmWC7VQrfx bqmts8vbGTxQA=; b=T+229Hb2Lsz9m5fCEwKjmtNXxxdnK/ad0oD/0yHBXdvPMw vmLQmmYbk81AMJ2vVZ+LlN/1oNva+Sl53sMSEZYeZBfykVwlVl9wR+Y3lJIg8aNC W/zOHdcaAeNpzyGc9yQXOBlioRGm1/bwmWrBNDpbEbmbuoVgQ7sDbCnBsTD54= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 6CECC2C8058; Thu, 20 Mar 2014 19:57:24 -0700 (PDT) Date: Thu, 20 Mar 2014 21:57:23 -0500 From: Nico Williams To: Ira McDonald Message-ID: <20140321025720.GI3471@localhost> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <20140320220407.GO24183@mournblade.imrryr.org> <20140320231744.GH3471@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/luFd9jQooIe4yqJI8yFGAoFjTFc Cc: "saag@ietf.org" Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 02:57:34 -0000 On Thu, Mar 20, 2014 at 09:35:55PM -0400, Ira McDonald wrote: > To be useful, the chosen term should be obvious and meaningful to end > users, not just to administrators. > > In popular usage, the adjective "opportunistic" falls into the same > deep hole of probable misunderstanding that Nico noted for BTNS. I don't think so, for the reasons I gave in other posts. But I recognize my own bias may blind me to the truth of your statement. That's why I suggested a survey. If we're really going to try to greatly improve the lot of Internet security, we'd better get various details right, right down to the name that the public will hear. We could also reach out to English and/or marketing experts. > I suggest that only positive adjectives be considered, for example: "Opportunistic" is only negative when considered alone or with nouns with negative connotation. Otherwise it ranges from neutral to positive connotations. The thesauruses I looked at don't capture this. Consider all of these nouns as modified by opportunistic: opportunistic politician opportunistic investment opportunistic infection opportunistic sale opportunistic theft opportunistic leisure ... Search for these phrases in quotes, you'll see what I mean. > "practical encryption" "Opportunistic encryption" says (to me) "we encrypt when we can", which, is about right (even if we always encrypt, the important part is that which we won't always be able to do, namely: authentication, and which the uninitiated will tend to understand intuitively by "encryption"). To my ear, "practical encryption" ranges from "not impractical" (hah) to "it does what you would expect" (except it won't always, so we're back onto thin ice). Also, remember that the problem with OE was reuse of the term. How about "opportunistic security"? Nico -- From nobody Fri Mar 21 04:53:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C41A0969 for ; Fri, 21 Mar 2014 04:53:17 -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, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, RDNS_NONE=0.793] 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 CVOW4iqclLQ8 for ; Fri, 21 Mar 2014 04:53:16 -0700 (PDT) Received: from hoba.ie (unknown [92.51.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id 512E91A096F for ; Fri, 21 Mar 2014 04:53:16 -0700 (PDT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stephen) by hoba.ie (Postfix) with ESMTPSA id 625FDE01ED; Fri, 21 Mar 2014 11:53:05 +0000 (GMT) Message-ID: <532C2822.4090308@cs.tcd.ie> Date: Fri, 21 Mar 2014 11:53:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , Michael Richardson References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> In-Reply-To: <20140320231001.GG3471@localhost> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GdP-a6FF1YFSMNmbAAbp0bZ8tJ0 Cc: saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 11:53:17 -0000 On 03/20/2014 11:10 PM, Nico Williams wrote: > On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >> We seem to all know what we mean here, we are just bikeshedding on a >> word. > > This is not bikeshedding. Names matter. I agree with Nico's conclusion in this case, though I might get to it via a different route. It seems fairly clear that we are not so far getting consensus for any term that does not include the word "opportunistic." Do folks agree with that? S. From nobody Fri Mar 21 05:00:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17BB1A08AE for ; Fri, 21 Mar 2014 05:00:04 -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, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, RDNS_NONE=0.793] 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 8n1AZ51iz0bB for ; Fri, 21 Mar 2014 05:00:03 -0700 (PDT) Received: from hoba.ie (unknown [92.51.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id C2E3E1A0969 for ; Fri, 21 Mar 2014 05:00:03 -0700 (PDT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stephen) by hoba.ie (Postfix) with ESMTPSA id D1AFCE01ED; Fri, 21 Mar 2014 11:59:52 +0000 (GMT) Message-ID: <532C29B9.8090703@cs.tcd.ie> Date: Fri, 21 Mar 2014 11:59:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> In-Reply-To: <6861.1395341319@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/odqu16NgkMlsyzgBd1i6lCJI7nE Cc: saag Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 12:00:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2014 06:48 PM, Michael Richardson wrote: > Stephen Farrell wrote: >> broadly, since it'll generate too much opposition from the "but I >> don't want to encrypt" camp. If however, a strong > > Can you tell me more about this camp? I am not familiar with who > they are, and what they say. (And I wasn't at STRINT) That wasn't really to do with STRINT, more from the gigantic IETF LC for perpass-attack. There were a very few folks who just don't want to encrypt stuff. One or two who want to send stuff via Ham radio and are not supposed to send ciphertext. And one or two more I just never could figure the reason why. But mostly, its really folks who don't want other folks to encrypt for a mixture of good and bad reasons. We do not need to delve into it here, but IMO a defensible reason to not want everything to be ciphertext does exist which is inbound malware scanning. (I'm not saying that that wins the argument, just that its a defensible argument.) People who want/need to do that would be dead against a thing called pervasive encryption I'd bet. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTLCm5AAoJEC88hzaAX42iqJcH/jkvFxz0zbK+VJX3Vw4lcnu7 sMhfNe5DPgjA0I03WmP6oTqNq9yNE7oB4Tn7FaWgHTvIBa71/Zxh+mJY2QBVNZwG JGX1FrbRr0SNSoQ/JzpwTOZ+r+unE3YBo/GHX61s7SSgLwlRmei7v8AOukMXxT9i qwyiWz+vnYpkUBHRx5tQ92Pfxja5RAqB7SZxoA8xuNE32GAQNT237G3Zl1MzObIs ire2MhV0UybWdTOtpecJIhJHUmNE4fHx81ipMFYZQTdUQu+fHG/xvdbWDGjps8QA GX1g+eTG58yJf0Mse2j7UflFwQpem5osvX1PNikH810BGNcZsZiC5xg7Q1hYbIA= =AopC -----END PGP SIGNATURE----- From nobody Fri Mar 21 07:25:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2501A08DD for ; Fri, 21 Mar 2014 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.547] 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 yVY9q8pPhELc for ; Fri, 21 Mar 2014 07:25:55 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0A01A0738 for ; Fri, 21 Mar 2014 07:24:48 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA19854; Fri, 21 Mar 2014 09:56:37 -0400 (EDT) Date: Fri, 21 Mar 2014 09:56:37 -0400 (EDT) From: Mouse Message-Id: <201403211356.JAA19854@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 21 Mar 2014 09:17:43 -0400 (EDT) To: saag@ietf.org In-Reply-To: <532C29B9.8090703@cs.tcd.ie> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532C29B9.8090703@cs.tcd.ie> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sKDdgKBFdtvIKdf8_cIXg1OqhbE Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 14:25:57 -0000 >>> [...], since it'll generate too much opposition from the "but I >>> don't want to encrypt" camp. >> Can you tell me more about this camp? > There were a very few folks who just don't want to encrypt stuff. > One or two who want to send stuff via Ham radio and are not supposed > to send ciphertext. I had this reaction when I saw, upthread, > We are going around in circles. I think we - the larger Internet > Community - ned to explain this and get everyone that manages a > system, that configures software to get aboard this ship. My reaction, as a sysadmin and software configurer, is that you will never get me aboard any ship that involves encrypting everything. I didn't mention it because I saw no point; I'm enough of an outlier, and see so much that's so much worse wrong with the Internet already, that it didn't strike me as worth the electrons it would cost. But, yes, I do not want to encrypt stuff - or, at least, there plenty of stuff I do not want to encrypt. There are two basic reasons for this: (1) I like to be able to see what's going on on my network by snooping on intermediate nodes, and (2) the computron load imposed by encryption is significant for enough of my machines to matter to me. Additionally, I see (3) a nontrivial fraction of my traffic is already encrypted, making further encryption an almost total waste of resources; this matters most for the machines for which (2) is relevant, so it's really a subset of it. (4) This puts a good deal of relatively complex, and very difficult to vet for even people usually pretty good at code vetting, code in security-critical paths. This wouldn't matter much - if the encryption is bad, the security properties are no worse than what you get from sending in the clear - except that people will feel safe even if they aren't. (A lot of people seem to think of "safe" (or "secure") as a boolean thing, not the spectrum it actually is, exacerbating this.) Come to think of it, there's also (5) some people are in places where encryption is illegal or under onerous legal restrictions. Would you exclude them from the net entirely? (This is basically the argument about the hams in a different dress.) Oh, and (6) a good deal of my traffic is stuff that's public anyway (like FTPing from my anonymous FTP area, or public mailing list mail) and encrypting it is thus a total waste of resources. (1) can be seen as a case of "folks who don't want other folks to encrypt" where I am both the "folks" and the "other folks" (and thus the description's "other" is inaccurate). Of course, how much of an argument this forms for the IETF is for the IETF to determine. Internet governance is already headed in directions antithetical enough to me that I have learned to not expect anyone to care what I think. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Fri Mar 21 07:35:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E351A09B6 for ; Fri, 21 Mar 2014 07:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qMS3MNWHZno for ; Fri, 21 Mar 2014 07:35:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 087D71A09B4 for ; Fri, 21 Mar 2014 07:35:05 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2LEYe74014657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 07:34:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <532C2822.4090308@cs.tcd.ie> Date: Fri, 21 Mar 2014 07:34:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Z5Utelv3gZ_YrCVxYGU2GF5me4U Cc: saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 14:35:06 -0000 On Mar 21, 2014, at 4:53 AM, Stephen Farrell = wrote: > On 03/20/2014 11:10 PM, Nico Williams wrote: >> On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >>> We seem to all know what we mean here, we are just bikeshedding on a >>> word. >>=20 >> This is not bikeshedding. Names matter. =20 >=20 > I agree with Nico's conclusion in this case, though I might get > to it via a different route. >=20 > It seems fairly clear that we are not so far getting consensus > for any term that does not include the word "opportunistic." >=20 > Do folks agree with that? Yes. Separately, I would argue that if we use "opportunistic foo" which is = not "opportunistic encryption", that definition will have to = differentiate the two and the difference will be obscure even to = developers. At that point, we look silly for not just redefining the = term everyone is already using, "opportunistic encryption". --Paul Hoffman= From nobody Fri Mar 21 07:41:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0182E1A09AA for ; Fri, 21 Mar 2014 07:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LONGWORDS=2.035] 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 p6-rQJ_1QmDQ for ; Fri, 21 Mar 2014 07:41:49 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5CC1A0973 for ; Fri, 21 Mar 2014 07:41:48 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 Mar 2014 10:41:36 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0174.001; Fri, 21 Mar 2014 10:41:35 -0400 From: Dan Brown To: "'stephen.farrell@cs.tcd.ie'" Thread-Topic: [saag] Name >> bikeshed color (Re: better ** terminology) Thread-Index: AQHPRJGXB3EH5T4sAkyn9ag1mcyI0prrsikA///YMsA= Date: Fri, 21 Mar 2014 14:41:35 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C5C6AF@XMB116CNC.rim.net> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> In-Reply-To: <532C2822.4090308@cs.tcd.ie> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000C_01CF44F2.213D3EB0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bPBd4NDM8LGQLmutvrnXaFXez0I Cc: "saag@ietf.org" Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 14:41:51 -0000 ------=_NextPart_000_000C_01CF44F2.213D3EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stephen, My bikeshed vote would go to passive encryption 3 reasons: resists passive attacks, user can be passive, massive surveillance hindered To me, pervasive mainly conveys the upside, but not downside risk of a MITM. Opportunistic seems too much like occasional, whereas the goal is to be frequent, and again does not convey the downside risk (MITM). Also, both words also have a rather mischievous connotation, which might be unfair to users not even aware of its use. Best regards, Dan PS BTW, more brainstormed alternative terms: casual encryption provisional encryption presumptive encryption eager encryption expedient encryption procedural encryption quotidian encryption nominal encryption pencil encryption pragmatic encryption bicycle encryption WordNet helped me to find some of the brainstorm adjectives above. I often started from a term for either the upside or downside, then searched for a related term that had both an upside and downside. Right now, I see any of the above to be as good as pervasive or opportunistic, but not as good as passive. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Friday, March 21, 2014 7:53 AM > To: Nico Williams; Michael Richardson > Cc: saag > Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) > > > > On 03/20/2014 11:10 PM, Nico Williams wrote: > > On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: > >> We seem to all know what we mean here, we are just bikeshedding on a > >> word. > > > > This is not bikeshedding. Names matter. > > I agree with Nico's conclusion in this case, though I might get to it via a different > route. > > It seems fairly clear that we are not so far getting consensus for any term that > does not include the word "opportunistic." > > Do folks agree with that? > > S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_000C_01CF44F2.213D3EB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzIx MTQ0MTM0WjAjBgkqhkiG9w0BCQQxFgQUFuIPXlrSCcXMt/QxOgg0yiJbWxMwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgKur3gmoy7L3 DE2VSs1R44zZ8pYVZKt4lP263X5t1lvBcRxWzkc48GGsQRiLDCxE/MOsFKT9tBncHy4yBi5oBGn0 CUqOqgK4ayy+ZOuOiRHkbOZqPxyLaVRq+rZPUCzaGbvyEqQiAKn/hmRGBlgH4xJrxTrrDAguFKG4 esyEbpITAAAAAAAA ------=_NextPart_000_000C_01CF44F2.213D3EB0-- From nobody Fri Mar 21 07:44:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662691A09B6 for ; Fri, 21 Mar 2014 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 9BN7QISjIg-5 for ; Fri, 21 Mar 2014 07:43:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 095341A0973 for ; Fri, 21 Mar 2014 07:43:56 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6320693C1AF; Fri, 21 Mar 2014 14:43:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> Date: Fri, 21 Mar 2014 15:43:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mdP8MTjOe-DitC7X-y7ZLYOXbOI Cc: saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 14:43:59 -0000 On 21 Mar 2014, at 15:34, Paul Hoffman wrote: > On Mar 21, 2014, at 4:53 AM, Stephen Farrell = wrote: >=20 >> On 03/20/2014 11:10 PM, Nico Williams wrote: >>> On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >>>> We seem to all know what we mean here, we are just bikeshedding on = a >>>> word. >>>=20 >>> This is not bikeshedding. Names matter. =20 >>=20 >> I agree with Nico's conclusion in this case, though I might get >> to it via a different route. >>=20 >> It seems fairly clear that we are not so far getting consensus >> for any term that does not include the word "opportunistic." >>=20 >> Do folks agree with that? >=20 > Yes. >=20 > Separately, I would argue that if we use "opportunistic foo" which is = not "opportunistic encryption", that definition will have to = differentiate the two and the difference will be obscure even to = developers. At that point, we look silly for not just redefining the = term everyone is already using, "opportunistic encryption". Yes, we would.=20 We have a group here in Sweden trying to come up with swedish names for = computer-related terms. We decided that floppy disc was "flexskiva". I = don't think anyone will remember that term, even though it was = technichally correct and a proper translation of "floppy disc". It = became "Floppy" and stayed "floppy". I just asked my son if he knew what = a "flexskiva" is and he looked at me with an empty stare. "Floppy" he = knew immediately :-) Long story, but I do agree with Paul. Let's take ownership of the term = "opportunistic encryption". We don't have the resources to get a new = term out there, established in time for what we want to do.=20 Let's try to define a common definition of the goal with "opportunistic = encryption" in non-detailed way. Then let's define all the solutions = that is grouped under this in a detailed, correct and well-defined way. (ducks) /O= From nobody Fri Mar 21 07:56:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D61A0128 for ; Fri, 21 Mar 2014 07:56:52 -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 DAnM_PE2MLtT for ; Fri, 21 Mar 2014 07:56:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2348F1A0738 for ; Fri, 21 Mar 2014 07:56:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6DC312AB250; Fri, 21 Mar 2014 14:56:40 +0000 (UTC) Date: Fri, 21 Mar 2014 14:56:40 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140321145640.GU24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5EYjbmLuOuBk2ElKqicLQd3xZ4M Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 14:56:53 -0000 On Fri, Mar 21, 2014 at 07:34:37AM -0700, Paul Hoffman wrote: > > It seems fairly clear that we are not so far getting consensus > > for any term that does not include the word "opportunistic." > > > > Do folks agree with that? > > Yes. And yes. I have in the back packet other adjectives that are close: "adaptive", "pragmatic", "flexible", "scalable", but none fit as well. > Separately, I would argue that if we use "opportunistic foo" > which is not "opportunistic encryption", that definition will have > to differentiate the two and the difference will be obscure even > to developers. At that point, we look silly for not just redefining > the term everyone is already using, "opportunistic encryption". I take strong exception to this. Coining the term "green bike-shed" does not confuse people about what "green" is. There is 8 years of history behind "opportunistic TLS" in Postfix and I see no reason to change that, just because an umbrella term to cover more than TLS has been proposed. The term "opportunistic TLS" is simply a more specific version of "opportunistic encryption", and "opportunistic DANE TLS" is a more specific form still. -- Viktor. From nobody Fri Mar 21 08:21:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0641A09B0 for ; Fri, 21 Mar 2014 08:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC6LEKqTEGzy for ; Fri, 21 Mar 2014 08:21:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1431A0731 for ; Fri, 21 Mar 2014 08:21:15 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2LFL4Du016628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Mar 2014 08:21:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140321145640.GU24183@mournblade.imrryr.org> Date: Fri, 21 Mar 2014 08:21:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> To: saag@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QrPCuHseW2s11FZEfvcHgepjNaQ Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 15:21:16 -0000 On Mar 21, 2014, at 7:56 AM, Viktor Dukhovni = wrote: > On Fri, Mar 21, 2014 at 07:34:37AM -0700, Paul Hoffman wrote: >=20 >>> It seems fairly clear that we are not so far getting consensus >>> for any term that does not include the word "opportunistic." >>>=20 >>> Do folks agree with that? >>=20 >> Yes. >=20 > And yes. I have in the back packet other adjectives that are close: > "adaptive", "pragmatic", "flexible", "scalable", but none fit as > well. >=20 >> Separately, I would argue that if we use "opportunistic foo" >> which is not "opportunistic encryption", that definition will have >> to differentiate the two and the difference will be obscure even >> to developers. At that point, we look silly for not just redefining >> the term everyone is already using, "opportunistic encryption". >=20 > I take strong exception to this. Coining the term "green bike-shed" > does not confuse people about what "green" is. There is 8 years > of history behind "opportunistic TLS" in Postfix and I see no reason > to change that, just because an umbrella term to cover more than > TLS has been proposed. The term "opportunistic TLS" is simply > a more specific version of "opportunistic encryption", and > "opportunistic DANE TLS" is a more specific form still. Saying that the Postfix's community use of a specific definition of = "opportunistic TLS" should trump the large value of having a single = definition for "opportunistic encryption" feels somewhat selfish. Note = that Michael Richardson, whose RFC was the first to use the term = "opportunistic encryption", have given up change control on the term so = that we can get more universal encryption. --Paul Hoffman= From nobody Fri Mar 21 08:33:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7D1A098F for ; Fri, 21 Mar 2014 08:33:17 -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, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, RDNS_NONE=0.793] 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 eVgahef3B2uP for ; Fri, 21 Mar 2014 08:33:15 -0700 (PDT) Received: from hoba.ie (unknown [92.51.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id 935711A08CD for ; Fri, 21 Mar 2014 08:33:15 -0700 (PDT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stephen) by hoba.ie (Postfix) with ESMTPSA id 6F4B6E01ED for ; Fri, 21 Mar 2014 15:33:05 +0000 (GMT) Message-ID: <532C5BB2.1090808@cs.tcd.ie> Date: Fri, 21 Mar 2014 15:33:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> In-Reply-To: <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oqx7lPFE_1MSquLQP7SziIgK7BQ Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 15:33:17 -0000 Folks, >>>> It seems fairly clear that we are not so far getting consensus >>>> for any term that does not include the word "opportunistic." >>>> >>>> Do folks agree with that? I deliberately stopped with the above question. So far I've seen a number of yes responses, one set of alternate suggestions (without an answer to the above question) and have also gotten a few offlist mails with yet more alternative suggestions. If we can bottom out on *just* the above question, then we can go on to see how best to proceed, but e.g. the discussion between Paul and Viktor would be part of that next step, *after* we end up concluding that we have rough consensus on the answer to the above question. I think if we take this one step at a time, we're more likely to make progress. Thanks, S. From nobody Fri Mar 21 08:33:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5771A098A for ; Fri, 21 Mar 2014 08:33:46 -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 goCSzXaDkZE3 for ; Fri, 21 Mar 2014 08:33:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 431B71A0989 for ; Fri, 21 Mar 2014 08:33:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C03BB2AB250; Fri, 21 Mar 2014 15:33:28 +0000 (UTC) Date: Fri, 21 Mar 2014 15:33:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140321153328.GX24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gx8nL5BAKaR1HTi2oIHQEYuljio Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 15:33:46 -0000 On Fri, Mar 21, 2014 at 08:21:01AM -0700, Paul Hoffman wrote: > > I take strong exception to this. Coining the term "green bike-shed" > > does not confuse people about what "green" is. There is 8 years > > of history behind "opportunistic TLS" in Postfix and I see no reason > > to change that, just because an umbrella term to cover more than > > TLS has been proposed. The term "opportunistic TLS" is simply > > a more specific version of "opportunistic encryption", and > > "opportunistic DANE TLS" is a more specific form still. > > Saying that the Postfix's community use of a specific definition > of "opportunistic TLS" should trump the large value of having a > single definition for "opportunistic encryption" feels somewhat > selfish. I have nothing against "opportunistic encryption" as an umbrella term for lots of more specific terms. There is nothing wrong with one of the more specific terms being "opportunistic TLS" or (synonymous) "opportunistic TLS encryption". This is really just a special case that is aligned with the umbrella term. We don't at this time need to decide to ban related, non-conflicting uses of the adjective, that can be done on a case-by-case basis where there is specific likelihood of confusion. Adjectives can and do decorate multiple nouns without confusion. This sub-thread is a side-show, I think we should return to the main topic if there is anything further to say on that. Otherwise, we have our winner. (What was it again? Did I hear someone say: Scalable Opportunistic Adaptive Pragmatic Encryption? with the acronym SOAP-E? Now that's marketing! :-) -- Viktor. From nobody Fri Mar 21 08:35:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF461A047D for ; Fri, 21 Mar 2014 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXSIb4tJAKwT for ; Fri, 21 Mar 2014 08:35:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id A25B31A0478 for ; Fri, 21 Mar 2014 08:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=806; q=dns/txt; s=iport; t=1395416122; x=1396625722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Br9/dVebhMVtyULY1DqcVxYrINZrsVXJ5Bj5/DQNakE=; b=OnGyTumreGOkJ+BKKAJl7P2HpusJEaMNJDnYt6xLSfNdK9IKR1EB01SJ 2MyRsjb1oCX1Z3vBZRQNu+P3Q1eB85yWXX+Abp1ijtcF4LdyFW8gYQD/l dTxg3od/JUHHD3AfgcFvz/6QlhwfpW83egXYweVBQJXGx3VkLgUjHmNtS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAH1bLFOtJXG+/2dsb2JhbABZgwY7V7slhzSBFRZ0giUBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYdxCA3PZRMEjjczB4MkgRQEmEmSMYMtgis X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="29337655" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 21 Mar 2014 15:35:22 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2LFZMmB027513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 15:35:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 10:35:21 -0500 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell Thread-Topic: [saag] Name >> bikeshed color (Re: better ** terminology) Thread-Index: AQHPRPwmY97VQLedWE22eK1CiS6v3JrsAC4A Date: Fri, 21 Mar 2014 15:35:21 +0000 Message-ID: References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> In-Reply-To: <532C2822.4090308@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.91] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LXBCwgsWDcJqlodEPn9B2to7_mA Cc: saag , Michael Richardson Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 15:35:33 -0000 On Mar 21, 2014, at 4:53 AM, Stephen Farrell wr= ote: >=20 >=20 > On 03/20/2014 11:10 PM, Nico Williams wrote: >> On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >>> We seem to all know what we mean here, we are just bikeshedding on a >>> word. >>=20 >> This is not bikeshedding. Names matter. =20 >=20 > I agree with Nico's conclusion in this case, though I might get > to it via a different route. >=20 > It seems fairly clear that we are not so far getting consensus > for any term that does not include the word "opportunistic." >=20 > Do folks agree with that? >=20 [Joe] yes. > S. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Mar 21 09:18:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177841A0470 for ; Fri, 21 Mar 2014 09:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdy7XkGfed10 for ; Fri, 21 Mar 2014 09:18:25 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 667271A06D2 for ; Fri, 21 Mar 2014 09:18:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 2CCAB91AD7 for ; Fri, 21 Mar 2014 09:18:15 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id DEF8421DE57 for ; Fri, 21 Mar 2014 09:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=wGbVIh6K0jfCGamLbB16XqD 5WKo=; b=YcWNVj5Vy1/EnJNl8PkRX1qRQhTM/LLvmx/BcJ8j4jwzssc1Miu452p Pnjn0R3HJbBJI7Pd0QNq1pz9XebuP8mMyoBTCIwvifiHOEb68l/eTUxTkyIB4J43 qnc2eoqbzXiMbk2rrr4cAtqMCFFFaWHfbMP2xFnHnVQ6HMvBid5k= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 8487E21DE56 for ; Fri, 21 Mar 2014 09:18:14 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so1726377wes.40 for ; Fri, 21 Mar 2014 09:18:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i4oCDMxHbvJLH27gWbMGYV/eQg5xFB7Z01zV1C7Jfw4=; b=fDXwko4myiAburR1IWS4oeMwFAXDcK6sVH8UlTmdVuxzlELWbHEU2BImxGe838pWXV Hne7sQ5FnGAHFiGrQQ87yDG8Wvdw2G+kTZ1FNfH4NJ7Pp4saGHyjFL8jTHWzoSpYu/1r PRlokS95uh0S62UF8YFQABubE5YXTnnHeUJoQ3emifLQdZNF31CWExTMjFdOuvsE82uT 08rRU4dYwZWe3a1uOyO9ABS/uffwn8kWuc4y6A1ffOlKLA64d47O48YWMmQnhkoEIPPL M8SeFyEZCRY8c6iTYG6bOBEdKqMuEwSLOH/Igh2i9S2JBnbbvTaktRKqoZyXjMqNY5bZ lDkA== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr2884050wiw.39.1395418691996; Fri, 21 Mar 2014 09:18:11 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 09:18:11 -0700 (PDT) In-Reply-To: <20140321153328.GX24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> <20140321153328.GX24183@mournblade.imrryr.org> Date: Fri, 21 Mar 2014 11:18:11 -0500 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9IRRlfhUMxcz9LGpeTU52KrbjWA Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 16:18:27 -0000 On Fri, Mar 21, 2014 at 10:33 AM, Viktor Dukhovni wrote: > Adjectives can and do decorate multiple nouns without confusion. > This sub-thread is a side-show, I think we should return to the > main topic if there is anything further to say on that. Otherwise, > we have our winner. (What was it again? Did I hear someone say: > > Scalable Opportunistic Adaptive Pragmatic Encryption? > > with the acronym SOAP-E? Now that's marketing! :-) Fortunately the public isn't conscious of the horrors of SOAP, so that would actually work! :^) The public does like acronyms, you know. So that might actually work. And a bag-full of adjectives might be the right approach to convey what we must through redundancy -- no SPOF in our naming :) Nico -- From nobody Fri Mar 21 10:55:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB01A09F5 for ; Fri, 21 Mar 2014 10:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 BwivuN3zjEpC for ; Fri, 21 Mar 2014 10:55:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 333C81A09EF for ; Fri, 21 Mar 2014 10:55:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A530FBE68 for ; Fri, 21 Mar 2014 17:54:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUeRK3ViB0kT for ; Fri, 21 Mar 2014 17:54:48 +0000 (GMT) Received: from [10.2.3.4] (unknown [86.45.63.226]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7BFDCBE5F for ; Fri, 21 Mar 2014 17:54:48 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Stephen Farrell Date: Fri, 21 Mar 2014 17:54:45 +0000 To: saag@ietf.org Message-ID: <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aJ9naT9kgZ5Z_N2czip1aQXcVw0 Subject: [saag] Fwd: W3C Web Crypto API - moving to Last Call 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, 21 Mar 2014 17:55:04 -0000 -------- Original Message -------- From: GALINDO Virginie Sent: 21 March 2014 17:10:45 GMT+00:00 To: Jim Schaad , "odonoghue@isoc.org" , "stephen.farrell@cs.tcd.ie" , "Kathleen.Moriarty.ietf@gmail.com" Cc: Harry Halpin , "wseltzer@w3.org" Subject: W3C Web Crypto API - moving to Last Call Hi IETF and JOSE team, The Web Cryptography Working Group has decided to go to Last Call for the Web Cryptography API next week. We'd like to make sure your group has enough time to review the specification. Is four weeks enough time? If I don't hear back from you, I am going to assume it is enough time. Our latest draft is here: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html Regards, Virginie Galindo Gemalto chair of W3C web crypto wg ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus From nobody Fri Mar 21 11:03:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFA1A09E1 for ; Fri, 21 Mar 2014 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 MSYbDtl0eNjX for ; Fri, 21 Mar 2014 11:03:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id A9F7E1A07B7 for ; Fri, 21 Mar 2014 11:03:20 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id AECBE20041 for ; Fri, 21 Mar 2014 15:22:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 78D9263AB2; Fri, 21 Mar 2014 14:03:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 62CD863A9E for ; Fri, 21 Mar 2014 14:03:09 -0400 (EDT) From: Michael Richardson To: saag In-Reply-To: References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/y2Ad3F_wyM1W-ZzyRVWnouk1gGA Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 18:03:22 -0000 --=-=-= Olle E. Johansson wrote: > Long story, but I do agree with Paul. Let's take ownership of the term > "opportunistic encryption". We don't have the resources to get a new > term out there, established in time for what we want to do. okay. > Let's try to define a common definition of the goal with "opportunistic > encryption" in non-detailed way. Is "non-detailed" a technical way to say, "marketing"? If so, I'm with you. > Then let's define all the solutions > that is grouped under this in a detailed, correct and well-defined > way. And the detailed, protocol-specific mechanisms can have super-cool and/or ultra-obscure, but 100% collision resistant acronyms? I'm for that. ==== X: "Hi, I'm Mr. X, VP marketing of Example Inc. Our new product has Opportunistic Encryption" Me: "Oh, that's awesome. Does it support the OE FLEXSKIVA method?" X: (shuffles papers), "Oh, yes, we support FLEKXIVA, no problem!" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyx+3YqHRg3pndX9AQKdCwQAl2uK7CdOEJ8leJKSrjrBHFpdqlqFSgX8 M0lK3v5TLqxm27RU7v8AyzZQl70yLPiC4ifoojDxj3KUEScfd85SgHw1i2oGfM7+ wty1TKbDUi+5rCFxXH4DMD76Chvu14xpEhdY9Gqp8g4b4oKRHuF6V4dzIIG61eO3 +qmRbSinW5M= =X4hb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 21 11:04:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F131A0A04 for ; Fri, 21 Mar 2014 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 HOtBMniKUA3S for ; Fri, 21 Mar 2014 11:04:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id EA7471A09F0 for ; Fri, 21 Mar 2014 11:04:41 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80F4F20041 for ; Fri, 21 Mar 2014 15:24:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D61063AB2; Fri, 21 Mar 2014 14:04:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6731D63A9E for ; Fri, 21 Mar 2014 14:04:32 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yZI67UgoV1Ix3HTJ6qSdXru_Szo Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 18:04:43 -0000 --=-=-= Paul Hoffman wrote: > Saying that the Postfix's community use of a specific definition of > "opportunistic TLS" should trump the large value of having a single > definition for "opportunistic encryption" feels somewhat selfish. Note > that Michael Richardson, whose RFC was the first to use the term > "opportunistic encryption", have given up change control on the term so > that we can get more universal encryption. And if I could withdraw 4322, to make this process more Happy Happy Joy Joy, I would. :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyx/MIqHRg3pndX9AQKJ5QQAwURCSL9Y+zGI1MwkczFqKACAH3QsO0/2 OWVbe/jZB8MrMR1x/rDNDtXdlyj7Jy9mtE9s2kzjGbLN2byOMb2NyEwckt9xYE9T ebyP8kJOYkfnLt81aw53ZHBxYDBQSYdxmHAwbZuNVZLuqzWVicjfXaE+hJAaszO6 w8H5gEd8k1E= =7qNW -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 21 11:15:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935B1A09FF for ; Fri, 21 Mar 2014 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od8aQ1imHDLc for ; Fri, 21 Mar 2014 11:15:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id BCD631A0A20 for ; Fri, 21 Mar 2014 11:15:49 -0700 (PDT) Received: from mail3-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 18:15:40 +0000 Received: from mail3-ch1 (localhost [127.0.0.1]) by mail3-ch1-R.bigfish.com (Postfix) with ESMTP id E4D0420018C; Fri, 21 Mar 2014 18:15:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zf7Izbb2dI98dI542I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail3-ch1: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(51704005)(2473001)(479174003)(24454002)(13464003)(54316002)(47736001)(56776001)(54356001)(76482001)(47976001)(50986001)(53806001)(86362001)(4396001)(92566001)(46102001)(93516002)(85852003)(49866001)(15975445006)(83506001)(81816001)(95416001)(81686001)(94316002)(94946001)(98676001)(19580395003)(80976001)(19580405001)(83322001)(97336001)(97186001)(93136001)(2656002)(87266001)(83072002)(87936001)(92726001)(56816005)(90146001)(85306002)(74366001)(63696002)(79102001)(77982001)(74482001)(36756003)(74876001)(81342001)(81542001)(15202345003)(76786001)(74662001)(74502001)(47446002)(66066001)(65816001)(80022001)(95666003)(20776003)(51856001)(59766001)(31966008); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:174E7A93.89E695C2.41FB9F8B.D1EADB5C.202DA; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail3-ch1 (localhost.localdomain [127.0.0.1]) by mail3-ch1 (MessageSwitch) id 1395425738193523_13936; Fri, 21 Mar 2014 18:15:38 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail3-ch1.bigfish.com (Postfix) with ESMTP id 2A4461E00CA; Fri, 21 Mar 2014 18:15:38 +0000 (UTC) Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 18:15:37 +0000 Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 18:15:35 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 18:15:35 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 18:15:35 +0000 From: "Paterson, Kenny" To: Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] Fwd: W3C Web Crypto API - moving to Last Call Thread-Index: AQHPRS696WWZ7Sz43EejtnMM+IzKnprr2LaA Date: Fri, 21 Mar 2014 18:15:34 +0000 Message-ID: References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> In-Reply-To: <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [80.42.226.146] x-forefront-prvs: 0157DEB61B Content-Type: text/plain; charset="us-ascii" Content-ID: <30D4493425C9C64E86C44CD6F77DB678@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lrRj6n4sC1PhEBQ4nbCiHZA3kws Cc: "Virginie.GALINDO@gemalto.com" , "cfrg@irtf.org" Subject: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call 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, 21 Mar 2014 18:15:53 -0000 Hi Stephen, [Cross-posting to CFRG, since it seems relevant] On 21/03/2014 17:54, "Stephen Farrell" wrote: >-------- Original Message -------- >From: GALINDO Virginie >Sent: 21 March 2014 17:10:45 GMT+00:00 >To: Jim Schaad , "odonoghue@isoc.org" >, "stephen.farrell@cs.tcd.ie" >, "Kathleen.Moriarty.ietf@gmail.com" > >Cc: Harry Halpin , "wseltzer@w3.org" >Subject: W3C Web Crypto API - moving to Last Call > >Hi IETF and JOSE team, > > > >The Web Cryptography Working Group has decided to go to Last Call for the >Web Cryptography API next week. We'd like to make sure your group has >enough time to review the specification. Is four weeks enough time? If I >don't hear back from you, I am going to assume it is enough time. Our >latest draft is here: > > > >https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > > > >Regards, > >Virginie Galindo > >Gemalto > >chair of W3C web crypto wg > Tibor Jager, Juarj Somorovsky and I sent this team feedback some time ago about the undesirability of standardising already-broken algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no integrity protection).=20 This was in response to a request for feedback from CFRG. We gave them chapter and verse (and citations) about why this is generally a BAD IDEA: http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html The broken algorithms and modes are still in the Web Crypto document. Moreover, there are no relevant warnings about these broken algorithms and modes in the "security considerations" section of the current Web Crypto draft. Needless to say, I'm not minded to provide any more free advice to this group. Cheers, Kenny=20 From nobody Fri Mar 21 11:20:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8C1A0A21 for ; Fri, 21 Mar 2014 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 P8HckvUoE2Ll for ; Fri, 21 Mar 2014 11:20:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CF0F71A0790 for ; Fri, 21 Mar 2014 11:20:09 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LIJSEA018251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 11:19:28 -0700 (PDT) Message-ID: <532C82B2.8040300@isi.edu> Date: Fri, 21 Mar 2014 11:19:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Richardson , saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> <9354.1395425072@sandelman.ca> In-Reply-To: <9354.1395425072@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8Bxl-QGq4Ca1R6CJjUGNNgfy5ZQ Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 18:20:12 -0000 On 3/21/2014 11:04 AM, Michael Richardson wrote: > > Paul Hoffman wrote: > > Saying that the Postfix's community use of a specific definition of > > "opportunistic TLS" should trump the large value of having a single > > definition for "opportunistic encryption" feels somewhat selfish. Note > > that Michael Richardson, whose RFC was the first to use the term > > "opportunistic encryption", have given up change control on the term so > > that we can get more universal encryption. > > And if I could withdraw 4322, to make this process more Happy Happy Joy Joy, > I would. :-) And that's part of the confusion; using a term that originates in that RFC in a way that is explicitly noted as excluded *in that RFC* will continue to cause confusion as long as the term is used to mean both things. That's good reason for using a new term. Familiarity isn't necessarily be worth the baggage. Joe From nobody Fri Mar 21 11:27:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955121A0790 for ; Fri, 21 Mar 2014 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 9aYtF_uWONcC for ; Fri, 21 Mar 2014 11:27:51 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8EC1A08F2 for ; Fri, 21 Mar 2014 11:27:51 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LIQw1q020423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 11:26:58 -0700 (PDT) Message-ID: <532C8474.2050606@isi.edu> Date: Fri, 21 Mar 2014 11:27:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams , Michael Richardson References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> In-Reply-To: <20140320231001.GG3471@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qkN91V5W8wRcVcV1a-H4xGWDgoI Cc: saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 18:27:52 -0000 On 3/20/2014 4:10 PM, Nico Williams wrote: > On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >> We seem to all know what we mean here, we are just bikeshedding on a >> word. > > This is not bikeshedding. Names matter. Consider BTNS... > > BTNS failed for many reasons, but one of them was that the name > indicated much less utility than it provided. > > BTNS (_with_ connection latching) is basically what's being proposed > today, only not using IKE (nor ESP). IMO, it is the persistent desire to bolt BTNS to other components (like connection latching) that undermines its utility and pervasiveness. BTNS was intended to obviate the need for PKI altogether and show the benefit to doing authentication even without confirming identity, whereas connection latching just moves that need to a different protocol layer. Joe From nobody Fri Mar 21 11:44:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14E61A0A38 for ; Fri, 21 Mar 2014 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 VrBevnmQCZQV for ; Fri, 21 Mar 2014 11:44:26 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6BB1A0A39 for ; Fri, 21 Mar 2014 11:44:26 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LIhGSK025670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 11:43:16 -0700 (PDT) Message-ID: <532C8846.3050503@isi.edu> Date: Fri, 21 Mar 2014 11:43:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Michael Richardson , Stephen Farrell References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> In-Reply-To: <532B4B34.3040106@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FkGFOG-x5NRrd9b9rNrRuXKFWcE Cc: saag Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 18:44:28 -0000 On 3/20/2014 1:10 PM, Daniel Kahn Gillmor wrote: > To be clear, i think we're all talking about a best-effort, > "on-by-default" encrypted replacement for cleartext as a way to raise > the cost of pervasive monitoring. We're just lacking consensus on what > we should call that basic concept. This hits one of two key aspects: 1) always there (on by default) 2) not what you really want, but "better than nothing" (that's where BTNS comes from) So maybe something hitting more on point #1 than #2: - reliable security - minimally reliable security Or, if you want "marketing" - minimal and reliable security (MARS) ?? Joe From nobody Fri Mar 21 11:56:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8261E1A0790 for ; Fri, 21 Mar 2014 11:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 YfAhu-bUA0y0 for ; Fri, 21 Mar 2014 11:56:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6F1A08F2 for ; Fri, 21 Mar 2014 11:56:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 89781473F4; Fri, 21 Mar 2014 18:55:52 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1415A47492; Fri, 21 Mar 2014 18:55:52 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id CDE9D80040; Fri, 21 Mar 2014 18:55:51 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Fri, 21 Mar 2014 14:55:51 -0400 From: "Salz, Rich" To: "Paterson, Kenny" , Stephen Farrell , "saag@ietf.org" Date: Fri, 21 Mar 2014 14:55:50 -0400 Thread-Topic: [saag] Fwd: W3C Web Crypto API - moving to Last Call Thread-Index: AQHPRS696WWZ7Sz43EejtnMM+IzKnprr2LaAgAAKdzA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FCF24F04@USMBX1.msg.corp.akamai.com> References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/i91pGUHgRDCzgOEiAYsWoSG4m38 Cc: "Virginie.GALINDO@gemalto.com" , "cfrg@irtf.org" Subject: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call 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, 21 Mar 2014 18:56:04 -0000 Their response seems to have been "we're designing an API for folks who und= erstand the issues." (e.g., http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0189.ht= ml) That seems na=EFve to me. -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Fri Mar 21 12:10:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A051E1A0A1D for ; Fri, 21 Mar 2014 12:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 YcyOgtkIvF5N for ; Fri, 21 Mar 2014 12:10:34 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (agjbgdcfdbgj.dreamhost.com [69.163.253.169]) by ietfa.amsl.com (Postfix) with ESMTP id BDBBC1A09FF for ; Fri, 21 Mar 2014 12:10:34 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 7D7F71601 for ; Fri, 21 Mar 2014 12:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=M3SnW3340BUB/2xyrB3j EWSOV3s=; b=g5KQEsrrIhNg78M8qhzTfYww7K+x6mgHg+SFMmcRJduTYUTgl1V3 /TurwrvGomSGH5C0G4AJUftdLNyqC2Irdh5dkikNccqiiN8ymufD483spjcqvUJk rENoKXkzzWUM++0Na4VpXOv9WlALLKRyFKKJuwL41YOj/mbJGVVgRhQ= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 2B2871600 for ; Fri, 21 Mar 2014 12:10:24 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so1909495wgh.35 for ; Fri, 21 Mar 2014 12:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KhHkuxdWVoB4QSBaynwehvAk+/fudR/Wp4kaS9UJRn4=; b=kVKfdX7Y4LSHdM/8sPhh8Kc+jY0nyT0fkBfBVsy2lzx/D/+JxmfZ6bl8xkDTRVempr jMGdOzFlnHuH/euorCTi6VcbEXdtXtKc/BnpLYHEnBof4mTTFwQlSdyL9jKh1QU4Sbqe +xHjbk59fLg5zMhrq97Iqdb0s4geU1zyQ/5RfDZz/dBNzepaGXWSTy1AlGTIt4QNDbWx QwcJFndeFhUFEEUeD+wHRNoi6VQUi7i36cgQd2tCWLWC9VY7vL3QoE5D/4RcHmI6C7Qx oMvMszR3Fxyt6AcYRwRlDgpLym5OTMZDIJ7uIPSxGi2eQaLIVsa+lkufy3I5lOy23Djn a52w== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr3873562wij.42.1395429023875; Fri, 21 Mar 2014 12:10:23 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 12:10:23 -0700 (PDT) In-Reply-To: <9354.1395425072@sandelman.ca> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> <9354.1395425072@sandelman.ca> Date: Fri, 21 Mar 2014 14:10:23 -0500 Message-ID: From: Nico Williams To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JHh4pk0BTUVM2R1Vo0a-jmqrkhA Cc: "saag@ietf.org" Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 19:10:35 -0000 On Fri, Mar 21, 2014 at 1:04 PM, Michael Richardson wrote: > > Paul Hoffman wrote: > > Saying that the Postfix's community use of a specific definition of > > "opportunistic TLS" should trump the large value of having a single > > definition for "opportunistic encryption" feels somewhat selfish. Note > > that Michael Richardson, whose RFC was the first to use the term > > "opportunistic encryption", have given up change control on the term so > > that we can get more universal encryption. > > And if I could withdraw 4322, to make this process more Happy Happy Joy Joy, > I would. :-) Just update it, give it a new name, or simply note that it has nothing to do with the new meaning of the term. There's no need to make this too hard :) Nico -- From nobody Fri Mar 21 12:15:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD52D1A09FF for ; Fri, 21 Mar 2014 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TS21CwZB7Zm for ; Fri, 21 Mar 2014 12:15:16 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (agjbgdcfdbfe.dreamhost.com [69.163.253.154]) by ietfa.amsl.com (Postfix) with ESMTP id 040FA1A08FD for ; Fri, 21 Mar 2014 12:15:15 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id B759F2C806B for ; Fri, 21 Mar 2014 12:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iRKWHwFfbu30a4mNERYY yjN1LPA=; b=ISjjl8cHqwBHgABEQIPbnidJtCalgRBmF3WhEgr+kKrifUfQbYNI rQGvS5RWRMLC8837IVbOe5+mP+3mDqDn36zVGETf2s3MDOhxp9gfl479IJZwUzNK 01hN9ZNiR15cZ3PwcjzKQDJbGucBoDQSLgLC8BpbRxi0PGaZm9hank0= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 69BC52C8058 for ; Fri, 21 Mar 2014 12:15:06 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so1889535wes.36 for ; Fri, 21 Mar 2014 12:15:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lshr62X8x3nbvxNc8az3TZaKnwO1xTv0wTekpFX+ttE=; b=g/elsIHWF5gDZuPeogW6BGVm/jrbrmlTrOfUX6IwQgfTMROcRC5owdUXhLIsIpZD2E LSi87Bmckh/rRGjGUSDSZELEl1pBnyksNOhObc/TtKYdhYtTgte00ls38oGgY1VBF+NV Zx7MbCSOVupSCfRkQw+L1i3Kv4yDoTqBFnC/L20eoQ2B9+9IR4EsNwjhnjlMGast5sZr 898E9J1rR/P3azWsYH/NGRHQpqsyjjriydjEf4VSCjZ17sy14UIxUz9vSUL1T77/+hjf ezWm6uDMINmENYz+PDH8xrzp/g+v009Nx3AOVkwaLevOF1Udss1vkTw7r4Hb+BN0k5fq Ugog== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr4574831wib.39.1395429305090; Fri, 21 Mar 2014 12:15:05 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 12:15:05 -0700 (PDT) In-Reply-To: <532C8474.2050606@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> Date: Fri, 21 Mar 2014 14:15:05 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CoEyevWeapkgm8nzKOawJcRdyfg Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 19:15:17 -0000 On Fri, Mar 21, 2014 at 1:27 PM, Joe Touch wrote: > On 3/20/2014 4:10 PM, Nico Williams wrote: >> BTNS (_with_ connection latching) is basically what's being proposed >> today, only not using IKE (nor ESP). > > > IMO, it is the persistent desire to bolt BTNS to other components (like > connection latching) that undermines its utility and pervasiveness. I'm not sure how to put this diplomatically, but I'll try. End-to-end IPsec w/o connection latching is *worse* than the TLS renego and resumption bugs, and for the same sorts of reason: missing cryptographic bindings. The only reason that nobody gives a damn about that problem is that nobody uses IPsec for anything other than VPN or in small networks. If we don't learn the lessons of the TLS debacles (each and every one of them) then let's just give up. > BTNS was intended to obviate the need for PKI altogether and show the > benefit to doing authentication even without confirming identity, whereas > connection latching just moves that need to a different protocol layer. You're confusing your intentions for BTNS with mine. Nico -- From nobody Fri Mar 21 12:17:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2551A0790 for ; Fri, 21 Mar 2014 12:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 1NLKrcldOBIw for ; Fri, 21 Mar 2014 12:16:59 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (unknown [69.163.253.149]) by ietfa.amsl.com (Postfix) with ESMTP id DFA1B1A08FD for ; Fri, 21 Mar 2014 12:16:57 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 9E1912005D90B for ; Fri, 21 Mar 2014 12:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tLkeMww9YkO7Jm+yFoys znmnh3E=; b=JSjxcRitWVoqM7CcC0XVYwDBAjP7qvIU8elWPiwHN5XVnf+Gv87I AN+X27M0UCQlS3CN36/ejulVaUwA5OB/zR7jdIdNE49OaV8+rv6WwyznKUJMigjX VxGqmrq5D4HfY8YUkxx7zGqq2AT6Bq+wCmvx7UnAexTjRnFma4T6yec= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id 532E82005D90E for ; Fri, 21 Mar 2014 12:16:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so862926wib.2 for ; Fri, 21 Mar 2014 12:16:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DLoas4KRjxaJb7OkiOPcTWnx/PluxE02qgCzhgwruK4=; b=SWxho9wyS12o9P+U+4sna+JByGm5+PzNwXsDcdKrbbQiKg8Qh7QLwY69V8mq/mSHWe UZcAoA+NhYHic0taZOUtPpgiNHY5s35ykfN+ncM6+ZX+eMvVeYVNzyKkpJm4gqALKb1R YIVWo501qZKgUd37chsSNi33Wd622R2Dh1u/DVtYlPNgHxmVYSDvn+ax2u9TM4UOwGaF xsAw7wePVf8NBEHRdoPurewYUYYBzaqJZSzCTJgZr31mnpWp835dGtpTeR6f6z05Wk6m lC9GE7ttCQVyuyC7+bQBeqxXHRUEV0vkgz8QzKPqraiOmpDtWXXn9ApU0FPZ3VYcSzye hf/w== MIME-Version: 1.0 X-Received: by 10.180.189.139 with SMTP id gi11mr4497851wic.53.1395429407242; Fri, 21 Mar 2014 12:16:47 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 12:16:47 -0700 (PDT) In-Reply-To: <532C8846.3050503@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532C8846.3050503@isi.edu> Date: Fri, 21 Mar 2014 14:16:47 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JZiZkOtwDXScCyDW2cA9kY5HwYA Cc: Michael Richardson , saag Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 19:17:00 -0000 On Fri, Mar 21, 2014 at 1:43 PM, Joe Touch wrote: > On 3/20/2014 1:10 PM, Daniel Kahn Gillmor wrote: >> To be clear, i think we're all talking about a best-effort, >> "on-by-default" encrypted replacement for cleartext as a way to raise >> the cost of pervasive monitoring. We're just lacking consensus on what >> we should call that basic concept. > > > This hits one of two key aspects: > > 1) always there (on by default) > > 2) not what you really want, but > "better than nothing" > > (that's where BTNS comes from) > > So maybe something hitting more on point #1 than #2: > > - reliable security > > - minimally reliable security > > Or, if you want "marketing" > > - minimal and reliable security (MARS) > > ?? No, no, and no. No names that invite condescension. We've seen that movie. Let's try something original instead of a rerun. Nico -- From nobody Fri Mar 21 12:19:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607FC1A08FD for ; Fri, 21 Mar 2014 12:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Smr0eI6qxLpX for ; Fri, 21 Mar 2014 12:19:05 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3AD1A0790 for ; Fri, 21 Mar 2014 12:19:05 -0700 (PDT) Received: from [10.230.254.208] (mobile-166-137-219-193.mycingular.net [166.137.219.193]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LJIbHE006858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 12:18:41 -0700 (PDT) References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11D167) From: Joe Touch Date: Fri, 21 Mar 2014 12:18:37 -0700 To: Nico Williams X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_3F74wWcnFTfMt_3xrtD4v3rJMs Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 19:19:06 -0000 > On Mar 21, 2014, at 12:15 PM, Nico Williams wrote: > >> On Fri, Mar 21, 2014 at 1:27 PM, Joe Touch wrote: >>> On 3/20/2014 4:10 PM, Nico Williams wrote: >>> BTNS (_with_ connection latching) is basically what's being proposed >>> today, only not using IKE (nor ESP). >> >> >> IMO, it is the persistent desire to bolt BTNS to other components (like >> connection latching) that undermines its utility and pervasiveness. > > I'm not sure how to put this diplomatically, but I'll try. End-to-end > IPsec w/o connection latching is *worse* than the TLS renego and > resumption bugs, and for the same sorts of reason: missing > cryptographic bindings. The only reason that nobody gives a damn > about that problem is that nobody uses IPsec for anything other than > VPN or in small networks. > > If we don't learn the lessons of the TLS debacles (each and every one > of them) then let's just give up. > >> BTNS was intended to obviate the need for PKI altogether and show the >> benefit to doing authentication even without confirming identity, whereas >> connection latching just moves that need to a different protocol layer. > > You're confusing your intentions for BTNS with mine. Given I took BTNS to the IETF, I'm not confused at all. Joe > > Nico > -- From nobody Fri Mar 21 12:21:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5501A0A21 for ; Fri, 21 Mar 2014 12:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 5ew_5IAluCLX for ; Fri, 21 Mar 2014 12:21:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7EF1A08FD for ; Fri, 21 Mar 2014 12:21:30 -0700 (PDT) Received: from [10.230.254.208] (mobile-166-137-219-193.mycingular.net [166.137.219.193]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2LJJwGd013179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 12:20:09 -0700 (PDT) References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532C8846.3050503@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11D167) From: Joe Touch Date: Fri, 21 Mar 2014 12:19:58 -0700 To: Nico Williams X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/R7Fr_gmIQpDsAXLg2HCZcbbedeM Cc: Michael Richardson , saag Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 19:21:32 -0000 > On Mar 21, 2014, at 12:16 PM, Nico Williams wrote: > >> On Fri, Mar 21, 2014 at 1:43 PM, Joe Touch wrote: >>> On 3/20/2014 1:10 PM, Daniel Kahn Gillmor wrote: >>> To be clear, i think we're all talking about a best-effort, >>> "on-by-default" encrypted replacement for cleartext as a way to raise >>> the cost of pervasive monitoring. We're just lacking consensus on what >>> we should call that basic concept. >> >> >> This hits one of two key aspects: >> >> 1) always there (on by default) >> >> 2) not what you really want, but >> "better than nothing" >> >> (that's where BTNS comes from) >> >> So maybe something hitting more on point #1 than #2: >> >> - reliable security >> >> - minimally reliable security >> >> Or, if you want "marketing" >> >> - minimal and reliable security (MARS) >> >> ?? > > No, no, and no. No names that invite condescension. We've seen that > movie. Let's try something original instead of a rerun. That would be fine too. O* being a rerun. Joe > > Nico > -- From nobody Fri Mar 21 12:33:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FFE1A0A1D for ; Fri, 21 Mar 2014 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx-YvyFPGAeO for ; Fri, 21 Mar 2014 12:33:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (agjbgdcfdbfe.dreamhost.com [69.163.253.154]) by ietfa.amsl.com (Postfix) with ESMTP id DC5891A09FD for ; Fri, 21 Mar 2014 12:33:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AEA332C806D for ; Fri, 21 Mar 2014 12:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4F43YNkrHKzZFVUnbuVG 63oU86A=; b=arCee46nFfA+LknBCBeEj0khGEDgWNCR+RMTphgmdI89DHj8fuWE +Jlw+2SJ2kR3CkfLUeDyEIaODzOfQym2JwofQSx4TjM2J6Pu6itOjOmtILqUp/cI OsAYMEIK3M++5kTJSZrDBxk3sHvX5Ai2OZkbtrps0p5evQFMWDk0EFw= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 5FE082C8082 for ; Fri, 21 Mar 2014 12:33:34 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so816277wiv.15 for ; Fri, 21 Mar 2014 12:33:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=azI771R8RG91daH7CA09ut5Lb8dpv/WLSjQR0S/3eR4=; b=HuU2P46zC6bOtQp5gcNhhSkB8CTKeqKuUvhcKCv4GRHfdKxo2Tm91uPN98Jq94FzZF 5DYQt2ZZmKDS9fmQ+yDVHtb0zyHQPg0aKiCPZwecMYf1gck+ISod6zdetDU6Idhq9642 0+XHKvq3IKk75JJBeN7v3Z88aF6XoWuuVflkkVskZjqXUZWfep4nAK6FJK/D4Bx1Jl0s U/VBsDKwhZmYBzKZixE7TjS+EFjvx5FR7Ux902sh2gR0TYoNPybS0YuZKW9ex0j/IWpC ZERte9vO0GyXVmMvveltJC6q34Vs8POaoIMSl6KIJpZxodpfg1Cd0h9HaR1932f3Aar8 gv2A== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr3982537wij.42.1395430413243; Fri, 21 Mar 2014 12:33:33 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 12:33:33 -0700 (PDT) In-Reply-To: References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> Date: Fri, 21 Mar 2014 14:33:33 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4tuSo40YpWp1XZn_xld4t8AQ8WE Cc: saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 19:33:45 -0000 On Fri, Mar 21, 2014 at 2:18 PM, Joe Touch wrote: >> On Mar 21, 2014, at 12:15 PM, Nico Williams wrote: >>> BTNS was intended to obviate the need for PKI altogether and show the >>> benefit to doing authentication even without confirming identity, whereas >>> connection latching just moves that need to a different protocol layer. >> >> You're confusing your intentions for BTNS with mine. > > Given I took BTNS to the IETF, I'm not confused at all. You know -or should remember- that that's not quite right. You're leaving out a lot of details. It's a forgivable error. I don't want to get into a pissing match because it's not becoming, and I don't want to embarrass myself as much as you have yourself. I'll leave it here. I ask you instead to stop acting as though your intended use of BTNS was the only one. If you want to continue this I recommend we go off-list so we stop lowering the signal-to-noise ratio on the list. Nico -- From nobody Fri Mar 21 13:02:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97E1A06F0 for ; Fri, 21 Mar 2014 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Q7qAzOlmWgqC for ; Fri, 21 Mar 2014 13:02:16 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6019B1A034F for ; Fri, 21 Mar 2014 13:02:16 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LK1fD0020271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 13:01:41 -0700 (PDT) Message-ID: <532C9AA7.505@isi.edu> Date: Fri, 21 Mar 2014 13:01:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4EBxUVCGXXHDWzIM4Pqa6KqHSog Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:02:17 -0000 On 3/21/2014 12:15 PM, Nico Williams wrote: >> IMO, it is the persistent desire to bolt BTNS to other components (like >> >connection latching) that undermines its utility and pervasiveness. > > I'm not sure how to put this diplomatically, but I'll try. End-to-end > IPsec w/o connection latching is*worse* than the TLS renego and > resumption bugs, and for the same sorts of reason: missing > cryptographic bindings. FWIW, there's nothing worse than a connection that cannot make progress, and that's what happens when you have TLS that can be shutdown. BTNS IPsec stand-alone (without connection latching) accomplishes a few things: - raises the bar of attackers, who now need to participate in the DH exchange as a MITM to succeed (vs just sending individual packets that don't require computation) - keeps a connection from being shutdown in-progress by off-path attacks; once you've connected, you stay connected Those are worth something. Not what TLS provides, and not what IPsec provides, but "better than nothing". Joe From nobody Fri Mar 21 13:12:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28C31A0808 for ; Fri, 21 Mar 2014 13:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 vyIjF2yYP5S2 for ; Fri, 21 Mar 2014 13:12:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (unknown [69.163.253.179]) by ietfa.amsl.com (Postfix) with ESMTP id D07611A07F6 for ; Fri, 21 Mar 2014 13:12:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 52F091DE085 for ; Fri, 21 Mar 2014 13:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UlDqa1awdXmSuyAMjgSu XWVxgHY=; b=iZ6kX5H9WvGu2my09zBCXxvJKE5F4ilqwAcKgxDIwuuGhnzkdIC/ YGSHPJ1ttAKX8awU5YOhfHaDbtLMDTIjOFNWQGdbHLt4i+/wXSxmwKLpZ1k+M9F0 OfvirVeavXmLl+e3kO4YbCKfr4dCiAAt6yY8n0bHrQ1/Ki+LNeyMGwM= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 01C571DE084 for ; Fri, 21 Mar 2014 13:12:18 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so854047wiv.3 for ; Fri, 21 Mar 2014 13:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ctCvkdWYPZklkIIUoni4Ei1PULcRMJt3dI5ISo5kXvU=; b=Qp2QsOrP9Svkd5CR2epkFXbBj1xsLS+BJAbXhfS0tbAUVjmdEy4HW6x2ZZLaBgKHOX Zp8j5JFge8bjYnYCTxTO3jPvHCTgB3pGQdkLmH4b2GksaItxehq3/SNPNGK3XBCAMGcP yZPD8PhqWWzwJ2Q3GpvuCK1boq4nLTKqeDTGwOc3aOT7oQ3PMwacHX+dh25KJ2Wt1w4j oYpMEOrxDEytU7q/+VlrAZAD9c8xQ8lPVGpVjgk3kJt8CPkJzlrw0R+x7xhP50F03zhi 3TRoZjweHR/0vMhm0BDSj34fW8H/vjuj3Jth/hg8+djRsqGHsd0saGbdN1FsQOsqGiIp 3nNg== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr4850663wib.39.1395432737963; Fri, 21 Mar 2014 13:12:17 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 13:12:17 -0700 (PDT) In-Reply-To: <532C9AA7.505@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> Date: Fri, 21 Mar 2014 15:12:17 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PWSBTsi65Jg5SUJO7UJBQjw7XfA Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:12:30 -0000 On Fri, Mar 21, 2014 at 3:01 PM, Joe Touch wrote: > FWIW, there's nothing worse than a connection that cannot make progress, and > that's what happens when you have TLS that can be shutdown. We don't care: BGP is stupid. We're talking about !BGP. We may even be talking about !TCP. We're NOT going to have success with an IPsec-based solution (the specs necessary for that are already published). The trend is to deal with all problems at the app layer. People have written high-performance TCP/IP user-land stacks and others have written kernel-mode apps, all using TCP or UDP and no IPsec in sight. If apps need to reconnect, they will. That's why we have so much work going into things like TCP Fast Open or TLS zero-round trip session resumption. That's the future: in-bad key exchange. It's the future because out-of-band key exchange (i.e., IKE) failed, and it failed for many, many reasons all of which can be summarized as: a) out-of-band == lots of OS infrastructure which b) was never good enough that the apps got enough control or information. You're stuck in the past Joe. Nico -- From nobody Fri Mar 21 13:26:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981691A08E2 for ; Fri, 21 Mar 2014 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Z1B3151kAayz for ; Fri, 21 Mar 2014 13:26:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A41A0A10 for ; Fri, 21 Mar 2014 13:26:45 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LKQ6ZY027591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 13:26:07 -0700 (PDT) Message-ID: <532CA060.2030307@isi.edu> Date: Fri, 21 Mar 2014 13:26:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uxtvXhOz0qtc9YtXpVq1cFuJ8zU Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:26:48 -0000 On 3/21/2014 1:12 PM, Nico Williams wrote: > On Fri, Mar 21, 2014 at 3:01 PM, Joe Touch wrote: >> FWIW, there's nothing worse than a connection that cannot make progress, and >> that's what happens when you have TLS that can be shutdown. > > We don't care: BGP is stupid. We're talking about !BGP. We may even > be talking about !TCP. We're NOT going to have success with an > IPsec-based solution (the specs necessary for that are already > published). Agreed; the idea of using DH without signatures can be applied to any layer - e.g., TLS (on both ends, not just one), TCP-AO, etc. > The trend is to deal with all problems at the app layer. The trend is to reinvent the Internet at the app layer; not all trends are good. But even at the app layer, or in app-layer tunneled implementations (e.g., IPsec over UDP), there is a benefit to providing some security without assuming any PKI. > If apps need to reconnect, they will. They will try, but it comes at a cost. Regardless, there's benefit to having security that makes fewer assumptions but still provides something better than the absence of security. ... > That's the future: in-band key exchange. In-band or out-of-band, assuming PKI is the problem, and the past we need to move beyond. Joe From nobody Fri Mar 21 13:36:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D62C1A08E2 for ; Fri, 21 Mar 2014 13:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 d_W4C4alGSV4 for ; Fri, 21 Mar 2014 13:36:20 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (unknown [69.163.253.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDC91A09F5 for ; Fri, 21 Mar 2014 13:36:20 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id A9A9D1E071 for ; Fri, 21 Mar 2014 13:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=NfNjo2yZZKdEFL9PQtvs nzIK2aQ=; b=COJJXS8SYXmiQeHxxT/tcmtvcXVmOmUc8I7+X1M0StxmbV7ZYLHb LjkP+oNStvZsNI2mOrVmd9Yi9JrymnGQgU+0IbEcbyxWP52tJOt8NLrDtwZxtP9T b5VZE419wTJq5UZwss2OVVI1Zqovi1IoR6VmbFynNgA1sl3/dcvh6vk= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 53FBF1E064 for ; Fri, 21 Mar 2014 13:36:10 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1948011wes.34 for ; Fri, 21 Mar 2014 13:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tuz8KgB5iPZP/LF1cFJOjd52OigTr3ER9YHVTuUbEeU=; b=KiTjmNQg8Ks/Phs+/QTERJ8PAyP7vY4Bk+oFlyCuMvfEY4X42heJ/76fsMlxV+2btG 55y6Pe0JF1gXpkcA2Gfx19eh6AE6Ynb8cyLeVet03u2kUeirUZ1Ri6U/qKjZENhdtims ijhLeE9on0SOoxRXZgawD7BDXcCQIXRUarjQ11E7Kk+Z7PuMwdT7lLAOKCzgw+/rC0kX Id3UFA2V9kSFi5ILfGK5brREyQ61E4OWIj/TxzehF6bLjOouZlWpi7DEQtpWN8A5tRmT DcbxZXo1QPEpC4DFSLI7XyKixFxZ03V0GhCa64JEsRnkA1aezSVpiHr4dRqV/Ii0RH7j mYpw== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr4995087wib.1.1395434169330; Fri, 21 Mar 2014 13:36:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 13:36:09 -0700 (PDT) In-Reply-To: <532CA060.2030307@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> Date: Fri, 21 Mar 2014 15:36:09 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HLAmsQeqyBRkjjrDW0_QKP-MoUc Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:36:21 -0000 On Fri, Mar 21, 2014 at 3:26 PM, Joe Touch wrote: > On 3/21/2014 1:12 PM, Nico Williams wrote: >> The trend is to deal with all problems at the app layer. > > The trend is to reinvent the Internet at the app layer; not all trends are > good. But even at the app layer, or in app-layer tunneled implementations > (e.g., IPsec over UDP), there is a benefit to providing some security > without assuming any PKI. This trend is a very, very good one. Are you familiar with mosh (http://mosh.mit.edu/)? You should be. Mosh solves mobility... because TCP doesn't. Because all relevant IP mobility options are too complex, not in widespread use or available, or have annoying trade-offs. Is that bad? No! If the IETF missed the boat on mobility at the TCP and/or IP layers, well boo-hoo and too bad. But it also indicates that often we should do less at the lower layers and more at the higher layers. Yes, we can be more efficient at lower layers. That's why I wanted BTNS w/ connection latching and CB: so we could push crypto down to the ESP layer, where a) we'd have fewer cryptographic keys/schedules/contexts (NFS multiplexes multiple users' traffic on one connection, so that's a win), b) it'd be easier to fob off the ESP crypto onto NICs like Sun's Neptune NIC. It didn't happen. Get over it. Instead we now have AES-NI and such, so we can cope. >> If apps need to reconnect, they will. > > > They will try, but it comes at a cost. Regardless, there's benefit to having > security that makes fewer assumptions but still provides something better > than the absence of security. With TCP FO and zero-round trip resumption the cost is minimal. With UDP there's equivalent costs. >> That's the future: in-band key exchange. > > In-band or out-of-band, assuming PKI is the problem, and the past we need to > move beyond. PKI is orthogonal. I'm making zero assumptions about authentication technology. Stop confusing things. Nico -- From nobody Fri Mar 21 13:45:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E171A08DB for ; Fri, 21 Mar 2014 13:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 HFNiI5bWN0gX for ; Fri, 21 Mar 2014 13:45:44 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEB71A0792 for ; Fri, 21 Mar 2014 13:45:44 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LKjKMF003849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 13:45:20 -0700 (PDT) Message-ID: <532CA4E2.6020309@isi.edu> Date: Fri, 21 Mar 2014 13:45:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pCyYyRKFj4RvyheSiAZxaKAUN6s Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:45:46 -0000 On 3/21/2014 1:36 PM, Nico Williams wrote: > On Fri, Mar 21, 2014 at 3:26 PM, Joe Touch wrote: >> On 3/21/2014 1:12 PM, Nico Williams wrote: >>> The trend is to deal with all problems at the app layer. >> >> The trend is to reinvent the Internet at the app layer; not all trends are >> good. But even at the app layer, or in app-layer tunneled implementations >> (e.g., IPsec over UDP), there is a benefit to providing some security >> without assuming any PKI. > > This trend is a very, very good one. Are you familiar with mosh > (http://mosh.mit.edu/)? You should be. > > Mosh solves mobility... because TCP doesn't. Because all relevant IP > mobility options are too complex, not in widespread use or available, > or have annoying trade-offs. > > Is that bad? No! If the IETF missed the boat on mobility at the TCP > and/or IP layers, well boo-hoo and too bad. > > But it also indicates that often we should do less at the lower layers > and more at the higher layers. That's an argument for overlays, but not necessarily for reinventing the Internet at the app layer. ... >>> That's the future: in-band key exchange. >> >> In-band or out-of-band, assuming PKI is the problem, and the past we need to >> move beyond. > > PKI is orthogonal. I'm making zero assumptions about authentication > technology. Stop confusing things. Sorry, but if you don't get around the PKI problem, your approach is already DOA. PKI *is* the problem. Joe From nobody Fri Mar 21 13:52:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171001A09F5 for ; Fri, 21 Mar 2014 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 u_jI6g8k62Ns for ; Fri, 21 Mar 2014 13:52:20 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (unknown [69.163.253.186]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCB1A08E2 for ; Fri, 21 Mar 2014 13:52:20 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 15DB71E064 for ; Fri, 21 Mar 2014 13:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lIU2W6aki61cCRkaBB1o bAcj1dI=; b=h+zXI4eDYafSoAzSl2jMXeL0MuA8eXaz5Y2b/Jq3RwVQQ7ibIISO 50A/9XhSL8cXnPh4q3o7JJbiF7zbfaWWgsglTNg7MfbLG3haM9Q0S5DbSKHYUGwF Itmo3hOIqVRtWBNaR2tsFmq4K3dZMRYp1noQmdTCz6/Tl/jDaf1+hpo= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id BD5DA1E059 for ; Fri, 21 Mar 2014 13:52:10 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so1932003wgg.6 for ; Fri, 21 Mar 2014 13:52:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYLSzfAgz0aBeEcN35xLJRRrelTwk847BWAmI6xkR1I=; b=f5iQCGo5MtzCXztK3TWWGAUS6goLbCCCplwxqLNFokGjO0HQSgtMlffLYNr/AdEuV4 7+5BvB7yUl1aXWXIArBWr3AyTpingfSIsfkgb+dwAyog6HgT+BWw+4s/w1NmN4j8tUM9 xmzL6mLaEAMgDjlQY2Q/WRkLORaahsg+EmNo8S26vWDvSoSphkiwzskRzY/iW/F+9Mhv 3zJYap7Ca0molSHsam2M/9+Jew1moAtCaciYN54dIK9ZxSBYgTKzbXEUYNtNSr7vX21+ 6Ee/JvSjQRaFGGQBH5xo7LQK7rL2l2bin4/aBz6agGNHhAs7pxspNBwA68Cvs5ef/e+i BGvA== MIME-Version: 1.0 X-Received: by 10.180.189.139 with SMTP id gi11mr4928606wic.53.1395435129538; Fri, 21 Mar 2014 13:52:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 13:52:09 -0700 (PDT) In-Reply-To: <532CA4E2.6020309@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> Date: Fri, 21 Mar 2014 15:52:09 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZZruOatWwVwGDCi_9GUZIi-8lZQ Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 20:52:21 -0000 On Fri, Mar 21, 2014 at 3:45 PM, Joe Touch wrote: > On 3/21/2014 1:36 PM, Nico Williams wrote: >>>> That's the future: in-band key exchange. >>> >>> In-band or out-of-band, assuming PKI is the problem, and the past we need >>> to >>> move beyond. >> >> PKI is orthogonal. I'm making zero assumptions about authentication >> technology. Stop confusing things. > > Sorry, but if you don't get around the PKI problem, your approach is already > DOA. > > PKI *is* the problem. The whole point of whatever we're going to call that which is being proposed in this and related threads is to start by providing ephemeral-ephemeral [EC]DH key exchange, unauthenticated. I.e., NO bloody PKI. *Then* attempt too to do something for authentication, such as DANE, PKI, Kerberos, anything, anything you can make work that's appropriate to the apps'/user's context/policies/goals. I guess you just haven't read these threads, so you're just making noise. Please stop. Nico -- From nobody Fri Mar 21 14:04:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125561A0720 for ; Fri, 21 Mar 2014 14:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 QHoU4znB69re for ; Fri, 21 Mar 2014 14:04:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7C1A0410 for ; Fri, 21 Mar 2014 14:04:32 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LL4Bhg009883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 14:04:11 -0700 (PDT) Message-ID: <532CA94D.5030407@isi.edu> Date: Fri, 21 Mar 2014 14:04:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/kYdGNTKE9OEwmuBF04tKRjTjnDY Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:04:34 -0000 On 3/21/2014 1:52 PM, Nico Williams wrote: ... >> PKI *is* the problem. > > The whole point of whatever we're going to call It may be YOUR point, but it isn't mine... > that which is being > proposed in this and related threads is to start by providing > ephemeral-ephemeral [EC]DH key exchange, unauthenticated. I.e., NO > bloody PKI. No PKI for the first step... > *Then* attempt too to do something for authentication, > such as DANE, PKI, Kerberos, anything, anything you can make work > that's appropriate to the apps'/user's context/policies/goals. These all end up assuming preshared keys or PKI. So you're back where you started in terms of getting things to work "all the time". FWIW, the result is exactly what we called BTNS-CBB in RFC 5387, except applying them to other protocols that aren't IPsec (which nothing in BTNS was really tied to, except by instantiation of specific protocol changes). Joe From nobody Fri Mar 21 14:13:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC91A0410 for ; Fri, 21 Mar 2014 14:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 oGZEMcrIQRlc for ; Fri, 21 Mar 2014 14:13:54 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A21A0720 for ; Fri, 21 Mar 2014 14:13:54 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id C652831805D for ; Fri, 21 Mar 2014 14:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dKtsfCSo1qOlMa9DUwST PXFnPPg=; b=wcC0GECj4dtld1oqYXT0Sh9sd9HHUv0YfJ8foo+XT8ZUqTv1WGp2 6BhPCQTIu/CYWn/ffTTMWul8kolwYyIfv4+46W5PDrxNRZOc/PPSfjiP3EXcn9mJ +sRSqkn/mxlJjSX0QyEkAVAWEAlYX7pRRAY8ZI/JJ255a7biI2CaTjU= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 776B2318057 for ; Fri, 21 Mar 2014 14:13:44 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so1924222wes.22 for ; Fri, 21 Mar 2014 14:13:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2PhOe409Tev9r/8WGgVuRTNmAYuT8OPrWyQ0TIZFxmA=; b=DCNP6fnbbwyBeGGeVWQVEPOPxxh0iALKPrBuRTIwoxICxeEddiPzCP3JRDLvV+PM2g QPBZJQSH3M0PWq0Tt3DEsZ+BXqZdOF4c6xjuE9u/KeIiRt1sogksoy/JONFbsUKl2Hwo ZA1EE2suaIo/4HiY9+7CAF55NW7gVaPbNwrH0xj2+eaa/rokhLIG1HYKxTfuZUS27fNk Iz2jJBSiIzqurt7negCl7Ey9omYwD+oaD96NiHEOKkGkSIcNYyHddAIMa3kiqnPJLrAx bxiYaDdnXG2lMBKW3CgWFXwBXygMdWTF/UjDXgImjyVmr4Sg1SOUBqzzPuB/uAA+weDw otHw== MIME-Version: 1.0 X-Received: by 10.180.189.139 with SMTP id gi11mr5030596wic.53.1395436423434; Fri, 21 Mar 2014 14:13:43 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 14:13:43 -0700 (PDT) In-Reply-To: <532CA94D.5030407@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CA94D.5030407@isi.edu> Date: Fri, 21 Mar 2014 16:13:43 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Y8KKyEIfPwxIlae5qdPy_irc078 Cc: Michael Richardson , saag Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:13:55 -0000 On Fri, Mar 21, 2014 at 4:04 PM, Joe Touch wrote: > On 3/21/2014 1:52 PM, Nico Williams wrote: >> that which is being >> proposed in this and related threads is to start by providing >> ephemeral-ephemeral [EC]DH key exchange, unauthenticated. I.e., NO >> bloody PKI. > > No PKI for the first step... Right. > >> *Then* attempt too to do something for authentication, >> such as DANE, PKI, Kerberos, anything, anything you can make work >> that's appropriate to the apps'/user's context/policies/goals. > > These all end up assuming preshared keys or PKI. So you're back where you > started in terms of getting things to work "all the time". I'm done responding to you. You're just making too much noise. Nico -- From nobody Fri Mar 21 14:15:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894021A0410 for ; Fri, 21 Mar 2014 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 BccU4id1NBVF for ; Fri, 21 Mar 2014 14:15:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5041A08C6 for ; Fri, 21 Mar 2014 14:15:52 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2LLFgeI025951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Mar 2014 17:15:42 -0400 Received: from bofh.nohats.ca (vpn-56-39.rdu2.redhat.com [10.10.56.39]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2LLFfn6014062 for ; Fri, 21 Mar 2014 17:15:42 -0400 Message-ID: <532CABFD.6010309@redhat.com> Date: Fri, 21 Mar 2014 17:15:41 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p4702BjCnRGMKrIFcSmA2dRn8nw Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:15:55 -0000 On 03/21/2014 04:52 PM, Nico Williams wrote: > The whole point of whatever we're going to call that which is being > proposed in this and related threads is to start by providing > ephemeral-ephemeral [EC]DH key exchange, unauthenticated. I.e., NO > bloody PKI. That was not my impression. That might be one mode of things, but authentication via DANE out-of-band still falls within my candidate definition of "opportunistic" (based on: I am told to initiate unencrypted, let's look in DNS if i can do better than that) Paul From nobody Fri Mar 21 14:19:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CABC1A0A09 for ; Fri, 21 Mar 2014 14:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mgqS0ntsMeG for ; Fri, 21 Mar 2014 14:19:54 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (agjbgdcfdbfj.dreamhost.com [69.163.253.159]) by ietfa.amsl.com (Postfix) with ESMTP id DED671A08C7 for ; Fri, 21 Mar 2014 14:19:54 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id A3632674060 for ; Fri, 21 Mar 2014 14:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Z7c2Jc3KRZYl/MaIKjik BrKEg1s=; b=oSuCTQATej4Mmq2TR3MGWFqVBhf+psDxki2DREiY0Uz7J7AfecCM AdE7f9UGHWPrwyU8Upl9aPYzNjLfdVDYsNnRfU2lxD6O3x8eS6yv4028dTd9nPGV s4H/GLWsEBheLtbawXhqHn7J5c7FmcevNZsPJ5YT2jCIG/8Q8zxwV+s= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 55A36674057 for ; Fri, 21 Mar 2014 14:19:45 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so1940088wgh.34 for ; Fri, 21 Mar 2014 14:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/O7CIHbvhXBkNTgB9n6pp8BcKppuDxyM/VZArW80gJs=; b=DH02Dk71Dh65SVs4ngS9FhfJo+nQTUCaSnmA1dYOGZoCe7T/BtsxHzmokHB5RVik2B dwREKW5AiYF0b7lCkA+CRxP08UIxQIIMIGJI+uumluBtyBqdtIgzBz+K1U3aPmqYpFzR h9QCNlBdh+dERT5Aq3EuPlWIxalSGzgcDmygYDmJ9y+9NW5y7uIbDz1d4mwJDFBKDdIj sfF+ib9vDQuTTXirxqXjDMqxWJzlKg8oHKxf7F2NoBgbuPvJTLnUIdB3yibsig3kXyJI O/nQa0d1qrXhFHIelqmOI++2jM/t2DBrSfynyuU9Hqml5crt7F8gjRHbomtacBbyOZ7o Ma1A== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr80538wib.1.1395436784187; Fri, 21 Mar 2014 14:19:44 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 14:19:44 -0700 (PDT) In-Reply-To: <532CABFD.6010309@redhat.com> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> Date: Fri, 21 Mar 2014 16:19:44 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZyzvfMgGxmHm_gXDURvgJEtd5iA Cc: "saag@ietf.org" Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:19:56 -0000 On Fri, Mar 21, 2014 at 4:15 PM, Paul Wouters wrote: > On 03/21/2014 04:52 PM, Nico Williams wrote: > >> The whole point of whatever we're going to call that which is being >> proposed in this and related threads is to start by providing >> ephemeral-ephemeral [EC]DH key exchange, unauthenticated. I.e., NO >> bloody PKI. > > That was not my impression. That might be one mode of things, but authentication via DANE out-of-band still falls within my candidate definition of "opportunistic" Right. Where do we disagree? > (based on: I am told to initiate unencrypted, let's look in DNS if i can do better than that) Right. Remember the context: Joe claims doing anything more than unauthenticated DH == PKI, omg omg!!! So you're picking nits in my response to Joe's silliness, which isn't useful if you agree he's being silly :) Nico -- From nobody Fri Mar 21 14:26:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2D91A0A18 for ; Fri, 21 Mar 2014 14:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 IdA_G98PgZmQ for ; Fri, 21 Mar 2014 14:26:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCC61A07F9 for ; Fri, 21 Mar 2014 14:26:09 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LLPUij016871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 14:25:30 -0700 (PDT) Message-ID: <532CAE4C.1070104@isi.edu> Date: Fri, 21 Mar 2014 14:25:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams , Paul Wouters References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ouQss7tXJ4P4ZADze0YURWB9nk0 Cc: "saag@ietf.org" Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:26:10 -0000 On 3/21/2014 2:19 PM, Nico Williams wrote: > Remember the context: Joe claims doing anything more than > unauthenticated DH == PKI, omg omg!!! I'm not saying that doing more is silly, but it absolutely requires more infrastructure: - channel binding across layers - some sort of signed authentication at the higher layer - which necessarily assumes some sort of keys, either preshared or distributed Doing anything more than unauthenticated keying might be opportunistic, but it's not "always on" because there will be cases where the keying material is not available. IMO, that's less useful, and one of the failures of the BTNS WG in focusing solely on BTNS-CBB to the exclusion of considering the benefits of BTNS-SAB (stand-alone, without keys or bindings at other layers). If that's silly, fine. If that's out of scope for this thread, even better. Joe From nobody Fri Mar 21 14:39:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7B1A07F8 for ; Fri, 21 Mar 2014 14:39:55 -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 AKHCWAfUN6j0 for ; Fri, 21 Mar 2014 14:39:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 923541A0753 for ; Fri, 21 Mar 2014 14:39:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AB20C2AB250; Fri, 21 Mar 2014 21:39:43 +0000 (UTC) Date: Fri, 21 Mar 2014 21:39:43 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140321213943.GG24183@mournblade.imrryr.org> References: <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532CABFD.6010309@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QZmLLarCu9hBXIwPgSmggSJljrU Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 21:39:55 -0000 On Fri, Mar 21, 2014 at 05:15:41PM -0400, Paul Wouters wrote: > > NO bloody PKI. > > That was not my impression. That might be one mode of things, > but authentication via DANE out-of-band still falls within my > candidate definition of "opportunistic" Yes, as stated up-thread. Folks, I think we've derailed again. There is no real disagreement about the beast we're trying to name, or perhaps more to the point, this is not the thread that defines the beast precisely. Rather this is the thread for agreeing on a reasonable name which can then be defined to cover various use-cases, and elaborated in various application protocols, ... Sorry about the knee-jerk reaction to Paul's comment about "opportunistic foo", whether he is right or wrong, that is not the subject of this thread. RETURN TO MAIN THREAD: Though I've said it before, my vote is for "opportunistic foo". With the "umbrella" foo being "encryption", and where appropriate other foo's that are consistent with the umbrella term. If we have not already finished the consensus building, please indicate any strong preferences for or against just the umbrella term. -- Viktor. From nobody Fri Mar 21 14:45:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7311A0917 for ; Fri, 21 Mar 2014 14:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSkgvmqjJetH for ; Fri, 21 Mar 2014 14:45:05 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (agjbgdcfdbef.dreamhost.com [69.163.253.145]) by ietfa.amsl.com (Postfix) with ESMTP id E653D1A07E3 for ; Fri, 21 Mar 2014 14:45:01 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 75A4F2007F121 for ; Fri, 21 Mar 2014 14:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=WrCY/P+tKAGLwmIuJ5kTsM0 pJgY=; b=SH+Rn1jjhcXXC2kNJhz2hpPHwqpHzH5im3kmh/YOfasNYez8UTuZGmO BhtrnbzLTvGGieiSryEWAHUfeCmo1Cm0LayRFcVig83avsfQJGA7QTJtvPJDJK+i HwotoT0Xx72sy8cQL77DQTq1U/nMR2IyYzW8sDCiIwRW8E1bBBVA= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 2B2ED2007F11E for ; Fri, 21 Mar 2014 14:44:52 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so900808wiw.6 for ; Fri, 21 Mar 2014 14:44:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=evnvpqo6r4Plpmdiv0wGdHN5L1koak+lpV2sZofpwjk=; b=nIfGTUscDXoAbHo3YxBSZ4W1chBH/FixiMcYFEXgnI0NH6Ukw+wJh0aJIeyD5Tnt2D qJeTm3jAtsJoyrzo+dVTrDuO6mnbDd5uZIv/6vuN0AwWUXt7lc6HAapAnzwpV2fdX44G TGfaNbGW7/ccvj3bsiF96PNcZ+lSoMsWNjdC289zNvb1ksBRQI0vzyX+sfWF/3SzXLxR 1AZp11wRIsDkiPSbuEdnBamRgIm9aSysFRYFjAVk/KAUjrnViktl8SVtZx+AKoTrdzQ8 OhjH/wma0fbHsQrqQlfKJ2pZw+S2WkyplSq8Hn1In8fFigzexFqjfuu/yVLtEb1nJ42F GgRQ== MIME-Version: 1.0 X-Received: by 10.180.101.40 with SMTP id fd8mr4526195wib.1.1395438290934; Fri, 21 Mar 2014 14:44:50 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 14:44:50 -0700 (PDT) In-Reply-To: <20140321213943.GG24183@mournblade.imrryr.org> References: <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> <20140321213943.GG24183@mournblade.imrryr.org> Date: Fri, 21 Mar 2014 16:44:50 -0500 Message-ID: From: Nico Williams To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lVK8OfkdOr8gC3ZOQnOJ7sajUZU Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 21:45:06 -0000 On Fri, Mar 21, 2014 at 4:39 PM, Viktor Dukhovni wrote: > RETURN TO MAIN THREAD: +1 for this. Thanks. > Though I've said it before, my vote is for "opportunistic foo". > With the "umbrella" foo being "encryption", and where appropriate > other foo's that are consistent with the umbrella term. > > If we have not already finished the consensus building, please > indicate any strong preferences for or against just the umbrella > term. +1. Nico -- From nobody Fri Mar 21 15:07:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08F51A07F9 for ; Fri, 21 Mar 2014 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 5fXFEwEzE6ZC for ; Fri, 21 Mar 2014 15:07:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD31A08C7 for ; Fri, 21 Mar 2014 15:07:36 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LM6nZ8028973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 15:06:49 -0700 (PDT) Message-ID: <532CB7FB.30009@isi.edu> Date: Fri, 21 Mar 2014 15:06:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> <20140321213943.GG24183@mournblade.imrryr.org> In-Reply-To: <20140321213943.GG24183@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Wxe-V9pAdmItbA-aIofUnWyN4zE Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 22:07:39 -0000 On 3/21/2014 2:39 PM, Viktor Dukhovni wrote: >... > RETURN TO MAIN THREAD: > > Though I've said it before, my vote is for "opportunistic foo". > With the "umbrella" foo being "encryption", and where appropriate > other foo's that are consistent with the umbrella term. > > If we have not already finished the consensus building, please > indicate any strong preferences for or against just the umbrella > term. If you're linked to keys elsewhere (e.g., DANE, etc.) +1 Joe From nobody Fri Mar 21 15:47:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E51A0751 for ; Fri, 21 Mar 2014 15:47:14 -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, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, RDNS_NONE=0.793] 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 hTfjx2uLX9XS for ; Fri, 21 Mar 2014 15:47:12 -0700 (PDT) Received: from hoba.ie (unknown [92.51.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AE1A0720 for ; Fri, 21 Mar 2014 15:47:12 -0700 (PDT) Received: from [10.87.48.12] (unknown [86.45.63.226]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stephen) by hoba.ie (Postfix) with ESMTPSA id B443EE01ED for ; Fri, 21 Mar 2014 22:47:01 +0000 (GMT) Message-ID: <532CC165.1040008@cs.tcd.ie> Date: Fri, 21 Mar 2014 22:47:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> <20140321213943.GG24183@mournblade.imrryr.org> In-Reply-To: <20140321213943.GG24183@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FY2ie180NMClsczdyUiOFnrd1no Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 22:47:14 -0000 On 03/21/2014 09:39 PM, Viktor Dukhovni wrote: > > Folks, I think we've derailed again. Thanks Viktor. The bikeshed was busy while I was at dinner;-) So far we've seen nobody who claims to think we can achieve consensus for another term. Some have suggested other terms but nobody has claimed that any of those seem to be getting consensus. So, if someone thinks that some other term could achieve rough consensus please do make that argument now. Note: I don't mean suggest more terms, I mean make an argument for why one/some other term can in practice get rough consensus. Note also that I mean "can" there, and not "should, in my perfect world." Thanks, S. PS: If things remain the same, then the next question will be how to handle the word opportunistic, but let's please hold off on that until we get the first thing out of the way. Monday will do for that if things stay the same. From nobody Fri Mar 21 15:58:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5D51A0751 for ; Fri, 21 Mar 2014 15:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 utB8Vn-qkAqA for ; Fri, 21 Mar 2014 15:58:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 544E11A0720 for ; Fri, 21 Mar 2014 15:58:32 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37332 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8OT-000C6M-IM for saag@ietf.org; Fri, 21 Mar 2014 18:58:29 -0400 Message-ID: <532CC40D.5000804@bbn.com> Date: Fri, 21 Mar 2014 18:58:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <5328C2F2.5040204@bbn.com> <925.1395256095@sandelman.ca> In-Reply-To: <925.1395256095@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6clVBqjZfMTr-zz1mEdoH3PPQmM Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 22:58:34 -0000 Michael, > Stephen Kent wrote: > > - it proposes yet another term for the subject of our protracted > > terminology discussion > > - it defines what that term means, based on a STRINT workshop breakout > > group > > - it argues why "opportunistic encryption" is a poor terminology choice > > for what we want to describe > > - it examines some other aspects of terminology for key management > > that yields authenticated, anonymous, or pseudonymous communications > > > > Change: > The term opportunistic encryption (OE) was coined by Michael > Richardson in "Opportunistic Encryption using the Internet Key > Exchange (IKE)" an Informational RFC [RFC4322]. In this RFC the term > is defined as: > > To: > The term opportunistic encryption (OE) was documented by Michael > Richardson et al in "Opportunistic Encryption using the Internet Key > Exchange (IKE)" an Informational RFC [RFC4322]. The term was coined > by John Gilmore and Hugh Daniel in the mid-1990s. In this RFC the term is defined as: I didn't see a mention of this earlier use of the term in your RFC. Is there any written record of the earlier use by these folks? Steve From nobody Fri Mar 21 15:58:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58731A08F5 for ; Fri, 21 Mar 2014 15:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 qN6nB5CYZMyC for ; Fri, 21 Mar 2014 15:58:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 789081A0753 for ; Fri, 21 Mar 2014 15:58:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35758 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8OQ-000NB8-Sq for saag@ietf.org; Fri, 21 Mar 2014 18:58:27 -0400 Message-ID: <532CC412.7000701@bbn.com> Date: Fri, 21 Mar 2014 18:58:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <532B2A6A.3000205@bbn.com> <20140320210740.GF3471@localhost> In-Reply-To: <20140320210740.GF3471@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/W5WcF-VySW_AGdgC-SJQOtGtdJA Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 22:58:38 -0000 Nico, > ... >> I'm concerned that the first bullet is a security goal, while the second >> is an example of a security mechanism > Substitute "sometimes works against active attackers" for the mechanism. > > The mechanism is not the salient fact. Although it can be if it means > leaking into UIs (e.g., as in traditional SSH LoF). I'm not complaining about the mechanism, just the mixing of security service descriptions and mechanisms. And yes, LoF/TOFU usually involves a user accepting a new credential, an that runes counter to the "invisible to the user" model some folks have suggested. Good point. > ... > If users won't be aware of it at all then it should just be > unauthenticated key agreement + authenticated symmetric encryption. OK. > I'd call that "pervasive", yes, but the term will leak into mainstream > use. I think we should plan on users knowing about it even if it were > easier if they didn't. fair point. > DANE and/or TACK could be used but now failures to match expected keys > will mean making users aware (and they'll need a way to override, won't > they, the usual give-my-money-to-the-bad-guys-OK button on a dialog). You raise a good point. If DANE credential are available, then the target of a connection has made an effort to be authenticated via a high-quality mechanism. So some sort of error seems appropriate. This issue deserves more attention. > ... >> it can all be subsumed, for external consumption, under the PE label. > I thought you didn't want users to be aware of it. Why would we need a > "PE" label for them to see? > > :) I was alluding to the PR that is inevitably associated with this effort. > (My point is we'll have to try to pin the marketing aspect of this down > a bit.) yep. > ... >> I don't disagree with the bullets above, but what I think we should consider >> when creating criteria for evaluation of new (and existing) protocols is >> a prioritized list of attack classes (vs. threats). The list I have >> in mind is: >> >> 1. purely passive attacks (traditional passive wiretapping) >> against payloads >> 2. payload wiretapping enabled by an active attack such as DNS >> response injection >> (which may yield a MiTM atack) >> 3. wiretapping enabled by exfiltration of traffic keys or a bad PRNG >> (the result of malware on a machine at one end pf the other) > We can't help local security from a protocol point of view. On the > contrary, we can only have network security if we have local security to > start with (I know this is a rather defeatist seeming position! but it's > correct). Therefore we should not consider (3). Not sure ow to interpret your last comment above. My suggestion was that #3 above was more indicative of a targeted attack, not PM, and thus we could consider it a lower priority. Also,m it's largely outside the scope of what we do in the IETF, where protocols to enable interoperability have been our primary focus. Steve From nobody Fri Mar 21 15:58:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814DA1A08FA for ; Fri, 21 Mar 2014 15:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 UXq7ipkvKgJj for ; Fri, 21 Mar 2014 15:58:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 039A31A0921 for ; Fri, 21 Mar 2014 15:58:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37335 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8Ob-000C6T-RA for saag@ietf.org; Fri, 21 Mar 2014 18:58:37 -0400 Message-ID: <532CC415.9080307@bbn.com> Date: Fri, 21 Mar 2014 18:58:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <5329B594.9020705@bbn.com> <532B2A6A.3000205@bbn.com> <20140320210740.GF3471@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1zxeZk4487edKPWXfTewwXEHqfA Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 22:58:41 -0000 Nico, > On Thu, Mar 20, 2014 at 4:07 PM, Nico Williams wrote: >> On Thu, Mar 20, 2014 at 01:50:34PM -0400, Stephen Kent wrote: >>> [...] >>> In part, that's why I like Pervasive Encryption. If we say we're trying >>> to combat pervasive monitoring, the terminology overlap seems to make it >>> natural, no matter what we do :-). >> Cute. > Hmm, cute but dangerous. The pervasive monitoring is mostly TLAs/LEOs > or their deputized agents, and they have the resources and position to > mount active attacks. Therefore PE had better to much better than > just protect against passive attacks or we may end up with a major > marketing failure in our hands, and badly damaged reputation. > > Nico We have seen revelations that active attacks of the sort in my bullet #2 have been employed. I was not suggesting that such attacks are out of scope, but rather that if we choose to prioritize the set of attacks of interest, this was a reasonable order. We can give partial credit if we choose ;-). Steve From nobody Fri Mar 21 15:59:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DFE1A0916 for ; Fri, 21 Mar 2014 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 EQdgoZSLpGRB for ; Fri, 21 Mar 2014 15:59:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE101A0753 for ; Fri, 21 Mar 2014 15:59:10 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37336 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8P6-000C6c-7E for saag@ietf.org; Fri, 21 Mar 2014 18:59:08 -0400 Message-ID: <532CC433.30903@bbn.com> Date: Fri, 21 Mar 2014 18:58:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> In-Reply-To: <532B4B34.3040106@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/u-ocVbHMO8X4GVHBS3SD45GnPj4 Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 21 Mar 2014 22:59:15 -0000 DKG, > ... > > here's my abbreviated take on the major complaints for existing > candidate terms: > --------------------- > > "Opportunistic encryption" isn't ideal because it has other historic > meanings. amen. > "Unauthenticated encryption" is inaccurate because some of these > connections might actually be authenticated (and because it appears to > contrast with "authenticated encryption" which is a specific term of art > in the crypto world, related to message integrity) +1 > "Pervasive encryption" is likely to be inaccurate because (sadly) we > won't win and get everything to be encrypted (it won't be truly > pervasive) any time soon. I must point out that Stephen Farrell's I-D (soon to be RFC) notes that pervasive is not the same a ubiquitous, so I don't agree that a lack of encryption everywhere is a valid reason for rejecting this term. > "Opportunistic keying" seems a bit off because we're not just discussing > choosing keys, but also talking about the way those keys are used. eh? > --------------------- > > i'll throw one more candidate term into the ring that i think avoids the > problems listed above: > > "Hygienic encryption" > > I'm proposing this from a public health analogy (e.g. [0]): a > best-effort, on-by-default, encrypted replacement for cleartext as a > defense against pervasive monitoring is like washing your hands after > using the toilet. Everyone should do it for the social good, and it's > also not enough to protect you from disaster or deliberate, targeted > compromise. good rationale, but it seems a bit too (something?) Steve From nobody Fri Mar 21 15:59:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8E1A0753 for ; Fri, 21 Mar 2014 15:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 kkmeh4Fv4J74 for ; Fri, 21 Mar 2014 15:59:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B097E1A0720 for ; Fri, 21 Mar 2014 15:59:14 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35762 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8P3-000NBT-7F for saag@ietf.org; Fri, 21 Mar 2014 18:59:05 -0400 Message-ID: <532CC438.9080105@bbn.com> Date: Fri, 21 Mar 2014 18:59:04 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> In-Reply-To: <532C2822.4090308@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p8zUA3itdZQMRqDh88LWTqNE2yg Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 22:59:16 -0000 Stephen, > On 03/20/2014 11:10 PM, Nico Williams wrote: >> On Thu, Mar 20, 2014 at 02:48:39PM -0400, Michael Richardson wrote: >>> We seem to all know what we mean here, we are just bikeshedding on a >>> word. >> This is not bikeshedding. Names matter. > I agree with Nico's conclusion in this case, though I might get > to it via a different route. > > It seems fairly clear that we are not so far getting consensus > for any term that does not include the word "opportunistic." > > Do folks agree with that? I failed to mention another reason I dislike "opportunistic encryption" as our chosen term. When a colleague did a literature search he found that a majority of about 70 papers in IEEE, ACM ,and similar publications used this term as originally defined in 4322. So it seems unreasonable (to me) that the IETF can unilaterally decide, years later, to redefine the term. Prior to the recent PM focus, I don't think this term was being used commonly in the IETF. So, let's move beyond a 6-9 month infatuation with a term that had been used in a technically inaccurate fashion and just make up something new. Steve From nobody Fri Mar 21 15:59:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03161A0A11 for ; Fri, 21 Mar 2014 15:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Ptkp4cK2jeUS for ; Fri, 21 Mar 2014 15:59:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5891A0916 for ; Fri, 21 Mar 2014 15:59:18 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37338 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8PD-000C6f-Ul for saag@ietf.org; Fri, 21 Mar 2014 18:59:16 -0400 Message-ID: <532CC43B.30600@bbn.com> Date: Fri, 21 Mar 2014 18:59:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> <3DD65687-E3C4-4663-8177-53B3BC4E1856@vpnc.org> <20140321145640.GU24183@mournblade.imrryr.org> <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> In-Reply-To: <8642E28C-13CA-4B47-B497-2F2275AF78A0@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IZoXm_z_wHMbWmNcMYHJwCYSIvw Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 21 Mar 2014 22:59:23 -0000 Paul, > ... > Saying that the Postfix's community use of a specific definition of "opportunistic TLS" should trump the large value of having a single definition for "opportunistic encryption" feels somewhat selfish. Note that Michael Richardson, whose RFC was the first to use the term "opportunistic encryption", have given up change control on the term so that we can get more universal encryption. With all due respect, Michael gave up change control when the RFC was published. And, I noted in a recent message, a larger community has used the term for a number of years, in a variety of publications. While not all of them used the term in a fashion consistent with 4322, most did. Steve From nobody Fri Mar 21 16:40:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EEF1A072C for ; Fri, 21 Mar 2014 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 S7jpY1wg5N5W for ; Fri, 21 Mar 2014 16:40:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBF61A06DF for ; Fri, 21 Mar 2014 16:40:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37339 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WR8PI-000C6j-CL; Fri, 21 Mar 2014 18:59:20 -0400 Message-ID: <532CC440.9060405@bbn.com> Date: Fri, 21 Mar 2014 18:59:12 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Farrell , saag References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> In-Reply-To: <532B3644.1080704@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OKNwJoJwHrrS5VO8umrkdZJlLz0 Subject: Re: [saag] better ** terminology 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, 21 Mar 2014 23:40:25 -0000 Stephen, > Steve, > > I like lots of the text in the draft, thanks. thanks. > However, I don't think the PE term is going to be that > useful for us and have a possible concern about direction. > I also have a suggestion, just to see how it lands... oh well :-(. > On PE: I think the term as defined is cute and defensible, > but I think it'll cause us problems if we try adopt it > broadly, since it'll generate too much opposition from the > "but I don't want to encrypt" camp. If however, a strong > consensus emerged for the PE term, I could live with that > but I don't see it yet, and personally I preferred your > previous OK suggestion, or re-defining OE. The word > opportunistic really does seem to me to be the best match > for what I see most people talking about to be honest. OK, I mean no problem ;-). > About direction: I think that perhaps the draft overspecifies > PE/OK/OE in ways, e.g. your point #2 saying PE is not a > substitute. We know that in many cases mutually authenticated > crypto can be used, but that it is often not used because its > perceived as too heavy-weight. Now you do say that the list > are characteristics that PE exhibits, so this might just > be a case of worthsmithing being needed, but I don't think > it'll be useful if we end up with terminology that just > causes more arguments, e.g. "that protocol cannot do PE/OK/OE > because it would be possible to do mutual" is not where > we want to end up. I don't think I understand you comments above, but the I-D was quickly revised and certainly needs work. > And a suggestion: given that the word opportunistic is > what is being used, how's about we describe ways in which > the word opportunistic can sensibly be used when discussing > keying and encryption. For example by saying that it means > doing key exchange and encryption at the opportune time in > an opportune manner? I don't see that characterization as informative, but maybe I;'m missing your point. > In terms of your text that'd mean something like: > > OLD: > > PE (for realtime communication) exhibits the following > characteristics: > > NEW: > > The term opportunistic when used to describe security > mechanisms used in a protocol basically means doing > key exchange and encryption at an opportune time in > an opportune manner, without tightly coupling that > with endpoint authentication. OK, now that I see text, I don't like it :-). "Opportune" here does not seem meaningful to me. > Protocols doing key exchange and encryption can > usefully be described as opportunistic if they exhibit > characteristics such as the following, when those are > relevant for the protocol concerned: Oh, so you define "opportune" based on the characteristics I cited later. Now I get your point, but I can't say that I agree with it. > And then your list, which (modulo wordsmithing), I like. > > Lastly, I recognise that probably you and I disagree about > it, but I do not think that we need to honour the definition > of OE as previously used in RFCs. We do need to note it, > and say why we're changing it if we do and how any new > definition differs from previous usage. Things move on and > if we have consensus to re-define that term, that's just > fine. I'd be interested in more opinions on that issue. I think we should honor the 4322 definition for two reasons: - it describes a specific class of mechanisms that merits a unique, unambiguous term - the term has been used in the broader literature (not just I-Ds and RFCs, and the majority of the uses appear to be consistent with (and cite?) 4322. Thus if the IETF decides to redefine the term now, it sets a bad precedent. Steve From nobody Fri Mar 21 16:58:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8562A1A072C for ; Fri, 21 Mar 2014 16:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.003 X-Spam-Level: *** X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_PSBL=2.7] 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 s_yugZjrtIsz for ; Fri, 21 Mar 2014 16:58:49 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (mysql.benrbradley.com [69.163.253.146]) by ietfa.amsl.com (Postfix) with ESMTP id BF8441A06DF for ; Fri, 21 Mar 2014 16:58:49 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 30F002005D10B for ; Fri, 21 Mar 2014 16:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=8KqWsD5tauxydW1PUf8xY70LHoM=; b=LnchyPBLSe9 BlFIdb/sx5mPTzcP0Z5exW1SwIlf39GlqNlIjTjZtgVPBGHlx7O1fqeChrlwEZoR QF6MUO6SJYML9I1V8IZ/sfH+raSdwiafmUNzLhixdZKEvdhg2b/C9vLF+zepmuMb DBiSn9CwZTwP3Z/wD3NMmhizDyeeeUF4= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id DA8642005D10A for ; Fri, 21 Mar 2014 16:58:39 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn9so959691wib.1 for ; Fri, 21 Mar 2014 16:58:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uDN94heZouxpna+Fy9udgMxykbO1Wzq6p0ChT+euR2w=; b=KceS6/r/QFqAcXK341FKoNPzFXuNQLlEX4tIPvtkHwJiALXlgAa+2w9Fdc4lt8v4Ed y8BPvixrzUNOJ+vS6clMQCUKhicsW9SVSKDGvw4udr5oeOZOOk2ABdyokPFHeBwA9/nW x9Ko0xi8x3fgR47oxtp5R20Wt9GafbX7P3Ocn/qP3xa05Ig/w5uRAe77QjpL0fW66jD8 LnJZQyFcH95/bV0MMZjKXRBmc530T6xb6CF5ktZ3IMITOjTR//JwyMHhvSYC9F1/2xgI T40KZsSk+ZUh16T2Hgi1MvOCZL5Lnmc8+IEO/bQoyEUe/5gLKa1i1xHuUW08fdTIFemH 1Sog== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr387093wib.1.1395446318616; Fri, 21 Mar 2014 16:58:38 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 21 Mar 2014 16:58:38 -0700 (PDT) Date: Fri, 21 Mar 2014 18:58:38 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4ZOYD-S8nLyXGYN7GQfHlDmhJH0 Cc: "saag@ietf.org" Subject: [saag] Proposal: use OE for now (Re: better ** terminology) 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, 21 Mar 2014 23:58:50 -0000 On Fri, Mar 21, 2014 at 5:58 PM, Stephen Kent wrote: > [...] It's good to see that we agree on the rationale for a term like "opportunistic foo". You don't yet agree as to actually using "opportunistic foo", but in time you will ;) More seriously, I propose the following: - _for the time being_ we should use "opportunistic encryption" to refer to the new thing in Internet-Drafts and on the relevant mailing lists - commit to reaching out to language specialists and/or to surveying the public prior to publication as an RFC on the Standards track. (I really do think this is important enough to warrant a more scientific approach to naming this beast. Conversely I am not convinced that my own preference and logic behind it will work best in the long haul, and that self-doubt leads me to wanting more input.) The rough consensus certainly seems to be that no term proposed until now is quite as good an option as "opportunistic encryption", so I don't see the harm in settling on that in the interim. And I see much good in doing so: we'd stop spending so much effort on naming and move on to more substantive matters. Nico -- From nobody Fri Mar 21 17:06:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9F01A0788 for ; Fri, 21 Mar 2014 17:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 w7QG5U3tsLpa for ; Fri, 21 Mar 2014 17:06:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5851A07A8 for ; Fri, 21 Mar 2014 17:06:39 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2M06T51031229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Mar 2014 20:06:30 -0400 Received: from bofh.nohats.ca (vpn-56-39.rdu2.redhat.com [10.10.56.39]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2M06ToF027364 for ; Fri, 21 Mar 2014 20:06:29 -0400 Message-ID: <532CD405.6090600@redhat.com> Date: Fri, 21 Mar 2014 20:06:29 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <925.1395256095@sandelman.ca> <532CC40D.5000804@bbn.com> In-Reply-To: <532CC40D.5000804@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NOUXt0sH-9KTOSolvWKzfgXv-f4 Subject: Re: [saag] better ** terminology 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, 22 Mar 2014 00:06:42 -0000 On 03/21/2014 06:58 PM, Stephen Kent wrote: >> The term opportunistic encryption (OE) was documented by Michael >> Richardson et al in "Opportunistic Encryption using the Internet Key >> Exchange (IKE)" an Informational RFC [RFC4322]. The term was coined >> by John Gilmore and Hugh Daniel in the mid-1990s. In this RFC the term is defined as: > I didn't see a mention of this earlier use of the term in your RFC. Is there > any written record of the earlier use by these folks? http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/glossary.html#carpediem Opportunistic encryption A situation in which any two IPSEC-aware machines can secure their communications, without a pre-shared secret and without a common PKI. This is a long-term goal of the Linux FreeS/WAN project which we expect to acheive using Secure DNS. http://www.freeswan.org/history.html The idea is to deploy PC-based boxes that will sit between your local area network and the Internet (near your firewall or router) which opportunistically encrypt your Internet packets. Whenever you talk to a machine (like a Web site) that doesn't support encryption, your traffic goes out "in the clear" as usual. Whenever you connect to a machine that does support this kind of encryption, this box automatically encrypts all your packets, and decrypts the ones that come in. In effect, each packet gets put into an "envelope" on one side of the net, and removed from the envelope when it reaches its destination. This works for all kinds of Internet traffic, including Web access, Telnet, FTP, email, IRC, Usenet, etc. From nobody Fri Mar 21 17:54:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46661A0945 for ; Fri, 21 Mar 2014 17:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.547] 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 WlxwK4iyzHQg for ; Fri, 21 Mar 2014 17:54:50 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5642F1A0922 for ; Fri, 21 Mar 2014 17:54:50 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA00306; Fri, 21 Mar 2014 20:48:09 -0400 (EDT) Date: Fri, 21 Mar 2014 20:48:09 -0400 (EDT) From: Mouse Message-Id: <201403220048.UAA00306@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 21 Mar 2014 20:11:16 -0400 (EDT) To: saag@ietf.org In-Reply-To: <532CA4E2.6020309@isi.edu> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C8474.2050606@isi.edu> <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dznQKgBIQPcwwqWTxlWb-wNgUVI Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 22 Mar 2014 00:54:55 -0000 >>> The trend is to reinvent the Internet at the app layer; [...] >> This trend is a very, very good one. Strong disagreement here. The Internet was built with a lot of thought from a bunch of very very smart people, many of whom made mistakes that needed to be fixed despite being the best of the best. Application-layer authors mostly are not, nor ever will be, the best of the best. If the Internet is reinvented at the app layer, it will be reinvented many times, usually badly, in incompatible ways. Each reinvention will have new and creative bugs at both code and protocol layers. This strikes me as a recipe for bad interactions, especially around reactions to congestion. >> Are you familiar with mosh (http://mosh.mit.edu/)? You should be. I just read that page. My reaction is a shudder and a burst of gratitude that I don't have to deal with it. Why? A whole bunch of reasons. Some of them, like its dogmatic assumption that everyone wants (or can even tolerate) UTF-8, are not relevant to saag. But others, like its reinventing of reliable transport atop UDP, are. The webpage gives me no reason to think its authors even _thought_ about congestion control, which makes me feel it is nigh on certain that it either doesn't even try to react to congestion or it gets it wrong. And then there's their reaction to a reviewer. Quoting from the webpage: > "ISO 2022 locking escape sequences oh flying spaghetti monster please > kill me now." - actual USENIX peer review from the Mosh paper. > (Why you should trust Mosh with your remote terminal needs: we > worry about details so obscure, even USENIX reviewers don't want > to hear about them.) ...uh, guys, maybe it's just that you deserve to be panned? This is an amazing piece of spin-doctoring, to take a review that bad and respin it as something positive. I'm impressed, impressed that they thought to do it, impressed that they came up with a way, impressed that they had the sheer gall to try it...and very very impressed - negatively, but impressed - that they did. >> Mosh solves mobility... because TCP doesn't. Because all relevant >> IP mobility options are too complex, not in widespread use or >> available, or have annoying trade-offs. Unlike mosh, which...is too complex (predictive echo?? I'm amazed you can imply it's not "too complex" with a straight face), not in widespread use (if they have to trumpet individuals using it, it is not in widespread use) or available (well, this one I'm willing to give them), or has annoying trade-offs (reinventing TCP? no v6? no forwarding? and those are just the ones that are obvious without even trying to build-and-install it). mosh really needs to die. It needs to either use TCP or reconstruct the whole of TCP atop UDP; if it can be a better TCP, the right answer is to make TCP better and thereby allow _all_ applications to benefit; if it can't, it's still better for it to use TCP. The only thing reinventing TCP atop UDP does for it is allow it to be more aggressive about grabbing network resources in the presence of network overload - ie, to be a greedily ill-behaved inhabitant of the network. We need fewer, not more, such. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Fri Mar 21 18:03:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99E31A08E1 for ; Fri, 21 Mar 2014 18:03:34 -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 opd30NEPQWLC for ; Fri, 21 Mar 2014 18:03:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B61A08C5 for ; Fri, 21 Mar 2014 18:03:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4FF4E2AB137; Sat, 22 Mar 2014 01:03:22 +0000 (UTC) Date: Sat, 22 Mar 2014 01:03:22 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140322010322.GI24183@mournblade.imrryr.org> References: <532C9AA7.505@isi.edu> <532CA060.2030307@isi.edu> <532CA4E2.6020309@isi.edu> <532CABFD.6010309@redhat.com> <20140321213943.GG24183@mournblade.imrryr.org> <532CC165.1040008@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532CC165.1040008@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/08t2OKO0snd4xY4w-OaRFZ7atr0 Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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: Sat, 22 Mar 2014 01:03:35 -0000 On Fri, Mar 21, 2014 at 10:47:01PM +0000, Stephen Farrell wrote: > So, if someone thinks that some other term could achieve rough > consensus please do make that argument now. Note: I don't mean > suggest more terms, I mean make an argument for why one/some > other term can in practice get rough consensus. Note also that > I mean "can" there, and not "should, in my perfect world." I was describing this discussion to a friend, and set that opportunistic was doing a good job of capturing "as strong as possible" encryption. His comment was: "Why not call it ASAP encryption", where ASAP is an acronym for "as strong as possible". Can this gain consensus? It has the advantage of no prior history, and roughly the right semantics. The disadvantage is that the standard meaning of ASAP is different, and this is not as useful for prepending to other terms, so for example, I don't see using "ASAP DANE TLS". So my vote is still for "opportunistic", but if "ASAP encryption" takes the world by storm as the umbrella term, I can live with that. Given all the discussion here, it is difficult to imagine any one choice getting universal approval. How "rough" does rough consensus need to be? -- Viktor. From nobody Sat Mar 22 00:08:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B531A03B3 for ; Sat, 22 Mar 2014 00:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 DEkBP-gPNcgd for ; Sat, 22 Mar 2014 00:08:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 25B421A007A for ; Sat, 22 Mar 2014 00:08:53 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 30EA493C1AF; Sat, 22 Mar 2014 07:08:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <532C8846.3050503@isi.edu> Date: Sat, 22 Mar 2014 08:08:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <720F1B76-23D8-4417-810E-FE99E86BFDF4@edvina.net> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532C8846.3050503@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ffglzwo4wtqMZ2o8TBcOEF9rfGs Cc: Michael Richardson , saag Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 22 Mar 2014 07:08:56 -0000 On 21 Mar 2014, at 19:43, Joe Touch wrote: >=20 >=20 > On 3/20/2014 1:10 PM, Daniel Kahn Gillmor wrote: >> To be clear, i think we're all talking about a best-effort, >> "on-by-default" encrypted replacement for cleartext as a way to raise >> the cost of pervasive monitoring. We're just lacking consensus on = what >> we should call that basic concept. >=20 > This hits one of two key aspects: >=20 > 1) always there (on by default) >=20 > 2) not what you really want, but > "better than nothing" >=20 > (that's where BTNS comes from) >=20 > So maybe something hitting more on point #1 than #2: >=20 > - reliable security >=20 > - minimally reliable security Reliably means that users can rely on it and we don't want users to be = involved. >=20 > Or, if you want "marketing" >=20 > - minimal and reliable security (MARS) >=20 Best effort alternative security topology - BEAST? /O ;-) From nobody Sat Mar 22 07:10:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528031A096E for ; Sat, 22 Mar 2014 07:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.6 X-Spam-Level: *** X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_IS_SMALL6=0.556, RDNS_NONE=0.793] 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 L8P6HXV7G0_W for ; Sat, 22 Mar 2014 07:10:20 -0700 (PDT) Received: from hoba.ie (unknown [92.51.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE21A0545 for ; Sat, 22 Mar 2014 07:10:19 -0700 (PDT) Received: from [10.87.48.12] (unknown [86.45.55.181]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stephen) by hoba.ie (Postfix) with ESMTPSA id 5382FE01ED; Sat, 22 Mar 2014 14:10:18 +0000 (GMT) Message-ID: <532D99CA.10405@cs.tcd.ie> Date: Sat, 22 Mar 2014 14:10:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Paterson, Kenny" , "saag@ietf.org" References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xIl3PFa-xRCNe-QEqxrqSUqnBLY Cc: "Virginie.GALINDO@gemalto.com" Subject: [saag] pkcs#1v1.5 (was: Re: Fwd: W3C Web Crypto API - moving to Last Call) 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, 22 Mar 2014 14:10:22 -0000 Hi Kenny, On 03/21/2014 06:15 PM, Paterson, Kenny wrote: > Hi Stephen, > > [Cross-posting to CFRG, since it seems relevant] [reducing back to saag, see below for why:-) ] > Tibor Jager, Juarj Somorovsky and I sent this team feedback some > time ago about the undesirability of standardising already-broken > algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode > encryption with no integrity protection). Not sure I'd agree with "broken" there, other than from a theoretical POV. Old/weaker/sniffy and not state-of-the-art would be fair though. In any case, yes, there's better crypto primitives to be used. But there's an ongoing topic here that might be worth a thread - how to move beyond pkcs#1v1.5 and other mechanisms with known crypto issues (whether currently practical or not) but where there's *huge* deployment and many many implementations in use in the wild on all sorts of platforms. I don't know how we can improve that situation (since a lot of this is not controlled by the IETF or W3C) but I do know a lot of security folks would like it if we could. Unfortunately, history seems to show that it requires a very-near- practical break before implementations and deployments will change in sufficient numbers. And maybe it also requires the non-existence of a band-aid that can be applied at another protocol or s/w layer. And of course this problem is really nothing to do with the crypto but is all about implementations and deployments. (Hence dropping cfrg cross-post:-) But ideas welcome... Cheers, S. PS: On the w3c spec: yes, it'd seem entirely reasonable to warn about known issues and e.g. say that we do expect to move away from these at some point. That's a good comment. I'm surprised if they blew that off. > > On 21/03/2014 17:54, "Stephen Farrell" wrote: > >> -------- Original Message -------- >> From: GALINDO Virginie >> Sent: 21 March 2014 17:10:45 GMT+00:00 >> To: Jim Schaad , "odonoghue@isoc.org" >> , "stephen.farrell@cs.tcd.ie" >> , "Kathleen.Moriarty.ietf@gmail.com" >> >> Cc: Harry Halpin , "wseltzer@w3.org" >> Subject: W3C Web Crypto API - moving to Last Call >> >> Hi IETF and JOSE team, >> >> >> >> The Web Cryptography Working Group has decided to go to Last Call for the >> Web Cryptography API next week. We'd like to make sure your group has >> enough time to review the specification. Is four weeks enough time? If I >> don't hear back from you, I am going to assume it is enough time. Our >> latest draft is here: >> >> >> >> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html >> >> >> >> Regards, >> >> Virginie Galindo >> >> Gemalto >> >> chair of W3C web crypto wg >> > > > Tibor Jager, Juarj Somorovsky and I sent this team feedback some time ago > about the undesirability of standardising already-broken algorithms and > modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no integrity > protection). > > This was in response to a request for feedback from CFRG. We gave them > chapter and verse (and citations) about why this is generally a BAD IDEA: > > http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html > > The broken algorithms and modes are still in the Web Crypto document. > Moreover, there are no relevant warnings about these broken algorithms and > modes in the "security considerations" section of the current Web Crypto > draft. > > Needless to say, I'm not minded to provide any more free advice to this > group. > > Cheers, > > Kenny > > > > From nobody Sat Mar 22 08:10:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1F1A03FB for ; Sat, 22 Mar 2014 08:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6EHF8x9KKuAS for ; Sat, 22 Mar 2014 08:09:56 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id ECB211A0755 for ; Sat, 22 Mar 2014 08:09:55 -0700 (PDT) Received: from mail1-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Sat, 22 Mar 2014 15:09:55 +0000 Received: from mail1-am1 (localhost [127.0.0.1]) by mail1-am1-R.bigfish.com (Postfix) with ESMTP id EC5664A0115; Sat, 22 Mar 2014 15:09:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: PS-7(z579ehf7Izbb2dI98dI9371I1102I542I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1de098h17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail1-am1: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(189002)(199002)(24454002)(377454003)(479174003)(13464003)(2473001)(43544003)(81342001)(2656002)(63696002)(20776003)(86362001)(85306002)(94946001)(97336001)(97186001)(93136001)(69226001)(87936001)(87266001)(83072002)(56816005)(90146001)(95416001)(66066001)(80022001)(93516002)(65816001)(2201001)(92566001)(95666003)(92726001)(94316002)(98676001)(79102001)(77982001)(59766001)(53806001)(74876001)(81816001)(76482001)(56776001)(74366001)(54316002)(54356001)(83322001)(19580405001)(46102001)(19580395003)(51856001)(15975445006)(85852003)(81542001)(80976001)(76796001)(74706001)(76786001)(47736001)(49866001)(47446002)(47976001)(74482001)(15202345003)(50986001)(74502001)(4396001)(81686001)(74662001)(36756003)(31966008)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:E67CF1D5.8BE691DD.7DDBDD8B.42E5E040.20709; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail1-am1 (localhost.localdomain [127.0.0.1]) by mail1-am1 (MessageSwitch) id 1395500993140919_23793; Sat, 22 Mar 2014 15:09:53 +0000 (UTC) Received: from AM1EHSMHS021.bigfish.com (unknown [10.3.201.251]) by mail1-am1.bigfish.com (Postfix) with ESMTP id 144D9300061; Sat, 22 Mar 2014 15:09:53 +0000 (UTC) Received: from AMSPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.5) by AM1EHSMHS021.bigfish.com (10.3.207.150) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 22 Mar 2014 15:09:52 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by AMSPRD0310HT002.eurprd03.prod.outlook.com (10.255.40.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Sat, 22 Mar 2014 15:09:52 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.898.11; Sat, 22 Mar 2014 15:09:51 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0898.005; Sat, 22 Mar 2014 15:09:51 +0000 From: "Paterson, Kenny" To: Stephen Farrell , "saag@ietf.org" , "cfrg@irtf.org" Thread-Topic: pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call) Thread-Index: AQHPRdiIOWzUzYSJ3Uax4nMLHIMeoprtNdIA Date: Sat, 22 Mar 2014 15:09:50 +0000 Message-ID: References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> In-Reply-To: <532D99CA.10405@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [80.42.211.120] x-forefront-prvs: 01583E185C Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/saag/69jEMGqHhl79QA1lwYwCyjG0bHU Cc: "Virginie.GALINDO@gemalto.com" Subject: Re: [saag] pkcs#1v1.5 (was: Re: Fwd: W3C Web Crypto API - moving to Last Call) 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, 22 Mar 2014 15:10:00 -0000 Hi On 22/03/2014 14:10, "Stephen Farrell" wrote: > >Hi Kenny, > >On 03/21/2014 06:15 PM, Paterson, Kenny wrote: >> Hi Stephen, >>=20 >> [Cross-posting to CFRG, since it seems relevant] > >[reducing back to saag, see below for why:-) ] [re-cross-posting to cfrg, see below for why] > >> Tibor Jager, Juarj Somorovsky and I sent this team feedback some >> time ago about the undesirability of standardising already-broken >> algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode >> encryption with no integrity protection). > >Not sure I'd agree with "broken" there, other than from a theoretical >POV. Old/weaker/sniffy and not state-of-the-art would be fair though. >In any case, yes, there's better crypto primitives to be used. Well, unauthenticated encryption (e.g. CBC mode) has been broken *in practice* in many real-world systems, including, for example IPsec (starting with Bellovin's work, but reaching its nadir in my work with Degabriele from IEEE S&P 2007) and XML encryption (Jager and Somorovsky, ACM-CCS 2011).=20 The Bleichenbacher "million message" attack against PKCS#1v1.5 encryption was significantly improved in a paper at Crypto 2012 by Bardou et al., and applied to a variety of security tokens and a fielded HSM. Practical attacks against XML encryption based on the known weaknesses in PKCS#1v1.5 were demonstrated by Jager et al at ESORICS 2012. So several of the schemes being proposed for standardisation for general purpose use in this WebCrypto standard have already been broken *in practice* and *several times over*. It seems foolhardy to be including them in a new standard, irrespective of the "facts on the ground" concerning their deployment. >But there's an ongoing topic here that might be worth a thread - how to >move beyond pkcs#1v1.5 and other mechanisms with known crypto issues >(whether currently practical or not) but where there's *huge* >deployment and many many implementations in use in the wild on all >sorts of platforms. I agree, this is important. But putting the already broken schemes in a new standard does not seem helpful in that regard. >I don't know how we can improve that situation (since a lot of this is >not controlled by the IETF or W3C) but I do know a lot of security >folks would like it if we could. > >Unfortunately, history seems to show that it requires a very-near- >practical break before implementations and deployments will change in >sufficient numbers. And maybe it also requires the non-existence of >a band-aid that can be applied at another protocol or s/w layer. And what a sad state of affairs that is. The history of, for example, chained IVs in SSL/TLS should be salutary lesson in the folly of this approach. There, Rogaway already presented a theoretical attack in 1995. It was explained how this could be exploited to recover plaintext in 2006 by Bard, but without a working attack. Finally, the SSL/TLS community got its backside badly bitten by BEAST in 2011, which basically took Bard's attack and showed how to realise it in the web setting. Cue much panic and hand-wringing. Well, everybody was warned... >And of course this problem is really nothing to do with the crypto >but is all about implementations and deployments. (Hence dropping >cfrg cross-post:-) These issues should be a first class concern for cfrg. There are serious research questions at stake here. Like: how do we build developer-proof APIs; how do we retire protocols, modes, algorithms which are showing signs of weakness; how do we automatically find crypto bugs, side channels, and the like, and eliminate them. > >But ideas welcome... Here's one idea: make sure that a new standard does not include broken algorithms and modes. Then, to be able to claim compliance with the standard, existing deployments will have to get their house in order. Here's another: let's set up an aggressive timescale for deprecation of SSLv3, TLS 1.0 and TLS 1.1. > >Cheers, >S. > >PS: On the w3c spec: yes, it'd seem entirely reasonable to warn about >known issues and e.g. say that we do expect to move away from these at >some point. That's a good comment. I'm surprised if they blew that >off. They seem to have pretty much blown it off. Check out the specification's security considerations section: http://www.w3.org/TR/WebCryptoAPI/#security "This API includes a variety of cryptographic operations, some of which may have known security issues when used inappropriately. Application developers should take care to review the appropriate cryptographic literature before making use of certain algorithms, and should avoid attempting to develop new cryptographic protocols whenever possible." For me, this is not nearly stark or specific enough. What is the average developer meant to make of it? Cheers Kenny > >>=20 >> On 21/03/2014 17:54, "Stephen Farrell" >>wrote: >>=20 >>> -------- Original Message -------- >>> From: GALINDO Virginie >>> Sent: 21 March 2014 17:10:45 GMT+00:00 >>> To: Jim Schaad , "odonoghue@isoc.org" >>> , "stephen.farrell@cs.tcd.ie" >>> , "Kathleen.Moriarty.ietf@gmail.com" >>> >>> Cc: Harry Halpin , "wseltzer@w3.org" >>> Subject: W3C Web Crypto API - moving to Last Call >>> >>> Hi IETF and JOSE team, >>> >>> >>> >>> The Web Cryptography Working Group has decided to go to Last Call for >>>the >>> Web Cryptography API next week. We'd like to make sure your group has >>> enough time to review the specification. Is four weeks enough time? If >>>I >>> don't hear back from you, I am going to assume it is enough time. Our >>> latest draft is here: >>> >>> >>> >>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html >>> >>> >>> >>> Regards, >>> >>> Virginie Galindo >>> >>> Gemalto >>> >>> chair of W3C web crypto wg >>> >>=20 >>=20 >> Tibor Jager, Juarj Somorovsky and I sent this team feedback some time >>ago >> about the undesirability of standardising already-broken algorithms and >> modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no integrity >> protection).=20 >>=20 >> This was in response to a request for feedback from CFRG. We gave them >> chapter and verse (and citations) about why this is generally a BAD >>IDEA: >>=20 >> http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html >>=20 >> The broken algorithms and modes are still in the Web Crypto document. >> Moreover, there are no relevant warnings about these broken algorithms >>and >> modes in the "security considerations" section of the current Web Crypto >> draft. >>=20 >> Needless to say, I'm not minded to provide any more free advice to this >> group. >>=20 >> Cheers, >>=20 >> Kenny=20 >>=20 >>=20 >>=20 >>=20 > From nobody Sat Mar 22 09:16:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868011A09AD for ; Sat, 22 Mar 2014 09:16:46 -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 3sEcYAeVCn4R for ; Sat, 22 Mar 2014 09:16:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CCA291A09A8 for ; Sat, 22 Mar 2014 09:16:44 -0700 (PDT) Received: from [192.168.42.103] (h-67-101-156-56.nycm.ny.dynamic.megapath.net [67.101.156.56]) by che.mayfirst.org (Postfix) with ESMTPSA id 97588F984; Sat, 22 Mar 2014 12:16:42 -0400 (EDT) Message-ID: <532DB76A.8070604@fifthhorseman.net> Date: Sat, 22 Mar 2014 12:16:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> In-Reply-To: <532CC433.30903@bbn.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9vKG7qKSnJRQ59Uh92bc3EibNUDoLXNXj" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PPTWI5PBhDYCBBk4yI1e19SEiaI Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 22 Mar 2014 16:16:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9vKG7qKSnJRQ59Uh92bc3EibNUDoLXNXj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/21/2014 06:58 PM, Stephen Kent wrote: > [dkg wrote:] >> "Opportunistic keying" seems a bit off because we're not just discussi= ng >> choosing keys, but also talking about the way those keys are used. > eh? to clarify: if we opportunistically do key agreement between peers that have never seen before, and then we use those keys for a MAC for our session, we've now got cryptographically strong message integrity (the usefulness of this is left as an exercise to the reader), but no encryption. This is arguably "opportunistic keying" but it doesn't provide any resistance against pervasive monitoring. --dkg --9vKG7qKSnJRQ59Uh92bc3EibNUDoLXNXj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTLbdqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcZEQQALdf7je6t9Ce6Xu2GBOv7WJq yoIa33JXvxyURZfHHxpOaX3pUhs9rQRKCV5IYN94XtvuVwZJzkD4j8IBsklU2rg1 M3Ng15xz0nOjbJQ5kUYzSQCX5d/+CGbjxFjUo/f214d2XBzUwsv87DyxodoYlpK5 082ow+v09ARqJf+jxXN6P6DgxHbx4L3/9p6KdrMVgmRj9AlS8x7esjwxm93t3bAW rPGYk4nrmRkkelyz3Z/GywHDf8JqFu04D+dOoFeg+VPBtmxxZd076hpEvIwA0vgC Z5pcYo7zJLR7NNsFWm0VYi8IkySnw+1rGxa+yzxLByfVlMyjO1ip8gULvebEo7sR FpEDNolVTxX+fY8ynfBlCWaR40pwGSHxvPhZpdFGAlL8o38RaI3cWihRXtnzD7YD Gba1T3S3EzGgVy/+UOtOQJh0oVVVb84DZYrX1oOGvz7BGzGsB7+UR6Ln7lKqvJ3C GSCABGgrHzHehoQfsj5Ka4VfO7MfbD1jcuzNtvj66Fi2b5j5Rsc0dEWDHNm3w5Rl hkBC+vX1NCVr3ph8PgQ5lQBsHWuVOsliDFMXtUUoMM/eGIFNzccq2qyGydM9CShv fL0i2JqLjdEdW3hCZfWeC5+D6xFVQMevx/SS8kyBOqkow7bcl+CoegYLsa/qpoaA GZqWlr8Jo/fd0w5fQ8gW =AJE/ -----END PGP SIGNATURE----- --9vKG7qKSnJRQ59Uh92bc3EibNUDoLXNXj-- From nobody Sat Mar 22 10:57:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EC31A075D for ; Sat, 22 Mar 2014 10:57:36 -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 VKQ3L3XdNu08 for ; Sat, 22 Mar 2014 10:57:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id EB3421A0731 for ; Sat, 22 Mar 2014 10:57:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5E0142AB137; Sat, 22 Mar 2014 17:57:32 +0000 (UTC) Date: Sat, 22 Mar 2014 17:57:32 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140322175732.GL24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532CC433.30903@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OhzN7jEmIMCu5vDKCd1Ym7jDryo Subject: Re: [saag] better ** terminology 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: Sat, 22 Mar 2014 17:57:36 -0000 On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote: > >"Opportunistic encryption" isn't ideal because it has other historic > >meanings. > > amen. I have a suggestion that might help get us out of the rut, we could use: opportunistic security rather than overload the existing, opportunistic encryption to which the principal objection seems to be prior use with IPSEC to mean something more specific than the intended umbrella term. OBSERVATION: The reason the adjective opportunistic is such a good fit for many of the nouns in this space, is that hints at without specifically promising two different aspects of taking maximizing advantage of opportunity: - Whenever possible. - As strong as possible. Many of the proposed alternatives miss one or the other or both aspects desirable in the umbrella term. Thus for example "pervasive" does not suggest maximizing strength, ASAP focuses only on strongest possible, ... For example, "opportunistic TLS", is primarily unauthenticated TLS whenever possible (not necessarily strong, but best effort), while "opportunistic DANE TLS" maximizes opportunity to take advantage of DANE authentication in a downgrade-resistant manner. This is both as strong as possible, and whenever possible. So unless a miracle happens, I don't see a better adjective coming our way. If broadening the IPsec term is to be a sticking point (it does not seem such an insurmountably compelling precedent to me), perhaps we can keep "opportunistic" which IMHO fits like a glove and change "foo"? -- Viktor. From nobody Sat Mar 22 11:31:06 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E791A09BF for ; Sat, 22 Mar 2014 11:31:02 -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, 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 uMepSd1BgowT for ; Sat, 22 Mar 2014 11:31:01 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADD1A09BC for ; Sat, 22 Mar 2014 11:31:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 29DB74745E; Sat, 22 Mar 2014 18:31:00 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1CC654745C; Sat, 22 Mar 2014 18:31:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 18DE22027; Sat, 22 Mar 2014 18:31:00 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 22 Mar 2014 14:30:59 -0400 From: "Salz, Rich" To: "Paterson, Kenny" , Stephen Farrell , "saag@ietf.org" , "cfrg@irtf.org" Date: Sat, 22 Mar 2014 14:30:58 -0400 Thread-Topic: pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call) Thread-Index: AQHPRdiIOWzUzYSJ3Uax4nMLHIMeoprtNdIAgAA25uA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FCF2504B@USMBX1.msg.corp.akamai.com> References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VtHMUfWR6h8DIDWEoVzJwaSHfqw Cc: "Virginie.GALINDO@gemalto.com" Subject: Re: [saag] pkcs#1v1.5 (was: Re: Fwd: W3C Web Crypto API - moving to Last Call) 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, 22 Mar 2014 18:31:02 -0000 > I agree, this is important. But putting the already broken schemes in a n= ew standard does not seem helpful in that regard. It's a new API. It's not a standardization of something that already exis= ts, it's a brand new whole-cloth invention of something that did not exist = before. And yet, we're going to allow developers to create broken data. "= Does not seem helpful" is really understatement. Perhaps they can create read-only bindings for these insecure structures? Perhaps, as a gedanken experiment, I can propose a generalization of the sy= mmetric encryption algorithm rot-13, which has a huge historical legacy via= Usenet? The security considerations are pretty simple: "do not choose numb= er of rounds (n) and shift size (s) such that n*s is zero mod 26." That wo= uld seem to meet all the requirements of the current draft. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Sat Mar 22 15:22:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62E1A0A18 for ; Sat, 22 Mar 2014 15:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, 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 2bc0k99oaZNo for ; Sat, 22 Mar 2014 15:22:13 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3301A08BD for ; Sat, 22 Mar 2014 15:22:13 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn9so1440145wib.13 for ; Sat, 22 Mar 2014 15:22: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:mime-version:date:message-id:subject:from:to :content-type; bh=cIJ1HQXyjjLvdbFWKz0UVZSKYn6AuUoCs7bzTTO71aw=; b=ROtgrxSHoUQRRVDU0nSkNIQzfN3Bir5dsOXragQebp5d3HyEdsuRD2iIpOHrsevbid LUkaYCl72dwrRAnWGAPYnriomqL4Dih+gycfds/sOUNWqe9RT+WKQoYbaTq/37bD2UvS zMWSANSdt6pfoWcpXzUSUyIYPccjHf/+s1XYPq2DG4AuhWpc1hsaxB3jaliccBsO4E+5 x1ydJIAkJ3JcXLylxhkCWH5bitld+uqvkA8Jgf27/cLxUVevOsYr/+UyGuko8GmN9NsQ xHNo8MDPfvoI6lvdSJteCTB5MBax7SiFrvghY7OGkOzrW4p10DAEDKe6ynPgOLQdaLQp Go4g== X-Gm-Message-State: ALoCoQnaOXdM8W+fmE9bQRUXtOOuTplmsA6YssndEkcSwUwH8jbbOGnHIMGK0wcJc9pd0n/+v+T7 MIME-Version: 1.0 X-Received: by 10.180.9.42 with SMTP id w10mr5644755wia.20.1395526933005; Sat, 22 Mar 2014 15:22:13 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Sat, 22 Mar 2014 15:22:12 -0700 (PDT) X-Originating-IP: [184.23.29.222] Date: Sat, 22 Mar 2014 15:22:12 -0700 Message-ID: From: Trevor Perrin To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HrWWszwlGLSx5W7UzYgyMJhCyNc Subject: [saag] OpenSSL and TACK (tangent from: Re: better ** terminology) 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, 22 Mar 2014 22:22:16 -0000 On Wed, Mar 19, 2014 at 10:20 PM, Viktor Dukhovni wrote: > > Anyway this is all rather tentative, Tack has to first be available > in TLS toolkits (OpenSSL in my case), and I'll probably have to > wait quite some time before that's the case. Hi Viktor, all, OpenSSL 1.0.2 (in beta) lets you specify TLS Extensions to be returned if a client asks for them (see SSL_CTX_use_serverinfo_file) [1]. This is sufficient for the server-side of TACK. For generating signing keys and signing tacks there's "tackpy" [2]. For the client-side, OpenSSL 1.0.2 has callbacks to request and handle arbitrary TLS extensions. These could be used to validate tacks with "tackc" [3]. I don't expect OpenSSL to integrate TACK more than that. The callbacks were added so that kind of logic could live outside OpenSSL. The bulk of the work on client-side is keeping a store of pins. That's probably best done by the app using its desired data store, and not by a library. Anyways, browsers seem to be focusing on CT instead of pinning, so the TACK people (Moxie, me, a few others) would be eager to work on other use cases. If anyone wants to talk more, please get in touch, or bring this up on UTA WG or the tack list [4]. We're quite willing to supply patches and help drive this forward. Trevor [1] http://www.openssl.org/source/ [2] https://github.com/tack/tackpy [3] https://github.com/tack/tackc [4] https://lists.riseup.net/www/info/tack From nobody Sun Mar 23 01:44:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800CE1A091D for ; Sun, 23 Mar 2014 01:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 ttjkGfbtHN6G for ; Sun, 23 Mar 2014 01:44:25 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0551A065A for ; Sun, 23 Mar 2014 01:44:24 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so2867426lan.30 for ; Sun, 23 Mar 2014 01:44:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=uWmtq2cAjyFU61RLRBozeHdEL+6FaiDYhWt4mJ16mGM=; b=H8GUefAv7OMKtEwl0ru3dkuQfb0ipu8oIUJV/K0LUdlwh9up2qRXh+ayjP9TcTNV1w Vkoiwb8/lvX1FKMlpzXWSW8VaR146OsF6ZQ7sbY3aV50xJtJN96iEQxzA2lNd8tIGo6o kkGAsWh+J9yqdWiaAyeBZ2mEIgROsA6SLtxzEBvlkB+28pjZanRjIkm3EaY/AVeoMSAb R9rB+EfsKNUiHi4S/1Z171aWosduvqfBTXM5WdpVy09fQGBmOVVxmcdydO5B3B7cwNjN wMbp8vRs7DOK/a3C4/bSXuERPsSM1tr38F/idbWGMTlC/tPmam5LXPBrPMAEzRhTAoLd Uarw== X-Gm-Message-State: ALoCoQmWb3l6ri0PRRHQkFQl8AKWVSks0kZsGeLDFPXhpMFb7KPSITyGCxUgy8B5Oxw8voWGNdPb MIME-Version: 1.0 X-Received: by 10.112.150.233 with SMTP id ul9mr39065079lbb.2.1395564264016; Sun, 23 Mar 2014 01:44:24 -0700 (PDT) Received: by 10.114.0.243 with HTTP; Sun, 23 Mar 2014 01:44:23 -0700 (PDT) X-Originating-IP: [203.116.152.2] In-Reply-To: <20140322175732.GL24183@mournblade.imrryr.org> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> Date: Sun, 23 Mar 2014 16:44:23 +0800 Message-ID: From: Warren Kumari To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/i4VHwSBiqcFdDrV90bbUfz1aQmI Subject: Re: [saag] better ** terminology 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, 23 Mar 2014 08:44:27 -0000 On Sun, Mar 23, 2014 at 1:57 AM, Viktor Dukhovni wrote: > On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote: > >> >"Opportunistic encryption" isn't ideal because it has other historic >> >meanings. >> >> amen. > > I have a suggestion that might help get us out of the rut, we could use: > > opportunistic security > > rather than overload the existing, > > opportunistic encryption > > to which the principal objection seems to be prior use with IPSEC > to mean something more specific than the intended umbrella term. I still *prefer* "opportunistic encryption" (I think that the folk that already know the term are bright enough to not get confused by the new usage (or are already involved in this discussion :-P), and the ones who don't know it will grok the meaning), but "opportunistic security" is the best alternative I've heard... W > > OBSERVATION: > > The reason the adjective opportunistic is such a good fit for many > of the nouns in this space, is that hints at without specifically > promising two different aspects of taking maximizing advantage of > opportunity: > > - Whenever possible. > > - As strong as possible. > > Many of the proposed alternatives miss one or the other or both aspects > desirable in the umbrella term. Thus for example "pervasive" does not > suggest maximizing strength, ASAP focuses only on strongest possible, > ... > > For example, "opportunistic TLS", is primarily unauthenticated > TLS whenever possible (not necessarily strong, but best effort), > while "opportunistic DANE TLS" maximizes opportunity to take advantage > of DANE authentication in a downgrade-resistant manner. This is > both as strong as possible, and whenever possible. > > So unless a miracle happens, I don't see a better adjective coming our way. > If broadening the IPsec term is to be a sticking point (it does not seem > such an insurmountably compelling precedent to me), perhaps we can keep > "opportunistic" which IMHO fits like a glove and change "foo"? > > -- > Viktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Mar 23 07:54:06 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993551A6FC4 for ; Sun, 23 Mar 2014 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 WSmlz8vKhWaE for ; Sun, 23 Mar 2014 07:54:02 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 21D221A6FC3 for ; Sun, 23 Mar 2014 07:54:01 -0700 (PDT) Received: from men75-11-88-175-104-179.fbx.proxad.net ([88.175.104.179] helo=[192.168.1.6]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WRjmi-00027q-5K for saag@ietf.org; Sun, 23 Mar 2014 10:54:00 -0400 Message-ID: <532EF580.70501@w3.org> Date: Sun, 23 Mar 2014 15:53:52 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: saag@ietf.org References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> In-Reply-To: <532D99CA.10405@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2xM3uMgp_6obNIZTcOeNFgONjnE Subject: Re: [saag] pkcs#1v1.5 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, 23 Mar 2014 14:54:04 -0000 On 03/22/2014 03:10 PM, Stephen Farrell wrote: > > Hi Kenny, > > On 03/21/2014 06:15 PM, Paterson, Kenny wrote: >> Hi Stephen, >> >> [Cross-posting to CFRG, since it seems relevant] > [reducing back to saag, see below for why:-) ] > >> Tibor Jager, Juarj Somorovsky and I sent this team feedback some >> time ago about the undesirability of standardising already-broken >> algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode >> encryption with no integrity protection). > Not sure I'd agree with "broken" there, other than from a theoretical > POV. Old/weaker/sniffy and not state-of-the-art would be fair though. > In any case, yes, there's better crypto primitives to be used. > > But there's an ongoing topic here that might be worth a thread - how to > move beyond pkcs#1v1.5 and other mechanisms with known crypto issues > (whether currently practical or not) but where there's *huge* > deployment and many many implementations in use in the wild on all > sorts of platforms. > > I don't know how we can improve that situation (since a lot of this is > not controlled by the IETF or W3C) but I do know a lot of security > folks would like it if we could. > > Unfortunately, history seems to show that it requires a very-near- > practical break before implementations and deployments will change in > sufficient numbers. And maybe it also requires the non-existence of > a band-aid that can be applied at another protocol or s/w layer. > > And of course this problem is really nothing to do with the crypto > but is all about implementations and deployments. (Hence dropping > cfrg cross-post:-) We are very happy to take this feedback on, however - I recommend you forward it to public-webcrypto-comments@w3.org so it can be publically recorded by the W3C. While I'm on SAAG list, not everyone in the WebCrypto WG is and so we may miss comments. Note that there was a tension in the Crypto API between backwards-compatibility with popular crypto already implemented in the browser and ensuring only "safe" crypto will be used. The WG went towards the former path, but would be happy to hear arguments towards the latter. cheers, harry > > But ideas welcome... > > Cheers, > S. > > PS: On the w3c spec: yes, it'd seem entirely reasonable to warn about > known issues and e.g. say that we do expect to move away from these at > some point. That's a good comment. I'm surprised if they blew that > off. > >> On 21/03/2014 17:54, "Stephen Farrell" wrote: >> >>> -------- Original Message -------- >>> From: GALINDO Virginie >>> Sent: 21 March 2014 17:10:45 GMT+00:00 >>> To: Jim Schaad , "odonoghue@isoc.org" >>> , "stephen.farrell@cs.tcd.ie" >>> , "Kathleen.Moriarty.ietf@gmail.com" >>> >>> Cc: Harry Halpin , "wseltzer@w3.org" >>> Subject: W3C Web Crypto API - moving to Last Call >>> >>> Hi IETF and JOSE team, >>> >>> >>> >>> The Web Cryptography Working Group has decided to go to Last Call for the >>> Web Cryptography API next week. We'd like to make sure your group has >>> enough time to review the specification. Is four weeks enough time? If I >>> don't hear back from you, I am going to assume it is enough time. Our >>> latest draft is here: >>> >>> >>> >>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html >>> >>> >>> >>> Regards, >>> >>> Virginie Galindo >>> >>> Gemalto >>> >>> chair of W3C web crypto wg >>> >> >> Tibor Jager, Juarj Somorovsky and I sent this team feedback some time ago >> about the undesirability of standardising already-broken algorithms and >> modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no integrity >> protection). >> >> This was in response to a request for feedback from CFRG. We gave them >> chapter and verse (and citations) about why this is generally a BAD IDEA: >> >> http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html >> >> The broken algorithms and modes are still in the Web Crypto document. >> Moreover, there are no relevant warnings about these broken algorithms and >> modes in the "security considerations" section of the current Web Crypto >> draft. >> >> Needless to say, I'm not minded to provide any more free advice to this >> group. >> >> Cheers, >> >> Kenny >> >> >> >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Mar 23 08:01:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608181A0A0C for ; Sat, 22 Mar 2014 14:11:55 -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=unavailable 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 0zD8SnMUPXX8 for ; Sat, 22 Mar 2014 14:11:52 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1B1A0A08 for ; Sat, 22 Mar 2014 14:11:51 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so3853816yho.29 for ; Sat, 22 Mar 2014 14:11: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 :cc:content-type:content-transfer-encoding; bh=axkDHeXrRiP1RQZ8o7A8PQo3XptY5MawnpU5gxnsHcM=; b=o2LhLkz0etnCfykIMxoimTIzv1sEMFUdb8jkf5KK7p+4an3RA/8mdjzaOQupXenGEG yWJvflv2twZK3WZoEPBpJvnMSwgWWUN2Gp4bsN3NxspT2XHr5VFd6bRjtf9qtUj3Nzuj 6jSgJ98TCpWaZp7wJ9Wuzt+kGi8TocGTOLuUwcwLOCd3YViB43ogPVn3PLkQRKJre6od LN03mElTtn+UAnu3IS2GyHSua/vEeqgUZMWqhffzoVRCGXV2k33Neaw5nA/kdokfUFkI SjCHpZTAxbxnMEdnAtNL4nQ66t7ex4LFYXP+q1a15EOf4BgA+3oWpTlugE3lyrht8D+U Hi1Q== MIME-Version: 1.0 X-Received: by 10.236.151.198 with SMTP id b46mr53053303yhk.3.1395522711647; Sat, 22 Mar 2014 14:11:51 -0700 (PDT) Received: by 10.170.80.214 with HTTP; Sat, 22 Mar 2014 14:11:51 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FCF2504B@USMBX1.msg.corp.akamai.com> References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C711FCF2504B@USMBX1.msg.corp.akamai.com> Date: Sat, 22 Mar 2014 14:11:51 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/96PIpOoiZ08ni842shfUY6_rD4A X-Mailman-Approved-At: Sun, 23 Mar 2014 08:01:51 -0700 Cc: "Virginie.GALINDO@gemalto.com" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [saag] [Cfrg] pkcs#1v1.5 (was: Re: Fwd: W3C Web Crypto API - moving to Last Call) 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, 22 Mar 2014 21:11:55 -0000 On Sat, Mar 22, 2014 at 11:30 AM, Salz, Rich wrote: >> I agree, this is important. But putting the already broken schemes in a = new standard does not seem helpful in that regard. > > It's a new API. It's not a standardization of something that already ex= ists, it's a brand new whole-cloth invention of something that did not exis= t before. And yet, we're going to allow developers to create broken data. = "Does not seem helpful" is really understatement. > > Perhaps they can create read-only bindings for these insecure structures? > > Perhaps, as a gedanken experiment, I can propose a generalization of the = symmetric encryption algorithm rot-13, which has a huge historical legacy v= ia Usenet? The security considerations are pretty simple: "do not choose nu= mber of rounds (n) and shift size (s) such that n*s is zero mod 26." That = would seem to meet all the requirements of the current draft. Let's be even clearer: there is no reason why crypto_box(pubkey, seckey, message, nonce, assoc_data) cannot be provided in the API as a safe combination of the primitives already existing, but the current draft ignores what application developers actually want. By providing subtle_crypto the authors are saying that PKCS 1.5 and AES-CBC aren't problems, but AES-CTR is. (This is actually said in the current draft). By failing to provide a safe alternative to roll your own, they are asking developers who don't know anything about crypto to play a Choose-Your-Own-Adventure novel where most paths end with death. This is the wrong approach to take. If the current draft is implemented, expect thousands of of badly broken applications to be built on top if it. It should be difficult to do the wrong thing, and easy to do the right thing, but this API takes the opposite approach. Sincerely, Watson Ladd > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Mar 23 14:13:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600BB1A09EA for ; Sun, 23 Mar 2014 14:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.13 X-Spam-Level: X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, 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 d84rbNE3ygOB for ; Sun, 23 Mar 2014 14:13:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5381A09F7 for ; Sun, 23 Mar 2014 14:13:21 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 405589A43C1; Sun, 23 Mar 2014 17:13:11 -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 j+isN7TjGK83; Sun, 23 Mar 2014 17:12:47 -0400 (EDT) Received: from [192.168.5.215] (unknown [61.8.225.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 707DB9A43B5; Sun, 23 Mar 2014 17:12:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Sun, 23 Mar 2014 17:12:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14C0D5FC-4878-4E9D-85CA-C57CC77CB9AD@vigilsec.com> References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CmfdfEsAXs0qKaxhV4FQKMnbtxw Cc: Virginie.GALINDO@gemalto.com, IRTF CFRG , IETF SAAG Subject: Re: [saag] pkcs#1v1.5 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, 23 Mar 2014 21:13:24 -0000 {top post} Last December, on two separate SAAG mail list threads, I suggested that = we begin the migration to RSA-OAEP and RSA-PSS. I have copied the first = message in each of those threads below to save folks time with the mail = archive search. I continue to believe that we should begin this = migration. It takes a really long time to make such a transition. Let's get = started today. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D From: Russ Housley Date: December 4, 2013 5:40:33 AM EST To: IETF SAAG Subject: [saag] RSA-OAEP We have known for a very long time that PKCS #1 Version 1.5 (see RFC = 2313) key transport is vulnerable to adaptive chosen ciphertext attacks. = Exploitation reveals the result of a particular RSA decryption, = requires access to an oracle which will respond to a hundreds of = thousands of ciphertexts, which are constructed adaptively in response = to previously-received replies providing information on the successes or = failures of attempted decryption operations. As a result, the attack = appears significantly less feasible in store-and-forward environments = than interactive ones. PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to = address this situation, but we have seen very little movement toward = RSA-OAEP. While we are reviewing algorithm choices in light of the = pervasive surveillance situation, I think we should take the time to = address known vulnerabilities like this one. If we don't, then we are = leaving an partially open door for a well funded attacker. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=20 From: Russ Housley Date: December 4, 2013 6:04:57 AM EST To: IETF SAAG Subject: [saag] RSA-PSS We have known for a very long time that PKCS #1 Version 1.5 (see RFC = 2313) signature is more fragile than we might like. PKCS #1 Version 1.5 = signatures were developed in an ad hoc manner; RSASSA-PSS as specified = in PKCS #1 Version 2.1 (see RFC 3447) was developed based on = mathematical foundations. I am aware of two attacks against PKCS #1 Version 1.5 implementations: First, the Bleichenbacher attack against implementations. In this = attack, implementations do not calculate the length of the padding, but = rather scan the 0xff at the beginning until they find a 0x00 byte. = Also, a small RSA exponent (for example e=3D3). Second, fault-based attacks described by Boneh and others. By injecting = random faults into the RSA calculations, the attacker is able to = regenerate the private key from the knowledge of faulty signatures. RSA-PSS offers significant improvement against both of these attacks. We have seen very little movement toward RSA-PSS. While we are = reviewing algorithm choices in light of the pervasive surveillance = situation, I think we should take the time to consider improvements in = our algorithm choices. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D On Mar 22, 2014, at 11:09 AM, Paterson, Kenny wrote: > Hi >=20 > On 22/03/2014 14:10, "Stephen Farrell" = wrote: >>=20 >> Hi Kenny, >>=20 >> On 03/21/2014 06:15 PM, Paterson, Kenny wrote: >>> Hi Stephen, >>>=20 >>> [Cross-posting to CFRG, since it seems relevant] >>=20 >> [reducing back to saag, see below for why:-) ] >=20 > [re-cross-posting to cfrg, see below for why] >=20 >>=20 >>> Tibor Jager, Juarj Somorovsky and I sent this team feedback some >>> time ago about the undesirability of standardising already-broken >>> algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode >>> encryption with no integrity protection). >>=20 >> Not sure I'd agree with "broken" there, other than from a theoretical >> POV. Old/weaker/sniffy and not state-of-the-art would be fair though. >> In any case, yes, there's better crypto primitives to be used. >=20 > Well, unauthenticated encryption (e.g. CBC mode) has been broken *in > practice* in many real-world systems, including, for example IPsec > (starting with Bellovin's work, but reaching its nadir in my work with > Degabriele from IEEE S&P 2007) and XML encryption (Jager and = Somorovsky, > ACM-CCS 2011).=20 >=20 > The Bleichenbacher "million message" attack against PKCS#1v1.5 = encryption > was significantly improved in a paper at Crypto 2012 by Bardou et al., = and > applied to a variety of security tokens and a fielded HSM. Practical > attacks against XML encryption based on the known weaknesses in = PKCS#1v1.5 > were demonstrated by Jager et al at ESORICS 2012. >=20 > So several of the schemes being proposed for standardisation for = general > purpose use in this WebCrypto standard have already been broken *in > practice* and *several times over*. It seems foolhardy to be including > them in a new standard, irrespective of the "facts on the ground" > concerning their deployment. >=20 >=20 >> But there's an ongoing topic here that might be worth a thread - how = to >> move beyond pkcs#1v1.5 and other mechanisms with known crypto issues >> (whether currently practical or not) but where there's *huge* >> deployment and many many implementations in use in the wild on all >> sorts of platforms. >=20 > I agree, this is important. But putting the already broken schemes in = a > new standard does not seem helpful in that regard. >=20 >> I don't know how we can improve that situation (since a lot of this = is >> not controlled by the IETF or W3C) but I do know a lot of security >> folks would like it if we could. >>=20 >> Unfortunately, history seems to show that it requires a very-near- >> practical break before implementations and deployments will change in >> sufficient numbers. And maybe it also requires the non-existence of >> a band-aid that can be applied at another protocol or s/w layer. >=20 > And what a sad state of affairs that is. >=20 > The history of, for example, chained IVs in SSL/TLS should be salutary > lesson in the folly of this approach. There, Rogaway already presented = a > theoretical attack in 1995. It was explained how this could be = exploited > to recover plaintext in 2006 by Bard, but without a working attack. > Finally, the SSL/TLS community got its backside badly bitten by BEAST = in > 2011, which basically took Bard's attack and showed how to realise it = in > the web setting. Cue much panic and hand-wringing. Well, everybody was > warned... >=20 >> And of course this problem is really nothing to do with the crypto >> but is all about implementations and deployments. (Hence dropping >> cfrg cross-post:-) >=20 > These issues should be a first class concern for cfrg. There are = serious > research questions at stake here. Like: how do we build = developer-proof > APIs; how do we retire protocols, modes, algorithms which are showing > signs of weakness; how do we automatically find crypto bugs, side > channels, and the like, and eliminate them. >=20 >>=20 >> But ideas welcome... >=20 > Here's one idea: make sure that a new standard does not include broken > algorithms and modes. Then, to be able to claim compliance with the > standard, existing deployments will have to get their house in order. >=20 > Here's another: let's set up an aggressive timescale for deprecation = of > SSLv3, TLS 1.0 and TLS 1.1. >=20 >>=20 >> Cheers, >> S. >>=20 >> PS: On the w3c spec: yes, it'd seem entirely reasonable to warn about >> known issues and e.g. say that we do expect to move away from these = at >> some point. That's a good comment. I'm surprised if they blew that >> off. >=20 > They seem to have pretty much blown it off. Check out the = specification's > security considerations section: >=20 > http://www.w3.org/TR/WebCryptoAPI/#security >=20 >=20 > "This API includes a variety of cryptographic operations, some of = which > may have known security issues when used inappropriately. Application > developers should take care to review the appropriate cryptographic > literature before making use of certain algorithms, and should avoid > attempting to develop new cryptographic protocols whenever possible." >=20 >=20 > For me, this is not nearly stark or specific enough. What is the = average > developer meant to make of it? >=20 > Cheers >=20 > Kenny >=20 >=20 >>=20 >>>=20 >>> On 21/03/2014 17:54, "Stephen Farrell" >>> wrote: >>>=20 >>>> -------- Original Message -------- >>>> From: GALINDO Virginie >>>> Sent: 21 March 2014 17:10:45 GMT+00:00 >>>> To: Jim Schaad , "odonoghue@isoc.org" >>>> , "stephen.farrell@cs.tcd.ie" >>>> , "Kathleen.Moriarty.ietf@gmail.com" >>>> >>>> Cc: Harry Halpin , "wseltzer@w3.org" = >>>> Subject: W3C Web Crypto API - moving to Last Call >>>>=20 >>>> Hi IETF and JOSE team, >>>>=20 >>>>=20 >>>>=20 >>>> The Web Cryptography Working Group has decided to go to Last Call = for >>>> the >>>> Web Cryptography API next week. We'd like to make sure your group = has >>>> enough time to review the specification. Is four weeks enough time? = If >>>> I >>>> don't hear back from you, I am going to assume it is enough time. = Our >>>> latest draft is here: >>>>=20 >>>>=20 >>>>=20 >>>> = https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Virginie Galindo >>>>=20 >>>> Gemalto >>>>=20 >>>> chair of W3C web crypto wg >>>>=20 >>>=20 >>>=20 >>> Tibor Jager, Juarj Somorovsky and I sent this team feedback some = time >>> ago >>> about the undesirability of standardising already-broken algorithms = and >>> modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no = integrity >>> protection).=20 >>>=20 >>> This was in response to a request for feedback from CFRG. We gave = them >>> chapter and verse (and citations) about why this is generally a BAD >>> IDEA: >>>=20 >>> = http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html >>>=20 >>> The broken algorithms and modes are still in the Web Crypto = document. >>> Moreover, there are no relevant warnings about these broken = algorithms >>> and >>> modes in the "security considerations" section of the current Web = Crypto >>> draft. >>>=20 >>> Needless to say, I'm not minded to provide any more free advice to = this >>> group. >>>=20 >>> Cheers, >>>=20 >>> Kenny=20 From nobody Sun Mar 23 15:10:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8D1A0A0C for ; Sun, 23 Mar 2014 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=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 Ddg7q-GWbzRE for ; Sun, 23 Mar 2014 15:10:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D1E481A6FC1 for ; Sun, 23 Mar 2014 15:10:00 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C9B0E20049; Sun, 23 Mar 2014 19:29:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 30CE563AB2; Sun, 23 Mar 2014 18:09:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 20F2063AA2; Sun, 23 Mar 2014 18:09:58 -0400 (EDT) From: Michael Richardson To: Stephen Kent In-Reply-To: <532CC40D.5000804@bbn.com> References: <5328C2F2.5040204@bbn.com> <925.1395256095@sandelman.ca> <532CC40D.5000804@bbn.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HPZzxDALlsxrtelRhlE5TWDJvHE Cc: saag Subject: Re: [saag] better ** terminology 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, 23 Mar 2014 22:10:05 -0000 --=-=-= Stephen Kent wrote: >> To: >> The term opportunistic encryption (OE) was documented by Michael >> Richardson et al in "Opportunistic Encryption using the Internet Key >> Exchange (IKE)" an Informational RFC [RFC4322]. The term was coined >> by John Gilmore and Hugh Daniel in the mid-1990s. In this RFC the term is defined as: > I didn't see a mention of this earlier use of the term in your RFC. Is there > any written record of the earlier use by these folks? As Paul pointed out, and is in the references for 4322, the entire system was described in a document formerly known as "opportunism.spec": http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/opportunism.spec which later was renamed. I'm sure it's in the 1.5 and earlier trees, but maybe I'm wrong. and also: http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/overview.html -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUy9btYqHRg3pndX9AQJ/xwQA6kyql4vIdIBidxZ12HgPBfd17nX2PoHD l/IBX3bA3e73BtVLHFSaZkbOnEFR1elE1dHO3NSAzkBE3YX5+dAZ6wO90Wyz3+Wa bAcg4RRxQAgBw5qHTLpep04PjcIBPidhUlbn2sT5mFFP2UGcdfUhsjJ+N0Kvr6RX x+4Ow1jEbZg= =mjhT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 06:05:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAA81A0203 for ; Mon, 24 Mar 2014 06:05:09 -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, 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 CmxsweDaC6oX for ; Mon, 24 Mar 2014 06:05:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7938A1A0202 for ; Mon, 24 Mar 2014 06:05:04 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-d4-53302b2ca9a7 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D2.6C.12743.D2B20335; Mon, 24 Mar 2014 13:55:09 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Mon, 24 Mar 2014 09:04:58 -0400 From: Scott Mansfield To: "saag@ietf.org" Thread-Topic: (1) Global Standards Symposium; (2) workshop on spoofing Thread-Index: Ac8etgWGm+E6SKIcTNm7VNq8eo8XRACZC0qgABXZJNAAEWExkAljcxRQAAH1SjA= Date: Mon, 24 Mar 2014 13:04:57 +0000 Message-ID: References: <4a2d71ac8b2c476487d5f1d79c77c871@TUCM03.TUECSP.UNICC.ORG> <4f3fa21db7734b34963e75543e2265bd@TUCM03.TUECSP.UNICC.ORG> In-Reply-To: <4f3fa21db7734b34963e75543e2265bd@TUCM03.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E245586439934E00eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPiK6utkGwweNGcYtL718zWrx6cZPd 4tqcRjaLKf2dTA4sHkuW/GTyeDWtkdVj1s4nLB6r7nxhDWCJ4rJJSc3JLEst0rdL4Mpo2raP qaDxK2PFom/32BsYt95i7GLk4JAQMJE48Ievi5ETyBSTuHBvPVsXIxeHkMARRomHD/4zQzjL GSWO7L/EDFLFBtSwddd0RhBbREBZYvmf5+wgRcwC3xklDn1byQaSEBZwlfi9cx0zRJGbxOJf z8C2iQj4SazdXAZisgioShzaIQ9SwSvgK9FwcRbUrhNMEs/P7QabzyngLjHv1BawkYxA130/ tYYJxGYWEJe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStJTFp6jhWiPl/i0dmLjBDLBCVOznzC MoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxi BEbgMQk23R2Me15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjgtZb K+0PcX0MP3g4dtUjpX9743Y06X4V71aaE7BxPZuV/rON2qm51WtONXlMc9xfw3Qx+2Jax4wX vVqd/p7zWsX2q+o3H74tzzllQnr2qbfflqZNu3DUiX9DhAcrj/Z6UzOBysvn2a0q7U/uzWM/ 0O3gv9Vttmvis90TJfgdOiICt8a8EuJTYinOSDTUYi4qTgQAIbZeoI4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/V3qzQsUdEHk7iR4KX85J0jjRYHQ Cc: Joel Halpern , David Sinicrope , "Leslie Daigle \(daigle@isoc.org\)" , "rjsparks@nostrum.com" Subject: [saag] FW: (1) Global Standards Symposium; (2) workshop on spoofing 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, 24 Mar 2014 13:05:09 -0000 --_000_EF35EE4B92789843B1DECBC0E245586439934E00eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Security Area in general and STIR in particular.... I have received a request for support from the ITU-T. There is a workshop = on caller ID spoofing during the ITU-T SG2 meeting on 2 June. The ITU-T wo= uld like to have an introduction to STIR. How would you like to handle thi= s type of request? Regards, -scott. From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int] Sent: Monday, March 24, 2014 5:42 AM To: Scott Mansfield Cc: Jamoussi, Bilel; Ntoko, Alexander; Zhang, Jie Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing Scott, Below pls find info on the spoofing workshop. Would an expert from the IETF= STIR group be able to provide an introduction on activities and progress i= n the STIR group? Reinhard ITU workshop on caller ID spoofing at 2:30-5:30 PM of 2 June 2014, during t= he coming ITU-T SG2 meeting (28 May-6 June). Caller ID spoofing can happen in cases of PSTN-PSTN, and with higher potent= ial, in IP-PSTN, IP-IP, IP-PSTN-IP, as analyzed in draft-ietf-stir-threats-= 00.txt (http://tools.ietf.org/pdf/draft-ietf-stir-threats-00.pdf). Attack Scenarios: - Impersonation, IP-PSTN An attacker on the Internet uses a commercial WebRTC service to send a call to the PSTN with a chosen calling party number. The service contacts an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the CPN field of an IAM. When the IAM reaches the terminating telephone switch, the terminal renders the attacker's chosen calling party number as the calling identity. - Impersonation, PSTN-PSTN An attacker with a traditional PBX (connected to the PSTN through ISDN) sends a Q.931 SETUP request with a chosen calling party number which a service provider inserts into the corresponding SS7 calling party number (CPN) field of a call setup message (IAM). When the IAM reaches the endpoint switch, the terminal renders the attacker's chosen calling party number as the calling identity. - Impersonation, IP-IP An attacker with an IP phone sends a SIP request to an IP-enabled voicemail service. The attacker puts a chosen calling party number into the From header field value of the INVITE. When the INVITE reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity. - Impersonation, IP-PSTN-IP An attacker with an IP phone sends a SIP request to the telephone number of a voicemail service, perhaps without even knowing that the voicemail service is IP-based. The attacker puts a chosen calling party number into the From header field value of the INVITE. The attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the CPN of an IAM. That IAM then traverses the PSTN until (perhaps after a call forwarding) it reaches another gateway, this time back to the IP realm, to an H.323 network. The PSTN-IP gateway puts takes the calling party number in the IAM CPN field and puts it into the SETUP request. When the SETUP reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity. From: Scott Mansfield [mailto:scott.mansfield@ericsson.com] Sent: Tuesday, February 04, 2014 3:42 PM To: Scholl, Reinhard Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing I am still exploring that, but the leadership doesn't seem interested at t= his time. Do you have more information on the workshop? Regards, -scott. From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int] Sent: Tuesday, February 04, 2014 1:24 AM To: Scott Mansfield Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing Thanks Scott. Is there interest to pursue a joint ITU/IETF workshop on spoo= fing? Reinhard From: Scott Mansfield [mailto:scott.mansfield@ericsson.com] Sent: Monday, February 03, 2014 21:02 To: Scholl, Reinhard Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing Reinhard, I have spoken with the COO of ISOC, the chair of the IETF, and the chair of= the IAB and they are not interested in a GSS-like event in June. If the situation changes, I will send an email. I'm back in Geneva for the= SG15 meeting if you would like to meet in person. Regards, -scott. From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int] Sent: Friday, January 31, 2014 1:59 PM To: Scott Mansfield Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander Subject: (1) Global Standards Symposium; (2) workshop on spoofing Hi Scott, As we discussed during your stay mid-January, have you had a chance to inqu= ire whether IETF would be interested in joining us for a Global Standards S= ymposium (tentatively 12 - 13 June 2014)? And a further suggestion for collaboration: would IETF be interested in a j= oint ITU/IETF workshop on spoofing (tentatively 30 May 2014 during ITU-T St= udy Group 2)? Best regards Reinhard --_000_EF35EE4B92789843B1DECBC0E245586439934E00eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Security Area in general = and STIR in particular….

 <= /p>

I have received a request= for support from the ITU-T.  There is a workshop on caller ID spoofin= g during the ITU-T SG2 meeting on 2 June.  The ITU-T would like to have an introduction to STIR.  How would you like to handle this t= ype of request?

 <= /p>

Regards,

-scott.=

 <= /p>

From: Scholl, = Reinhard [mailto:reinhard.scholl@itu.int]
Sent: Monday, March 24, 2014 5:42 AM
To: Scott Mansfield
Cc: Jamoussi, Bilel; Ntoko, Alexander; Zhang, Jie
Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofin= g

 

Scott,<= /p>

 <= /p>

Below pls find info on th= e spoofing workshop. Would an expert from the IETF STIR group be able to pr= ovide an introduction on activities and progress in the STIR group?

 <= /p>

Reinhard

 <= /p>

ITU workshop on caller ID spoofing at 2:30-5:30 PM o= f 2 June 2014, during the coming ITU-T SG2 meeting (28 May-6 June). 

 

Caller ID spoofing can h= appen in cases of PSTN-PSTN, and with higher potential, in IP-PSTN, IP-IP, = IP-PSTN-IP, as analyzed in draft-ietf-stir-threats-00.txt (http://tools.i= etf.org/pdf/draft-ietf-stir-threats-00.pdf).

 

Attack Scenarios:

 

-     =      Impersonation= , IP-PSTN

An attacker on the Internet uses a commercial WebRTC service to send<= o:p>

a call to the PSTN with a chosen calling party number. The service

contacts an Internet-to-PSTN gateway, which inserts the attacker̵= 7;s

chosen calling party number into the CPN field of an IAM. When the

IAM reaches the terminating telephone switch, the terminal renders

the attacker’s chosen calling party number as the calling ident= ity.

 

-     =      Impersonation= , PSTN-PSTN

An attacker with a traditional PBX (connected to the PSTN through

ISDN) sends a Q.931 SETUP request with a chosen calling party number<= o:p>

which a service provider inserts into the corresponding SS7 calling

party number (CPN) field of a call setup message (IAM). When the IAM<= o:p>

reaches the endpoint switch, the terminal renders the attacker’= s

chosen calling party number as the calling identity.

 

-     =      Impersonation= , IP-IP

An attacker with an IP phone sends a SIP request to an IP-enabled

voicemail service. The attacker puts a chosen calling party number

into the From header field value of the INVITE. When the INVITE<= /o:p>

reaches the endpoint terminal, the terminal renders the attacker̵= 7;s

chosen calling party number as the calling identity.

 

-     =      Impersonation= , IP-PSTN-IP

An attacker with an IP phone sends a SIP request to the telephone

number of a voicemail service, perhaps without even knowing that the<= o:p>

voicemail service is IP-based. The attacker puts a chosen calling

party number into the From header field value of the INVITE. The=

attacker’s INVITE reaches an Internet-to-PSTN gateway, which in= serts

the attacker’s chosen calling party number into the CPN of an I= AM.

That IAM then traverses the PSTN until (perhaps after a call

forwarding) it reaches another gateway, this time back to the IP=

realm, to an H.323 network. The PSTN-IP gateway puts takes the

calling party number in the IAM CPN field and puts it into the SETUP<= o:p>

request. When the SETUP reaches the endpoint terminal, the terminal

renders the attacker’s chosen calling party number as the calli= ng

identity.

 =

 <= /p>

 <= /p>

From: Scott Ma= nsfield [mailto:scott.mansfield@ericsson.com]
Sent: Tuesday, February 04, 2014 3:42 PM
To: Scholl, Reinhard
Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander
Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofin= g

 

I  am still explorin= g that, but the leadership doesn’t seem interested at this time.=

Do you have more informat= ion on the workshop?

 <= /p>

Regards,

-scott.=

 <= /p>

From: Scholl, = Reinhard [mailto:reinhard.scholl= @itu.int]
Sent: Tuesday, February 04, 2014 1:24 AM
To: Scott Mansfield
Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander
Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofin= g

 

Thanks Scott. Is there in= terest to pursue a joint ITU/IETF workshop on spoofing? Reinhard=

 <= /p>

From: Scott Ma= nsfield [mailto:scott.mansf= ield@ericsson.com]
Sent: Monday, February 03, 2014 21:02
To: Scholl, Reinhard
Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander
Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofin= g

 

Reinhard,

 <= /p>

I have spoken with the CO= O of ISOC, the chair of the IETF, and the chair of the IAB and they are not= interested in a GSS-like event in June.

 <= /p>

If the situation changes,= I will send an email.  I’m back in Geneva for the SG15 meeting = if you would like to meet in person.

 <= /p>

Regards,

-scott.=

 <= /p>

 <= /p>

 <= /p>

From: Scholl, = Reinhard [mailto:reinhard.scholl= @itu.int]
Sent: Friday, January 31, 2014 1:59 PM
To: Scott Mansfield
Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander
Subject: (1) Global Standards Symposium; (2) workshop on spoofing

 

Hi Scott,

 <= /p>

As we discussed during yo= ur stay mid-January, have you had a chance to inquire whether IETF would be= interested in joining us for a Global Standards Symposium (tentatively 12 – 13 June 2014)?

 <= /p>

And a further suggestion = for collaboration: would IETF be interested in a joint ITU/IETF workshop on= spoofing (tentatively 30 May 2014 during ITU-T Study Group 2)?

 <= /p>

Best regards

 <= /p>

Reinhard

--_000_EF35EE4B92789843B1DECBC0E245586439934E00eusaamb105erics_-- From nobody Mon Mar 24 07:00:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2641A0219 for ; Mon, 24 Mar 2014 07:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 pkcCBp_Pe7Te for ; Mon, 24 Mar 2014 07:00:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3931A0215 for ; Mon, 24 Mar 2014 07:00:33 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 50A8E1A00AA; Mon, 24 Mar 2014 15:00:32 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BAkf-DaLzcEA; Mon, 24 Mar 2014 15:00:30 +0100 (CET) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id B4D0F1A00A8; Mon, 24 Mar 2014 15:00:30 +0100 (CET) Received: from [10.53.40.204] (port=10810 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WS5J7-0007Jx-NN; Mon, 24 Mar 2014 14:52:53 +0100 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 24 Mar 2014 15:00:30 +0100 Message-ID: <53303A7D.9010304@secunet.com> Date: Mon, 24 Mar 2014 15:00:29 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Russ Housley , "Paterson, Kenny" , IRTF CFRG References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <532D99CA.10405@cs.tcd.ie> <14C0D5FC-4878-4E9D-85CA-C57CC77CB9AD@vigilsec.com> In-Reply-To: <14C0D5FC-4878-4E9D-85CA-C57CC77CB9AD@vigilsec.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Kvha1V364rJ1kSzV0UGfUet6U18 Cc: IETF SAAG Subject: Re: [saag] [Cfrg] pkcs#1v1.5 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, 24 Mar 2014 14:00:37 -0000 6 months ago, I raised the question on the tls mailing list, if we shouldn't allow usage of RSA-PSS signatures in TLS. There was almost no support for that idea and the arguments I faced were - The need to support both legacy RSA and RSA-PSS introduces considerable complexity, in particular, if we try to reuse existing cipher suites - PSS doesn't give much benefit over PKCS#1v1.5. As Peter Gutmann put it: "I know it's *theoretically* better, but unless you do -1.5 really badly there's no practical weakness that would encourage an upgrade." I was told that there was an attempt, some years ago, to mandate RSA-PSS for certificates. It was met with pretty much universal rejection, to the extent that people would probably ignore the requirement even if it was made a MUST in the spec and as a result was dropped. Clearly the issue with PKCS#1v1.5 encryption is worse, so there might be more urge to migrate to OAEP. As development of TLS 1.3 is just about to start, this might be the right time. Johannes Russ Housley schrieb am 23.03.2014 22:12: > {top post} > > Last December, on two separate SAAG mail list threads, I suggested that we begin the migration to RSA-OAEP and RSA-PSS. I have copied the first message in each of those threads below to save folks time with the mail archive search. I continue to believe that we should begin this migration. > > It takes a really long time to make such a transition. Let's get started today. > > Russ > > = = = = = = = = = > > From: Russ Housley > Date: December 4, 2013 5:40:33 AM EST > To: IETF SAAG > Subject: [saag] RSA-OAEP > > We have known for a very long time that PKCS #1 Version 1.5 (see RFC 2313) key transport is vulnerable to adaptive chosen ciphertext attacks. Exploitation reveals the result of a particular RSA decryption, requires access to an oracle which will respond to a hundreds of thousands of ciphertexts, which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations. As a result, the attack appears significantly less feasible in store-and-forward environments than interactive ones. > > PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to address this situation, but we have seen very little movement toward RSA-OAEP. While we are reviewing algorithm choices in light of the pervasive surveillance situation, I think we should take the time to address known vulnerabilities like this one. If we don't, then we are leaving an partially open door for a well funded attacker. > > Russ > From nobody Mon Mar 24 08:51:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F901A0242 for ; Mon, 24 Mar 2014 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 M_Vx4ysy_0gb for ; Mon, 24 Mar 2014 08:51:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E95EB1A01C5 for ; Mon, 24 Mar 2014 08:51:22 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49671) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WS79t-000OXc-7O for saag@ietf.org; Mon, 24 Mar 2014 11:51:29 -0400 Message-ID: <5330547B.1000809@bbn.com> Date: Mon, 24 Mar 2014 11:51:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> In-Reply-To: <20140322175732.GL24183@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_nKmbchM5BmpljTIXi_RrBxTAtM Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 15:51:27 -0000 Viktor, > On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote: > >>> "Opportunistic encryption" isn't ideal because it has other historic >>> meanings. >> amen. > I have a suggestion that might help get us out of the rut, we could use: > > opportunistic security this work for me, as does your later suggestion of ASAP. Steve From nobody Mon Mar 24 08:55:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71EB1A023C for ; Mon, 24 Mar 2014 08:55:16 -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 du8g-_eHAi13 for ; Mon, 24 Mar 2014 08:55:15 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id CD9EE1A0227 for ; Mon, 24 Mar 2014 08:55:14 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id hl1so8166677igb.1 for ; Mon, 24 Mar 2014 08:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3icz2kDHeU2EhRS4mxkAImKfmKH794IqnTqq7anu/xs=; b=LoTeJR28VK2J/HCgAYBInMANsXn9plojPNhjLNhV8LCEwD85EUtajA6OBkLjqizgNB tHFEYCcmxVzKpkqDKXyLRsH40bDjOSzup4Yhpvmdx01ot7qFvi+v2ATZmwYx+R2x3Vgd BZRxH9dbWoQ6lQCDILECJHLSn/ogvVWhuITNGd5PDaJvNKkY0G4A6uJAkHS5lTnzorBE SkIeNsRk4tfoSBOfVKP51p3GJlp13HyDuRG9z3fobAjEuomsw20MGvlUzDDUD/1oruMF wuqnxlofIF7HTmvH8L2x2ay79PQUJ/iMeL0Mmx46s/VyySDFI+xXuwCMzfwtLTPyBGl1 QPIw== X-Received: by 10.42.50.3 with SMTP id y3mr52842683icf.12.1395676514032; Mon, 24 Mar 2014 08:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.168.100 with HTTP; Mon, 24 Mar 2014 08:54:50 -0700 (PDT) In-Reply-To: <5330547B.1000809@bbn.com> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> <5330547B.1000809@bbn.com> From: Ira McDonald Date: Mon, 24 Mar 2014 11:54:50 -0400 Message-ID: To: Stephen Kent , Ira McDonald Content-Type: multipart/alternative; boundary=90e6ba1efb96d71e7a04f55c428e Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ab6XaO-vAqg3GlJqQNQU0-L_QzM Cc: "saag@ietf.org" Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 15:55:17 -0000 --90e6ba1efb96d71e7a04f55c428e Content-Type: text/plain; charset=ISO-8859-1 Hi, I prefer the suggestion for ASAP (a positive term). In modern English "opportunistic" is typically negative and also conveys "untrustworthy" - which is the opposite of the intent here. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Mar 24, 2014 at 11:51 AM, Stephen Kent wrote: > Viktor, > > > On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote: >> >> "Opportunistic encryption" isn't ideal because it has other historic >>>> meanings. >>>> >>> amen. >>> >> I have a suggestion that might help get us out of the rut, we could use: >> >> opportunistic security >> > this work for me, as does your later suggestion of ASAP. > > Steve > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --90e6ba1efb96d71e7a04f55c428e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I prefer the sug= gestion for ASAP (a positive term).=A0 In modern English "opportunisti= c"
is typically negative and also conveys "untrustworthy= " - which is the opposite of the
intent here.

Cheers,
- Ira


Ira McDonald (M= usician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions = WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
= IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High No= rth Inc
http://sites.google.com/site/blueroofmusic=
http://sites.google.com/site/highnorthinc
mailto: bluero= ofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0= 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-= 2434



On Mon, Mar 24, 2014 at 11:51 AM, Stephe= n Kent <kent@bbn.com> wrote:
Viktor,


On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote:

"Opportunistic encryption" isn't ideal because it has other h= istoric
meanings.
amen.
I have a suggestion that might help get us out of the rut, we could use:
=A0 =A0 =A0 =A0 opportunistic security
this work for me, as does your later suggestion of ASAP.

Steve



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

--90e6ba1efb96d71e7a04f55c428e-- From nobody Mon Mar 24 08:55:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC74C1A0251 for ; Mon, 24 Mar 2014 08:55:21 -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 MjrzlmniPTQ4 for ; Mon, 24 Mar 2014 08:55:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9321A0242 for ; Mon, 24 Mar 2014 08:55:20 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49675) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WS7Dj-000Oap-4B for saag@ietf.org; Mon, 24 Mar 2014 11:55:27 -0400 Message-ID: <53305569.0@bbn.com> Date: Mon, 24 Mar 2014 11:55:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <5328C2F2.5040204@bbn.com> <925.1395256095@sandelman.ca> <532CC40D.5000804@bbn.com> <5595.1395612598@sandelman.ca> In-Reply-To: <5595.1395612598@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Iap7xuNbItyZaDMIvsoIDAs9DpE Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 15:55:22 -0000 Michael & Paul, Thanks for pointing out the reference [OEspec] I had overlooked in 4322. I'll revise the I-D to reflect that earlier doc (BTW, the link in 4322 doesn't work anymore). Steve From nobody Mon Mar 24 09:01:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30DD1A0188 for ; Mon, 24 Mar 2014 09:01:26 -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 NvtXccfAU1Is for ; Mon, 24 Mar 2014 09:01:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9541A0242 for ; Mon, 24 Mar 2014 09:01:25 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49676) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WS7Jb-000OfK-NN for saag@ietf.org; Mon, 24 Mar 2014 12:01:31 -0400 Message-ID: <533056D6.8080907@bbn.com> Date: Mon, 24 Mar 2014 12:01:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cIqC2Ii9c3lmNt9C0ad_daIDWDU Subject: Re: [saag] Proposal: use OE for now (Re: better ** terminology) 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, 24 Mar 2014 16:01:26 -0000 Nico, > On Fri, Mar 21, 2014 at 5:58 PM, Stephen Kent wrote: >> [...] > It's good to see that we agree on the rationale for a term like > "opportunistic foo". You don't yet agree as to actually using > "opportunistic foo", but in time you will ;) yes I can feel it growing on me :-). > More seriously, I propose the following: > > - _for the time being_ we should use "opportunistic encryption" to > refer to the new thing in Internet-Drafts and on the relevant mailing > lists > > - commit to reaching out to language specialists and/or to surveying > the public prior to publication as an RFC on the Standards track. > > (I really do think this is important enough to warrant a more > scientific approach to naming this beast. Conversely I am not > convinced that my own preference and logic behind it will work best in > the long haul, and that self-doubt leads me to wanting more input.) > > The rough consensus certainly seems to be that no term proposed until > now is quite as good an option as "opportunistic encryption", so I > don't see the harm in settling on that in the interim. And I see much > good in doing so: we'd stop spending so much effort on naming and move > on to more substantive matters. As I noted, the IETF published an RFC that defined the term, and folks outside of the IETF have made use of it, often in ways consistent with the 4322 definition. As a result, it strikes me as irresponsible to redefine the term just because a lot of folks who were not familiar with 4322 began using the term. A branding campaign seems very "un-IETF-like" and so if folks choose to pursue that I hope its done externally. Steve From nobody Mon Mar 24 09:14:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9077A1A01B9 for ; Mon, 24 Mar 2014 09:14:07 -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 lVNqSH1QhtXV for ; Mon, 24 Mar 2014 09:14:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C97C61A01CD for ; Mon, 24 Mar 2014 09:14:02 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49718) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WS7Vp-000OoH-93 for saag@ietf.org; Mon, 24 Mar 2014 12:14:09 -0400 Message-ID: <533059CB.7000702@bbn.com> Date: Mon, 24 Mar 2014 12:14:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <532DB76A.8070604@fifthhorseman.net> In-Reply-To: <532DB76A.8070604@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VCsy9RU05ovGEivjYX6vt0u1I3A Subject: Re: [saag] Hygienic encryption [was: Re: better ** terminology] 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, 24 Mar 2014 16:14:07 -0000 DKG, > On 03/21/2014 06:58 PM, Stephen Kent wrote: >> [dkg wrote:] >>> "Opportunistic keying" seems a bit off because we're not just discussing >>> choosing keys, but also talking about the way those keys are used. >> eh? > to clarify: if we opportunistically do key agreement between peers that > have never seen before, and then we use those keys for a MAC for our > session, we've now got cryptographically strong message integrity (the > usefulness of this is left as an exercise to the reader), but no > encryption. This is arguably "opportunistic keying" but it doesn't > provide any resistance against pervasive monitoring. > > --dkg Good point. So let's forget about opportunistic keying. Steve From nobody Mon Mar 24 09:21:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91A81A025C for ; Mon, 24 Mar 2014 09:21:02 -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 aaDb-S0sfivS for ; Mon, 24 Mar 2014 09:20:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C9D1B1A0266 for ; Mon, 24 Mar 2014 09:20:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6EDABE53; Mon, 24 Mar 2014 16:20:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loTp7K7db1ut; Mon, 24 Mar 2014 16:20:55 +0000 (GMT) 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 63764BE47; Mon, 24 Mar 2014 16:20:55 +0000 (GMT) Message-ID: <53305B67.3050709@cs.tcd.ie> Date: Mon, 24 Mar 2014 16:20:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> <5330547B.1000809@bbn.com> In-Reply-To: <5330547B.1000809@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/b5_mjjVK4ivfU2MxAtRFA4bjDGw Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 16:21:03 -0000 Hi all, On 03/24/2014 03:51 PM, Stephen Kent wrote: > Viktor, > >> On Fri, Mar 21, 2014 at 06:58:59PM -0400, Stephen Kent wrote: >> >>>> "Opportunistic encryption" isn't ideal because it has other historic >>>> meanings. >>> amen. >> I have a suggestion that might help get us out of the rut, we could use: >> >> opportunistic security > this work for me, as does your later suggestion of ASAP. Me too, or at least good enough. I'd say let's let Steve update the I-D that way and then we can hopefully work on the other text and get done soonish. S > > Steve > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Mon Mar 24 09:23:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382291A022B for ; Mon, 24 Mar 2014 09:23:37 -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 rWudZCyXM9K2 for ; Mon, 24 Mar 2014 09:23:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 258D21A0235 for ; Mon, 24 Mar 2014 09:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19357BE53 for ; Mon, 24 Mar 2014 16:23:34 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaKLqFHjQcRO for ; Mon, 24 Mar 2014 16:23:34 +0000 (GMT) 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 80EA7BE47 for ; Mon, 24 Mar 2014 16:23:33 +0000 (GMT) Message-ID: <53305C05.5030701@cs.tcd.ie> Date: Mon, 24 Mar 2014 16:23:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <20140320231001.GG3471@localhost> <532C2822.4090308@cs.tcd.ie> In-Reply-To: <532C2822.4090308@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UEzcRM2u8N_tXPOCb_yxITlFT-o Subject: Re: [saag] Name >> bikeshed color (Re: better ** terminology) 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, 24 Mar 2014 16:23:37 -0000 On 03/21/2014 11:53 AM, Stephen Farrell wrote: > It seems fairly clear that we are not so far getting consensus > for any term that does not include the word "opportunistic." > > Do folks agree with that? I think we have an answer to this one, which is that we will end up using the word opportunistic. And Steve's said he'll update the I-D to see if the term opportunistic security works as our preferred term. So let's call this particular question closed and see how it looks when we have a -01 draft and go from there. Thanks, S. From nobody Mon Mar 24 11:11:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662D91A026E for ; Mon, 24 Mar 2014 11:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 uWAZYRxx27qZ for ; Mon, 24 Mar 2014 11:11:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E29D61A0268 for ; Mon, 24 Mar 2014 11:11:25 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2OIBFkq006823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Mar 2014 14:11:22 -0400 Received: from bofh.nohats.ca (vpn-58-240.rdu2.redhat.com [10.10.58.240]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2OHUBFH004556 for ; Mon, 24 Mar 2014 13:30:11 -0400 Message-ID: <53306BA3.7030008@redhat.com> Date: Mon, 24 Mar 2014 13:30:11 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: saag@ietf.org References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> <5330547B.1000809@bbn.com> <53305B67.3050709@cs.tcd.ie> In-Reply-To: <53305B67.3050709@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ent4wwzC72JLgCesGU6puYG7838 Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 18:11:30 -0000 redefining the acronym ASAP seems unwise. It will always stand for As Soon As Possible no matter what a bunch of security geeks say it means. Paul From nobody Mon Mar 24 11:37:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1E51A028F for ; Mon, 24 Mar 2014 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, 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 YriFzRBDOZMx for ; Mon, 24 Mar 2014 11:37:38 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id B3E131A028B for ; Mon, 24 Mar 2014 11:37:37 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA17997; Mon, 24 Mar 2014 14:37:36 -0400 (EDT) Date: Mon, 24 Mar 2014 14:37:36 -0400 (EDT) From: Mouse Message-Id: <201403241837.OAA17997@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 24 Mar 2014 14:34:01 -0400 (EDT) To: saag@ietf.org In-Reply-To: <53306BA3.7030008@redhat.com> References: <5328C2F2.5040204@bbn.com> <532B3644.1080704@cs.tcd.ie> <6861.1395341319@sandelman.ca> <532B4B34.3040106@fifthhorseman.net> <532CC433.30903@bbn.com> <20140322175732.GL24183@mournblade.imrryr.org> <5330547B.1000809@bbn.com> <53305B67.3050709@cs.tcd.ie> <53306BA3.7030008@redhat.com> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/C-KMO3sl-KjduUx7CdEf6JbkGa8 Subject: Re: [saag] better ** terminology 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, 24 Mar 2014 18:37:39 -0000 > redefining the acronym ASAP seems unwise. It will always stand for As Soon A$ To a point, of course. But there _is_ prior art for other uses; I know someone who was working on a Linux distro called ASAP, which IIRC stood for Another Slackware Alpha Port. I feel reasonably sure the name was chosen to play on the common meaning of the term, but still, it is something like precedent. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Mon Mar 24 16:19:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB8F1A02FD for ; Mon, 24 Mar 2014 16:19:09 -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 98dgoezzGzLC for ; Mon, 24 Mar 2014 16:19:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B39931A02F3 for ; Mon, 24 Mar 2014 16:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2BF88BE57 for ; Mon, 24 Mar 2014 23:19:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpEenIXYZuAb for ; Mon, 24 Mar 2014 23:18:59 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.25.37]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38220BE54 for ; Mon, 24 Mar 2014 23:18:59 +0000 (GMT) Message-ID: <5330BD63.10803@cs.tcd.ie> Date: Mon, 24 Mar 2014 23:18:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> In-Reply-To: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140324230315.20999.31424.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rRu-6j5k-K_7Levq77G0Rfiyjs8 Subject: [saag] Fwd: New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP 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, 24 Mar 2014 23:19:09 -0000 Hiya, FYI, this list has just been setup by the transport ADs to continue discussions from London. It'd be great if a bunch of security folks signed up to help them out with that. Cheers, S. -------- Original Message -------- Subject: New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP Date: Mon, 24 Mar 2014 16:03:15 -0700 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: mls.ietf@gmail.com, tcpcrypt@ietf.org A new IETF non-working group email list has been created. List address: tcpcrypt@ietf.org Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/ To subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt Purpose: The goal of this mailing list is to discuss encryption of TCP sessions, without necessarily requiring endpoint authentication in all cases (but while also making endpoint authentication possible). The initial purpose of the mailing list is to discuss the scope and a potential charter of a WG that would work on the definition of TCP extensions to support such encryption, or to find an existing WG to perform the work. For additional information, please contact the list administrators. From nobody Mon Mar 24 23:30:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8D1A0364 for ; Mon, 24 Mar 2014 23:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 kLdpInMPsVPQ for ; Mon, 24 Mar 2014 23:29:57 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id A4F681A00F5 for ; Mon, 24 Mar 2014 23:29:56 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id CBBFF9A43C9; Tue, 25 Mar 2014 02:29:45 -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 QFB0rCrvCrXh; Tue, 25 Mar 2014 02:29:22 -0400 (EDT) Received: from [10.196.197.6] (22-193.icannmeeting.org [199.91.193.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 84516F2C04B; Tue, 25 Mar 2014 02:29:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-44-809918144 From: Russ Housley In-Reply-To: Date: Tue, 25 Mar 2014 02:29:05 -0400 Message-Id: <059911D9-CDC8-4C51-ABCE-F2DEBB708CAA@vigilsec.com> References: <4a2d71ac8b2c476487d5f1d79c77c871@TUCM03.TUECSP.UNICC.ORG> <4f3fa21db7734b34963e75543e2265bd@TUCM03.TUECSP.UNICC.ORG> To: Scott Mansfield X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Gda-XW-pH9G5MgMxowgFm5-1p_I Cc: Joel Halpern , David Sinicrope , "saag@ietf.org" , "Leslie Daigle \(daigle@isoc.org\)" , "rjsparks@nostrum.com" Subject: Re: [saag] (1) Global Standards Symposium; (2) workshop on spoofing 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, 25 Mar 2014 06:30:00 -0000 --Apple-Mail-44-809918144 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I cannot add another trip to my schedule this June. That said, I can = help someone put together a set of slides. Russ On Mar 24, 2014, at 9:04 AM, Scott Mansfield wrote: > Security Area in general and STIR in particular=85. > =20 > I have received a request for support from the ITU-T. There is a = workshop on caller ID spoofing during the ITU-T SG2 meeting on 2 June. = The ITU-T would like to have an introduction to STIR. How would you = like to handle this type of request? > =20 > Regards, > -scott. > =20 > From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int]=20 > Sent: Monday, March 24, 2014 5:42 AM > To: Scott Mansfield > Cc: Jamoussi, Bilel; Ntoko, Alexander; Zhang, Jie > Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing > =20 > Scott, > =20 > Below pls find info on the spoofing workshop. Would an expert from the = IETF STIR group be able to provide an introduction on activities and = progress in the STIR group? > =20 > Reinhard > =20 > ITU workshop on caller ID spoofing at 2:30-5:30 PM of 2 June 2014, = during the coming ITU-T SG2 meeting (28 May-6 June).=20 > =20 > Caller ID spoofing can happen in cases of PSTN-PSTN, and with higher = potential, in IP-PSTN, IP-IP, IP-PSTN-IP, as analyzed in = draft-ietf-stir-threats-00.txt(http://tools.ietf.org/pdf/draft-ietf-stir-t= hreats-00.pdf). > =20 > Attack Scenarios: > =20 > - Impersonation, IP-PSTN > An attacker on the Internet uses a commercial WebRTC service to send > a call to the PSTN with a chosen calling party number. The service > contacts an Internet-to-PSTN gateway, which inserts the attacker=92s > chosen calling party number into the CPN field of an IAM. When the > IAM reaches the terminating telephone switch, the terminal renders > the attacker=92s chosen calling party number as the calling identity. > =20 > - Impersonation, PSTN-PSTN > An attacker with a traditional PBX (connected to the PSTN through > ISDN) sends a Q.931 SETUP request with a chosen calling party number > which a service provider inserts into the corresponding SS7 calling > party number (CPN) field of a call setup message (IAM). When the IAM > reaches the endpoint switch, the terminal renders the attacker=92s > chosen calling party number as the calling identity. > =20 > - Impersonation, IP-IP > An attacker with an IP phone sends a SIP request to an IP-enabled > voicemail service. The attacker puts a chosen calling party number > into the =46rom header field value of the INVITE. When the INVITE > reaches the endpoint terminal, the terminal renders the attacker=92s > chosen calling party number as the calling identity. > =20 > - Impersonation, IP-PSTN-IP > An attacker with an IP phone sends a SIP request to the telephone > number of a voicemail service, perhaps without even knowing that the > voicemail service is IP-based. The attacker puts a chosen calling > party number into the =46rom header field value of the INVITE. The > attacker=92s INVITE reaches an Internet-to-PSTN gateway, which inserts > the attacker=92s chosen calling party number into the CPN of an IAM. > That IAM then traverses the PSTN until (perhaps after a call > forwarding) it reaches another gateway, this time back to the IP > realm, to an H.323 network. The PSTN-IP gateway puts takes the > calling party number in the IAM CPN field and puts it into the SETUP > request. When the SETUP reaches the endpoint terminal, the terminal > renders the attacker=92s chosen calling party number as the calling > identity. > =20 > =20 > =20 > From: Scott Mansfield [mailto:scott.mansfield@ericsson.com]=20 > Sent: Tuesday, February 04, 2014 3:42 PM > To: Scholl, Reinhard > Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander > Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing > =20 > I am still exploring that, but the leadership doesn=92t seem = interested at this time. > Do you have more information on the workshop? > =20 > Regards, > -scott. > =20 > From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int]=20 > Sent: Tuesday, February 04, 2014 1:24 AM > To: Scott Mansfield > Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander > Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing > =20 > Thanks Scott. Is there interest to pursue a joint ITU/IETF workshop on = spoofing? Reinhard > =20 > From: Scott Mansfield [mailto:scott.mansfield@ericsson.com]=20 > Sent: Monday, February 03, 2014 21:02 > To: Scholl, Reinhard > Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander > Subject: RE: (1) Global Standards Symposium; (2) workshop on spoofing > =20 > Reinhard, > =20 > I have spoken with the COO of ISOC, the chair of the IETF, and the = chair of the IAB and they are not interested in a GSS-like event in = June. > =20 > If the situation changes, I will send an email. I=92m back in Geneva = for the SG15 meeting if you would like to meet in person. > =20 > Regards, > -scott. > =20 > =20 > =20 > From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int]=20 > Sent: Friday, January 31, 2014 1:59 PM > To: Scott Mansfield > Cc: Johnson, Malcolm; Jamoussi, Bilel; Ntoko, Alexander > Subject: (1) Global Standards Symposium; (2) workshop on spoofing > =20 > Hi Scott, > =20 > As we discussed during your stay mid-January, have you had a chance to = inquire whether IETF would be interested in joining us for a Global = Standards Symposium (tentatively 12 =96 13 June 2014)? > =20 > And a further suggestion for collaboration: would IETF be interested = in a joint ITU/IETF workshop on spoofing (tentatively 30 May 2014 during = ITU-T Study Group 2)? > =20 > Best regards > =20 > Reinhard --Apple-Mail-44-809918144 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = cannot add another trip to my schedule this June.  That said, I can = help someone put together a set of = slides.

Russ


On = Mar 24, 2014, at 9:04 AM, Scott Mansfield wrote:

I = have received a request for support from the ITU-T.  There is a = workshop on caller ID spoofing during the ITU-T SG2 meeting on 2 = June.  The ITU-T would like to have an introduction to STIR.  = How would you like to handle this type of = request?
From: Scholl, Reinhard = [mailto:reinhard.scholl@itu.int] 
Sent: Monday, March 24, 2014 5:42 = AM
To: Scott = Mansfield
Cc: Jamoussi, Bilel; Ntoko, = Alexander; Zhang, Jie
Subject: RE: (1) Global Standards = Symposium; (2) workshop on = spoofing
Below = pls find info on the spoofing workshop. Would an expert from the IETF = STIR group be able to provide an introduction on activities and progress = in the STIR group?
ITU workshop on caller ID = spoofing at 2:30-5:30 PM of 2 June 2014, during the coming ITU-T SG2 = meeting (28 May-6 June). 
From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int] 
Sent: Tuesday, February 04, 2014 = 1:24 AM
To: Scott = Mansfield
Cc: Johnson, Malcolm; Jamoussi, = Bilel; Ntoko, Alexander
Subject: RE: (1) Global Standards = Symposium; (2) workshop on = spoofing
Thanks = Scott. Is there interest to pursue a joint ITU/IETF workshop on = spoofing? Reinhard
From: Scholl, Reinhard [mailto:reinhard.scholl@itu.int] 
Sent: Friday, January 31, 2014 = 1:59 PM
To: Scott = Mansfield
Cc: Johnson, Malcolm; Jamoussi, = Bilel; Ntoko, Alexander
Subject: (1) Global Standards = Symposium; (2) workshop on = spoofing
Hi = Scott,
As we = discussed during your stay mid-January, have you had a chance to inquire = whether IETF would be interested in joining us for a Global Standards = Symposium (tentatively 12 =96 13 June 2014)?
And a = further suggestion for collaboration: would IETF be interested in a = joint ITU/IETF workshop on spoofing (tentatively 30 May 2014 during = ITU-T Study Group 2)?
 
Best = regards
, "saag@ietf.org" , David Sinicrope , Joel Halpern , "rjsparks@nostrum.com" Subject: Re: [saag] (1) Global Standards Symposium; (2) workshop on spoofing 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, 25 Mar 2014 13:03:25 -0000 On Tue, Mar 25, 2014 at 2:29 AM, Russ Housley wrote: > I cannot add another trip to my schedule this June. That said, I can help > someone put together a set of slides. > > Russ Maybe _they_ should put together slides and ask for comments. There's enough info available already. From nobody Thu Mar 27 10:59:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1237F1A01AF for ; Thu, 27 Mar 2014 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, 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 WeOdldDJcb-j for ; Thu, 27 Mar 2014 10:59:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F29971A0182 for ; Thu, 27 Mar 2014 10:59:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.197]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2RHx3ac012714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2014 10:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1395943159; bh=53mw6yQGW3I2Z/pmVhISPNAa6bfVwcMfgX+Jb7/XBNU=; h=Date:To:From:Subject:In-Reply-To:References; b=Wog6MBCOfPw0IHX0J6JW/Ge02Wuy1jQgMR/sDIqWIdoKhhyZ8Yp6Ic8IAcNaaq/ZB mQN165dwucKZarDWIPKsSUp4yD9auQScXE1pcw+zlWVj9m9idGiFIzwiws/e9GN5Ay W7V9uodcxDRMzEeALzJaFoiWK9LY01XcUk50W7jM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1395943159; i=@elandsys.com; bh=53mw6yQGW3I2Z/pmVhISPNAa6bfVwcMfgX+Jb7/XBNU=; h=Date:To:From:Subject:In-Reply-To:References; b=abQhLswmgOa2y1VFInI00U19f12pxWdrhqdAYVIct4o9UdV0GGGykaFSGToYLjWtq tSh2oL3YPbwTYS4UVp4vr1mQaLtIWCRyXZzZS/DOMWfKFhsetxffHplUXuSp37K2S1 hvWGJGw35R2wpcHemsL9jt2S694zKtHOqKg4H/P4= Message-Id: <6.2.5.6.2.20140327104428.0d056f58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Mar 2014 10:56:45 -0700 To: Paul Wouters , Yoav Nir , saag@ietf.org From: S Moonesamy In-Reply-To: <530AB805.1060308@redhat.com> References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/U4NG33fLpJVTedtcJsdYDNqSjFw Subject: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 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, 27 Mar 2014 17:59:32 -0000 Hi Paul, Yoav, I submitted http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-01 The changes are: - Removal of the usage policy - Removal of the SHA-1 fingerprint example There was a comment from Paul about ECDSA. It is already defined in RFC 6594. I'll submit another draft for specifying SHA-256 in general. There would have to be some guidance about not using SHA-1. Regards, S. Moonesamy From nobody Fri Mar 28 02:28:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7E1A04A6 for ; Fri, 28 Mar 2014 02:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DtrKlcWuEaoc for ; Fri, 28 Mar 2014 02:28:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E11C71A02E8 for ; Fri, 28 Mar 2014 02:28:04 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-71-53353e5035e8 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 32.CC.12743.05E35335; Fri, 28 Mar 2014 10:18:08 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 05:28:01 -0400 From: Scott Mansfield To: Scott Brim , Russ Housley Thread-Topic: [saag] (1) Global Standards Symposium; (2) workshop on spoofing Thread-Index: Ac8etgWGm+E6SKIcTNm7VNq8eo8XRACZC0qgABXZJNAAEWExkAljcxRQAAH1SjAAMhOhgAANwjAAAIbwLaA= Date: Fri, 28 Mar 2014 09:28:01 +0000 Message-ID: References: <4a2d71ac8b2c476487d5f1d79c77c871@TUCM03.TUECSP.UNICC.ORG> <4f3fa21db7734b34963e75543e2265bd@TUCM03.TUECSP.UNICC.ORG> <059911D9-CDC8-4C51-ABCE-F2DEBB708CAA@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPlG6AnWmwwdTvchaX3r9mtHj14ia7 xbU5jWwWU/o7mSze7TjM5sDqsXPWXXaPJUt+Mnm8mtbI6jFr5xMWj1V3vrAGsEZx2aSk5mSW pRbp2yVwZbTtyC34xFbxe7tPA+M51i5GTg4JAROJG5euskDYYhIX7q1n62Lk4hASOMIo0b+x ix3CWc4o8fPDb7AONqCOrbumM4LYIgJeEi+n/QfrYBZ4ziix9N1RoCIODmEBH4nJv5Qganwl +pbPYoOwkySaL75kB7FZBFQl/u/6DjaHF6jmadM2FohlnSwS11ZfAEtwCgRKfJzxFWwxI9B5 30+tYQKxmQXEJW49mc8EcbaAxJI955khbFGJl4//Qb2mJPHx93x2iHodiQW7P7FB2NoSyxa+ ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIywYxJsujsY97y0 PMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG8R/vrC73XbO0/8nGfs/S 7bhYuaL49EiWtpk3oxJZ2O81Fr5vd7Jp0d6S9qsuWaBk/tNF59/0XTv15nXGH3+ezTuc5J6x PQwuyX3y5lT8Cj6phGdqddLzbpQFc7DP9zr2Z6L/3wyPqcqyXs6ZE5x3tR19qPhu/5ofR7w+ eatbODyc866GRYlXiaU4I9FQi7moOBEAfcvjCn4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/suvj6_HGxFxMIu5QfIL8ip50Z5E Cc: Joel Halpern , "Leslie Daigle \(daigle@isoc.org\)" , "rjsparks@nostrum.com" , "saag@ietf.org" , David Sinicrope Subject: Re: [saag] (1) Global Standards Symposium; (2) workshop on spoofing 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, 28 Mar 2014 09:28:06 -0000 I don't think it is an unreasonable request for the ITU-T to ask the IETF t= o talk about an IETF work item. I would certainly feel more comfortable if= IETF experts wrote and presented the information. -scott. -----Original Message----- From: Scott Brim [mailto:scott.brim@gmail.com]=20 Sent: Tuesday, March 25, 2014 9:03 AM To: Russ Housley Cc: Scott Mansfield; Joel Halpern; David Sinicrope; saag@ietf.org; Leslie D= aigle (daigle@isoc.org); rjsparks@nostrum.com Subject: Re: [saag] (1) Global Standards Symposium; (2) workshop on spoofin= g On Tue, Mar 25, 2014 at 2:29 AM, Russ Housley wrote: > I cannot add another trip to my schedule this June. That said, I can=20 > help someone put together a set of slides. > > Russ Maybe _they_ should put together slides and ask for comments. There's enoug= h info available already. From nobody Fri Mar 28 12:07:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD31A078A for ; Fri, 28 Mar 2014 12:07:12 -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 wJDLRL2lI2jc for ; Fri, 28 Mar 2014 12:07:10 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5721A094E for ; Fri, 28 Mar 2014 12:07:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40711) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1WTc78-0000ZZ-RA (Exim 4.82_3-c0e5623) (return-path ); Fri, 28 Mar 2014 19:06:50 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WTc78-0000Eo-BS (Exim 4.72) (return-path ); Fri, 28 Mar 2014 19:06:50 +0000 Date: Fri, 28 Mar 2014 19:06:50 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: S Moonesamy In-Reply-To: <6.2.5.6.2.20140327104428.0d056f58@resistor.net> Message-ID: References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> <6.2.5.6.2.20140327104428.0d056f58@resistor.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rFzvbu4d0nav8ZS-_mrL7Mv5YyE Cc: saag@ietf.org Subject: Re: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 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, 28 Mar 2014 19:07:12 -0000 > http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-01 Excellent. This document fills a notable gap. > I'll submit another draft for specifying SHA-256 in general. There would have > to be some guidance about not using SHA-1. Ace. On a tangent... Do you know what the situation is wrt standardized ssh certificate authentication? A colleague of mine found an awkward interop bug in OpenSSH which allows a server offering certificate authentication to make the client skip SSHFP authentication. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic 5 to 7, occasionally gale 8 in west, becoming variable 3 or 4 later in east. Very rough in west, otherwise moderate or rough. Rain or showers. Moderate or good, occasionally poor. From nobody Fri Mar 28 12:16:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A07A1A095C for ; Fri, 28 Mar 2014 12:16:23 -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 iMyp6S8LAw5Q for ; Fri, 28 Mar 2014 12:16:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D706F1A06FD for ; Fri, 28 Mar 2014 12:16:20 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 85309F984; Fri, 28 Mar 2014 15:16:15 -0400 (EDT) Message-ID: <5335CA75.1040509@fifthhorseman.net> Date: Fri, 28 Mar 2014 15:16:05 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Tony Finch , S Moonesamy References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> <6.2.5.6.2.20140327104428.0d056f58@resistor.net> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K0wlCm80NcjFfNANpc9HgUX73M0FulSPa" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4UR8nZJ6MIrjPxaDx2opZMGA5HQ Cc: saag@ietf.org Subject: Re: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 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, 28 Mar 2014 19:16:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K0wlCm80NcjFfNANpc9HgUX73M0FulSPa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/28/2014 03:06 PM, Tony Finch wrote: > Do you know what the situation is wrt standardized ssh certificate > authentication? I don't think OpenSSH certificates are standardized at all (the OpenSSH source code *is* the standard, fwict). > A colleague of mine found an awkward interop bug in > OpenSSH which allows a server offering certificate authentication to > make the client skip SSHFP authentication. >=20 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D742513 MITRE declared this CVE-2014-2653 on Wednesday, fwiw. --dkg --K0wlCm80NcjFfNANpc9HgUX73M0FulSPa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNcp1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckhsQAKPSfpLA7GDUuC2MgYYLt/Jf nm3vVaE5/BOjLqlAr78RRMN1nf2VgUw9HeFJp50B9aKkXhKJ1sPWcYrcRqZrqfEg 9rb0DRRUYeIb7WRSPNuUQiPmrYK2CH7Jgv2fPvbxRdVx/VtcBXePF5N3GmV9syiL FavpJSIBBFDe8CsWUpHBswAJUH0qu1vX8h0UBPevf6gw6T+/fgGv+KIbEBbtlpkU GaphL+K8i2M2xIPZy4qT/U2YjdiSfEZ86aH8/kCNmWKZzVxfJftuSMEcpRxt1/b9 jE3N24FbV0PYsapS+b2Wpx/RN/QznkzQ67eVKWbKQJmrTkjc1PkDJzGYQ4SOghfh tXfn7h6FHz1yXA7ztzoRjO0JdDOfWudQ1LLVdlENkfLF0MY0fjkrhXhv4OaVWCZU /fu542DNAbif7Yc++KVbPZCYPk83S5x6P64Gnm/Qylxeq9nRzcxf6UgYKJeFJWek gMBdosGbQA96ylfH+eLbEBDV1jxuxtO+U9R+YxiskLh0aB/VIYTiWlSu8kP4v6SM Rlqr6lqLwdcBhS7PjavNBeOeWFdIiJiDpF36SdDz1UmN57dOOO967PyWHaiqirS1 iwWVwbB+ZWZIjuC0TGADIFU3/1P1fhxD2E3r04BktEn8qKtzGPS6fNIjuhdqzfJH u/CP+dAtvDO3vYS5KwgR =AxJQ -----END PGP SIGNATURE----- --K0wlCm80NcjFfNANpc9HgUX73M0FulSPa-- From nobody Fri Mar 28 12:16:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6B81A0967 for ; Fri, 28 Mar 2014 12:16:26 -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 uh0XSt9xBzj9 for ; Fri, 28 Mar 2014 12:16:25 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DC8D01A06EE for ; Fri, 28 Mar 2014 12:16:24 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so5425924pbc.30 for ; Fri, 28 Mar 2014 12:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=numxQFinPx8eUxpF6v0MOiRQfd7/Hm1OgyNZbLI0CIU=; b=nIBMxgTabkEazuGp3aOHWQoGWMx2hjLAaR6Wmpuq+/pZMwGqhsnf/yh6UZMhpKEfzg mz8dDs4cutaQicvsIsFp+sMDI6d9hKWBmkSvt0RsszPPjza0KO4kIFP7Cu/uCFIYQK58 xfveyobgnpji1HOvUWtGDDywqSJTHKq3/fBftlzk4l5tTJAzpiqgVBFwjRxnGGzpJPBP GjkvdXG3j6BrNZg6iFkkMo5RLVFxD6ggrGRbZuMTyf5eDCOXh4xSHe1cVV/8erEQuI+C YDX7VE7s6m53ou32Bj6XAxqeBnPJ0iWpYR9JI7ZYzXH3HsJt4jhir7mKhSGPk21yAZs8 lCbw== MIME-Version: 1.0 X-Received: by 10.66.240.130 with SMTP id wa2mr10485225pac.73.1396034182710; Fri, 28 Mar 2014 12:16:22 -0700 (PDT) Received: by 10.68.196.138 with HTTP; Fri, 28 Mar 2014 12:16:22 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> <6.2.5.6.2.20140327104428.0d056f58@resistor.net> Date: Fri, 28 Mar 2014 15:16:22 -0400 Message-ID: From: Shumon Huque To: Tony Finch Content-Type: multipart/alternative; boundary=047d7b15a4b78e0dcc04f5af897b Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gSogKfq4ySFDv50yN_VQQ0qCEns Cc: S Moonesamy , saag@ietf.org Subject: Re: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:16:27 -0000 --047d7b15a4b78e0dcc04f5af897b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 28, 2014 at 3:06 PM, Tony Finch wrote: > > On a tangent... > > Do you know what the situation is wrt standardized ssh certificate > authentication? A colleague of mine found an awkward interop bug in > OpenSSH which allows a server offering certificate authentication to > make the client skip SSHFP authentication. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 > > Tony. > Well, there's RFC 6187 (Standards Track): http://tools.ietf.org/html/rfc6187 Does OpenSSH implement this? Or more generally, which implementations support this? --Shumon. --047d7b15a4b78e0dcc04f5af897b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 28, 2014 at 3:0= 6 PM, Tony Finch <dot@dotat.at> wrote:

On a tangent...

Do you know what the situation is wrt standardized ssh certificate
authentication? A colleague of mine found an awkward interop bug in
OpenSSH which allows a server offering certificate authentication to
make the client skip SSHFP authentication.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D742513

Tony.

Well, there's R= FC 6187 (Standards Track):

=A0=A0=A0=A0=A0 http://tools.ietf.org/html/rfc6187
=A0
Does OpenSSH implement this? Or more generally, which implementations suppo= rt this?

--Shumon.

--047d7b15a4b78e0dcc04f5af897b-- From nobody Fri Mar 28 12:20:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C595F1A06FD for ; Fri, 28 Mar 2014 12:20:02 -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 ah5ALnnBJjDx for ; Fri, 28 Mar 2014 12:20:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BF1A036F for ; Fri, 28 Mar 2014 12:20:00 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B5693F984; Fri, 28 Mar 2014 15:19:57 -0400 (EDT) Message-ID: <5335CB5B.7070704@fifthhorseman.net> Date: Fri, 28 Mar 2014 15:19:55 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: shuque@gmail.com, Tony Finch References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> <6.2.5.6.2.20140327104428.0d056f58@resistor.net> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jUB68OCSJtC5dUCNK9ngcX8BN5XmuwhiK" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/R40_3SyTYByyaq0YhDcZoLb5RY4 Cc: S Moonesamy , saag@ietf.org Subject: Re: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 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, 28 Mar 2014 19:20:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jUB68OCSJtC5dUCNK9ngcX8BN5XmuwhiK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/28/2014 03:16 PM, Shumon Huque wrote: > Well, there's RFC 6187 (Standards Track): >=20 > http://tools.ietf.org/html/rfc6187 >=20 > Does OpenSSH implement this? Or more generally, which implementations > support this? OpenSSH does *not* implement this, but there is a well-known patchset from Roumen Petrov, which he keeps admirably up-to-date: http://www.roumenpetrov.info/openssh/ The OpenSSH authors have made it clear that they consider expanding the attack surface of OpenSSH to include X.509 and ASN.1 unacceptable to the upstream project. --dkg --jUB68OCSJtC5dUCNK9ngcX8BN5XmuwhiK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTNctbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcebAP/0Zw2ubnF3wthCLsnsUBC6Ta MNjmjmtV8/5G7vb2u8759Ac4yq1fW4yRjY9pFYdq5ZvGXD/Ns/KU5/IJKAw7odWM bmbEO/j85EciJ23ivNI9fuwuwBnXp1I2d7Bsuou7zzL3HLilDCjF1731oV4maaoi ag1he9bXMzZsMgyw/GpwiWbu/fSCI9HwDLxZFpgZutLI4WGxLLx/22aawSvHFPzC p4wg238JhVs9fmK23dWxrQAnATneZncdTV5auynXk+tPwN2FOmysVkZI6rdULHuO NL+ewFPPZPD+FHo84mKK8q+KJP5Cu4QlqePELmdBn8HfyTDX66GbysMTDxKtp3c6 OaFzCnFZ3MGSbQPRc7d+yDrQ6TlN8zUnLA+k6+yz5KhCwDOLsbbyJi0ptFxcnpVc mSIwUfMGm1w4GK/25tTO6gggUsu7pXemeH1AmGAwuZf7Qfh5K7ydn6GtMaspj3HP AKEHqPX6BRVUanof9nY6m23O1eDz5XAkUWMfqga0dIp+tLNn8LaCzNQcZmDbRzSI UX/floqjCbgwCaDGB0XvQBxOcMeEGjz7eykrc1EEMOtNIb0EhKBycRK/Tf7XhGWb 6yau6/CY4mAJaNpKA3H/+sIR2o7OuHo1kuaNNFljoOI8gonKAYn2ZRNRhno66ooR F/nnuMf57CgGj9GFivzN =6E7V -----END PGP SIGNATURE----- --jUB68OCSJtC5dUCNK9ngcX8BN5XmuwhiK-- From nobody Fri Mar 28 13:04:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9A1A0750 for ; Fri, 28 Mar 2014 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mXOZnu945T_M for ; Fri, 28 Mar 2014 13:04:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D16851A0344 for ; Fri, 28 Mar 2014 13:04:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.131.181]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s2SK4W2t003484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2014 13:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396037084; bh=/CXSAoJXT8QMdV7m1aJ77xbp2N/AgHwWoef3/jfhSJ4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fAYxVZ525CTh+qG33Jf9+1SGnpvuBYmbauWGpbEqZMJvgfzhV3j2IuQdChZsRaZoS KlIt1DwBoQZWg3UlQl+ca89H4jupIyD6YmDBQlQvqV9oy3J4rBLPZx6b2RXPsC4Drw +2sTEdipJ2h8N5ULuaeKwr1gakv0lsxr1u9Ar+pc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396037084; i=@elandsys.com; bh=/CXSAoJXT8QMdV7m1aJ77xbp2N/AgHwWoef3/jfhSJ4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=h/+adZqerbnfkcIH7ME5jnV3frAcPZIg+ovmdfj/ILuzbqmpScCOOrV20zr8aSa1T U2tLqrMa+4K7/CfClHQQkAlRdN3o+pg3RckXvpEx+V44CaVHivdLW2bcGBCjSI4DlU +Oj4KpIuPa7CNPEayMDvNkh3JOr/Cm6Cw9+MyJUc= Message-Id: <6.2.5.6.2.20140328121642.0e5d8e30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 28 Mar 2014 12:48:46 -0700 To: Tony Finch From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140204112023.0aec4c90@elandsys.com> <23AC0B40-66B5-468C-B96D-17B52F1F42A4@checkpoint.com> <530A45F8.1010202@cs.tcd.ie> <530AB805.1060308@redhat.com> <6.2.5.6.2.20140327104428.0d056f58@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0hHfl72AKg6CugQO7m873OleyaM Cc: saag@ietf.org Subject: Re: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01 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, 28 Mar 2014 20:04:56 -0000 Hi Tony, At 12:06 28-03-2014, Tony Finch wrote: >Excellent. This document fills a notable gap. Thanks for the feedback. >On a tangent... > >Do you know what the situation is wrt standardized ssh certificate >authentication? A colleague of mine found an awkward interop bug in >OpenSSH which allows a server offering certificate authentication to >make the client skip SSHFP authentication. > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 There is ongoing work on a fix. Regards, S. Moonesamy