From nobody Tue Jul 1 15:35: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 971EE1A0ABD; Tue, 1 Jul 2014 15:35:12 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptVk_EVb2w0I; Tue, 1 Jul 2014 15:35:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F8F1A0AA2; Tue, 1 Jul 2014 15:35:10 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.242.155.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FE5B22E255; Tue, 1 Jul 2014 18:35:03 -0400 (EDT) Message-ID: <53B3379C.1070701@seantek.com> Date: Tue, 01 Jul 2014 15:35:08 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: smime@ietf.org, "pkix@ietf.org" , saag@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070907020303050205050708" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lwKlwW3lTNSu3yVzxLPAPFyXZOw Cc: Simon Josefsson Subject: [saag] New Version Notification for draft-josefsson-pkix-textual-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 01 Jul 2014 22:35:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070907020303050205050708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Greetings S/MIME, PKIX, and SAAG lists: A revised draft of PKIX text encodings has been published. There are=20 only small changes. Simon asked Stephen and Kathleen if they could sponsor the document. We think it is pretty close to done, but look forward to reactions and=20 comments. Kind regards, Sean Leonard -------- Original Message -------- Subject: New Version Notification for draft-josefsson-pkix-textual-04.tx= t Date: Tue, 01 Jul 2014 15:05:27 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-josefsson-pkix-textual-04.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-josefsson-pkix-textual Revision: 04 Title: Text Encodings of PKIX and CMS Structures Document date: 2014-06-30 Group: Individual Submission Pages: 15 URL:=20 http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-04.txt Status: https://datatracker.ietf.org/doc/draft-josefsson-pkix-textual/ Htmlized: http://tools.ietf.org/html/draft-josefsson-pkix-textual-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-josefsson-pkix-textual-0= 4 Abstract: This document describes and discuss the text encodings of Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate Revocation Lists (CRLs), PKCS #10 Certification Request Syntax, PKCS #7 structures, Cryptographic Message Syntax (CMS), PKCS #8 Private- Key Information Syntax, and Attribute Certificates. The text encodings are well-known, are implemented by several applications and= libraries, and are widely deployed. This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability going forward. =20 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at=20 tools.ietf.org. The IETF Secretariat --------------ms070907020303050205050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDcwMTIyMzUwOFowIwYJKoZIhvcNAQkEMRYEFOwTjdxtqpy0FPlq sSmz0h4VYYq7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQCearn1bOQ2M8IdVzpluAyd4HAlKpN+ cBsOIkg/4/plXCVMD6Sc4HZkujdTU6tECgLR4vZ/fZNzzEB+U2VLYga6J/zMQjIRhUH+RABC 2dEJ5HQpYhPlUYdcfyO6qNjU0rUc2OTa6uVGCINawlGS45EEMM+7q2tULAcdHsMSzts2rOyc OGm77LzI/rzWnMBRA7todMPB1l90zLWya5FcbYlhYjXL0OacSb2QFoXoT/7T3IUrJHfV7kKo KNCyf050k5rx8/Q+lQ6+O9f9XZqWNeBS5EGWI9u3EZhhdaSJlWJKSNKdlF0F3PTVaq4ttO2U iaWdo5areZ4TwlT6dqRFjrimAAAAAAAA --------------ms070907020303050205050708-- From nobody Tue Jul 1 17:40: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 918811A0643 for ; Tue, 1 Jul 2014 17:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcwnEnuBxjO7 for ; Tue, 1 Jul 2014 17:40:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C43E11A0AA9 for ; Tue, 1 Jul 2014 17:40:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CBA2BDD8 for ; Wed, 2 Jul 2014 01:40:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_XFnP8iFZ8N for ; Wed, 2 Jul 2014 01:40:31 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.27.161]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9CA34BDD7 for ; Wed, 2 Jul 2014 01:40:31 +0100 (IST) Message-ID: <53B354FF.3040609@cs.tcd.ie> Date: Wed, 02 Jul 2014 01:40:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/63BTHZdGl4e7rp5y5vGj1-BIGf4 Subject: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 00:40:45 -0000 Hi all, A while back Viktor posted a mail with a short chunk of definitional text that seemed to be positively received on this list. [1] At my request, he's now posted that as an I-D [2] and I'd like to get your thoughts as to whether we should proceed with that and your comments on its content. When this is baked then I plan to do an IETF LC for it. In an ideal world I could start that before Toronto so please comment in the next week if at all possible. In case you're wondering, yes this does overlap with Steve Kent's longer draft [3] that also has good history and analysis of the issues. I'm chatting with Steve to see how he suggests to proceed with a de-overlapped (is that a word?;-) version of his text as well. I think that may also be of use, though I'd like to first have the definitional one [2] out the door if that's what seems to represent rough consensus. Cheers, S. [1] https://www.ietf.org/mail-archive/web/saag/current/msg05020.html [2] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security [3] https://tools.ietf.org/html/draft-kent-opportunistic-security From nobody Tue Jul 1 17:52: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 26CDA1B278E for ; Tue, 1 Jul 2014 17:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1qTPaIeLrrb for ; Tue, 1 Jul 2014 17:52:16 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4281A0442 for ; Tue, 1 Jul 2014 17:52: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 s620ptjN026143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Jul 2014 17:51:55 -0700 (PDT) Message-ID: <53B357AE.7040207@isi.edu> Date: Tue, 01 Jul 2014 17:51:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" References: <53B354FF.3040609@cs.tcd.ie> In-Reply-To: <53B354FF.3040609@cs.tcd.ie> 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/6jPLWt1EKHWuRh_-NlboYUPZuVA Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 00:52:18 -0000 Hi, Stephen (et al.), On 7/1/2014 5:40 PM, Stephen Farrell wrote: > > Hi all, > > A while back Viktor posted a mail with a short chunk of > definitional text that seemed to be positively received > on this list. [1] > > At my request, he's now posted that as an I-D [2] and > I'd like to get your thoughts as to whether we should > proceed with that and your comments on its content. When > this is baked then I plan to do an IETF LC for it. In > an ideal world I could start that before Toronto so > please comment in the next week if at all possible. > > In case you're wondering, yes this does overlap with > Steve Kent's longer draft [3] that also has good history > and analysis of the issues. I'm chatting with Steve to > see how he suggests to proceed with a de-overlapped (is that > a word?;-) version of his text as well. I think that may > also be of use, though I'd like to first have the definitional > one [2] out the door if that's what seems to represent > rough consensus. I think that the Dukhovni draft is a more useful starting point, but my concern is that - despite the abstract - the one term that is not defined is "opportunistic security" other than "providing some protection some of the time" -- which isn't horrible, but isn't explicit either. The closest it comes is the indirect description of properties in Section 2: - supports full fallback if needed - uses the strongest security possible The doc would benefit from including an explicit definition, e.g., in a preface of the properties in Section 2 or as a conclusion to their discussion. Joe > > Cheers, > S. > > [1] https://www.ietf.org/mail-archive/web/saag/current/msg05020.html > [2] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security > [3] https://tools.ietf.org/html/draft-kent-opportunistic-security > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Jul 1 17:59: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 33DF31B27A3 for ; Tue, 1 Jul 2014 17:59:22 -0700 (PDT) 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 iIebZY5h1FfA for ; Tue, 1 Jul 2014 17:59:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EA71B2793 for ; Tue, 1 Jul 2014 17:59:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C9ED82AAD93; Wed, 2 Jul 2014 00:59:18 +0000 (UTC) Date: Wed, 2 Jul 2014 00:59:18 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140702005918.GL16666@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B357AE.7040207@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nOGB5nAjyfqucESi1tHR9-lYvsQ Subject: Re: [saag] opportunistic security again 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, 02 Jul 2014 00:59:22 -0000 On Tue, Jul 01, 2014 at 05:51:58PM -0700, Joe Touch wrote: > I think that the Dukhovni draft is a more useful starting point, but my > concern is that - despite the abstract - the one term that is not defined is > "opportunistic security" other than "providing some protection some of the > time" -- which isn't horrible, but isn't explicit either. > > The closest it comes is the indirect description of properties in Section 2: > - supports full fallback if needed > - uses the strongest security possible Right, the intention was to define opportunistic security as a design which meets the criteria in section 2. > The doc would benefit from including an explicit definition, e.g., in a > preface of the properties in Section 2 or as a conclusion to their > discussion. This is I think a fair point. Anyone want to suggest text (and/or be a coauthor)? I am on vacation, so cycles are limited. -- Viktor. From nobody Tue Jul 1 22:13: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 C97EA1B27AE for ; Tue, 1 Jul 2014 22:13:32 -0700 (PDT) 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 1UMxTd-JiX54 for ; Tue, 1 Jul 2014 22:13:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A691B27AC for ; Tue, 1 Jul 2014 22:13:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2244C2AB2A1; Wed, 2 Jul 2014 05:13:29 +0000 (UTC) Date: Wed, 2 Jul 2014 05:13:29 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140702051329.GM16666@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140702005918.GL16666@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uswVYnDj0NtHXQfE_Q0q8EPHDD4 Subject: Re: [saag] opportunistic security again 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, 02 Jul 2014 05:13:33 -0000 On Wed, Jul 02, 2014 at 12:59:18AM +0000, Viktor Dukhovni wrote: > > The doc would benefit from including an explicit definition, e.g., in a > > preface of the properties in Section 2 or as a conclusion to their > > discussion. > > This is I think a fair point. Anyone want to suggest text (and/or > be a coauthor)? I am on vacation, so cycles are limited. OK, here's a proposed defintional summary for the end of section 2. diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security index 8af06b9..39a305b 100644 --- a/draft-dukhovni-opportunistic-security +++ b/draft-dukhovni-opportunistic-security @@ -144,6 +144,18 @@ + + In summary, opportunistic security is an umbrella term describing + adaptive communications security protocols that emphasize + ubiquity over unconditional strong security. The actual + protection provided by opportunistic security depends on the + capabilities of the communicating peers; opportunistic security + strives to at least encrypt network traffic without authentication, + while allowing fallback to cleartext with legacy peers, but + provides stronger security when possible on a peer-by-peer + basis. + +
-- Viktor. From nobody Wed Jul 2 00:34: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 187EC1A0AA1 for ; Wed, 2 Jul 2014 00:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUBhoSWqkKqk for ; Wed, 2 Jul 2014 00:34:49 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AD81A0A98 for ; Wed, 2 Jul 2014 00:34:49 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A104F6D664; Wed, 2 Jul 2014 03:34:45 -0400 (EDT) Message-ID: <53B3B615.3060101@iang.org> Date: Wed, 02 Jul 2014 08:34:45 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> In-Reply-To: <53B357AE.7040207@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/xPUrPvE9OQ1oUKz5v7x0ctulFzU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 07:34:51 -0000 On 2/07/2014 01:51 am, Joe Touch wrote: > I think that the Dukhovni draft is a more useful starting point, but my > concern is that - despite the abstract - the one term that is not > defined is "opportunistic security" other than "providing some > protection some of the time" -- which isn't horrible, but isn't explicit > either. > > The closest it comes is the indirect description of properties in > Section 2: > - supports full fallback if needed > - uses the strongest security possible > > The doc would benefit from including an explicit definition, e.g., in a > preface of the properties in Section 2 or as a conclusion to their > discussion. 2c: Opportunistic cryptography provides the strongest protection possible within the constraints that (a) the caller has decided to go ahead and communicate, and (b) only local or limited information, including none, is available to authenticate. In contrast, other forms assume the capability to stop & deny communication, and require that certain authentication metrics be available before proceeding. iang From nobody Wed Jul 2 07:08: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 2EF5D1A0102 for ; Wed, 2 Jul 2014 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PmWk6bQP2kq for ; Wed, 2 Jul 2014 07:08:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819001A00E8 for ; Wed, 2 Jul 2014 07:08:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59784 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2LDE-000A0I-5n for saag@ietf.org; Wed, 02 Jul 2014 10:08:40 -0400 Message-ID: <53B41267.9040105@bbn.com> Date: Wed, 02 Jul 2014 10:08:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> In-Reply-To: <20140702051329.GM16666@mournblade.imrryr.org> Content-Type: multipart/alternative; boundary="------------090705010100080301040509" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p1DFyePAkPzV3otlqjMBRQWN6bQ Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:08:43 -0000 This is a multi-part message in MIME format. --------------090705010100080301040509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit How about: "Opportunistic security" is an umbrella term that encompasses protocol (and infrastructure?) mechanisms that remove barriers to the widespread use of encryption in the Internet. Protocols that exhibit opportunistic security MUST attempt to effect encryption of traffic, but SHALL fall back to plaintext transmission if a peer does not appear to support the required functionality. Opportunistic security protocols MAY provide one or two-way authentication, but an inability to provide authentication MUST NOT cause encryption to be effected if that security service was successfully enabled. Steve --------------090705010100080301040509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit How about:

“Opportunistic security” is an umbrella term that encompasses protocol (and infrastructure?) mechanisms that remove barriers to the widespread use of encryption in the Internet. Protocols that exhibit opportunistic security MUST attempt to effect encryption of traffic, but SHALL fall back to plaintext transmission if a peer does not appear to support the required functionality. Opportunistic security protocols MAY provide one or two-way authentication, but an inability to provide authentication MUST NOT cause encryption to be effected if that security service was successfully enabled.


Steve
--------------090705010100080301040509-- From nobody Wed Jul 2 07:23: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 47DB71A004B for ; Wed, 2 Jul 2014 07:23:36 -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 OjibfNd2GstR for ; Wed, 2 Jul 2014 07:23:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7041A019A for ; Wed, 2 Jul 2014 07:23:25 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s62ENFkc054851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jul 2014 07:23:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <53B354FF.3040609@cs.tcd.ie> Date: Wed, 2 Jul 2014 07:23:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> References: <53B354FF.3040609@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3QmMMkweLLvzpXOnbF7va84EEdU Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:23:36 -0000 I agree with Joe that Viktor's draft is a better starting point than = Steve's. As for incorporating Steve's history: please don't. It's highly = opinionated and therefore harmful. Note that I say that as someone who = could not do a better job of writing a less opinionated version of the = history. The history here is contentious and, I believe, not at all = helpful in us getting community agreement on something with which we can = move forwards. --Paul Hoffman= From nobody Wed Jul 2 07:28: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 CD7581A01BE for ; Wed, 2 Jul 2014 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeCjWa22PB8a for ; Wed, 2 Jul 2014 07:28:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 280B01A019A for ; Wed, 2 Jul 2014 07:28:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42152BE14; Wed, 2 Jul 2014 15:28:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmiO9pXKcZ-9; Wed, 2 Jul 2014 15:28:50 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20DF9BE0E; Wed, 2 Jul 2014 15:28:50 +0100 (IST) Message-ID: <53B41722.4050707@cs.tcd.ie> Date: Wed, 02 Jul 2014 15:28:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> In-Reply-To: <1365DFD8-B575-4032-B948-5DB1E39AA596@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/ImhAgMZchRJqwEm3YBV4cqkaZP4 Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:28:53 -0000 On 02/07/14 15:23, Paul Hoffman wrote: > As for incorporating Steve's history: That was not the plan. I'm chatting with Steve about him taking out the bits that overlap with Viktor's definition-draft and to then separately progress the history and analysis bits as appropriate in draft-kent. I think while some of that may be controversial, it could be done and could be useful. But no need to get into that now, Steve has said it'll be after Toronto before he has time to do those edits so we can deal with it later. S. From nobody Wed Jul 2 07:45: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 D2D941A02F1 for ; Wed, 2 Jul 2014 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlsadA8WnPRs for ; Wed, 2 Jul 2014 07:45:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 209971A013B for ; Wed, 2 Jul 2014 07:45:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A79FBE14; Wed, 2 Jul 2014 15:45:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RId66raeR2Ye; Wed, 2 Jul 2014 15:45:12 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B021BE0E; Wed, 2 Jul 2014 15:45:12 +0100 (IST) Message-ID: <53B41AF8.5020508@cs.tcd.ie> Date: Wed, 02 Jul 2014 15:45:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> In-Reply-To: <53B41267.9040105@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/lXdi3_f75TGhrpdhVg9rfVMI6tA Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:45:15 -0000 I also think progressing Viktor's draft is a good plan. I think I prefer Steve's text below over Viktor's from last night. Other comments/nits on Viktor's -00: 1. s/draft-farrell-perpass-attack/rfc7258/ or BCP188 according to taste. 2. If using any 2119 terms, (which you currently do once I think) then I guess you need a ref to 2119. I suspect that this draft could get by without any 2119 terms though, so s/MUST/needs to/ in the 2nd last para of section 2 (and if folks agree with non-use of 2119 then equivalent changes would be needed in Steve's definition below) 3. last para of section 2: wouldn't it be good to say here that applications that do have a user interface ought not make the use or non-use or status of opportunistic security visible to the user as a default, ("no lock icon!") but that logging what's happened or allowing an advanced user to drill down to see what's what can be ok and useful? Or something like that? Cheers, S. On 02/07/14 15:08, Stephen Kent wrote: > How about: > > "Opportunistic security" is an umbrella term that encompasses protocol > (and infrastructure?) mechanisms that remove barriers to the widespread > use of encryption in the Internet. Protocols that exhibit opportunistic > security MUST attempt to effect encryption of traffic, but SHALL fall > back to plaintext transmission if a peer does not appear to support the > required functionality. Opportunistic security protocols MAY provide one > or two-way authentication, but an inability to provide authentication > MUST NOT cause encryption to be effected if that security service was > successfully enabled. > > > Steve > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Jul 2 07:45: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 A0C681A0316 for ; Wed, 2 Jul 2014 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tksz5EcsjnWE for ; Wed, 2 Jul 2014 07:45:16 -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 871EF1A0307 for ; Wed, 2 Jul 2014 07:45:16 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0FC1B4830E; Wed, 2 Jul 2014 14:45:16 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 03F1048148; Wed, 2 Jul 2014 14:45:16 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id DD9F49803D; Wed, 2 Jul 2014 14:45:15 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.95]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 2 Jul 2014 10:45:15 -0400 From: "Salz, Rich" To: Stephen Kent , "saag@ietf.org" Date: Wed, 2 Jul 2014 10:45:10 -0400 Thread-Topic: [saag] opportunistic security again Thread-Index: Ac+V/yYKNYqo8ltYRn6gdK8LKI+K5gABP1zA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71857FE44A8@USMBX1.msg.corp.akamai.com> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> In-Reply-To: <53B41267.9040105@bbn.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QMmhYKj4si0LGT7jz2oB6UxK-Mk Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:45:18 -0000 4p6iIOKAnE9wcG9ydHVuaXN0aWMgc2VjdXJpdHnigJ0gaXMgYW4gdW1icmVsbGEgdGVybSB0aGF0 IGVuY29tcGFzc2VzIHByb3RvY29sIChhbmQgaW5mcmFzdHJ1Y3R1cmU/KSBtZWNoYeKApi4NCg0K SSBsaWtlIHRoaXMgcGFyYWdyYXBoIQ0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5l ZXINCkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUENCklNOiByc2FsekBqYWJiZXIu bWU7IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg0K From nobody Wed Jul 2 07:54: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 B4B881A032D for ; Wed, 2 Jul 2014 07:54:49 -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 NeHkQebGYHW1 for ; Wed, 2 Jul 2014 07:54:48 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A1B1A0327 for ; Wed, 2 Jul 2014 07:54:47 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so7074490lab.38 for ; Wed, 02 Jul 2014 07:54: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=cWDR21XtpLFnA3Z+Y9noIyEQbCgfCLv2t2S4JDrqSeY=; b=Hg3Mdw9dFx6MQUfsinNlOrcB2mghq0ds21MZvcG8D1gOdz0RLkaK24CCf4SO4O/IkX WW3bt+AkqLjjkArKjS9OOPSpHGGgRFynZIB/yR2UfgvMxgze7hFAVDwumx2oFsRGpBuO I3xG6iNt2iIq4NHBKfqYqOMg6pqmgPHKhiV/RPISl3eSUjDGUfkGEYrTn7679+72RZR5 YXtTCwMhAQpvInCcr0mzB2tg0W8vJmd4uA+3KAkt30JKFXVPsGOqdZTLjC9TuXEvYxxQ 158XRNrOOHWSW7bm2B1xvo6eI6gWH+4hZ1RbxbOQ9OdcgjmODIvTpcFPGhEFm6hYvE2r lSDw== MIME-Version: 1.0 X-Received: by 10.112.209.73 with SMTP id mk9mr2084865lbc.64.1404312886042; Wed, 02 Jul 2014 07:54:46 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Wed, 2 Jul 2014 07:54:45 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71857FE44A8@USMBX1.msg.corp.akamai.com> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C71857FE44A8@USMBX1.msg.corp.akamai.com> Date: Wed, 2 Jul 2014 10:54:45 -0400 Message-ID: From: Kathleen Moriarty To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c33536b9e5a604fd3712ed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XLLz9q-GH5brz2hz_N5AziGX1ow Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 14:54:49 -0000 --001a11c33536b9e5a604fd3712ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 2, 2014 at 10:45 AM, Salz, Rich wrote: > =E2=9E=A2 =E2=80=9COpportunistic security=E2=80=9D is an umbrella term th= at encompasses protocol > (and infrastructure?) mecha=E2=80=A6. > +1, I think I do prefer this definition as well, I'm just not sure on the infrastructure part. We all know it's easier to attack infrastructure, so it's really important to protect it. My question here is to figure out if we think infrastructure is included in the goals for opportunistic security or is that something else? If it is something else, do we need more work on this as it seems to be forgotten quite a bit (maybe that is not in this draft, but in another related to the sysadmin attacks where they were targeted to gain access to infrastructure to monitor data, etc.). Thanks, Kathleen > > I like this paragraph! > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Best regards, Kathleen --001a11c33536b9e5a604fd3712ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 2, 2014 at 10:45 AM, Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com&g= t; wrote:
=E2=9E=A2 =E2=80=9COpportunistic security=E2= =80=9D is an umbrella term that encompasses protocol (and infrastructure?) = mecha=E2=80=A6.

+1, I think I do prefer this definition as well, I'= m just not sure on the infrastructure part. =C2=A0We all know it's easi= er to attack infrastructure, so it's really important to protect it. = =C2=A0My question here is to figure out if we think infrastructure is inclu= ded in the goals for opportunistic security or is that something else? If i= t is something else, do we need more work on this as it seems to be forgott= en quite a bit (maybe that is not in this draft, but in another related to = the sysadmin attacks where they were targeted to gain access to infrastruct= ure to monitor data, etc.).

Thanks,
Kathleen

I like this paragraph!

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


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



--
=

Best regards,
Kathleen
--001a11c33536b9e5a604fd3712ed-- From nobody Wed Jul 2 08:11: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 865F61B290B for ; Wed, 2 Jul 2014 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 iVUSMZiDNgtI for ; Wed, 2 Jul 2014 08:11:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5DE1B290E for ; Wed, 2 Jul 2014 08:11:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 998632002A; Wed, 2 Jul 2014 11:11:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0E30E63B0E; Wed, 2 Jul 2014 11:11:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F3A2B63B09; Wed, 2 Jul 2014 11:11:14 -0400 (EDT) From: Michael Richardson To: Stephen Kent In-Reply-To: <53B41267.9040105@bbn.com> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@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/yRVDca28HGGDhbsTl8sLINSIsRA Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 15:11:29 -0000 --=-=-= Stephen Kent wrote: > ?Opportunistic security? is an umbrella term that encompasses protocol (and > infrastructure?) mechanisms that remove barriers to the widespread use of > encryption in the Internet. Protocols that exhibit opportunistic security MUST > attempt to effect encryption of traffic, but SHALL fall back to plaintext > transmission if a peer does not appear to support the required functionality. > Opportunistic security protocols MAY provide one or two-way authentication, but > an inability to provide authentication MUST NOT cause encryption to be effected > if that security service was successfully enabled. I like this text better, and I like pointing out that the authentication can be {0,1,2} end points. Is it worth also saying: "While opportunistic security protocols MAY authenticate end points, the underlying trust of the end points MUST NOT be enhanced by this activity" (and I'm willing to change "MUST NOT" to "SHOULD NOT") -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7QhEoCLcPvd0N1lAQKxFQf/bUSVkvwCLukodkbfuolVMREbFl0XQ85C AGisyONqXF1WPWb+rvNBKvG9G9QKodVt7y8VV5LGoVCs1AO1VzXXPSkMSdEhyimO i/mTIw9kvBxCVTLymMgxMy0ScXkufhMUOEEcmb9/DILtss9DN5wZSCpqjxEkAzi6 ufvZ75aWCAP+Nm0zF8pNAOLIJYOmcH4rOJhr1Klcwq+2YTxivA/mCsd3cUMnY2b3 kuDGKJZNFFYeICHdc1jqZsc1WxeSOtNqlgp/L/MP0ODzDS7Wco82xPfp+6ZkAYYh bGKIxs/IPiGcBNdcB1Rw2m0HPZV8wLf+7adyEWORjQ2mlf/sdAy0MQ== =ly/g -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 2 08:13: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 1B44A1B2916 for ; Wed, 2 Jul 2014 08:13:35 -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 5DN5AsDYek97 for ; Wed, 2 Jul 2014 08:13:34 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D57E1B2915 for ; Wed, 2 Jul 2014 08:13:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 645A72002A; Wed, 2 Jul 2014 11:14:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4AB1363B0E; Wed, 2 Jul 2014 11:13:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 356EC63B09; Wed, 2 Jul 2014 11:13:33 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53B41AF8.5020508@cs.tcd.ie> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <53B41AF8.5020508@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/weju3NjVfIf1oDQjwKj3jrlPSCM Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 15:13:35 -0000 --=-=-= Stephen Farrell wrote: > 3. last para of section 2: wouldn't it be good to > say here that applications that do have a user > interface ought not make the use or non-use or > status of opportunistic security visible to the > user as a default, ("no lock icon!") but that > logging what's happened or allowing an advanced > user to drill down to see what's what can be ok > and useful? Or something like that? Yes, that's what I was trying to get to. (keeping with the 2119 terms, as I'm agnostic about your first point) Opportunistic security protocols SHOULD audit their activity for diagnostic purposes only, but MUST NOT change the trust model presented to the user and/or upper protocol layers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7QhnICLcPvd0N1lAQKbPwf9FglMkxWit0XRlQ1pDJPg2hjEkIOH401s UPunIfhyVCDqkF9+/0g5JYNillypUipTGZrG39hPbXt7navUr+4LiqynoDCMf+Of xu3fwIu6GA4DlwxqsTLg6MoGmlXtcW7Nt0rTbw/5+y4HdojsTDQouoOS6fs/7Ccl BVeGndPHcxrWQv/g2QL4ccwGGYQYZ7yTJae8HW2Tg4Urq8tBCFI//i3Aq5Dn48pw Hk4a0c0UwletSl9F906tZxKl5hLWGkJvMWnHEcusGOhWEFLPLj62scGU9YSbNSql urBth4Gyxqz7aVKf7uUmH+5ZWrQ7tGqF/ZJjhQGIJg2nomhohUjhLA== =4RVN -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 2 08:15: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 E91071B280C for ; Wed, 2 Jul 2014 08:15:36 -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 jYGj_E6zxIXC for ; Wed, 2 Jul 2014 08:15:36 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008891B2809 for ; Wed, 2 Jul 2014 08:15:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 672652002D; Wed, 2 Jul 2014 11:16:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4C89663B0E; Wed, 2 Jul 2014 11:15:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CB4663B09; Wed, 2 Jul 2014 11:15:35 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53B41722.4050707@cs.tcd.ie> References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> <53B41722.4050707@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/gkzC18Ajn4jACw1hlTbT36B2i34 Cc: Paul Hoffman , "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 15:15:37 -0000 --=-=-= Stephen Farrell wrote: > That was not the plan. I'm chatting with Steve about > him taking out the bits that overlap with Viktor's > definition-draft and to then separately progress the > history and analysis bits as appropriate in draft-kent. > I think while some of that may be controversial, > it could be done and could be useful. But no need to > get into that now, Steve has said it'll be after > Toronto before he has time to do those edits so we > can deal with it later. Good plan. I think that it is useful that we have the history of how we got here. I'm interested (over beer) in hearing about the controversial parts. I'm mostly interested in documented that there was controversy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7QiFoCLcPvd0N1lAQKs4Qf/SvHDydQSOd1PSMuXMefHj4uTmUjChT+8 ejNP+I8JO3YBPT8HD+7S78HwX5ERbm49EO/u9Xh1vOATFA2G/PknuJo5i4rynQ6x eFSAhBh+OkojbUjNPi1fn/Lns4Zyc6qJJqw7vAhXwmPGvQTiMmhr4NwyK1yKvy5e LFGRch3OxGWSuY8y5aFLKYAP317hW4Ae5CeS+wDStVsDOmMg7o+ouGs1M3sXlLWP zY6gNsb9/pi0M01F1xyoZf1D4g7V61kZp47x3xAGwr2QvuZsdcakxAi3qsVVF4nf hsBupQ1DL+j1mssy851EQ18Jr52p4TXYcVgIDIh2UchQ8KYv8dYpyQ== =GgY2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 2 08:16: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 828851B290F for ; Wed, 2 Jul 2014 08:16:04 -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 wYTlWOm7tNBH for ; Wed, 2 Jul 2014 08:16:01 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39701B2905 for ; Wed, 2 Jul 2014 08:16:00 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w7so7983844lbi.7 for ; Wed, 02 Jul 2014 08:15:59 -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=JkafaaSk8J0YEFUYPddCnIegLTeW6w6M374FBqEjqo0=; b=pJHP/7WXNR9ufg97VfIxlHGMmLxKm54VfbusRXPMAYPXdcoimhSUcV5ID5thze2OMW YFLZbpq6Csot5AeUQuofhDMilPd2GyC4nSdi6MgB9yGlVsRIB+RF5Qa6b13ECTlcYD/x CnA2xdYIqbKFUQ0OTpq8jLjA+EfCWBCz6cjJgvlcueRWbKrybeqG0rUcL036bSvfVV7o FdNYi0KTm7MIRhOIN8Z8er7xJlH3tdZ/1jygkQPC1pxaaPdylr2sjsVapRjYl18h2o4m i+ksfz5x4oBk4vz+FXUOdqijrk4PrTx4H8GJ7sAfvO4DMoJFeOXX1Vy4yKFeWHnYP8Fk 0lug== MIME-Version: 1.0 X-Received: by 10.112.17.7 with SMTP id k7mr40049104lbd.0.1404314159063; Wed, 02 Jul 2014 08:15:59 -0700 (PDT) Received: by 10.112.253.198 with HTTP; Wed, 2 Jul 2014 08:15:58 -0700 (PDT) In-Reply-To: <734.1404313874@sandelman.ca> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> Date: Wed, 2 Jul 2014 11:15:58 -0400 Message-ID: From: Kathleen Moriarty To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11c3d8d09aa69904fd375ecc Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yf-_jxu26ZKOwGj1-Nwcdvx46i8 Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 15:16:04 -0000 --001a11c3d8d09aa69904fd375ecc Content-Type: text/plain; charset=UTF-8 On Wed, Jul 2, 2014 at 11:11 AM, Michael Richardson wrote: > > Stephen Kent wrote: > > ?Opportunistic security? is an umbrella term that encompasses > protocol (and > > infrastructure?) mechanisms that remove barriers to the widespread > use of > > encryption in the Internet. Protocols that exhibit opportunistic > security MUST > > attempt to effect encryption of traffic, but SHALL fall back to > plaintext > > transmission if a peer does not appear to support the required > functionality. > > Opportunistic security protocols MAY provide one or two-way > authentication, but > > an inability to provide authentication MUST NOT cause encryption to > be effected > > if that security service was successfully enabled. > > > I like this text better, and I like pointing out that the authentication > can > be {0,1,2} end points. > > Is it worth also saying: > "While opportunistic security protocols MAY authenticate end points, the > underlying trust of the end points MUST NOT be enhanced by this > activity" > > (and I'm willing to change "MUST NOT" to "SHOULD NOT") > How about "is not"? Underlying trust of the end points is separate from any security offered by the protocol connecting those end points. I'm not sure MUST or SHOULD apply here, it's just separate (IMO). Thanks. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Best regards, Kathleen --001a11c3d8d09aa69904fd375ecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 2, 2014 at 11:11 AM, Michael Richardson <mcr+ietf@= sandelman.ca> wrote:

Stephen Kent <kent@bbn.com> wrote= :
=C2=A0 =C2=A0 > ?Opportunistic security? is an umbrella term that encomp= asses protocol (and
=C2=A0 =C2=A0 > infrastructure?) mechanisms that = remove barriers to the widespread use of
=C2=A0 =C2=A0 > encryption in the Internet. Protocols that exhibit oppor= tunistic security MUST
=C2=A0 =C2=A0 > attempt to effect encryption of traffic, but SHALL fall = back to plaintext
=C2=A0 =C2=A0 > transmission if a peer does not appear to support the re= quired functionality.
=C2=A0 =C2=A0 > Opportunistic security protocols MAY provide one or two-= way authentication, but
=C2=A0 =C2=A0 > an inability to provide authentication MUST NOT cause en= cryption to be effected
=C2=A0 =C2=A0 > if that security service was successfully enabled.


I like this text better, and I like pointing out that the authe= ntication can
be {0,1,2} end points.

Is it worth also saying:
=C2=A0 =C2=A0"While opportunistic security protocols MAY authenticate = end points, the
=C2=A0 =C2=A0underlying trust of the end points MUST NOT be enhanced by thi= s activity"

(and I'm willing to change "MUST NOT" to "SHOULD NOT&quo= t;)

How about "is not"? =C2= =A0Underlying trust of the end points is separate from any security offered= by the protocol connecting those end points. =C2=A0I'm not sure MUST o= r SHOULD apply here, it's just separate (IMO).

Thanks.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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




--

Best regards,
Kathleen
--001a11c3d8d09aa69904fd375ecc-- From nobody Wed Jul 2 09:23: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 AD4781B2815 for ; Wed, 2 Jul 2014 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 sEd45eg_uGhD for ; Wed, 2 Jul 2014 09:23:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586AC1A058E for ; Wed, 2 Jul 2014 09:23:56 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s62GNt5q002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 2 Jul 2014 12:23:55 -0400 Received: from bofh.nohats.ca (vpn-56-95.rdu2.redhat.com [10.10.56.95]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s62GNsq3000830 for ; Wed, 2 Jul 2014 12:23:55 -0400 Message-ID: <53B4321A.8050306@redhat.com> Date: Wed, 02 Jul 2014 12:23:54 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> In-Reply-To: <1365DFD8-B575-4032-B948-5DB1E39AA596@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.27 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vpR6KcHABPvmJLkiS6EIRcLYkAs Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 16:23:57 -0000 On 07/02/2014 10:23 AM, Paul Hoffman wrote: > I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that as someone who could not do a better job of writing a less opinionated version of the history. The history here is contentious and, I believe, not at all helpful in us getting community agreement on something with which we can move forwards. Agreed. Paul From nobody Wed Jul 2 09:26: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 104BF1B2939 for ; Wed, 2 Jul 2014 09:26:01 -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 sBO64ZVknLYc for ; Wed, 2 Jul 2014 09:25:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B159A1B292B for ; Wed, 2 Jul 2014 09:25:54 -0700 (PDT) Received: from [10.70.10.77] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 416B7F984; Wed, 2 Jul 2014 12:25:52 -0400 (EDT) Message-ID: <53B43286.6090004@fifthhorseman.net> Date: Wed, 02 Jul 2014 12:25:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Michael Richardson , Stephen Kent References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> In-Reply-To: <734.1404313874@sandelman.ca> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LEED849dbPw4FnHbB1D1sKpV67dnNaPqK" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JBeAjun7sRKOavYQX0pcoTxGe4U Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 16:26:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LEED849dbPw4FnHbB1D1sKpV67dnNaPqK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2014 11:11 AM, Michael Richardson wrote: > Is it worth also saying: > "While opportunistic security protocols MAY authenticate end points,= the > underlying trust of the end points MUST NOT be enhanced by this acti= vity" I think "underlying trust" is a term that's likely to sow more confusion than it resolves. I think you're referring to one peer's confidence about the identity of the other peer, or confidence in the confidentiality or integrity properties of the channel; all of these are substantially different from how much one peer "trusts" the other. I'm also not convinced that we want anyone employing opportunistic security to actively *prohibit* user indicators in cases where strong authentication is actually used. That is: the use of opportunistic security without strong authentication MUST NOT indicate to the user any level of confidence in the remote peer's identity or in the security of the traffic by default. But strong authentication layered securely on top of an opportunistically-acquired channel shouldn't preclude an indication to the user. As an example, most OTR chat clients (OTR is one of the most widespread OS implementations) show that you're using OTR, but that the remote peer is unauthenticated. once a strong authentication step is done, the UI indicates "authenticated". MUST NOT language seems like it could be read to prohibit this change. --dkg --LEED849dbPw4FnHbB1D1sKpV67dnNaPqK 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/ iQJ8BAEBCgBmBQJTtDKGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcnegP/1sXJi0DGZuyTGV01c7j7IsL znTD1tDjI324zfB2OeKc86F2LDm5a10btCR2mocKLOkPuFor3q5qla7B/8JdQhz7 YlgTITmAFMcV1BDy2QIUSeudlokn3iuuEaKmj8LdYAZbaSq7697eBCzGH2mGRnJL BX5mDol36BrGqdVA2GdsnFecRYjWvTA/h02ZJIkGs1IZuwP8aoIJa/mCa9LeiGmr vcXrU4rEbZyZg45VmSxlYqHc7i9cX7SSmuKgAW7oz3wKZhYYD13qnt6B9az9IrPr 1ec8eB/AILpBlJahxZ19OSgN0B9lZZI4IvXfe+zzbGHxtlKOO4epa1uKC58q5Xcl RIXKi3IpUfQPBD0z2G5AMkvWlVePbnNEMlpEkIiRrOrAqUxEQ8n9qLMQTes9IG/8 PjcqBWv/NvHEjJDe1MoVhxu3DRler7JiyCn0AcxxFdV9fH2xl8IkW90FmeHYw2VQ WfMXg4ZEMkEXhUfDdads6tlwopzY2wOhXhaK6hz2rmP+LU3DhCOvk1nPOnaJpSJp B+if7mSK5dMPNrvrXNHAQo8F0i/iPxnGLUdWysWRCwcFTugAyRPV0EjPL9mwA2qD w7OYfr0PZ+iUeye7PjKloK3Zs6YXbdHQo6qde0j768+YSr74C/hy1iIDVZs11u5o FyL0dv31r7k1KdNkqhlW =3xl1 -----END PGP SIGNATURE----- --LEED849dbPw4FnHbB1D1sKpV67dnNaPqK-- From nobody Wed Jul 2 09:27: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 8410F1B2926 for ; Wed, 2 Jul 2014 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 udhvCv7YJcXC for ; Wed, 2 Jul 2014 09:27:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4871B280C for ; Wed, 2 Jul 2014 09:27:31 -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 s62GRTvR003735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 2 Jul 2014 12:27:30 -0400 Received: from bofh.nohats.ca (vpn-56-95.rdu2.redhat.com [10.10.56.95]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s62GRTkt013312 for ; Wed, 2 Jul 2014 12:27:29 -0400 Message-ID: <53B432EE.4010408@redhat.com> Date: Wed, 02 Jul 2014 12:27:26 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> In-Reply-To: <53B41267.9040105@bbn.com> 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/mj0PKxkHK3ZDwgCpZyDDwaNukMI Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 16:27:32 -0000 On 07/02/2014 10:08 AM, Stephen Kent wrote: > How about: > > "Opportunistic security" is an umbrella term that encompasses protocol (and infrastructure?) mechanisms that remove barriers to the widespread use of encryption > in the Internet. Protocols that exhibit opportunistic security MUST attempt to effect encryption of traffic, but SHALL fall back to plaintext transmission if a > peer does not appear to support the required functionality. No this is wrong. If someone publishes a DANE or IPSECKEY record, and a client can validate that using DNSSEC, it MUST NOT fallback to plaintext. (although some of this depends on the definition of "Opportunistic security") Opportunistic security protocols MAY provide one or two-way authentication, or zero-way against only passive attacks? but an inability to > provide authentication MUST NOT cause encryption to be effected if that security service was successfully enabled. I don't understand this? On auth failure, remove the encryption? What would be gained by that? Paul From nobody Wed Jul 2 09:45: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 232AF1B2850 for ; Wed, 2 Jul 2014 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnXf5J6bw47m for ; Wed, 2 Jul 2014 09:45:15 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF651A05CB for ; Wed, 2 Jul 2014 09:45:15 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 9EA031E8B4; Wed, 2 Jul 2014 16:45:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404319510; bh=xbbzJoDoihq1cQGTHrPIuqBWMLFTEJ3KdsZzyfP9dO8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=B7HMguX9ZuufeuKG+Lxml9dH9egmDAlQsZbQW3IcFzZ8E7z/4xOrhkmxocVwBRNpm gumPYH6+GtydQtm4iDeaToMEYyTJSE4pz9hrhIKwrW0syI3rH9O60I1NYNPQKe3FaN D1IoPI3aN6DQdkDXfS56xLTAqTNjj5KHgkeLWtv0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DB0466001E; Wed, 2 Jul 2014 16:44:24 +0000 (UTC) From: James Cloos To: Stephen Kent In-Reply-To: <53B41267.9040105@bbn.com> (Stephen Kent's message of "Wed, 02 Jul 2014 10:08:39 -0400") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 02 Jul 2014 12:43:59 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140702:kent@bbn.com::LO8r6CErUhlYPgju:0000CDZ7R X-Hashcash: 1:30:140702:saag@ietf.org::ySYwiDDi0DFO16/E:0003kSce Archived-At: http://mailarchive.ietf.org/arch/msg/saag/I7VzwLHHZc2GTcXL6zwrZdvV9s8 Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 16:45:18 -0000 >>>>> "SK" == Stephen Kent writes: SK> "Opportunistic security" is an umbrella term that encompasses SK> protocol (and infrastructure?) mechanisms that remove barriers to SK> the widespread use of encryption in the Internet. Protocols that SK> exhibit opportunistic security MUST attempt to effect encryption of SK> traffic, but SHALL fall back to plaintext transmission if a peer SK> does not appear to support the required functionality. Opportunistic SK> security protocols MAY provide one or two-way authentication, but an SK> inability to provide authentication MUST NOT cause encryption to be SK> effected if that security service was successfully enabled. I like that, too. But is "effected" the intended word in the last sentence? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 2 09:59: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 059C51A007A for ; Wed, 2 Jul 2014 09:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvJNIVP3LwEQ for ; Wed, 2 Jul 2014 09:59:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042C21A0022 for ; Wed, 2 Jul 2014 09:59:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44621 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2NsY-000Dn2-3w for saag@ietf.org; Wed, 02 Jul 2014 12:59:30 -0400 Message-ID: <53B43A71.4060104@bbn.com> Date: Wed, 02 Jul 2014 12:59:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag Content-Type: multipart/alternative; boundary="------------030407000106060906010104" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mjPY7hhUFRl-7fWS5n7zaNswnjc Subject: [saag] slight whoops X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 16:59:32 -0000 This is a multi-part message in MIME format. --------------030407000106060906010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Yee thoughtfully noted a typo in the last sentence of my proposed text: MUST NOT cause encryption to be effected -> MUST NOT cause encryption to be affected Sorry 'bout that, Steve --------------030407000106060906010104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Yee thoughtfully noted a typo in the last sentence of my proposed text:

MUST NOT cause encryption to be effected ->


MUST NOT cause encryption to be affected

Sorry 'bout that,

Steve
--------------030407000106060906010104-- From nobody Wed Jul 2 10:04: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 4C76C1A0175 for ; Wed, 2 Jul 2014 10:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UokC1Z_yxR1R for ; Wed, 2 Jul 2014 10:04:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2071A0021 for ; Wed, 2 Jul 2014 10:04:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41262 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2Nxs-0003d0-SI for saag@ietf.org; Wed, 02 Jul 2014 13:05:01 -0400 Message-ID: <53B43BAF.5050705@bbn.com> Date: Wed, 02 Jul 2014 13:04:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <53B432EE.4010408@redhat.com> In-Reply-To: <53B432EE.4010408@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Q2Fvv2hERjxrH8ZIJ2_2r5hWrdU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:04:51 -0000 Paul, > On 07/02/2014 10:08 AM, Stephen Kent wrote: >> How about: >> >> "Opportunistic security" is an umbrella term that encompasses protocol (and infrastructure?) mechanisms that remove barriers to the widespread use of encryption >> in the Internet. Protocols that exhibit opportunistic security MUST attempt to effect encryption of traffic, but SHALL fall back to plaintext transmission if a >> peer does not appear to support the required functionality. > No this is wrong. If someone publishes a DANE or IPSECKEY record, and a client can validate that using DNSSEC, it MUST NOT fallback to plaintext. Please identify the specific phrase you believe is in error. My intent was to say that if a peer does not support OS ("the required functionality", then the initiator of a session falls back to plaintext. > (although some of this depends on the definition of "Opportunistic security") > > Opportunistic security protocols MAY provide one or two-way authentication, > > or zero-way against only passive attacks? One could add that OS does not implicitly offer any authentication, but that it MAY (as noted in my text) provide one or two-way auth. "zero-way" is not a term I've seen before. care to elaborate? > but an inability to >> provide authentication MUST NOT cause encryption to be effected if that security service was successfully enabled. > I don't understand this? On auth failure, remove the encryption? What would be gained by that? Sorry about the typo. I meant "affected." Steve From nobody Wed Jul 2 10:11: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 5B69D1A039B for ; Wed, 2 Jul 2014 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3irr5NY2uIOC for ; Wed, 2 Jul 2014 10:11:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEDC1A05C3 for ; Wed, 2 Jul 2014 10:11:04 -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 s62HAjRI025582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 10:10:54 -0700 (PDT) Message-ID: <53B43D15.1010001@isi.edu> Date: Wed, 02 Jul 2014 10:10:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> In-Reply-To: <20140702051329.GM16666@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/cpSGt58vt3ZiZcSh_B7pkZuVRFU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:11:07 -0000 I like this definition better than Steve's because it focuses on adaptability, which AFAICT is the key feature. I don't see the key feature being any single approach, including TOFU or unauthenticated encryption. Joe On 7/1/2014 10:13 PM, Viktor Dukhovni wrote: > On Wed, Jul 02, 2014 at 12:59:18AM +0000, Viktor Dukhovni wrote: > >>> The doc would benefit from including an explicit definition, e.g., in a >>> preface of the properties in Section 2 or as a conclusion to their >>> discussion. >> >> This is I think a fair point. Anyone want to suggest text (and/or >> be a coauthor)? I am on vacation, so cycles are limited. > > OK, here's a proposed defintional summary for the end of section 2. > > diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security > index 8af06b9..39a305b 100644 > --- a/draft-dukhovni-opportunistic-security > +++ b/draft-dukhovni-opportunistic-security > @@ -144,6 +144,18 @@ > > > > + > + In summary, opportunistic security is an umbrella term describing > + adaptive communications security protocols that emphasize > + ubiquity over unconditional strong security. The actual > + protection provided by opportunistic security depends on the > + capabilities of the communicating peers; opportunistic security > + strives to at least encrypt network traffic without authentication, > + while allowing fallback to cleartext with legacy peers, but > + provides stronger security when possible on a peer-by-peer > + basis. > + > + >
> >
> From nobody Wed Jul 2 10: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 4D3F21B283A for ; Wed, 2 Jul 2014 10:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2nlKjyz1Kjn for ; Wed, 2 Jul 2014 10:13:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E24F1B291D for ; Wed, 2 Jul 2014 10:13:44 -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 s62HDC5o026048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 10:13:12 -0700 (PDT) Message-ID: <53B43DA8.3090609@isi.edu> Date: Wed, 02 Jul 2014 10:13:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> In-Reply-To: <53B41267.9040105@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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/lFH0nCoseI9rI32_BHGyv2BJM1o Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:13:49 -0000 FWIW, if we do prefer this text overall, I suggest the following changes: On 7/2/2014 7:08 AM, Stephen Kent wrote: > How about: > > “Opportunistic security” is an umbrella term that encompasses insert "adaptive" > protocol > (and infrastructure?) mechanisms that remove barriers to the widespread > use of encryption in the Internet. Protocols that exhibit opportunistic > security MUST attempt to effect encryption of traffic, but SHALL fall IMO, if you use MUST in the first part, use MUST in the second (same meaning as SHALL as per RFC 2119, but less confusing to use a single term) > back to plaintext transmission if a peer does not appear to support the > required functionality. Opportunistic security protocols MAY provide one > or two-way authentication, but an inability to provide authentication > MUST NOT cause encryption to be effected if that security service was > successfully enabled. > > > Steve > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Jul 2 10:14: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 15D231B283A for ; Wed, 2 Jul 2014 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNybUrXTmFAW for ; Wed, 2 Jul 2014 10:13:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D2D1B29A9 for ; Wed, 2 Jul 2014 10:13:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60871 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2O6b-0003gI-GE; Wed, 02 Jul 2014 13:14:01 -0400 Message-ID: <53B43DCC.8030001@bbn.com> Date: Wed, 02 Jul 2014 13:13:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> In-Reply-To: <53B43286.6090004@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/_E_Lapn6uz9oLq8Uy2_OpDC60Vg Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:13:52 -0000 DKG, > On 07/02/2014 11:11 AM, Michael Richardson wrote: >> Is it worth also saying: >> "While opportunistic security protocols MAY authenticate end points, the >> underlying trust of the end points MUST NOT be enhanced by this activity" > I think "underlying trust" is a term that's likely to sow more confusion > than it resolves. I agree. > I think you're referring to one peer's confidence > about the identity of the other peer, or confidence in the > confidentiality or integrity properties of the channel; all of these are > substantially different from how much one peer "trusts" the other. yes. > I'm also not convinced that we want anyone employing opportunistic > security to actively *prohibit* user indicators in cases where strong > authentication is actually used. This is a tricky area. If OS yields the same level of authentication as an extant security protocol, it's hard to argue that one ought not provide the same security UI indication. But, if there is some difference between an OS version of TLS and the current version that presents the lock icon, then presenting that icon might create confusion. > That is: the use of opportunistic security without strong authentication > MUST NOT indicate to the user any level of confidence in the remote > peer's identity or in the security of the traffic by default. But > strong authentication layered securely on top of an > opportunistically-acquired channel shouldn't preclude an indication to > the user. Oh, this is your concern. I didn't get that from the prior paragraph. This is may be hard to do, depending on the context. If an OS-based encrypted channel is established using protocol A, and authentication is effected via protocol B (running over A) then one would not expect a security UI indication for A to later be displayed, right? If B has its own security UI, then I would expect it to display the session status based on what it did, as a client of A. > As an example, most OTR chat clients (OTR is one of the most widespread > OS implementations) show that you're using OTR, but that the remote peer > is unauthenticated. once a strong authentication step is done, the UI > indicates "authenticated". MUST NOT language seems like it could be > read to prohibit this change. This is an easy example, and in this case I concur. Steve From nobody Wed Jul 2 10: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 8A8521A0329 for ; Wed, 2 Jul 2014 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8oYiJZs4NPZ for ; Wed, 2 Jul 2014 10:15:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B101A0303 for ; Wed, 2 Jul 2014 10:15:12 -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 s62HELk2026502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 10:14:21 -0700 (PDT) Message-ID: <53B43DED.8080401@isi.edu> Date: Wed, 02 Jul 2014 10:14:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Wouters , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> <53B4321A.8050306@redhat.com> In-Reply-To: <53B4321A.8050306@redhat.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/FOMbHkGZ_IGohxEuHliiQDPX-QA Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:15:17 -0000 +1 On 7/2/2014 9:23 AM, Paul Wouters wrote: > On 07/02/2014 10:23 AM, Paul Hoffman wrote: >> I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that as someone who could not do a better job of writing a less opinionated version of the history. The history here is contentious and, I believe, not at all helpful in us getting community agreement on something with which we can move forwards. > > Agreed. > > Paul > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Jul 2 10:15: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 CFF5E1A01BD for ; Wed, 2 Jul 2014 10:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf-KrbwjojXq for ; Wed, 2 Jul 2014 10:15:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141791A0329 for ; Wed, 2 Jul 2014 10:15:20 -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 s62HE00F026398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 10:14:00 -0700 (PDT) Message-ID: <53B43DD8.7090007@isi.edu> Date: Wed, 02 Jul 2014 10:14:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: James Cloos , Stephen Kent References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.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/i6enOJrTHrG9halnG1bSZ_PXpCQ Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:15:22 -0000 On 7/2/2014 9:43 AM, James Cloos wrote: >>>>>> "SK" == Stephen Kent writes: > > SK> "Opportunistic security" is an umbrella term that encompasses > SK> protocol (and infrastructure?) mechanisms that remove barriers to > SK> the widespread use of encryption in the Internet. Protocols that > SK> exhibit opportunistic security MUST attempt to effect encryption of > SK> traffic, but SHALL fall back to plaintext transmission if a peer > SK> does not appear to support the required functionality. Opportunistic > SK> security protocols MAY provide one or two-way authentication, but an > SK> inability to provide authentication MUST NOT cause encryption to be > SK> effected if that security service was successfully enabled. > > I like that, too. > > But is "effected" the intended word in the last sentence? Seems to me too like it should be "affected". From nobody Wed Jul 2 10:24: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 A5D9F1B280C for ; Wed, 2 Jul 2014 10:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IL6V8XQcZ6I for ; Wed, 2 Jul 2014 10:24:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1506D1A034D for ; Wed, 2 Jul 2014 10:24:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60078 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2OGR-0003m1-RB for saag@ietf.org; Wed, 02 Jul 2014 13:24:12 -0400 Message-ID: <53B4402E.4090008@bbn.com> Date: Wed, 02 Jul 2014 13:23:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> In-Reply-To: <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IxoVDs-dLnFbnQBkikXcUwnzu6Y Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:24:01 -0000 > I agree with Joe that Viktor's draft is a better starting point than Steve's. As for incorporating Steve's history: please don't. It's highly opinionated and therefore harmful. Note that I say that as someone who could not do a better job of writing a less opinionated version of the history. The history here is contentious and, I believe, not at all helpful in us getting community agreement on something with which we can move forwards. > > --Paul Hoffman In writing my I-D I contacted several folks to get their input for the sections that describe specific security protocols. Michael Richardson, Tero Kivinen, Russ Housley, Sean Turner, Richard Barnes, Eric Rescorla, and Jon Peterson provided helpful feedback. I used their comments to revise the text for the protocol sections. I contacted Paul, who said he didn't like the definitions I selected, especially ones from RFC 4949, and he refused to provide any feedback on the sections I sent to him. I assume this is Paul's definition of "highly opinionated and therefore harmful." Oh well, ... Steve From nobody Wed Jul 2 10:26: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 BDA251B2846 for ; Wed, 2 Jul 2014 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYKG2khCv0IS for ; Wed, 2 Jul 2014 10:26:53 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E47D41B2918 for ; Wed, 2 Jul 2014 10:26:51 -0700 (PDT) Received: from [10.70.10.77] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B380CF984; Wed, 2 Jul 2014 13:26:48 -0400 (EDT) Message-ID: <53B440D9.30303@fifthhorseman.net> Date: Wed, 02 Jul 2014 13:26:49 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <53B43A71.4060104@bbn.com> In-Reply-To: <53B43A71.4060104@bbn.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uiP8BKGkPRRGNcPjIQwhh3L9LA7NqQEnI" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Iqjcg7Ib60R7shLnhQFEnwgOp7A Subject: Re: [saag] slight whoops X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:26:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uiP8BKGkPRRGNcPjIQwhh3L9LA7NqQEnI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2014 12:59 PM, Stephen Kent wrote: > Peter Yee thoughtfully noted a typo in the last sentence of my proposed= > text: >=20 > MUST NOT cause encryption to be effected -> >=20 >=20 > MUST NOT cause encryption to be affected Given that you're not the only native English speaker (?) to confuse these two words, and the confusion is probably even greater in the rest of the world, perhaps it would be better to replace them entirely with something less unclear. Do you mean: MUST NOT cause encryption to be disabled. or: MUST NOT cause encryption to be downgraded. ? --dkg --uiP8BKGkPRRGNcPjIQwhh3L9LA7NqQEnI 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/ iQJ8BAEBCgBmBQJTtEDZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc++kP/RD7c+Z+96o9TdI635JG9sjb cTJAHcQxtu7QmHFwMpEscpV0yo7Psu1rZQTPgleSLf26vFqPnG9je2kNA9JsKizZ YK0Y3KzPuHJmj3+Y1KtU+lJpCclvZRF50FtbGC1g3yknq+zecgrcFC1lGTzVg069 KoFZxpbZdkznNqBoo6qQz0+84OsFmBWO3Me2jQl/XBu2dfc9uCxhOWd+dIKC/sgq 1qZqhmedfIFiVWD2PbWB2AorSFQq1fCLFO+yex9hOGhHTS9VzfyrjMsFP8qz6Zqo KtrqX8YEvzUNWvcFlAFnhpK+m4Te4kVS7ASK3vXL4eRKQB1NR/n3/pFE4O/lB3Vb 1kixSMpmlwMPeMkWB1EAMDWT7tyF9Yb7d+yLzqd7iZIRW/L37VJuqg4rLOFdGDuE TjyDVllftOkL1pt6GSZ95di28ZUj0ShHhbHmcg2MCpk1aI8831sgC8suZNrvcQrM tNrrFHdC/FLbjI+k4aMWjftDJIt+liqwJHgydXzVGTSo3DBnFrcofyZHjKh/E2b1 YJTRCLpf5luaMsIoBpeFvat04HMi2qwr7ijK+Ug+57C7dLN41e4gijebwJl4jEzE an08JCmEb8jf2ys7BYJ4+cHFVSEzeC/3v4d0LgconXnXj2Q7qeQ1+a3Yi48x5vZJ Zj1j++7fnIhxqDWjvRrk =Pd/Z -----END PGP SIGNATURE----- --uiP8BKGkPRRGNcPjIQwhh3L9LA7NqQEnI-- From nobody Wed Jul 2 10: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 6FFA21B29A2 for ; Wed, 2 Jul 2014 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1L0zLbm8MT1 for ; Wed, 2 Jul 2014 10:29:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4A81A039F for ; Wed, 2 Jul 2014 10:29:14 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35818 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2OLJ-000EO0-4l for saag@ietf.org; Wed, 02 Jul 2014 13:29:13 -0400 Message-ID: <53B44168.8060804@bbn.com> Date: Wed, 02 Jul 2014 13:29:12 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> In-Reply-To: <53B43D15.1010001@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/g5aFNv_ACSmDFcSXUodG5Rb0nko Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:29:15 -0000 Joe, > I like this definition better than Steve's because it focuses on > adaptability, which AFAICT is the key feature. I don't see the key > feature being any single approach, including TOFU or unauthenticated > encryption. > > Joe Then you'll need to define what "adaptability" means. Many protocols already negotiate algs, and some will negotiate NULL encryption, so the ability to "adapt" in this context may not be so easy to define in a broadly agreed-upon fashion. I do agree that no single feature of the sort you cite above is central to the notion of "opportunistic." They are examples of mechanisms, and this doc should be able to define the concept separate from examples of mechanisms. Steve From nobody Wed Jul 2 10:52: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 820901B2873 for ; Wed, 2 Jul 2014 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ8u5eNQy1j4 for ; Wed, 2 Jul 2014 10:52:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AEA1B2870 for ; Wed, 2 Jul 2014 10:52:18 -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 s62HpnQE006825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 10:51:49 -0700 (PDT) Message-ID: <53B446B5.60303@isi.edu> Date: Wed, 02 Jul 2014 10:51:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> In-Reply-To: <53B44168.8060804@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/716owK_4_99JSgcT4kF_3BTxM-g Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:52:20 -0000 On 7/2/2014 10:29 AM, Stephen Kent wrote: > Joe, >> I like this definition better than Steve's because it focuses on >> adaptability, which AFAICT is the key feature. I don't see the key >> feature being any single approach, including TOFU or unauthenticated >> encryption. >> >> Joe > > Then you'll need to define what "adaptability" means. Many protocols > already negotiate > algs, and some will negotiate NULL encryption, so the ability to "adapt" > in this context > may not be so easy to define in a broadly agreed-upon fashion. Certainly. > I do agree that no single feature of the sort you cite above is central > to the notion > of "opportunistic." They are examples of mechanisms, and this doc should > be able to define > the concept separate from examples of mechanisms. Agreed. How's this? (admittedly a bit terse, but it might be a starting point): OS is the combination of a protocol mechanisms and infrastructure approaches that determines and applies the best security possible for each given use rather than requiring any specific protection as a prerequisite. From nobody Wed Jul 2 10:52: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 E7E2E1B2870 for ; Wed, 2 Jul 2014 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7xzl_TC77PB for ; Wed, 2 Jul 2014 10:52:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822D41B29C8 for ; Wed, 2 Jul 2014 10:52:35 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33104 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2Ohu-000ErR-Is; Wed, 02 Jul 2014 13:52:34 -0400 Message-ID: <53B446E1.5050407@bbn.com> Date: Wed, 02 Jul 2014 13:52:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , saag References: <53B43A71.4060104@bbn.com> <53B440D9.30303@fifthhorseman.net> In-Reply-To: <53B440D9.30303@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/4YNnEksOjg5GECR4n9bLfIeD8qk Subject: Re: [saag] slight whoops X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 17:52:40 -0000 DKG >> Peter Yee thoughtfully noted a typo in the last sentence of my proposed >> text: >> >> MUST NOT cause encryption to be effected -> >> >> >> MUST NOT cause encryption to be affected > Given that you're not the only native English speaker (?) to confuse > these two words, and the confusion is probably even greater in the rest > of the world, perhaps it would be better to replace them entirely with > something less unclear. Do you mean: > > MUST NOT cause encryption to be disabled. > > or: > > MUST NOT cause encryption to be downgraded. > > ? good point! let's go with "MUST NOT cause encryption to be disabled" Steve From nobody Wed Jul 2 11:01: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 827661B29DF for ; Wed, 2 Jul 2014 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gkHU2dIU7QG for ; Wed, 2 Jul 2014 11:01:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423C81B29DC for ; Wed, 2 Jul 2014 11:01:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49157 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2Oqk-000F5v-R9; Wed, 02 Jul 2014 14:01:42 -0400 Message-ID: <53B44906.5090408@bbn.com> Date: Wed, 02 Jul 2014 14:01:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> In-Reply-To: <53B446B5.60303@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/Otsy9lL1xzYI_9MU2yLvRpwGx6I Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 18:01:45 -0000 Joe, > > How's this? (admittedly a bit terse, but it might be a starting point): > > OS is the combination of a protocol mechanisms and infrastructure > approaches that determines and applies the best security possible for > each given use rather than requiring any specific protection as a > prerequisite. The refernce to "best" is worrisome. It's probably the best that can be achieved at the time of session creation. if there was an active attack at that time, the "best" may change the next time there is an attempt. Also, the sentence vaguely implies a fallback to plaintext, which may not be obvious to many readers. The allusion to "specific protection" is true, but maybe too terse. There is the IPsec notion of specified protection on a per-peer, bi-lateral basis, the TLS notion of specified protection based on use of an HTTPS URL, etc. There's a lot of variance associated with the phrase "specific protection" and that phrase has not been used widely, I believe. Trying to be too terse can sacrifice clarity. Steve From nobody Wed Jul 2 11:10: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 5242A1B29FA for ; Wed, 2 Jul 2014 11:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KouAVhvMr4fr for ; Wed, 2 Jul 2014 11:10:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id F33EE1B29FB for ; Wed, 2 Jul 2014 11:10:32 -0700 (PDT) Received: from [10.70.10.77] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 28591F984; Wed, 2 Jul 2014 14:10:31 -0400 (EDT) Message-ID: <53B44B0D.7000407@fifthhorseman.net> Date: Wed, 02 Jul 2014 14:10:21 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Stephen Kent References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <53B43DCC.8030001@bbn.com> In-Reply-To: <53B43DCC.8030001@bbn.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bvPgeak0n1jpJHf9OHGKaNu9BEwCwOKs5" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7J3JP-tF4qFFWTyuuHGomUqfP5k Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 18:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bvPgeak0n1jpJHf9OHGKaNu9BEwCwOKs5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/02/2014 01:13 PM, Stephen Kent wrote: > This is may be hard to do, depending on the context. Yes, good UI/UX for security tools is hard to do. > If an OS-based > encrypted channel is established using protocol A, and authentication > is effected via protocol B (running over A) then one would not expect > a security UI indication for A to later be displayed, right? If B has > its own security UI, then I would expect it to display the session stat= us > based on what it did, as a client of A. Most users don't see the protocols A and B as distinct. Probably, most users don't even know that they're using protocols A and B at all. The security indicators exposed to the users are usually within a context of the particular application or utility that they're using. That is, from their perspective, they're not using HTTP over TLS (over TCP as resolved via DNS over UDP (with DNSSEC extensions, etc=E2=80=A6)).= They're "surfing the web". The application has (or should have) knowledge of all of the protocols used, and should be able to make the determination about what authenticity and security indicators to present to the user based on the aggregate information. --dkg --bvPgeak0n1jpJHf9OHGKaNu9BEwCwOKs5 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/ iQJ8BAEBCgBmBQJTtEsNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcY2QQAM725gR+HR7ICAEnaNqmXYKC +u+XqCZacj/eRAaaUp0xQkZ5/P33TcrzFbRtAqjR4BWZ1cPtoBxHbm2yGSzmVirq W1HA+7ABlheqYZ8mQPs6NeoBGqR8S4sUGjVttWzKQOiFDHxLjW2UP6NZviBQZB26 BfSuSFkxrj8QpSCAlDm2kuwn692qzBE9WO123ga8j0h6T4Xps/Jsnm0Ab1hqIFDn qwZnZgGDV/qTzg1FcibPM8Sv1ek1ivAcz0gMCWi8lF8ToD7hVxDLCsBsKDlb+IMz lK9IXroXBaR/c7n296CTSP56FkWs/nv+W89C2U2zX0sxL2Uk03ymE21Q9lM/TCHr krWsEoc1QS5Pqx4y5K/Z6XPaPWu7xbopBGGA+JSTgcFT733Sxjz5M0k9g9sK4MuL cmGEywQcrMTUcutWdxvUOe2mUEqfyKmrzxbzD+AEcOlHq14iiN4WII2fFa18jizD h//vSgniropUqc9oS3IQawCjvTsYyiPvCvaA2VhhGwr21oS16uw1YlwaLSms4TSA aiVvx2wZFMFVCvmNwfLl4+GoORq8kfftFYTOVJda258y/fMgdjLOF8Bu/rmVWXxi VKfAXkmG0MwNJd/OdcGeCakATrf6gIsOA1llyilWJDkI/1dT/xrNsHtLavYd9Lue gkGMjrAKbIOs8LBUWvHh =Wcb7 -----END PGP SIGNATURE----- --bvPgeak0n1jpJHf9OHGKaNu9BEwCwOKs5-- From nobody Wed Jul 2 11:28: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 3B85C1B29DF for ; Wed, 2 Jul 2014 11:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X0rUkzjZA40 for ; Wed, 2 Jul 2014 11:28:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917E41B29DA for ; Wed, 2 Jul 2014 11:28:20 -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 s62IRw6U015832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 11:27:58 -0700 (PDT) Message-ID: <53B44F2E.5030200@isi.edu> Date: Wed, 02 Jul 2014 11:27:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> In-Reply-To: <53B44906.5090408@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/oqyyP94u9BvUDRlNF1wlvhHrR_0 Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 18:28:22 -0000 On 7/2/2014 11:01 AM, Stephen Kent wrote: > Joe, >> >> How's this? (admittedly a bit terse, but it might be a starting point): >> >> OS is the combination of a protocol mechanisms and infrastructure >> approaches that determines and applies the best security possible for >> each given use rather than requiring any specific protection as a >> prerequisite. > > The refernce to "best" is worrisome. It's probably the best that can be > achieved at the time of > session creation. Agreed; there's also a problem with the lack of a total ordering on the value of various aspects of security, so there may just be "different" features that are available in various constellations. > if there was an active attack at that time, the "best" > may change the next time > there is an attempt. Also, the sentence vaguely implies a fallback to > plaintext, which may not be > obvious to many readers. Agreed; I had that as an additional sentence that I omitted. > The allusion to "specific protection" is true, > but maybe too terse. > There is the IPsec notion of specified protection on a per-peer, > bi-lateral basis, the TLS notion > of specified protection based on use of an HTTPS URL, etc. There's a lot > of variance associated > with the phrase "specific protection" and that phrase has not been used > widely, I believe. > > Trying to be too terse can sacrifice clarity. Granted. Here's take 2 (or 3,4, or 5, depending on your count origin). The first sentence is an attempt at a single-sentence definition (I always think that's better, when possible). The rest explains the motivation and makes it clear what we're focusing on - and, in a sense, what's 'opportunistic' about it without referring to any specific mechanism... ---- OS is the combination of protocol mechanisms and infrastructure that applies the strongest security possible (including "none") to a given use at the time invoked while still supporting communication. Communication security systems have traditionally focused on ensuring some set of particular protections, even if those guarantees prohibit communication in some cases. OS establishes communication as the sole fixed requirement; all other aspects of protection are optimized to increase security, but never at the expense of allowing communication to proceed. --- From nobody Wed Jul 2 13:53: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 516E21B2A3B for ; Wed, 2 Jul 2014 13:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM0Ou6YKPk1y for ; Wed, 2 Jul 2014 13:53:21 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8C61B2A84 for ; Wed, 2 Jul 2014 13:53:21 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 34FDA1E6A8; Wed, 2 Jul 2014 20:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404334399; bh=TG3upVn8NabJRlCldiqEOdDfnfnELp3jMA3CbRYFtw0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=e9sb1hkeQgwy8/ZObRh3ZQthd+bMl1Kf0Crqfhsuget4sbXNaayndwY6Bj0PV4gyG cEjbzE96js7rIXK272mMjTJ+WbuM38EbfmPtjmIqdzOoeigdSg44D+EmA51Wy0tw2u JSxSGnKstKBc0xBmaxdu5oU6LxdsDSypMNPrsgDg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EA16060022; Wed, 2 Jul 2014 20:45:07 +0000 (UTC) From: James Cloos To: saag@ietf.org In-Reply-To: <53B3B615.3060101@iang.org> (iang@iang.org's message of "Wed, 02 Jul 2014 08:34:45 +0100") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <53B3B615.3060101@iang.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 02 Jul 2014 16:44:42 -0400 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140702:saag@ietf.org::GtLkoEJi/xTi5VuW:000+dKNL X-Hashcash: 1:30:140702:iang@iang.org::qFU8dAK6iCWr0q7H:000uhFHe Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_Abtsm5PWD-eSBNkYDoFOECOaDU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 20:53:22 -0000 >>>>> "IG" == ianG writes: ig> Opportunistic cryptography provides the strongest protection ig> possible within the constraints that (a) the caller has decided to ig> go ahead and communicate, and (b) only local or limited information, ig> including none, is available to authenticate. ig> In contrast, other forms assume the capability to stop & deny ig> communication, and require that certain authentication metrics be ig> available before proceeding. That also looks convincing, except that many consider oe to include cases where some participants are able to use one or more out-of-band methods not only to authenticate themselves but also to insist on authenticated-encrypt-or-block-until-it-works schematics. Such as the case where tlsa records are used, but connections still are accepted from legacy peers. Unless of course that falls under (a). If so, perhaps (a) requires a bit more verbiage explaining that some callers may use more data than others to decide whether to go ahead and communicate? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 2 14:22: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 A01F31B2AB0 for ; Wed, 2 Jul 2014 14:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGY_0ELYa9ZM for ; Wed, 2 Jul 2014 14:22:16 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582341A063B for ; Wed, 2 Jul 2014 14:22:16 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2F1761E4EC; Wed, 2 Jul 2014 21:22:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404336136; bh=fcHv9KJctPdLw0nCGBNkQs7ZoOwiv2/4AKNleZKiIYs=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AACo/mgWjJw+Q77K/GEQ022/XWqdR7wnHoRaB3PWpBPgt/maw2oHaOo6gdsn2QlbI FHe8r3KiLOJrtFTkjJ6LE1QbAFxArZCs5o09cor7DDCpH56pzNag0gUrt7se4fEifb wYABzXHCIXhLTZoK5UuLdBhWYF+z0yD1holSFrtg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 62BB46001E; Wed, 2 Jul 2014 21:16:28 +0000 (UTC) From: James Cloos To: saag@ietf.org In-Reply-To: (James Cloos's message of "Wed, 02 Jul 2014 16:44:42 -0400") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <53B3B615.3060101@iang.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 02 Jul 2014 17:16:03 -0400 Message-ID: Lines: 7 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140702:saag@ietf.org::kgSTWrlfx3DL/AuT:0002Lgyh Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lzPpPQLL35HXWirF7knvd1sFWNs Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 21:22:17 -0000 JC> That also looks convincing, Odd. I meant to type compelling. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 2 14:56: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 C79201B2ACE for ; Wed, 2 Jul 2014 14:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxNkugM8CDE5 for ; Wed, 2 Jul 2014 14:56:07 -0700 (PDT) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5821A0A74 for ; Wed, 2 Jul 2014 14:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id CAE21E6BA; Wed, 2 Jul 2014 17:56:06 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBhOXvV057uh; Wed, 2 Jul 2014 17:56:03 -0400 (EDT) Received: from [192.168.3.137] (24-205-93-255.dhcp.psdn.ca.charter.com [24.205.93.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id 8A178E473; Wed, 2 Jul 2014 17:56:02 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D184CA14-3E64-4977-A8F1-69E3B2848101" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <53B446E1.5050407@bbn.com> Date: Wed, 2 Jul 2014 14:56:01 -0700 Message-Id: References: <53B43A71.4060104@bbn.com> <53B440D9.30303@fifthhorseman.net> <53B446E1.5050407@bbn.com> To: saag X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9c3WbH-MfGfPBl_dchRHdEu-Wz4 Subject: Re: [saag] slight whoops X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 21:56:11 -0000 --Apple-Mail=_D184CA14-3E64-4977-A8F1-69E3B2848101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Just an FYI for anyone (per DKG) confused: an affect causes an effect. On Jul 2, 2014, at 10:52 AM, Stephen Kent wrote: > DKG > >>> Peter Yee thoughtfully noted a typo in the last sentence of my proposed >>> text: >>> >>> MUST NOT cause encryption to be effected -> >>> >>> >>> MUST NOT cause encryption to be affected >> Given that you're not the only native English speaker (?) to confuse >> these two words, and the confusion is probably even greater in the rest >> of the world, perhaps it would be better to replace them entirely with >> something less unclear. Do you mean: >> >> MUST NOT cause encryption to be disabled. >> >> or: >> >> MUST NOT cause encryption to be downgraded. >> >> ? > good point! > > let's go with "MUST NOT cause encryption to be disabled" > > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu --Apple-Mail=_D184CA14-3E64-4977-A8F1-69E3B2848101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = an FYI for anyone (per DKG) confused: an affect causes an = effect.

On Jul 2, 2014, at 10:52 AM, Stephen Kent = <kent@bbn.com> wrote:

DKG

Peter Yee thoughtfully noted a typo in the last sentence = of my proposed
text:

MUST NOT cause encryption to be effected = ->


MUST NOT cause encryption to be = affected
Given that you're not the only native English = speaker (?) to confuse
these two words, and the confusion is probably = even greater in the rest
of the world, perhaps it would be better to = replace them entirely with
something less unclear.  Do you = mean:

 MUST NOT cause encryption to be = disabled.

or:

 MUST NOT cause encryption to be = downgraded.

?
good point!

let's go with = "MUST NOT cause encryption to be = disabled"

Steve

____________________________________________= ___
saag mailing list
saag@ietf.org
https://www.ietf.org/ma= ilman/listinfo/saag

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_D184CA14-3E64-4977-A8F1-69E3B2848101-- From nobody Wed Jul 2 15:12: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 768B61B2AEC for ; Wed, 2 Jul 2014 15:12:04 -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, HTML_MESSAGE=0.001, 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 CEVdKRlLGM8j for ; Wed, 2 Jul 2014 15:12:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA71B2AED for ; Wed, 2 Jul 2014 15:12:01 -0700 (PDT) Received: from BN1BFFO11FD032.protection.gbl (10.58.144.33) by BN1BFFO11HUB015.protection.gbl (10.58.144.162) with Microsoft SMTP Server (TLS) id 15.0.969.12; Wed, 2 Jul 2014 22:11:59 +0000 Received: from mx01.five9.com (198.105.204.2) by BN1BFFO11FD032.mail.protection.outlook.com (10.58.144.95) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 2 Jul 2014 22:11:58 +0000 Received: from MB01.five9.com (10.7.8.141) by mx01.five9.com (10.7.15.111) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 15:11:51 -0700 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 15:11:57 -0700 From: Ronald del Rosario To: Daniel Kahn Gillmor , Stephen Kent Thread-Topic: [saag] opportunistic security again Thread-Index: AQHPlY5GdO8g9OMEREiLEbIp639mTJuMaeMAgAACDACAAEcFgIAAlYaAgAARfACAABTPAIAADXAAgAAPzYD//84jgA== Date: Wed, 2 Jul 2014 22:11:56 +0000 Message-ID: References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <53B43DCC.8030001@bbn.com> <53B44B0D.7000407@fifthhorseman.net> In-Reply-To: <53B44B0D.7000407@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.7.8.130] Content-Type: multipart/alternative; boundary="_000_CFD9D01DF50Frrosariofive9com_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:198.105.204.2; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(199002)(189002)(479174003)(377454003)(24454002)(92726001)(4396001)(71186001)(87936001)(99396002)(76176999)(83072002)(36756003)(54356999)(31966008)(79102001)(2656002)(21056001)(84326002)(92566001)(81342001)(19580405001)(83506001)(83322001)(106116001)(85852003)(80022001)(64706001)(86362001)(81542001)(76482001)(512944002)(53416004)(85306003)(16236675004)(44976005)(107046002)(46102001)(15975445006)(74662001)(74502001)(106466001)(50986999)(6806004)(30436002)(77096002)(20776003)(95666004)(19580395003)(77982001)(93886003)(85436002)(94096001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB015; H:mx01.five9.com; FPR:; MLV:sfv; PTR:mx01.five9.com; A:1; MX:1; LANG:en; X-OriginatorOrg: five94.onmicrosoft.com X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0260457E99 Received-SPF: Pass (: domain of five9.com designates 198.105.204.2 as permitted sender) receiver=; client-ip=198.105.204.2; helo=mx01.five9.com; Authentication-Results: spf=pass (sender IP is 198.105.204.2) smtp.mailfrom=rrosario@five9.com; Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vuw93WqvRj0nyiqjLkDnfibRHzg Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:12:04 -0000 --_000_CFD9D01DF50Frrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Yes, good UI/UX for security tools is hard to do." +1. What we did in-house is conduct basic/foundational Computer Security traini= ng with our UI/UX guy so he is aware of the concepts and how hard they are,= and why the design should be KISS (Keep it simple, stupid) In the end its= a security tool with attention to an awesome user experience (UX) This research material can help, which combines elements of UX design and s= ecurity: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/prese= ntation/akhawe -Ron F. del Rosario From: Daniel Kahn Gillmor > Date: Wednesday, July 2, 2014 at 11:10 AM To: Stephen Kent > Cc: "saag@ietf.org" > Subject: Re: [saag] opportunistic security again On 07/02/2014 01:13 PM, Stephen Kent wrote: This is may be hard to do, depending on the context. Yes, good UI/UX for security tools is hard to do. If an OS-based encrypted channel is established using protocol A, and authentication is effected via protocol B (running over A) then one would not expect a security UI indication for A to later be displayed, right? If B has its own security UI, then I would expect it to display the session status based on what it did, as a client of A. Most users don't see the protocols A and B as distinct. Probably, most users don't even know that they're using protocols A and B at all. The security indicators exposed to the users are usually within a context of the particular application or utility that they're using. That is, from their perspective, they're not using HTTP over TLS (over TCP as resolved via DNS over UDP (with DNSSEC extensions, etc=85)). They're "surfing the web". The application has (or should have) knowledge of all of the protocols used, and should be able to make the determination about what authenticity and security indicators to present to the user based on the aggregate information. --dkg ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_CFD9D01DF50Frrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <249230F00A43A44D92B81E71F670FA1F@five9.com> Content-Transfer-Encoding: quoted-printable
"Yes, good UI/UX for security tools is hard to do."

= +1.

=

= What we did in-house is conduct basic/foundational Computer Security traini= ng with our UI/UX guy so he is aware of the concepts and how hard they are,= and why the design should be KISS (Keep it simple, stupid)  In the end its a security tool with attention to = an awesome user experience (UX)

=

= This research material can help, which combines elements of UX design and s= ecurity:

= https://www.usenix.org/conference/usenixsecurity= 13/technical-sessions/presentation/akhawe

=

= -Ron F. del Rosario


From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wednesday, July 2, 2014 at 11= :10 AM
To: Stephen Kent <kent@bbn.com>
Cc: "saag@ietf.org" <saag@i= etf.org>
Subject: Re: [saag] opportunistic s= ecurity again

On 07/02/2014 01:13 PM, Stephen Kent wrote:
This is may be hard to do, depending on the context.

Yes, good UI/UX for security tools is hard to do.

If an OS-based
encrypted channel is established using protocol A, and authentication<= /div>
is effected via protocol B (running over A) then one would not expect<= /div>
a security UI indication for A to later be displayed, right? &nbs= p;If B has
its own security UI, then I would expect it to display the session sta= tus
based on what it did, as a client of A.

Most users don't see the protocols A and B as distinct.  Pro= bably, most
users don't even know that they're using protocols A and B at all.

The security indicators exposed to the users are usually within a
context of the particular application or utility that they're using.
That is, from their perspective, they're not using HTTP over TLS (over=
TCP as resolved via DNS over UDP (with DNSSEC extensions, etc=85)).
They're "surfing the web".

The application has (or should have) knowledge of all of the protocols=
used, and should be able to make the determination about what
authenticity and security indicators to present to the user based on t= he
aggregate information.

--dkg<= /div>




CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_CFD9D01DF50Frrosariofive9com_-- From nobody Wed Jul 2 15:28: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 356E41A0A83 for ; Wed, 2 Jul 2014 15:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQCBHKYH1qZA for ; Wed, 2 Jul 2014 15:28:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006E01A037D for ; Wed, 2 Jul 2014 15:28:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 028C520028; Wed, 2 Jul 2014 18:28:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 89F2663B0E; Wed, 2 Jul 2014 18:28:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 75C8F63B09; Wed, 2 Jul 2014 18:28:07 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor In-Reply-To: <53B43286.6090004@fifthhorseman.net> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.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/Fmp8yAKPlt0s5zGWuBCEaJKwerM Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:28:13 -0000 Daniel Kahn Gillmor wrote: > I think "underlying trust" is a term that's likely to sow more confusion > than it resolves. I think you're referring to one peer's confidence > about the identity of the other peer, or confidence in the > confidentiality or integrity properties of the channel; all of these are > substantially different from how much one peer "trusts" the other. > I'm also not convinced that we want anyone employing opportunistic > security to actively *prohibit* user indicators in cases where strong > authentication is actually used. So I think that you've confused yourself. If it's opportunistic security, then it didn't use strong authentication, therefore the prohibition against an indicator does not apply. If the admin did anything *AT ALL* (including, btw, in the SSH TOFU, typing "yes" to the public key prompt), then it is no longer opportunistic; the key is locked down. About 70% of the reviewers of RFC4332 would get confused about this, and it's why it took 2 years to get the document through. > As an example, most OTR chat clients (OTR is one of the most widespread > OS implementations) show that you're using OTR, but that the remote peer > is unauthenticated. once a strong authentication step is done, the UI > indicates "authenticated". MUST NOT language seems like it could be > read to prohibit this change. yes, but when in the "OTR in use case", the remote user gets no additional privileges. (In fact, in the authenticated case, they also get nothing more, but that's besides the point) -- ] 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 [ From nobody Wed Jul 2 15:31: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 445E31A0300 for ; Wed, 2 Jul 2014 15:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC7QVZ4WsgbX for ; Wed, 2 Jul 2014 15:30:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5BA1A02E9 for ; Wed, 2 Jul 2014 15:30:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BCAEE2002C; Wed, 2 Jul 2014 18:31:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D5C763B0E; Wed, 2 Jul 2014 18:30:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68CF663B09; Wed, 2 Jul 2014 18:30:58 -0400 (EDT) From: Michael Richardson To: Kathleen Moriarty In-Reply-To: References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C71857FE44A8@USMBX1.msg.corp.akamai.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/Pv59RGtuQ6Oi1S75_kcbdDRJhpQ Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:31:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kathleen Moriarty wrote: > On Wed, Jul 2, 2014 at 10:45 AM, Salz, Rich wrote: > =E2=9E=A2 =E2=80=9COpportunistic security=E2=80=9D is an umbrella ter= m that encompasses protocol > (and infrastructure?) mecha=E2=80=A6. > +1, I think I do prefer this definition as well, I'm just not sure on= the > infrastructure part. =C2=A0We all know it's easier to attack infrastr= ucture, so it's > really important to protect it. =C2=A0My question here is to figure o= ut if > we think I think you jumped on the word "infrastructure" and starting thinking integrity of BGP and DNS and the like. In the original context, it's simply that the opportunistic system MAY require some supporting actors ("infrastructure") for it to work, such as D= NS or TLSA or DNSSEC or ... and that those components need to be understood as being part of that system. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7SIIoCLcPvd0N1lAQLuXwf/TJhfSngGg80h7BHkMxo5OAQFLTT94vAr 23iBFAzWCT0mX9xZDCn67FvZSIKcRH0Y1NoDMyeYnMRQggh2gTihRW4AOgL/PpDW Aj8z1COJhMTyOGVNsg+4Ygb8XSrNd11FOnpWLO3TuqDoFPq+WSQNQ3z/9vGSl1GG RHT/ZHk8triaWY7CaOH3wBPVOFXPxwDPKgHQQd8CAz2o1YPAbzjEVQERGY0kHZXs ylzqVCXP6e6D3x/yBzaz7gyBJJ26un5oUlCSiHTJKA2tGubXuOWCGnYY7H+gCtIN KlFD2P1ZwNCq4VbaEAG0K6L5H+Gwn1YDhLWnNC7/1D/pwI/DIp+pJg== =YUh9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 2 15:31: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 3B6161A08EC for ; Wed, 2 Jul 2014 15:31:38 -0700 (PDT) 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 PtQ4Np3Kbim5 for ; Wed, 2 Jul 2014 15:31:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AD51A0769 for ; Wed, 2 Jul 2014 15:31:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E28E2AB2A1; Wed, 2 Jul 2014 22:31:36 +0000 (UTC) Date: Wed, 2 Jul 2014 22:31:36 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140702223135.GB12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27060.1404340087@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nRniKG1TXf1TRzSTDR8XZog_Ajw Subject: Re: [saag] opportunistic security again 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, 02 Jul 2014 22:31:38 -0000 On Wed, Jul 02, 2014 at 06:28:07PM -0400, Michael Richardson wrote: > If it's opportunistic security, then it didn't use strong authentication, Sorry, that is not the case. Please read the draft. Rather, OS might not use strong authentication with some peers, but some other peers may be strongly authenticated (e.g. opportunistic DANE TLS, for those peers that publish usable TLSA records). -- Viktor. From nobody Wed Jul 2 15:33: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 B00421A0A95 for ; Wed, 2 Jul 2014 15:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd_1kNiF4lOw for ; Wed, 2 Jul 2014 15:32:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 571191A04A3 for ; Wed, 2 Jul 2014 15:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 470EEBE17; Wed, 2 Jul 2014 23:32:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8vqrQ0WxoVB; Wed, 2 Jul 2014 23:32:48 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.120]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0415CBE14; Wed, 2 Jul 2014 23:32:48 +0100 (IST) Message-ID: <53B4888F.50201@cs.tcd.ie> Date: Wed, 02 Jul 2014 23:32:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , Daniel Kahn Gillmor References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> In-Reply-To: <27060.1404340087@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/3CaSyJODEBNVSWBJwzD-QL0vY6c Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:32:56 -0000 Michael, On 02/07/14 23:28, Michael Richardson wrote: > then it is no longer opportunistic; That "it" is ambiguous. The putative protocol in question still does support OS, but in that particular run of that deployment, it may be authenticating one or more endpoints. I don't think its really useful to talk about the latter as if its not OS. I think we'd be better off talking about such cases as being more than OS. S. From nobody Wed Jul 2 15: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 EED3D1B2818 for ; Wed, 2 Jul 2014 15:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 zhvlK1g_LhJK for ; Wed, 2 Jul 2014 15:36:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0867D1A0AB8 for ; Wed, 2 Jul 2014 15:36:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A91520028; Wed, 2 Jul 2014 18:36:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 55FED63B0E; Wed, 2 Jul 2014 18:36:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 402F663B09; Wed, 2 Jul 2014 18:36:20 -0400 (EDT) From: Michael Richardson To: Paul Wouters In-Reply-To: <53B432EE.4010408@redhat.com> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <53B432EE.4010408@redhat.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/VF_PBGzfNHQnNe_ywhxu9-njSJQ Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:36:22 -0000 --=-=-= Paul Wouters wrote: >> "Opportunistic security" is an umbrella term that encompasses protocol >>(and infrastructure?) mechanisms that remove barriers to the widespread >>use of encryption >> in the Internet. Protocols that exhibit opportunistic security MUST >>attempt to effect encryption of traffic, but SHALL fall back to >>plaintext transmission if a >> peer does not appear to support the required functionality. > No this is wrong. If someone publishes a DANE or IPSECKEY record, and a > client can validate that using DNSSEC, it MUST NOT fallback to > plaintext. RFC4332 says that is a local policy (speaking for IPSECKEY/TXT). You might want to say such a thing for a new IPSECKEY based IPSEC OE protocol; but as far as I have read, nothing is said. As for DANE and TLSA; I don't think that presences of a DNSSEC signed key forces the browser to use HTTPS over HTTP. There are other mechanisms to say that, but my IETF-specification-brain-cache is coming up empty right now. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7SJY4CLcPvd0N1lAQKrVAf7BsIDWd6LT11ywoj6PijUyYpzA7Qk/L9/ 9sxS/eLrLnstMclXz1IAGCzijE8KUs40Upu9fQ8UmnFr19GBGy98115tTzk4Bv0q MrNHP2id1MQw002579NQUxAGH7FusdiAfTpg8m4+JmPvN8J9tiDcemw5TIoTg1GU p2kc0MyAA+P/EH7ovLmD7JnnY6Xmd9A41dV6DUv/gUl6tfUz/Z0M8UcB14T6lHpe IYnWZY4ExzPEjDoccHaWP2UQtkubIHlt9frpI2ei8ETzTWr+aNh0zpYBoDMqHfts F1Ue1VJIp9qu1IRtC/Y/Oj6rcQduw/9g0KLdLsZKFdr1pQ+SqoUB4g== =O8LH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 2 15:53: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 6B87F1A0463 for ; Wed, 2 Jul 2014 15:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_POSSIBLE=2.697, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuIXCz3wf_gc for ; Wed, 2 Jul 2014 15:53:38 -0700 (PDT) Received: from mip.polyamory.org (mip.polyamory.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9621A041C for ; Wed, 2 Jul 2014 15:53:38 -0700 (PDT) Received: by mip.polyamory.org (Postfix, from userid 1002) id 4ED6810760; Wed, 2 Jul 2014 18:53:34 -0400 (EDT) Date: Wed, 2 Jul 2014 18:53:34 -0400 From: Ofer Inbar To: Joe Touch Message-ID: <20140702225334.GQ371@mip.aaaaa.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B44F2E.5030200@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B44F2E.5030200@isi.edu> User-Agent: Mutt/1.4.2.3i Organization: American Association Against Acronym Abuse Archived-At: http://mailarchive.ietf.org/arch/msg/saag/q-vJknBKFxwh64gYyJsQYKZKyNg Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 22:53:39 -0000 Joe Touch wrote: > OS is the combination of protocol mechanisms and infrastructure that > applies the strongest security possible (including "none") to a given > use at the time invoked while still supporting communication. > Communication security systems have traditionally focused on ensuring > some set of particular protections, even if those guarantees prohibit > communication in some cases. OS establishes communication as the sole > fixed requirement; all other aspects of protection are optimized to > increase security, but never at the expense of allowing communication to > proceed. I wonder if we have two different ideas of the goal of opportunistic security in different people's minds. My earlier impression was that one of the key problems OS intends to solve is the very common case where cleartext communication ends up happening now even though some form of unauthenticated encryption would be possible. However, this version of the definition seems to neglect or even contradict that. In other words, the main point is less "get the best security you can but allow communication regardless, even if it's cleartext". The main point is more "don't let the perfect be the enemy of the good - allow encryption if you can, even if it's not authenticated or otherwise ideal; some encryption, if posssible, is better than cleartext." Both of the above ideas seem to me goals of opportunistic security, but I think the latter is the more important one (since the former is something we already mostly do on the Internet), while I think this definition focuses on the former and leaves out the latter. -- Cos From nobody Wed Jul 2 16:08: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 DDCB01A0AAA for ; Wed, 2 Jul 2014 16:08:03 -0700 (PDT) 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 lGOMjFMSlDjZ for ; Wed, 2 Jul 2014 16:08:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BC41A0AAE for ; Wed, 2 Jul 2014 16:08:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8DE7D2AAD93; Wed, 2 Jul 2014 23:08:00 +0000 (UTC) Date: Wed, 2 Jul 2014 23:08:00 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140702230800.GC12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B4888F.50201@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7fby5Ks-Z-peURolqIxLkU8t-9k Subject: Re: [saag] opportunistic security again 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, 02 Jul 2014 23:08:04 -0000 On Wed, Jul 02, 2014 at 11:32:47PM +0100, Stephen Farrell wrote: > I don't think its really useful to talk about the latter > as if its not OS. I think we'd be better off talking about > such cases as being more than OS. It is important to not put an artificial ceiling on the effective security that can be achieved with OS. OS sets a low floor and works up from there on a peer-by-peer basis. Therefore, strongly authenticated connections are still OS (not "stonger than" OS) provided the use of strong authentication is itself opportunistic (e.g. conditioned on securely advertised peer capabilities, e.g. via DANE). It should also be noted that whether DANE authentication, for example, is opportunistic or static security policy is application and configuration dependent. With SMTP, where transport security has been opportunistic for a couple of decades, DANE authenticated TLS is also opportunistic. The presence of TLSA records need not imply a mandate to encrypt for every application protocol, but it is a strong signal of peer TLS support, and OS application protocol standards that support DANE ought to consider requiring TLS when relevant usable TLSA records are available. The above is I think too specific for the draft, the goal is to define broadly applicable principles. If the draft is not sufficiently clear on the goal of not capping OS at unauthenticated encryption, that text may need to be amplified. My hope is that a careful reading of the existing text makes the point clear. -- Viktor. From nobody Wed Jul 2 16:11: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 74FAA1B292D for ; Wed, 2 Jul 2014 16:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_TfTQEgsgDt for ; Wed, 2 Jul 2014 16:11:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A08D91A0ABF for ; Wed, 2 Jul 2014 16:11:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F18CBE14 for ; Thu, 3 Jul 2014 00:11:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvFEjawlBvLx for ; Thu, 3 Jul 2014 00:11:44 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.120]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07347BE12 for ; Thu, 3 Jul 2014 00:11:44 +0100 (IST) Message-ID: <53B491AF.5090202@cs.tcd.ie> Date: Thu, 03 Jul 2014 00:11:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> In-Reply-To: <20140702230800.GC12456@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/Nm5bGNL-jLQYGJQQVac7emM2NIY Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 23:11:48 -0000 On 03/07/14 00:08, Viktor Dukhovni wrote: >> > I don't think its really useful to talk about the latter >> > as if its not OS. I think we'd be better off talking about >> > such cases as being more than OS. > It is important to not put an artificial ceiling on the effective > security that can be achieved with OS. OS sets a low floor and > works up from there on a peer-by-peer basis. Therefore, strongly > authenticated connections are still OS (not "stonger than" OS) Fair point. As we're seeing again, its not simple to get that clear and correct. S. From nobody Wed Jul 2 16:12: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 EE3541A0ABF for ; Wed, 2 Jul 2014 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_POSSIBLE=2.697, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBqdJahvoqMV for ; Wed, 2 Jul 2014 16:11:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266BB1A0AAA for ; Wed, 2 Jul 2014 16:11:39 -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 s62NAgio017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 16:10:42 -0700 (PDT) Message-ID: <53B49172.9070702@isi.edu> Date: Wed, 02 Jul 2014 16:10:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ofer Inbar References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B44F2E.5030200@isi.edu> <20140702225334.GQ371@mip.aaaaa.org> In-Reply-To: <20140702225334.GQ371@mip.aaaaa.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/51UD9xwSZXyCn6qy0cEOS9CHD9M Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 02 Jul 2014 23:11:52 -0000 On 7/2/2014 3:53 PM, Ofer Inbar wrote: > Joe Touch wrote: >> OS is the combination of protocol mechanisms and infrastructure that >> applies the strongest security possible (including "none") to a given >> use at the time invoked while still supporting communication. >> Communication security systems have traditionally focused on ensuring >> some set of particular protections, even if those guarantees prohibit >> communication in some cases. OS establishes communication as the sole >> fixed requirement; all other aspects of protection are optimized to >> increase security, but never at the expense of allowing communication to >> proceed. > > I wonder if we have two different ideas of the goal of opportunistic > security in different people's minds. My earlier impression was that > one of the key problems OS intends to solve is the very common case > where cleartext communication ends up happening now even though some > form of unauthenticated encryption would be possible. However, this > version of the definition seems to neglect or even contradict that. I don't see how... > In other words, the main point is less "get the best security you can > but allow communication regardless, even if it's cleartext". Yes. > The main > point is more "don't let the perfect be the enemy of the good - allow > encryption if you can, even if it's not authenticated or otherwise > ideal; some encryption, if posssible, is better than cleartext." In that case, the best protection you can get is "some encryption", which is what you'd get. I.e., that's 100% consistent with the definition I provided. > Both of the above ideas seem to me goals of opportunistic security, > but I think the latter is the more important one (since the former > is something we already mostly do on the Internet), while I think > this definition focuses on the former and leaves out the latter. I don't see the difference. Joe From nobody Wed Jul 2 16:13: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 E8FE81A0ABF for ; Wed, 2 Jul 2014 16:13:19 -0700 (PDT) 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 lTR_5vVihKz5 for ; Wed, 2 Jul 2014 16:13:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA971A0ABA for ; Wed, 2 Jul 2014 16:13:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A8D682AAD93; Wed, 2 Jul 2014 23:13:17 +0000 (UTC) Date: Wed, 2 Jul 2014 23:13:17 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140702231317.GD12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B44F2E.5030200@isi.edu> <20140702225334.GQ371@mip.aaaaa.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140702225334.GQ371@mip.aaaaa.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Yb2yYWCqnx68c8Oq2pV_vPmYcoY Subject: Re: [saag] opportunistic security again 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, 02 Jul 2014 23:13:20 -0000 On Wed, Jul 02, 2014 at 06:53:34PM -0400, Ofer Inbar wrote: > Both of the above ideas seem to me goals of opportunistic security, > but I think the latter is the more important one (since the former > is something we already mostly do on the Internet), while I think > this definition focuses on the former and leaves out the latter. The design principles in section 2 of the draft are ordered with care. The first principle covers "both" halves of the suggested glass half-full, glass half-empty dichotomy. Interoperate to maximize deployment: The primary goal of designs that feature opportunistic security is to be able to communicate with any reasonably configured peer. If many peers are only capable of cleartext, then it is acceptable to fall back to cleartext when encryption is not possible. If authentication is only possible for some peers, then it is acceptable to authenticate only those peers and not the rest. Interoperability must be possible without bilateral coordination. Applications employing opportunistic security need to be deployable at Internet scale, with each peer independently configured to meet its own security needs (within the practical bounds of the application protocol). Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured. -- Viktor. From nobody Wed Jul 2 17:07: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 5CBDD1A0769 for ; Wed, 2 Jul 2014 17:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_POSSIBLE=2.697] 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 kezk0sdPYQKe for ; Wed, 2 Jul 2014 17:07:25 -0700 (PDT) Received: from mip.polyamory.org (mip.aaaaa.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id 57EFE1A0646 for ; Wed, 2 Jul 2014 17:07:25 -0700 (PDT) Received: by mip.polyamory.org (Postfix, from userid 1002) id 7316210760; Wed, 2 Jul 2014 20:07:21 -0400 (EDT) Date: Wed, 2 Jul 2014 20:07:21 -0400 From: Ofer Inbar To: Joe Touch Message-ID: <20140703000721.GR371@mip.aaaaa.org> References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B44F2E.5030200@isi.edu> <20140702225334.GQ371@mip.aaaaa.org> <53B49172.9070702@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B49172.9070702@isi.edu> User-Agent: Mutt/1.4.2.3i Organization: American Association Against Acronym Abuse Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FIrC-e5mUV4K2TMXev5cLx1Zlps Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 00:07:26 -0000 Joe Touch wrote: > >In other words, the main point is less "get the best security you can > >but allow communication regardless, even if it's cleartext". > > Yes. > > > The main > >point is more "don't let the perfect be the enemy of the good - allow > >encryption if you can, even if it's not authenticated or otherwise > >ideal; some encryption, if posssible, is better than cleartext." > > In that case, the best protection you can get is "some encryption", > which is what you'd get. I.e., that's 100% consistent with the > definition I provided. Okay, it sounds like we're not dealing with two different views of what OS is about. You agree with the view I described, so we're consistent on that. Goal A: Encrypt when possible, but don't let that prevent communication. If the choice is between cleartext vs. don't communicate, choose cleartext, but if encryption is possible, use it. Goal B: Some encryption is better than none, and encryption without authentication is better than cleartext without auth. Do the best you can, but avoid setting a high minimum standard such that you fall back to cleartext when that high standard cannot be met, even though some encryption would be possible. These are overlapping goals, or overlapping pieces of the overall goal. IMO Goal B is the bigger piece. Here's the definition I quoted: > >Joe Touch wrote: > >>OS is the combination of protocol mechanisms and infrastructure that > >>applies the strongest security possible (including "none") to a given > >>use at the time invoked while still supporting communication. > >>Communication security systems have traditionally focused on ensuring > >>some set of particular protections, even if those guarantees prohibit > >>communication in some cases. OS establishes communication as the sole > >>fixed requirement; all other aspects of protection are optimized to > >>increase security, but never at the expense of allowing communication to > >>proceed. This definition repeatedly calls out and emphasizes Goal A: "while still supporting communication." "Communication security systems have traditionally focused on ensuring some set of particular protections, even if those guarantees prohibit communication in some cases." "never at the expense of allowing communication to proceed." This definition never explicitly invokes Goal B. It never alludes to the fact that a lot of communications today falls back to cleartext because a higher standard of security cannot be met, even though some better-than-cleartext security is possible. In other words, that this does *not* come "at the expense of allowing communication to proceed," it comes at the expense of not encrypting where that could be done. This definition never directly emphasizes the situation where we have a choice between better security or some security and it's important to choose some security rather than none in such cases. It's implied by "applies the strongest security possible" and "are optimized to increase security," but both of those are relatively vague and only indirectly invoke Goal B. Someone unfamiliar with the context could easily be forgiven for reading this definition and coming away with only Goal A in mind. -- Cos From nobody Wed Jul 2 17:23: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 AD1601A0AC7 for ; Wed, 2 Jul 2014 17:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_POSSIBLE=2.697, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTUT9uah7mMX for ; Wed, 2 Jul 2014 17:22:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CBA1A0ABD for ; Wed, 2 Jul 2014 17:22:57 -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 s630MAHl003740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Jul 2014 17:22:10 -0700 (PDT) Message-ID: <53B4A232.20500@isi.edu> Date: Wed, 02 Jul 2014 17:22:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ofer Inbar References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B44F2E.5030200@isi.edu> <20140702225334.GQ371@mip.aaaaa.org> <53B49172.9070702@isi.edu> <20140703000721.GR371@mip.aaaaa.org> In-Reply-To: <20140703000721.GR371@mip.aaaaa.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/oT3O8TaXUwVf3lHCilzGXH-KI0M Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 00:22:59 -0000 On 7/2/2014 5:07 PM, Ofer Inbar wrote: > Joe Touch wrote: >>> In other words, the main point is less "get the best security you can >>> but allow communication regardless, even if it's cleartext". >> >> Yes. >> >>> The main >>> point is more "don't let the perfect be the enemy of the good - allow >>> encryption if you can, even if it's not authenticated or otherwise >>> ideal; some encryption, if posssible, is better than cleartext." >> >> In that case, the best protection you can get is "some encryption", >> which is what you'd get. I.e., that's 100% consistent with the >> definition I provided. > > Okay, it sounds like we're not dealing with two different views of > what OS is about. You agree with the view I described, so we're > consistent on that. > > Goal A: Encrypt when possible, but don't let that prevent > communication. If the choice is between cleartext vs. don't > communicate, choose cleartext, but if encryption is possible, > use it. Goal A ignores "do the best you can". It just says "encrypt when possible". There's a spectrum of what's possible - including plaintext. The goal is really to do the best you can with security without ever saying "I can't do X, so I won't do anything". > Goal B: Some encryption is better than none, and encryption without > authentication is better than cleartext without auth. Do the best > you can, I would stop right there. > but avoid setting a high minimum standard such that you fall > back to cleartext when that high standard cannot be met, even though > some encryption would be possible. Right - the point of OS is to prioritize as follows (lower number is higher priority): 1. communicate! 2. protect a little 3. protect more... N. protect the most You're supposed to go down the list until you can't satisfy the next item, then back up to the one you can. I.e., you never trade security for communication. > These are overlapping goals, or overlapping pieces of the overall > goal. IMO Goal B is the bigger piece. The first part of B is all you need. > Here's the definition I quoted: > >>> Joe Touch wrote: >>>> OS is the combination of protocol mechanisms and infrastructure that >>>> applies the strongest security possible (including "none") to a given >>>> use at the time invoked while still supporting communication. "strongest possible" + "while still supporting communication" is the same as the first part of B above. I don't think the rest of B is needed. >>>> Communication security systems have traditionally focused on ensuring >>>> some set of particular protections, even if those guarantees prohibit >>>> communication in some cases. OS establishes communication as the sole >>>> fixed requirement; all other aspects of protection are optimized to >>>> increase security, but never at the expense of allowing communication to >>>> proceed. > > This definition repeatedly calls out and emphasizes Goal A: > > "while still supporting communication." A ignores: - "strongest possible" (in my core definition) - "optimized to increase security" (in the further discussion) So I see the description I gave as supporting the first part of B. > "Communication security systems have traditionally focused on ensuring > some set of particular protections, even if those guarantees prohibit > communication in some cases." > > "never at the expense of allowing communication to proceed." > > This definition never explicitly invokes Goal B. The "Communication security" sentence doesn't, but it's a counterexample. The other two sentences do, as noted above. > It never alludes to > the fact that a lot of communications today falls back to cleartext But it doesn't really; when configured to use security, it falls back to "don't communicate". > because a higher standard of security cannot be met, even though some > better-than-cleartext security is possible. True, but I think I already addressed this. > In other words, that this > does *not* come "at the expense of allowing communication to proceed," > it comes at the expense of not encrypting where that could be done. It really does; IPsec doesn't backoff to cleartext. Email configured to use SSL doesn't backoff either. The only stuff that backsoff to cleartext (STARTTLS that fails) is doing so because there is no other level of security that the software supports. That's consistent with OE, though. > This definition never directly emphasizes the situation where we have > a choice between better security or some security and it's important I think it does, but if we need an additional sentence to make that more explicit, that's fine too.... Joe > to choose some security rather than none in such cases. It's implied > by "applies the strongest security possible" and "are optimized to > increase security," but both of those are relatively vague and only > indirectly invoke Goal B. Someone unfamiliar with the context could > easily be forgiven for reading this definition and coming away with > only Goal A in mind. > -- Cos > From nobody Thu Jul 3 02:00: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 5E3761B27C7 for ; Thu, 3 Jul 2014 02:00:07 -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 5Q54RNYlRCjo for ; Thu, 3 Jul 2014 02:00:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308A71B27B6 for ; Thu, 3 Jul 2014 02:00:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 26D606D669; Thu, 3 Jul 2014 04:59:59 -0400 (EDT) Message-ID: <53B51B8D.3080308@iang.org> Date: Thu, 03 Jul 2014 09:59:57 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <1365DFD8-B575-4032-B948-5DB1E39AA596@vpnc.org> <53B4402E.4090008@bbn.com> In-Reply-To: <53B4402E.4090008@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/S0-gAyPxUCFK7dxSg5qrp7omtDI Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 09:00:07 -0000 On 2/07/2014 18:23 pm, Stephen Kent wrote: > >> I agree with Joe that Viktor's draft is a better starting point than >> Steve's. As for incorporating Steve's history: please don't. any reference to this latter history? iang From nobody Thu Jul 3 04:17: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 75EE61B288E for ; Thu, 3 Jul 2014 04:17:30 -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 Kq9ZMy4hjN-M for ; Thu, 3 Jul 2014 04:17:29 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961131B2883 for ; Thu, 3 Jul 2014 04:17:28 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 678FF6D65F; Thu, 3 Jul 2014 07:17:23 -0400 (EDT) Message-ID: <53B53BC2.2050209@iang.org> Date: Thu, 03 Jul 2014 12:17:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> In-Reply-To: <53B43286.6090004@fifthhorseman.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/SeCnYA9qBIGsMQp92PrCjYK3eMU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 11:17:30 -0000 On 2/07/2014 17:25 pm, Daniel Kahn Gillmor wrote: > On 07/02/2014 11:11 AM, Michael Richardson wrote: >> Is it worth also saying: >> "While opportunistic security protocols MAY authenticate end points, the >> underlying trust of the end points MUST NOT be enhanced by this activity" > > I think "underlying trust" is a term that's likely to sow more confusion > than it resolves. Agreed. > I think you're referring to one peer's confidence > about the identity of the other peer, or confidence in the > confidentiality or integrity properties of the channel; all of these are > substantially different from how much one peer "trusts" the other. Right. Any use of the word 'trust' at a protocol level is likely to be a chimera, because (a) trust is a human thing, not a protocol agent concept, and (b) there is widespread use of the term in a deceptive fashion at the human layer. > I'm also not convinced that we want anyone employing opportunistic > security to actively *prohibit* user indicators in cases where strong > authentication is actually used. If we want a family of protocols that can range inclusively *and* transparently from cleartext to unauthenticated encryption to authenticated encryption, it seems a leap too far to also specify anything firm about user indicators. iang From nobody Thu Jul 3 04:30: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 AB1491B28A5 for ; Thu, 3 Jul 2014 04:30:14 -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 BGrLtnGimFor for ; Thu, 3 Jul 2014 04:30:13 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D531B28A4 for ; Thu, 3 Jul 2014 04:30:13 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id E35946D66D; Thu, 3 Jul 2014 07:30:12 -0400 (EDT) Message-ID: <53B53EC3.7030506@iang.org> Date: Thu, 03 Jul 2014 12:30:11 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> In-Reply-To: <53B44906.5090408@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/cvmJQCZd1is1caQYPKu-PWVsssc Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 11:30:14 -0000 On 2/07/2014 19:01 pm, Stephen Kent wrote: > Joe, >> >> How's this? (admittedly a bit terse, but it might be a starting point): >> >> OS is the combination of a protocol mechanisms and infrastructure >> approaches that determines and applies the best security possible for >> each given use rather than requiring any specific protection as a >> prerequisite. > The refernce to "best" is worrisome. That is the point; 'Best' by definition is subjective. We are in the world of compromise, and how design A delivers in contrast to design B will not be immediately clear nor should be specified overly in advance. If we wanted an objective term we would add it, but it's now a more precise protocol. E.g., in foot races, a personal best time is one clarity suitable for short races, whereas the marathon is more about getting to the end than the speed. For browsing wikipedia we'd prefer anon encryption, and for bitcoin we want authenticated publication, neither is better until we see more about the context. iang From nobody Thu Jul 3 07:24: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 17A021B2A6E for ; Thu, 3 Jul 2014 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYhRNDSPPX5B for ; Thu, 3 Jul 2014 07:24:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A2E1B2A32 for ; Thu, 3 Jul 2014 07:24:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DA50A20028; Thu, 3 Jul 2014 10:24:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7CED563B0E; Thu, 3 Jul 2014 10:24:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6CC3063B0A; Thu, 3 Jul 2014 10:24:06 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53B4888F.50201@cs.tcd.ie> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@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/VPBYiSSBuKCfNCvEExNoV21ENHE Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 14:24:09 -0000 Stephen Farrell wrote: > On 02/07/14 23:28, Michael Richardson wrote: >> then it is no longer opportunistic; > That "it" is ambiguous. The putative protocol in question > still does support OS, but in that particular run of that > deployment, it may be authenticating one or more endpoints. > I don't think its really useful to talk about the latter > as if its not OS. I think we'd be better off talking about > such cases as being more than OS. I agree that perhaps "it" is ambiguous. Of course TLS can be used in many different configurations, and the same port and application can support many different instances using different options. -- ] 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 [ From nobody Thu Jul 3 07:45: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 77B7E1B29D7 for ; Thu, 3 Jul 2014 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 3C5QJbn0FFKQ for ; Thu, 3 Jul 2014 07:45:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229831B29D8 for ; Thu, 3 Jul 2014 07:45:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF9402002B for ; Thu, 3 Jul 2014 10:46:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 51D0F63B0E; Thu, 3 Jul 2014 10:45:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 382C463B0A for ; Thu, 3 Jul 2014 10:45:38 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <20140702223135.GB12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <20140702223135.GB12456@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/h1IN1jbjSLcqi5_vkVNszb4UjRc Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 14:45:40 -0000 --=-=-= Viktor Dukhovni wrote: >> If it's opportunistic security, then it didn't use strong >>authentication, > Sorry, that is not the case. Please read the draft. Rather, OS > might not use strong authentication with some peers, but some other > peers may be strongly authenticated (e.g. opportunistic DANE TLS, > for those peers that publish usable TLSA records). I think you are trying to say that opportunistically using TLS because the client saw a TLSA record secured by DNSSEC is Strong Security. I reread draft-dukhovni-opportunistic-security-00. It says: No misrepresentation of security: Unauthenticated communication or use of authentication that is vulnerable to MiTM attacks is not represented as strong security. Where strong security is required, opportunistic security is not a substitute, though the underlying mechanisms may in some cases be very similar. I have more written, but decided it would be best to stop here for now. I am happy with the draft, btw. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7Vsj4CLcPvd0N1lAQJCQwgAoRHYfpHnddeV2jn95sl2QYMS0BdOB6yb vDRko5LA5Mby/zkzn5zqElboG9yzv3lAkiVkGYl+OQFaPhSSH9/7GRgKmsUMFvki IyRz7dePbYWvP+NiPhU+OuCPDULQzz+DIBRurmBgo5uNYzvNeL1l1S1ptlXobnxg L4Zrxgh70hoDJ/KhzdYfBXpZMo8oLOeLaYC8daSkAV0kTxSd50edvsL0aPdY5EF1 s4juPLo3kIU1maJv3A6oz+1D9iCbPn9pOwTN8W2J0eNr343/0ahz8knyZ9ixRe+e Qqs8UMBHQJwkwSvHIMtoop1IowdwCZgUGQNclmujKOY/u+Td2q774w== =J9c6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 3 07:52:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC3B1A0103 for ; Thu, 3 Jul 2014 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 5Gk6eDH8nycG for ; Thu, 3 Jul 2014 07:52:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E24B1A00F8 for ; Thu, 3 Jul 2014 07:52:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DF6D2002B for ; Thu, 3 Jul 2014 10:53:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2276763B0E; Thu, 3 Jul 2014 10:52:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0B8F163B0A for ; Thu, 3 Jul 2014 10:52:27 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <20140702230800.GC12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@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/rWrcIHwWJidQtglVLiBV_OUGwN8 Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 14:52:29 -0000 --=-=-= Viktor Dukhovni wrote: > On Wed, Jul 02, 2014 at 11:32:47PM +0100, Stephen Farrell wrote: >> I don't think its really useful to talk about the latter >> as if its not OS. I think we'd be better off talking about >> such cases as being more than OS. > It is important to not put an artificial ceiling on the effective > security that can be achieved with OS. OS sets a low floor and > works up from there on a peer-by-peer basis. Therefore, strongly > authenticated connections are still OS (not "stonger than" OS) > provided the use of strong authentication is itself opportunistic > (e.g. conditioned on securely advertised peer capabilities, e.g. > via DANE). Okay, so we now have a term we can use "OS". Now, I think that we need to replace the words "strongly authenticated" above with something else, as those words are too confusing in this context. I don't think that the MiTM resistant form of OS process you describe should be called 'strongly authenticated', because that then confuses situations where the security was mandated and/or established by chain to a locally trusted anchor. (please remember that I'm a PK*I* hater when I wrote this) I think that the draft should define the term strongly authenticated as something that is not what you describe, but we need a new term for what you are describing. I'm okay with "authenticated OS" or "OAS"... > The presence of TLSA records need not imply a mandate to encrypt > for every application protocol, but it is a strong signal of peer > TLS support, and OS application protocol standards that support > DANE ought to consider requiring TLS when relevant usable TLSA > records are available. Right; if I intercept the SMTP connection and remove the STARTTLS option from the EHLO, the connection probably won't go dark even if the TLSA is there. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7VuKICLcPvd0N1lAQLLQQf+LnNvRYTFYxrxhhLTl5x5cBjIJ0ZETqFd m+q577U48e13tdiPZca7PTBtZebjujpSzxkbDtpQww8cs2g3qMb5cAXndoAUgwRM M80hm/yLdENGf//DTn8xwhylGFYQuwZEeBZNMmQq+OoCP9LD8NORogvTdXtAIE9A UkeRWusenNK0LyIOR1GqS4L5MQopXTzR82QV/V1KAzyojeb6ONCXkTmxgqzKdUsl UQI4lyZssJ/P3zCzqbR2RcImSAp6igglz4QEXmHmReppjXG62RYT7NUITyvjsjKo nCkOjuXjeXqOvaUWSsJ4TjuPH0vO5UZ0HMLaNz3Rb5ti9Bur9HZXeA== =NMpB -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 3 08:04:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E3C1B2A22 for ; Thu, 3 Jul 2014 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avSMSebvg7lL for ; Thu, 3 Jul 2014 08:04:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1450E1B2AF8 for ; Thu, 3 Jul 2014 08:04:22 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49196) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2iYm-000A2n-Gd for saag@ietf.org; Thu, 03 Jul 2014 11:04:28 -0400 Message-ID: <53B570EF.5080502@bbn.com> Date: Thu, 03 Jul 2014 11:04:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B53EC3.7030506@iang.org> In-Reply-To: <53B53EC3.7030506@iang.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Rtj6y9gWPOfd03Q560yHTCIeMKo Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 15:04:37 -0000 Ian, > On 2/07/2014 19:01 pm, Stephen Kent wrote: >> Joe, >>> How's this? (admittedly a bit terse, but it might be a starting point): >>> >>> OS is the combination of a protocol mechanisms and infrastructure >>> approaches that determines and applies the best security possible for >>> each given use rather than requiring any specific protection as a >>> prerequisite. >> The refernce to "best" is worrisome. > > That is the point; 'Best' by definition is subjective. Using subjective terms in a standard is rarely a good idea. It means that different readers may interpret the terms differently, and that is not good. Steve From nobody Thu Jul 3 08:23: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 21A6D1A02C1 for ; Thu, 3 Jul 2014 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8RGEW7xl9r5 for ; Thu, 3 Jul 2014 08:23:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F211E1A02F6 for ; Thu, 3 Jul 2014 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=734; q=dns/txt; s=iport; t=1404401013; x=1405610613; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jcPP17cyqwUEtETaKODXRHFkhv0PtXCaljU1YGdueqg=; b=InSFNfMVDN9q6Zjf6b8raVACNsOEEVc66JTG7UVmRPEpUIk1vPvl2+es Ai1xX7CVbuKR/NVdsS736mWpsnavQbDwVvN3alOL2U28zhGdVmTfnTrWj I4W9qhFz0urOme85mxnUtlqbfpDuofa2ldq/C18jmETy4/e8sVLZkmTAm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAK90tVOtJV2Q/2dsb2JhbABagw2EG6hNAQIBAQEFAW4BmWYBgQoWdYQEAQEEI1UBEAsODAIFFgsCAgkDAgECAUUGAQwBBwEBiD6tSJtrF4EshESJMgeCd4FMAQSabYcOjHyDRTs X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="58101796" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 03 Jul 2014 15:23:32 +0000 Received: from [10.61.205.215] ([10.61.205.215]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s63FNVnj022212; Thu, 3 Jul 2014 15:23:31 GMT Message-ID: <53B57574.5080507@cisco.com> Date: Thu, 03 Jul 2014 17:23:32 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , Daniel Kahn Gillmor References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> In-Reply-To: <27060.1404340087@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Xi1urmxgbUMjNVAJMElRkBCe0ik Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 15:23:43 -0000 Michael, We may indeed be confusing ourselves. OTR does have an indicator and "what you get" is that lovely padlock indicating that the conversation is secure. We don't have to argue over definitions of what that is because the user surely won't read any conclusion we might come to. I took the original comment a slightly different way, however. Rather than prohibiting strongly authenticated end points, opportunistic security has the possibility to introduce additional downgrade attacks, and that is what must be guarded against. This is classically easy on the web since the URIs have been different. It could be more of a thing elsewhere, depending on what choices get xmitted in the clear. Eliot From nobody Thu Jul 3 08:26: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 64E781B2AF9 for ; Thu, 3 Jul 2014 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 c4nQwdqIzcO0 for ; Thu, 3 Jul 2014 08:26:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687F91B2AB8 for ; Thu, 3 Jul 2014 08:26:49 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s63FQlwU028776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 3 Jul 2014 11:26:48 -0400 Received: from bofh.nohats.ca (vpn-61-93.rdu2.redhat.com [10.10.61.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s63FQlKo012797 for ; Thu, 3 Jul 2014 11:26:47 -0400 Message-ID: <53B57636.4020208@redhat.com> Date: Thu, 03 Jul 2014 11:26:46 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B57574.5080507@cisco.com> In-Reply-To: <53B57574.5080507@cisco.com> 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.23 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nJ89s3zieDty1PklrNV6kvEmt8s Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 15:26:52 -0000 On 07/03/2014 11:23 AM, Eliot Lear wrote: > Michael, > > We may indeed be confusing ourselves. OTR does have an indicator and > "what you get" is that lovely padlock Ian Goldberg and team (myself included) have blocked any art attempt at using a _padlock_ anywhere in pidin-otr and libotr. Any padlocks used has been by third-party UI's against upstream recommendations. Padlocks are completely useless to describe non-binary states. Paul From nobody Thu Jul 3 08:27: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 6724C1B2AB0 for ; Thu, 3 Jul 2014 08:26: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 XSDtkZHuuCzp for ; Thu, 3 Jul 2014 08:26:52 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAD61B2AEC for ; Thu, 3 Jul 2014 08:26:52 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id DCB1A6D5FE; Thu, 3 Jul 2014 11:26:47 -0400 (EDT) Message-ID: <53B57636.1060804@iang.org> Date: Thu, 03 Jul 2014 16:26:46 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B53EC3.7030506@iang.org> <53B570EF.5080502@bbn.com> In-Reply-To: <53B570EF.5080502@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/0Oudf849VWINs_9uU7hvKFEiOzw Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 15:26:55 -0000 Hello Stephen, On 3/07/2014 16:04 pm, Stephen Kent wrote: > Ian, >> On 2/07/2014 19:01 pm, Stephen Kent wrote: >>> Joe, >>>> How's this? (admittedly a bit terse, but it might be a starting point): >>>> >>>> OS is the combination of a protocol mechanisms and infrastructure >>>> approaches that determines and applies the best security possible for >>>> each given use rather than requiring any specific protection as a >>>> prerequisite. >>> The refernce to "best" is worrisome. >> >> That is the point; 'Best' by definition is subjective. > Using subjective terms in a standard is rarely a good idea. It means > that different readers may interpret the terms differently, and that > is not good. When I read Victor's document [0], to paraphrase, I find that it is a memo to describe [1] opportunistic security, that which strives to deliver at least some protection most of the time, within constraints of broad interoperability and peer capabilities. If we took out subjectivity, we'd be left with section 3. I wouldn't term it a standard, more a guide (and memo sounds good). iang [0] Just to be clear; http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00 [1] with a nod to the current debate, I softened "define" in the original text. I think it would be quite an achievement to actually define opportunistic security. From nobody Thu Jul 3 08:30: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 90C741A0299 for ; Thu, 3 Jul 2014 08:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 689aR6iF5Qhe for ; Thu, 3 Jul 2014 08:30:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666D61A00F8 for ; Thu, 3 Jul 2014 08:30:30 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s63FUOK8024553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 3 Jul 2014 11:30:29 -0400 Received: from bofh.nohats.ca (vpn-61-93.rdu2.redhat.com [10.10.61.93]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s63FUO6p032625 for ; Thu, 3 Jul 2014 11:30:24 -0400 Message-ID: <53B57710.6080307@redhat.com> Date: Thu, 03 Jul 2014 11:30:24 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <12626.1404399147@sandelman.ca> In-Reply-To: <12626.1404399147@sandelman.ca> 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.26 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5tSsLtfICInxkkGLoGYAL2rSZvg Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 15:30:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/03/2014 10:52 AM, Michael Richardson wrote: >> The presence of TLSA records need not imply a mandate to encrypt for every application protocol, but it is a strong signal of peer TLS support, and OS >> application protocol standards that support DANE ought to consider requiring TLS when relevant usable TLSA records are available. > > Right; if I intercept the SMTP connection and remove the STARTTLS option from the EHLO, the connection probably won't go dark even if the TLSA is there. I fought about making the presence of a TLSA record mandate encryption. People got all upset about dictating local policy. Paul Hoffman tried twice to introduce a signaling record (HASTLS was one) to allow a server to specify some expectations. It went nowhere, and now individual DANE documents are specifying what to do themselves in this case. Of course, the only thing that makes sense is to hard fail. I believe DANE for SMTP does just that, so stripping out STARTTLS should not work to obtain plaintext email. Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJTtXcPAAoJEISzragz8T5uqPcH/RoW3mZy8F75xMHlXUlxsULq KcMw9PCr9F5479XmLWY9EqqaC17dsbs9EyNRSGIR63K7NNOCAQmsQ1F5cIgoijif 2iYyGceItl5E5OciD3lL6L+y3aQikQxh1XwbozGYrCRfvtMq9hcpQOd8OX6etS5d 8Kr6m9UlTUyk3Hux9BQ7Szmd59whOkpEWyXDlFZeRiMXHH2IjsnJk+In9z8MZXDo rMEjxl9L/+CmGhmIclPP0NriOebuSkCf1GEXJ//LJcmtL6bxaCI2qYrJtc/NrGel V2ZPTDDHjnJ8k0+adVWO3zAuCGbU/Pmk/bVZCeGU4KTANANTjCF37PkryqXA1GU= =8roN -----END PGP SIGNATURE----- From nobody Thu Jul 3 11:14: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 E47561B2981 for ; Thu, 3 Jul 2014 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Key-TnN1mSwy for ; Thu, 3 Jul 2014 11:14:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760351B294B for ; Thu, 3 Jul 2014 11:14:51 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49260) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2lXC-000BgD-SK for saag@ietf.org; Thu, 03 Jul 2014 14:15:02 -0400 Message-ID: <53B59D99.2020709@bbn.com> Date: Thu, 03 Jul 2014 14:14:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B43D15.1010001@isi.edu> <53B44168.8060804@bbn.com> <53B446B5.60303@isi.edu> <53B44906.5090408@bbn.com> <53B53EC3.7030506@iang.org> <53B570EF.5080502@bbn.com> <53B57636.1060804@iang.org> In-Reply-To: <53B57636.1060804@iang.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-LP8WcPDlF4ELDL4O_uQj3CS5UM Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 18:14:53 -0000 Ian, > Hello Stephen, > > On 3/07/2014 16:04 pm, Stephen Kent wrote: >> Ian, >>> On 2/07/2014 19:01 pm, Stephen Kent wrote: >>>> Joe, >>>>> How's this? (admittedly a bit terse, but it might be a starting point): >>>>> >>>>> OS is the combination of a protocol mechanisms and infrastructure >>>>> approaches that determines and applies the best security possible for >>>>> each given use rather than requiring any specific protection as a >>>>> prerequisite. >>>> The refernce to "best" is worrisome. >>> That is the point; 'Best' by definition is subjective. >> Using subjective terms in a standard is rarely a good idea. It means >> that different readers may interpret the terms differently, and that >> is not good. > When I read Victor's document [0], to paraphrase, I find that it is a > memo to describe [1] opportunistic security, that which strives to > deliver at least some protection most of the time, within constraints of > broad interoperability and peer capabilities. Until OS is widely available, "most of the time" it will deliver plaintext connections :-). > If we took out subjectivity, we'd be left with section 3. I wouldn't > term it a standard, more a guide (and memo sounds good). I defer to Stephen Farrell as to the target status for the document. If it is Informational, then I misspoke when noting the problems with subjective terms in standards. But, I still believe that subjective terms are not desirable for a doc that is intended to convey a clear characterization of a term. Guidance is useful, but clarify is paramount. If we can't be clear about what OS is, then we can still provide a list of mechanisms that are supportive of the concept that we're unable to define :-). Imposing a total order on the list introduces subjectivity, when then engenders a lot of text to explain the rationale used by the author to impose the ordering. Steve From nobody Thu Jul 3 11:26: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 0CDA31B2B3F for ; Thu, 3 Jul 2014 11:26:18 -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 lgWfChVWnLeR for ; Thu, 3 Jul 2014 11:26:16 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425EB1B2B1E for ; Thu, 3 Jul 2014 11:26:16 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 7DEF96D627; Thu, 3 Jul 2014 14:26:11 -0400 (EDT) Message-ID: <53B59BC6.7020507@iang.org> Date: Thu, 03 Jul 2014 19:07:02 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> In-Reply-To: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.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/2UXrWdugqddpp9-k1fu4a2uaZqI Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:26:18 -0000 On 27/06/2014 20:25 pm, Christian Huitema wrote: > Am I the only one who believes that the draft would be stronger if it also discussed the "pitfalls of agility?" You're not the only one, and I would go further. For the document to be useful, I think the document should describe what purpose, what it is, and *how it works*. From the intro: "cryptographic algorithms become weaker with time. ... Algorithm agility is achieved when a protocol can easily support more that one set of cryptographic algorithms. describes the first two, but I have trouble with the how; all discussions about how we actually switch from A to B tend to be short of a reasonable plan. Section 2.3 "Transition from Weak Algorithms" says: To facilitate transition, protocols MUST be able to advertise which algorithms are supported. This may naturally occur as part of an algorithm selection or negotiation mechanism. ... In any case, there come a point where one refuses to use the weak algorithm. This can happen on a flag day, or each installation can select a date on their own. So we've got + first party selection and/or second party negotiation. + flag days. This seems to be pretty weak in contrast to the criticisms levelled. Consider this statement: When selecting a suite of cryptographic algorithms, the strength of each algorithm MUST be considered. Yet, we know that most (or all) users are not capable of considering the strength of algorithms, and certainly not capable of balancing the strength of a suite. This is a job for experts. > The poster child for that is probably TLS. [good points snipped...] My first thought then is that we should not be allowing the swapping of algorithms; only suites should be swapped, because only suites can be balanced. (And, by extension, only complete suites.) Second point being, if we are recommending alternate suites, then there has to be a way for those above mentioned experts to then make a switch so. The first mechanism above (selection/negotiation) is something done by users or user software, and it fails to answer how a user would know. The second does speak: In any case, there come a point where one refuses to use the weak algorithm. This can happen on a flag day.... How is this day declared? I can imagine that if the WG declares that on a certain date suite A is deprecated, then that would work, at least for further discussion. But, I'd like to see that stated up front. I wonder if this is actually what IETF is set up to do, so I'd really like to see some views here. And, to repeat myself, if the document is suggesting that the users themselves decide, this is dangerous advice, not friendly at all. > There are counter arguments, e.g. national governments insisting that their communications be secured via homemade crypto. ... In this time of post-Snowden revelations, is the national government argument still relevant? iang From nobody Thu Jul 3 12:17: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 60D3B1B2A0B for ; Thu, 3 Jul 2014 12:17:32 -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 BGKgEVL_Qpvq for ; Thu, 3 Jul 2014 12:17:31 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57081B29DE for ; Thu, 3 Jul 2014 12:17:31 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so712488veb.14 for ; Thu, 03 Jul 2014 12:17:30 -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=MWNi2XHFvPb54pi9dWXhzKrsUC9FMDNFnuzdgVlnv9I=; b=T7tZr9Mgxvnk4hUz2PAgRXaJ6SZaIFku2L7Eq1AfDxQB/UVFlUkp6GY2SabnlhoHft uSRwtHKtTmv+iCz8cb4wpx4j4HoJGouNOC/xviU6v6sGyyGHPGEdbwJuJi5tVS/3ZEuz k/5bA+yRIWGccSU09yOJ1mgip72PsFcg+qmtPLw/dxH9CG/VrESl0SyBDQsFDbFJG0jm 9M2mI8up0kuma3g/+QzNo9sVqFahCdS3rYwhk187gziv6oD19Qg7GNnLAtVBiZiBg2hU dq3fIsmU35f5cafObMANpgjh26VagNLdyZFutSYywgUdw8F3Ci8wy+oHAqeBylcypNWu iWFQ== MIME-Version: 1.0 X-Received: by 10.58.186.172 with SMTP id fl12mr2013726vec.39.1404415050843; Thu, 03 Jul 2014 12:17:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Thu, 3 Jul 2014 12:17:30 -0700 (PDT) In-Reply-To: References: <53B43A71.4060104@bbn.com> <53B440D9.30303@fifthhorseman.net> <53B446E1.5050407@bbn.com> Date: Thu, 3 Jul 2014 15:17:30 -0400 X-Google-Sender-Auth: MUm9UrjOJKr6DTOVV26sfxzM6cM Message-ID: From: Barry Leiba To: Henry B Hotz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fdnPVHs3Y6rZP8RHGK9zR_mkyCQ Cc: saag Subject: Re: [saag] slight whoops X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 19:17:32 -0000 > Just an FYI for anyone (per DKG) confused: an affect causes an effect. What? No. If you want a cute sentence like that, maybe "Affecting something causes an effect." But I don't see how that's a useful mnemonic. For the usage that we're likely to make, "affect" (pronounced "uh-FEKT") will always be a verb. (As a noun, pronounced "AFF-ekt", it's only used in psychology.) If you're using "affect" as a noun, question your usage. "Effect" will almost always be used as a noun. (As a verb, it means, "make happen", as in "to effect a change," to make a change happen.) If you're using "effect" as a verb, question your usage: it might be correct, but make sure. And I can think of no useful mnemonic for this. One just has to memorize it. Barry From nobody Thu Jul 3 15:25: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 27A2A1A0385 for ; Thu, 3 Jul 2014 15:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOGYdCcDvjvJ for ; Thu, 3 Jul 2014 15:25:15 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE11B1A032E for ; Thu, 3 Jul 2014 15:25:15 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id AA1161E11C; Thu, 3 Jul 2014 22:25:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404426312; bh=l+gPxfLjOUfxfFlH/e5CHgd56Ig5XFOOhern/tI5KaQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NH48GdFu1R1nhJaQ3hqRB7tD78MzSnbS5+q3sCSpC+JHpqBKs9lbUXE+ce8RH8Xr6 so3glEyExRuAJabsTYP8iNe2+2x0ayMavMsSiVrShf0+dtFY4m9xqzB7AXRPimuIki 5zdP4mNhZEhDRPEwvNhWbPFc96yuX6xJsWCNftl4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E418D6001E; Thu, 3 Jul 2014 22:17:49 +0000 (UTC) From: James Cloos To: Paul Wouters In-Reply-To: <53B57710.6080307@redhat.com> (Paul Wouters's message of "Thu, 03 Jul 2014 11:30:24 -0400") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <12626.1404399147@sandelman.ca> <53B57710.6080307@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 03 Jul 2014 18:17:24 -0400 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140703:pwouters@redhat.com::hapw7aAdxTKR7rIG:000000000000000000000000000000000000000000O5hu X-Hashcash: 1:30:140703:saag@ietf.org::+m+DLKOKMrAgMevt:000VK0i+ Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ejtU4w2pcmnmf8MUoFw6RgZkD-E Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 22:25:17 -0000 >>>>> "PW" == Paul Wouters writes: PW> Of course, the only thing that makes sense is to hard fail. I PW> believe DANE for SMTP does just that, so stripping out STARTTLS PW> should not work to obtain plaintext email. It depends on how the sending mta is configured. With postfix, if one configures: smtp_use_tls = yes smtp_tls_note_starttls_offer = yes smtp_tls_security_level = dane smtp_dns_support_level = dnssec then outgoing mail will defer if the destination has signed tlsa which is dnssec-bogus or if the destination mta lacks starttls or if the cert it offers fail to match any of the tlsa. But that is not the default. One has to choose that config. I haven't looked into what the other MTAs do. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Jul 3 15:44: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 977521A064C for ; Thu, 3 Jul 2014 15:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gK8dhTgejeO for ; Thu, 3 Jul 2014 15:44:07 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCC21A063F for ; Thu, 3 Jul 2014 15:44:07 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 3764D1E308; Thu, 3 Jul 2014 22:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404427447; bh=w0nJCuPhkQMF/S98R4eq7Wo7W9xMKMmYvm85f9k+WQE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z4Bn4R12HYt3dB3LYYcZvtO9EknyMKSUKwj7RgwgCVeRJcjPoXDxZ3Yx6TWL58awv 2y3g560v/gp//BfKozGWC6rPfpWegBaHfy5UL0cIgSRMLS3V/p1pTWMM4REGYvnfu5 1r35Cp7jqxLstG3NEhNLNtzbJ9/UUqFrnXwEUnx4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9DA9E6001E; Thu, 3 Jul 2014 22:35:02 +0000 (UTC) From: James Cloos To: saag@ietf.org In-Reply-To: <28884.1404340580@sandelman.ca> (Michael Richardson's message of "Wed, 02 Jul 2014 18:36:20 -0400") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <53B432EE.4010408@redhat.com> <28884.1404340580@sandelman.ca> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 03 Jul 2014 18:34:37 -0400 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140703:saag@ietf.org::clX/iKGjm7AI8mnL:000DDbJ9 X-Hashcash: 1:30:140703:mcr+ietf@sandelman.ca::8ev7MQilEjxGzsJW:000000000000000000000000000000000000000WvKLT X-Hashcash: 1:30:140703:pwouters@redhat.com::tj7tqv82Unmhbyiu:00000000000000000000000000000000000000000NuFm1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bQuQseTvcB_NfMO4Eebtm7oleyU Cc: Michael Richardson Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 03 Jul 2014 22:44:08 -0000 >>>>> "MR" == Michael Richardson writes: MR> As for DANE and TLSA; I don't think that presences of a DNSSEC MR> signed key forces the browser to use HTTPS over HTTP. Nor should it, for cases like http vs https. But a tlsa on _80._tcp... could be declared an indication that the server supports rfc 2817 tls upgrade and that the client SHOULD do such an Upgrade. That said, I'm sure many would prefer to let the client choose when and whether to try Upgrade, and thus would be happier if _80._tcp tlsa declares 2817 support but not 2817 requirement. Similarly, starttls protocols like ftp or imap may prefer tls only be required for authenticated connections; those also offering anonymous ftp, imap, etc may prefer clients avoid tls for the anon connections. (For anon imap; think of access to public mailinglist archives, such as ietf, AIUI, plans.) For other starttls protocols, the existance of a signed tlsa can make a good indicator that tls is not just supported, but preferred or even demanded. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Jul 3 16:54: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 B36FB1B2923 for ; Thu, 3 Jul 2014 16:54:23 -0700 (PDT) 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 Y93jIqc385oH for ; Thu, 3 Jul 2014 16:54:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C66A1A020A for ; Thu, 3 Jul 2014 16:54:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BCBD12AB2A4; Thu, 3 Jul 2014 23:54:19 +0000 (UTC) Date: Thu, 3 Jul 2014 23:54:19 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140703235419.GJ12456@mournblade.imrryr.org> References: <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <12626.1404399147@sandelman.ca> <53B57710.6080307@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/azZh79Sgplv6RFxYX3ulI8Vz6JM Subject: Re: [saag] opportunistic security again 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, 03 Jul 2014 23:54:23 -0000 On Thu, Jul 03, 2014 at 06:17:24PM -0400, James Cloos wrote: > It depends on how the sending mta is configured. > > With postfix, if one configures: > > smtp_use_tls = yes > smtp_tls_note_starttls_offer = yes > smtp_tls_security_level = dane > smtp_dns_support_level = dnssec > > then outgoing mail will defer if the destination has signed tlsa which > is dnssec-bogus or if the destination mta lacks starttls or if the cert > it offers fail to match any of the tlsa. > > But that is not the default. One has to choose that config. The view of the implementor, is that DANE, being a fairly new bleeding edge feature, is not enabled by default. However, once DANE is enabled, authentication is enforced when TLSA RRs are present. There is also a "dane-only" level, that can be enabled for selected peers, which requires usable TLSA RRs or fails. > I haven't looked into what the other MTAs do. No other MTAs support DANE yet, I'm hoping the Exim folks will get on board soonish. -- Viktor. From nobody Thu Jul 3 17:10: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 827BE1B2B7C for ; Thu, 3 Jul 2014 17:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 pBZcI4wcFvuk for ; Thu, 3 Jul 2014 17:10:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424FC1B2B76 for ; Thu, 3 Jul 2014 17:10:22 -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 s640AKPi017152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Jul 2014 20:10:21 -0400 Received: from bofh.nohats.ca (vpn-61-93.rdu2.redhat.com [10.10.61.93]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s640AKD9028775; Thu, 3 Jul 2014 20:10:20 -0400 Message-ID: <53B5F0EB.9090800@redhat.com> Date: Thu, 03 Jul 2014 20:10:19 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: James Cloos , saag@ietf.org References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <53B432EE.4010408@redhat.com> <28884.1404340580@sandelman.ca> 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.24 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pDwg7P_CJfk-P3sBNBwwLbKUM5A Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 04 Jul 2014 00:10:25 -0000 On 07/03/2014 06:34 PM, James Cloos wrote: >>>>>> "MR" == Michael Richardson writes: > > MR> As for DANE and TLSA; I don't think that presences of a DNSSEC > MR> signed key forces the browser to use HTTPS over HTTP. > > Nor should it, for cases like http vs https. > > But a tlsa on _80._tcp... could be declared an indication that the > server supports rfc 2817 tls upgrade and that the client SHOULD do > such an Upgrade. Why not obsolete port 80? Use TLS on 443, even with unauthenticated keys on both sides. Paul From nobody Fri Jul 4 12:21: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 9A4FB1B2EF3 for ; Fri, 4 Jul 2014 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfbUZ1_e31IB for ; Fri, 4 Jul 2014 12:21:26 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A380D1B2EF1 for ; Fri, 4 Jul 2014 12:21:26 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 489FD6D679; Fri, 4 Jul 2014 15:21:21 -0400 (EDT) Message-ID: <53B6FEB0.50804@iang.org> Date: Fri, 04 Jul 2014 20:21:20 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> In-Reply-To: <53B59BC6.7020507@iang.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/13v2PrsHamabp7siSIsMnjVo-Vc Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 19:21:27 -0000 I wonder if it is is possible to list the potential strategies for alg agility? And perhaps add their pros&cons? Here's a strawman list of possibilities, with full intent to be rewritten entirely, just in case this helps: 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, and once added this tends to be supported for a long time. Crypto freedom taken to vanity extremes. Downside is weakness of deprecation; weak ciphers stick around forever. As algorithms are the component of choice, protocol errors tend to impact many algorithms. Lots of 'downgrade' possibility, lots of user confusion or ignorance, waste in maintenance of too many components. 2. primary + extras. Everyone must implement the central chosen set, and any others they desire. Most instances will prefer/negotiate the primary, only in specialised instances will the alternates be chosen. Downside is that there is no clear alternate choice. 3. Primary + secondary MUSTs. As there are two MUST suites, there is always a fallback, by config. 4. Odds and evens. Each version has two suites, a primary and a secondary, initially numbered 1 and 2. In each succeeding version, the last version's primary is dropped, and secondary moves up to primary. A new secondary is added (numbered 3, etc). Fallback / switchover can be done by configuration and by version upgrade. 5. one true cipher suite. No config fall back available, a failure in the suite triggers a requirement to upgrade the entire version. Simpler to implement, no negotiation woes. 6. parallel twinned suites, where the protocol duplicates every component. Ciphers are CTR/XOR'd in parallel, HMACs are serialised, etc. This involves a performance hit that many would be annoyed by, and is sometimes considered to be "inventing your own ciphers." No particular upgrade path but not particularly vulnerable to any component weakness. I'm sure there are more. And the thoughts above are very scrappy, by no means suitable for a draft. But maybe a useful approach? iang From nobody Sun Jul 6 06: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 E2CDF1A02E2 for ; Sun, 6 Jul 2014 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bqwcztGOZIQD for ; Sun, 6 Jul 2014 06:34:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B291A02DC for ; Sun, 6 Jul 2014 06:34:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AF72A2AB2A6; Sun, 6 Jul 2014 13:34:37 +0000 (UTC) Date: Sun, 6 Jul 2014 13:34:37 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140706133437.GW12456@mournblade.imrryr.org> References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B491AF.5090202@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/P-lxcpZ22CBSvJaDb9yo_FX6zy4 Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:34:42 -0000 On Thu, Jul 03, 2014 at 12:11:43AM +0100, Stephen Farrell wrote: > On 03/07/14 00:08, Viktor Dukhovni wrote: > >> > I don't think its really useful to talk about the latter > >> > as if its not OS. I think we'd be better off talking about > >> > such cases as being more than OS. > > It is important to not put an artificial ceiling on the effective > > security that can be achieved with OS. OS sets a low floor and > > works up from there on a peer-by-peer basis. Therefore, strongly > > authenticated connections are still OS (not "stonger than" OS) > > Fair point. As we're seeing again, its not simple to get that > clear and correct. Since it is after July 05, I can no longer submit an update, until submission is reopened on the 21st. The tentative update text is below: + + In summary, opportunistic security is an umbrella term that + encompasses protocol designs that remove barriers to the + widespread use of encryption in the Internet. The actual + protection provided by opportunistic security depends on the + capabilities of the communicating peers; opportunistic security + MUST attempt to at least encrypt network traffic, while allowing + fallback to cleartext with peers that do not appear to be + encryption capable. + + + + It is important to note that opportunistic security is not + limited to unauthenticated encryption. When possible, + opportunistic security SHOULD provide stronger security on a + peer-by-peer basis. For example, some peers may be authenticated + via DANE, TOFU or other means. Though authentication failure + MAY be a reason to abort a connection to a peer that is expected + to be authenticated, it MUST NOT instead lead to communication + in cleartext when encryption is an option. Some sending MTAs + employing STARTTLS have been observed to abort TLS transmission + when the receiving MTA fails authentication, only to immediately + deliver the same message over a cleartext connection. This + design blunder MUST be avoided. + I replaced the perpass draft reference with a reference to 7258 and added the boilerplate 2119 text and reference. I'll post a -01 on the 21st or so. -- Viktor. From nobody Sun Jul 6 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 CDF0D1A04B7 for ; Sun, 6 Jul 2014 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcLhFLnGil1i for ; Sun, 6 Jul 2014 09:16:38 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3731A04A2 for ; Sun, 6 Jul 2014 09:16:38 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 3A5761EA11; Sun, 6 Jul 2014 16:16:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404663396; bh=Krdct5pvm7iqAgdmdatzF3Jzq/T6S1OF2dmQv41y4uA=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AwBZZgB31ae6V3zuSRH+z3RyyN6hI4VgD8wcv8RYeuSgPXu27c253JRRS8MsyD9W9 v9LpPXLMFAzWS+J8AShu9YlMJiZ3vhssFGEkpjB/0uPEiODXqAoCcg0A0tN3IdcvrY 6Fiuepi9Z0LmxD0FYNcnuhcOfCgMk/AN1ELF1GiI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 89A7C6001E; Sun, 6 Jul 2014 16:13:35 +0000 (UTC) From: James Cloos To: saag@ietf.org In-Reply-To: <20140706133437.GW12456@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 6 Jul 2014 13:34:37 +0000") References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 06 Jul 2014 12:13:10 -0400 Message-ID: Lines: 1 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140706:saag@ietf.org::6+ueM7DpBwKhIz6P:0006lbUJ Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gL3os4Y6VQW2gQkWfuCAx_BEFag Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 06 Jul 2014 16:16:39 -0000 That update text has the right feel. From nobody Sun Jul 6 09:54: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 26F1E1A0640 for ; Sun, 6 Jul 2014 09:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNOaSgv7fAxj for ; Sun, 6 Jul 2014 09:54: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 C42831A05D1 for ; Sun, 6 Jul 2014 09:54:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0FFB7BE04 for ; Sun, 6 Jul 2014 17:54:55 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T9qTXcdncXe for ; Sun, 6 Jul 2014 17:54:54 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.50.166]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E0485BDD7 for ; Sun, 6 Jul 2014 17:54:53 +0100 (IST) Message-ID: <53B97F5D.9000407@cs.tcd.ie> Date: Sun, 06 Jul 2014 17:54:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> In-Reply-To: <20140706133437.GW12456@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/FqAYb1R0n0DCGjZRi1SJbfS8B9c Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 06 Jul 2014 16:54:57 -0000 Hiya, On 06/07/14 14:34, Viktor Dukhovni wrote: > Since it is after July 05, I can no longer submit an update, until > submission is reopened on the 21st. Assuming Viktor can do it, (can you?) would anyone object if I ok'd publication of the -01 and started a 4 week IETF LC on that? If you would object, please say so (and why) by Tuesday. (If you can't get to it by then, and we start IETF LC, then please do send your comments as part of that LC, and feel free to berate me for being hasty as part of that:-) I think we're down to polishing here really so we might as well get on with the IETF LC spanning the IETF meeting and see if that generates much or any discussion. Cheers, S. From nobody Sun Jul 6 10:08: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 3BFC81A0198 for ; Sun, 6 Jul 2014 10:08: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6u5138PvdKi for ; Sun, 6 Jul 2014 10:08:24 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31ED01A014E for ; Sun, 6 Jul 2014 10:08:24 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so14860363wiv.9 for ; Sun, 06 Jul 2014 10:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=N/w2Puq+ZWpqygXqRW24pwBBsK3V3GzjAZrG9iwTjV0=; b=pVCegCxLITS4WQr35BOhKmCHBXyVG+M8VArO7TT54U/XvDTP+ktATmR7MMKsZ3RUNf famlbi0j2rc6SOO8pOSfRQnmb7hiNl2ICowUTpFFDc/7wmoRKofb9RVfOw9iTDwxmaHh GJHjdRAn6cvbjvK5N1T5FbzyHltNHGa1lDlSo4DBfaVNd4YCS4hnPZNRbxbxxKKvNOaa L7HIflV6YhJPDYHwE7BVUQTN3eZ0E5WL9YxJrBcwzHCwVTj67+77TfHEg8neSmlKLfH3 5eLT6x9conZotjkMtN3hteqpZRazRXZGYhCdzcHc384zU/lEk+7t+usFqzPTqwVW9tpq tE/g== X-Received: by 10.194.200.3 with SMTP id jo3mr643244wjc.110.1404666502733; Sun, 06 Jul 2014 10:08:22 -0700 (PDT) Received: from nomad.lan (ip-94-112-138-148.net.upcbroadband.cz. [94.112.138.148]) by mx.google.com with ESMTPSA id ev9sm104967896wic.24.2014.07.06.10.08.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 06 Jul 2014 10:08:22 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <1404666500.13119.22.camel@nomad.lan> From: Nikos Mavrogiannopoulos To: Christian Huitema Date: Sun, 06 Jul 2014 19:08:20 +0200 In-Reply-To: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0t091LxS6SoiOSpQYIZef2gqOlg Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 17:08:26 -0000 On Fri, 2014-06-27 at 19:25 +0000, Christian Huitema wrote: > Am I the only one who believes that the draft would be stronger if it > also discussed the "pitfalls of agility?" The poster child for that is > probably TLS. The protocol includes a negotiation capability, so that > the parties can chose from a list of enumerated options. In theory, > that's very nice. As time passes, better options become available and > can be negotiated, providing for better security. But in practice, > there are issues: downgrading attacks, code bloat, unclear rules for > how to choose the "best" option, difficulty to remove obsolete > options... As a design rule, it seems that "few good options" is better > than "unfettered negotiation." Indeed, but this is a side-effect of independent of the agility. You may provide a protocol without future agility of algorithms, and still provide a ton of options to use. If you implement all the ciphersuites defined in TLS 1.0, you'll find out it is an enormous number of combinations defined on the main protocol. The later additions were very little in comparison to original numbers; since TLS 1.0 in standards track we only got AES-CBC/AES-GCM as well as elliptic curves, whilst in TLS 1.0 we had RC2-40, RC4-40, RC4, DES-40, 3DES, IDEA, several ciphersuites with static DH keys that were never actually used and so on (to their defense that was at a time that cipher research was at its infancy and supporting more options seemed like a good idea). What was more of an issue with the agility in TLS was that for a few years after it was deployed we had implementations, that would disconnect the client if proposed ciphersuites that were not referenced in the original spec, or advertised its support for TLS 1.1. That caused several interoperability issues, and was one of the fact that TLS 1.1 was never actually deployed (which would have made BEAST and several other attacks a non-issue). So while TLS is now considered an agile protocol, that was not the case in mid-2000, and its agility capabilities caused more trouble than solved issues. regards, Nikos From nobody Sun Jul 6 14:32: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 156A61A0AA9 for ; Sun, 6 Jul 2014 14:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQk_wpzhL6N9 for ; Sun, 6 Jul 2014 14:32:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0428A1A0601 for ; Sun, 6 Jul 2014 14:32:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2612620029; Sun, 6 Jul 2014 17:33:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 880C963B0E; Sun, 6 Jul 2014 17:32:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7937B63B0B; Sun, 6 Jul 2014 17:32:43 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53B97F5D.9000407@cs.tcd.ie> References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <53B97F5D.9000407@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/CyZES5Zas6g106PswmcymyFUSQw Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 06 Jul 2014 21:32:48 -0000 Stephen Farrell wrote: > On 06/07/14 14:34, Viktor Dukhovni wrote: >> Since it is after July 05, I can no longer submit an update, until >> submission is reopened on the 21st. > Assuming Viktor can do it, (can you?) would anyone object if I > ok'd publication of the -01 and started a 4 week IETF LC on that? > If you would object, please say so (and why) by Tuesday. (If you > can't get to it by then, and we start IETF LC, then please do send > your comments as part of that LC, and feel free to berate me for > being hasty as part of that:-) I would prefer to create a sub-term/adjective (FOO OS, Opportunistic FOO Security, OS FOO) to OS, to distinguish between an unauthenticated encryption (where failure to cleartext is reasonable), and the "stronger" very where a MITM can be detected by TOFU, DANE, etc. HOWEVER: I think that we can define those terms in another document, and let this one out as-is. use it in a sentence: "yeah, Mr. CEO: our system had detected that it could do FOOSTRONGER OS, but the receiving end had rekeyed unilaterally, and so we had to wait for the TTL on the TLSA record to expire before your email to example.com could be delivered securely" -- ] 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 [ From nobody Sun Jul 6 16:55: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 B3C501A0058 for ; Sun, 6 Jul 2014 16:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.414 X-Spam-Level: X-Spam-Status: No, score=-100.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 fwKpra5bZQaR for ; Sun, 6 Jul 2014 16:55:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C081A0056 for ; Sun, 6 Jul 2014 16:55:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4EFA52AB2A6; Sun, 6 Jul 2014 23:55:10 +0000 (UTC) Date: Sun, 6 Jul 2014 23:55:10 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140706235509.GZ12456@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B97F5D.9000407@cs.tcd.ie> <25032.1404682363@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mmOsIxcL4fX13v6IgPEplOSDLZk Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 23:55:14 -0000 On Sun, Jul 06, 2014 at 05:32:43PM -0400, Michael Richardson wrote: > I would prefer to create a sub-term/adjective (FOO OS, Opportunistic FOO > Security, OS FOO) to OS, to distinguish between an unauthenticated encryption > (where failure to cleartext is reasonable), and the "stronger" very where a > MITM can be detected by TOFU, DANE, etc. > > HOWEVER: I think that we can define those terms in another document, > and let this one out as-is. I think this will happen naturally as various opportunistic security specifications are developed in application specific standards. For example, the DANE SMTP specification talks about "opportunistic DANE TLS", which is a flavour of opportunistic security. On Sun, Jul 06, 2014 at 05:54:53PM +0100, Stephen Farrell wrote: > On 06/07/14 14:34, Viktor Dukhovni wrote: > > Since it is after July 05, I can no longer submit an update, until > > submission is reopened on the 21st. > > Assuming Viktor can do it, (can you?) would anyone object if I > ok'd publication of the -01 and started a 4 week IETF LC on that? How do I go about submitting it? Email you the ".xml" file? On Sun, Jul 06, 2014 at 12:13:10PM -0400, James Cloos wrote: > That update text has the right feel. Thanks. I tried to combine the feedback to -00 into a coherent whole. -- Viktor. From nobody Sun Jul 6 22:42: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 CA3441A0AF9 for ; Sun, 6 Jul 2014 22:42: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, 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 n43ZRPjwm9pn for ; Sun, 6 Jul 2014 22:42:29 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E80D1A0AF6 for ; Sun, 6 Jul 2014 22:42:29 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 31180594062 for ; Sun, 6 Jul 2014 22:42:29 -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=Qe385J4p2EYCDlbBt9aF 42qyRz8=; b=PCNwV77iwJONN6X6a4uawiYBj2db5EKybm6EJaUM48UVBHojOn7I RPBTJA3TCuBzYOLmvejQBdb7GEnYpczgUPf+etGB8+jPpqy+udySWOmrp6Db7wvD bqS8LTQRcWzKtDzFmcHzkVBBbZVVlIgUppuxvkUX7kB7meCFxLvX85U= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id D7D88594061 for ; Sun, 6 Jul 2014 22:42:28 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so3822276wes.29 for ; Sun, 06 Jul 2014 22:42:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.91.194 with SMTP id cg2mr35075458wib.12.1404711747595; Sun, 06 Jul 2014 22:42:27 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Sun, 6 Jul 2014 22:42:27 -0700 (PDT) In-Reply-To: <27060.1404340087@sandelman.ca> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> Date: Mon, 7 Jul 2014 00:42:27 -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/g8qZwq096n99gLQv0dNHDS1R5bA Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 05:42:29 -0000 On Wed, Jul 2, 2014 at 5:28 PM, Michael Richardson wrote: > yes, but when in the "OTR in use case", the remote user gets no additional > privileges. In this case "privilege" is strictly in the minds of the users who are instant messaging. It's not about privilege but about UIs: how to inform the user that the peer is not strongly authenticated. From nobody Sun Jul 6 22:45: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 3B52E1A0AFE for ; Sun, 6 Jul 2014 22:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV1TH221gSxH for ; Sun, 6 Jul 2014 22:45:56 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4C1A0AF9 for ; Sun, 6 Jul 2014 22:45:56 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 7157F3B805B for ; Sun, 6 Jul 2014 22:45:56 -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=EDLHmUuz+3FohBdqclTvfHC 4fP8=; b=bCI1odYzru/f/8/1p7yt1v5mUsuLHoJjoLQfm7vaaCLXakknslDeafs Qq7UVHRBbRjApiw+gevG3nLQCfxczwVXQEh5mCd88P3PUdmw2tf2HsqNKqEhNXex +PDpXsnCWx6vjZ3wq+LBmjwi47FkHjYbUjJ46S/chzqPdEQsjzjg= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 272AD3B8059 for ; Sun, 6 Jul 2014 22:45:56 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so3827734wgh.14 for ; Sun, 06 Jul 2014 22:45:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.91.194 with SMTP id cg2mr35092196wib.12.1404711955112; Sun, 06 Jul 2014 22:45:55 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Sun, 6 Jul 2014 22:45:54 -0700 (PDT) In-Reply-To: <20140702223135.GB12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <20140702223135.GB12456@mournblade.imrryr.org> Date: Mon, 7 Jul 2014 00:45:54 -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/IPn8k6Qxd5AQH7hSjjFORu3G-KQ Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 05:45:57 -0000 On Wed, Jul 2, 2014 at 5:31 PM, Viktor Dukhovni wrote: > On Wed, Jul 02, 2014 at 06:28:07PM -0400, Michael Richardson wrote: >> If it's opportunistic security, then it didn't use strong authentication, > > Sorry, that is not the case. Please read the draft. Rather, OS > might not use strong authentication with some peers, but some other > peers may be strongly authenticated (e.g. opportunistic DANE TLS, > for those peers that publish usable TLSA records). Agreed, but do note that when OS yields strong authentication this is meaningless unless there's a UI element (e.g., future failure when strong authentication of the same peer name cannot be obtained, and/or perhaps a UI element to indicate the authentication status of a "connection"/"session"/whatever. I.e., OS sets a floor of protection relative to passive attackers, but to opportunistically raise the floor to protection against active attackers has UI considerations. Nico -- From nobody Sun Jul 6 22:53: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 91D3C1A0AFB for ; Sun, 6 Jul 2014 22:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, 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 0J_bILBN2Xm0 for ; Sun, 6 Jul 2014 22:53:49 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ED9E01A0AFA for ; Sun, 6 Jul 2014 22:53:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D1BFB678062 for ; Sun, 6 Jul 2014 22:53:48 -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=Q1v4IWYhFtRBG1/3mP+sNODuIZA=; b=gLKDfIn1krK ZKej9rIxgYVSCjvqeuyuw4kSBEbXLOGTowtR+HDiZIUDxvYFINEHFKzAJ5l7Ec5R 7toIkqLCM/hnOHIu8DWkbNWdM1deaG42aUHpdCBDXClMJV/fi0p7v7Ups1mcF73E qcxWKVIU8xQeJRerUxmEZMJQbBzHiREQ= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 87B3F678058 for ; Sun, 6 Jul 2014 22:53:48 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so3833366wes.1 for ; Sun, 06 Jul 2014 22:53:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.195 with SMTP id wo3mr258943wjb.130.1404712427546; Sun, 06 Jul 2014 22:53:47 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Sun, 6 Jul 2014 22:53:47 -0700 (PDT) Date: Mon, 7 Jul 2014 00:53:47 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XgkhiW67a5_SSGYKAYuTdV4oJfY Cc: Michael Richardson , "saag@ietf.org" Subject: [saag] OS OR SA, not OS XOR SA (Re: opportunistic security again) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 05:53:49 -0000 On Wed, Jul 2, 2014 at 5:32 PM, Stephen Farrell wrote: > On 02/07/14 23:28, Michael Richardson wrote: >> then it is no longer opportunistic; > > That "it" is ambiguous. The putative protocol in question > still does support OS, but in that particular run of that > deployment, it may be authenticating one or more endpoints. I'm unwilling to say: OS XOR SA (SA==strong authentication), not without a fair bit more discussion. To get OS OR SA requires some UI element (see other recent response of mine). There may be cases where no UI element may be had, not even future failure on downgrade. In such cases we can only have OS XOR SA. Are there realistic OS XOR SA cases? End-to-end IPsec is not a good example case, FYI, because there's generally no good UI other than rummaging through logs to find out why bits aren't moving. Of course, IPsec could have better interfaces, but no standard interfaces exist other than the configuration databases like the PAD and SPD. I.e., end-to-end IPsec can't really provide SA as it is. Nico -- From nobody Mon Jul 7 00:29: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 9825E1B278E for ; Mon, 7 Jul 2014 00:29:21 -0700 (PDT) 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 Ow-bLK2hiC-n for ; Mon, 7 Jul 2014 00:29:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B751A00AD for ; Mon, 7 Jul 2014 00:29:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 413EE2AB2A8; Mon, 7 Jul 2014 07:29:18 +0000 (UTC) Date: Mon, 7 Jul 2014 07:29:18 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140707072918.GG12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <20140702223135.GB12456@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ShnMJ4V3mTm3uZbZ_9ZvrD_u5g8 Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 07:29:21 -0000 On Mon, Jul 07, 2014 at 12:45:54AM -0500, Nico Williams wrote: > I.e., OS sets a floor of protection relative to passive attackers, but > to opportunistically raise the floor to protection against active > attackers has UI considerations. Not necessarily, SMTP opportunistic DANE TLS has no UI. Rather, the goal is resist MiTM when possible, and secondarily to log the resulting protection level. Unauthenticated opportunistic TLS is vulnerable to MiTM, opportunistic DANE TLS is MiTM resistant. -- Viktor. From nobody Mon Jul 7 02:07: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 870F51B27F4 for ; Mon, 7 Jul 2014 02:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTKTvB9ClDiQ for ; Mon, 7 Jul 2014 02:07:26 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C4B1B27EB for ; Mon, 7 Jul 2014 02:07:26 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1D9BF6D477; Mon, 7 Jul 2014 05:07:21 -0400 (EDT) Message-ID: <53BA6348.20609@iang.org> Date: Mon, 07 Jul 2014 10:07:20 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <53B97F5D.9000407@cs.tcd.ie> In-Reply-To: <53B97F5D.9000407@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/KjkAM6t7IGb7-Vzt_9ASoq-AyUU Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 09:07:27 -0000 On 6/07/2014 17:54 pm, Stephen Farrell wrote: > On 06/07/14 14:34, Viktor Dukhovni wrote: >> Since it is after July 05, I can no longer submit an update, until >> submission is reopened on the 21st. > > Assuming Viktor can do it, (can you?) would anyone object if I > ok'd publication of the -01 and started a 4 week IETF LC on that? No objection, go ahead. > If you would object, please say so (and why) by Tuesday. (If you > can't get to it by then, and we start IETF LC, then please do send > your comments as part of that LC, and feel free to berate me for > being hasty as part of that:-) > > I think we're down to polishing here really so we might as > well get on with the IETF LC spanning the IETF meeting and see if > that generates much or any discussion. I have no objections. iang From nobody Mon Jul 7 07:08: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 393C91A0120 for ; Mon, 7 Jul 2014 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 qZrgFNrFnyVK for ; Mon, 7 Jul 2014 07:08:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8391A010A for ; Mon, 7 Jul 2014 07:08:41 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s67E8ejl031743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 7 Jul 2014 10:08:40 -0400 Received: from bofh.nohats.ca (vpn-57-151.rdu2.redhat.com [10.10.57.151]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s67E8db7010126 for ; Mon, 7 Jul 2014 10:08:39 -0400 Message-ID: <53BAA9E7.4010702@redhat.com> Date: Mon, 07 Jul 2014 10:08:39 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qWUUA4esbHgikkHoGDJ9JHJbtzM Subject: Re: [saag] OS OR SA, not OS XOR SA (Re: opportunistic security again) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 14:08:43 -0000 On 07/07/2014 01:53 AM, Nico Williams wrote: I.e., end-to-end IPsec can't really > provide SA as it is. It's not that hard to write a dbus or networkmanager notification. The UI part here is not a problem Paul From nobody Mon Jul 7 08:14: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 CF3801A0183 for ; Mon, 7 Jul 2014 08:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, 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 qIr8qq2GmhT5 for ; Mon, 7 Jul 2014 08:14:39 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 473A21A01E7 for ; Mon, 7 Jul 2014 08:14:35 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id B9B0B1B4059 for ; Mon, 7 Jul 2014 08:14: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=TEswM9r+Tqcarc+LZmy4 FCgqTNo=; b=NrhEhyA3erCNW9X9o5wOW016gea8RZVyG1xJ03DLm7FTGaCocJUs BGckFronsAoGuEAJMCtD8wjJ9+bT9QDFmdWoJelwYBAc6XHgD7LexiD7tVak3W0z jc2kDHwFOPvZ/6sMq8PoS60WweWm34tWQ/zvz96LkI+ZKz7vOLwQjZI= Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id A1BEB1B4057 for ; Mon, 7 Jul 2014 08:14:34 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id m1so4736811oag.19 for ; Mon, 07 Jul 2014 08:14:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.60.42 with SMTP id e10mr32094907obr.33.1404746073909; Mon, 07 Jul 2014 08:14:33 -0700 (PDT) Received: by 10.182.234.78 with HTTP; Mon, 7 Jul 2014 08:14:33 -0700 (PDT) In-Reply-To: <53BAA9E7.4010702@redhat.com> References: <53BAA9E7.4010702@redhat.com> Date: Mon, 7 Jul 2014 10:14:33 -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/nvwl0R3MQhRkPxoNIE_dpDEdA8E Cc: "saag@ietf.org" Subject: Re: [saag] OS OR SA, not OS XOR SA (Re: opportunistic security again) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 15:14:40 -0000 On Mon, Jul 7, 2014 at 9:08 AM, Paul Wouters wrote: > On 07/07/2014 01:53 AM, Nico Williams wrote: > I.e., end-to-end IPsec can't really >> provide SA as it is. > > It's not that hard to write a dbus or networkmanager notification. The UI part here is not a problem That's not responsive to my claim that whether we get OS OR SA or OS XOR SA is UI dependent. Nor is your reply all that useful as to IPsec. IPsec end-to-end errors should be part of the socket API., and hell, end-to-end IPsec needs to be part of the socket API altogether (see Solaris/Illumos' IP_SEC_OPT socket option, see RFC 5660, and the charter of the now concluded BTNS WG). The non-existence of the dbus/networkmanager notification you mention is telling :/ All these missing APIs and UIs are a large part of why end-to-end IPsec is not used much and not scalable to Internet scale. BTW, if we continue the IPsec-specific sub-thread let's change the Subject: again. This thread should be for discussion of its current Subject:. Nico -- From nobody Mon Jul 7 09: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 F36091A0402 for ; Mon, 7 Jul 2014 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] 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 VsV0in5yUydr for ; Mon, 7 Jul 2014 09:58:06 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973AB1A03BE for ; Mon, 7 Jul 2014 09:58:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7AA24E2034 for ; Mon, 7 Jul 2014 12:58:05 -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 13536-01-2 for ; Mon, 7 Jul 2014 12:58:03 -0400 (EDT) Received: from securerf.ihtfp.org (c-50-189-135-154.hsd1.ct.comcast.net [50.189.135.154]) (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 9273CE203A for ; Mon, 7 Jul 2014 12:58:02 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s67CZIaL028458; Mon, 7 Jul 2014 08:35:18 -0400 From: Derek Atkins To: saag@ietf.org References: <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> Date: Mon, 07 Jul 2014 08:35:18 -0400 In-Reply-To: <20140706133437.GW12456@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 6 Jul 2014 13:34:37 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/674tP0ijIELCw-SBjbr1GHosh5U Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 16:58:08 -0000 Viktor Dukhovni writes: > Since it is after July 05, I can no longer submit an update, until > submission is reopened on the 21st. > > The tentative update text is below: > > + > + In summary, opportunistic security is an umbrella term that > + encompasses protocol designs that remove barriers to the > + widespread use of encryption in the Internet. The actual > + protection provided by opportunistic security depends on the > + capabilities of the communicating peers; opportunistic security > + MUST attempt to at least encrypt network traffic, while allowing > + fallback to cleartext with peers that do not appear to be > + encryption capable. > + > + > + > + It is important to note that opportunistic security is not > + limited to unauthenticated encryption. When possible, > + opportunistic security SHOULD provide stronger security on a > + peer-by-peer basis. For example, some peers may be authenticated > + via DANE, TOFU or other means. Though authentication failure > + MAY be a reason to abort a connection to a peer that is expected > + to be authenticated, it MUST NOT instead lead to communication > + in cleartext when encryption is an option. Some sending MTAs > + employing STARTTLS have been observed to abort TLS transmission > + when the receiving MTA fails authentication, only to immediately > + deliver the same message over a cleartext connection. This > + design blunder MUST be avoided. > + I like this text. Thank you! > I replaced the perpass draft reference with a reference to 7258 > and added the boilerplate 2119 text and reference. I'll post a > -01 on the 21st or so. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Jul 7 09:58: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 2E3B41A040A for ; Mon, 7 Jul 2014 09:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.802 X-Spam-Level: ** X-Spam-Status: No, score=2.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DATE_IN_PAST_03_06=1.592, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsY6wwUGbY_a for ; Mon, 7 Jul 2014 09:58:08 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134851A03BE for ; Mon, 7 Jul 2014 09:58:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0B33EE2031; Mon, 7 Jul 2014 12:58:07 -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 13536-01-3; Mon, 7 Jul 2014 12:58:05 -0400 (EDT) Received: from securerf.ihtfp.org (c-50-189-135-154.hsd1.ct.comcast.net [50.189.135.154]) (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 5DB40E2035; Mon, 7 Jul 2014 12:58:04 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s67CeT4C028537; Mon, 7 Jul 2014 08:40:29 -0400 From: Derek Atkins To: ianG References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> Date: Mon, 07 Jul 2014 08:40:29 -0400 In-Reply-To: <53B6FEB0.50804@iang.org> (iang@iang.org's message of "Fri, 04 Jul 2014 20:21:20 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eHppjeeyy2rwURVls3bpA5TtFWU Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:58:09 -0000 ianG writes: > I wonder if it is is possible to list the potential strategies for alg > agility? And perhaps add their pros&cons? Here's a strawman list of > possibilities, with full intent to be rewritten entirely, just in case > this helps: > > > > 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, and > once added this tends to be supported for a long time. Crypto freedom > taken to vanity extremes. > > Downside is weakness of deprecation; weak ciphers stick around forever. > As algorithms are the component of choice, protocol errors tend to > impact many algorithms. Lots of 'downgrade' possibility, lots of user > confusion or ignorance, waste in maintenance of too many components. I hit this problem a couple weeks ago. I was trying to buy a train ticket online but I was getting an SSL error: no common cipher. It turns out the server *ONLY* supported a few DES ciphers, which of course I had turned off. They didn't support any of the AES or RC4 ciphers that firefox-30 supported. Quite annoying. "Luckily" I know how to enable those ciphers in firefox, so I was able to get my train ticket, but I certainly feel like I need to watch my credit card statement for the next month or two. *shudders* > 5. one true cipher suite. No config fall back available, a failure in > the suite triggers a requirement to upgrade the entire version. Simpler > to implement, no negotiation woes. And no way to recover if the suite is found to be bad. C.f.: DES+MD4. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Jul 7 10:19: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 BCA1B1A014C for ; Mon, 7 Jul 2014 10:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyrjv8uNnHpE for ; Mon, 7 Jul 2014 10:19:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B623C1A035B for ; Mon, 7 Jul 2014 10:19:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D2A31BE10 for ; Mon, 7 Jul 2014 18:19:42 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fOiZ_cRpYGH for ; Mon, 7 Jul 2014 18:19:42 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4FE6BE0F for ; Mon, 7 Jul 2014 18:19:42 +0100 (IST) Message-ID: <53BAD6AE.6060301@cs.tcd.ie> Date: Mon, 07 Jul 2014 18:19:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140706235509.GZ12456@mournblade.imrryr.org> In-Reply-To: <20140706235509.GZ12456@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/0J9pAD18WINU0FnlANE1QLyQGCo Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 17:19:46 -0000 Hiya, On 07/07/14 00:55, Viktor Dukhovni wrote: >> > Assuming Viktor can do it, (can you?) would anyone object if I >> > ok'd publication of the -01 and started a 4 week IETF LC on that? > How do I go about submitting it? Email you the ".xml" file? That's done now and -01 is posted. [1] As the plan is to start a 4 week IETF LC for that tomorrow (barring good objections) probably better to hold your comments/text tweaks for a day and post them on the IETF LC thread. Much easier to track 'em that way. Anyone feeling in the mood to be doc shepherd for this? If so, I'll be after a shepherd write up tomorrow, but that's pretty simple if you've done it before, though this one could generate some discussion during IETF LC I suppose, so fair warning if you do volunteer:-) If you're up for it, please just mail me off-list. Thanks Viktor for the quick turn around and thanks in advance to all who volunteer to shepherd, Cheers, S. [1] https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Mon Jul 7 10:30: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 9A72A1A0522 for ; Mon, 7 Jul 2014 10:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6wcNsmj9NmM for ; Mon, 7 Jul 2014 10:30:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 922AD1A04D2 for ; Mon, 7 Jul 2014 10:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09AE5BE10; Mon, 7 Jul 2014 18:30:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XBmQ0tz82_B; Mon, 7 Jul 2014 18:30:21 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFE0EBE0F; Mon, 7 Jul 2014 18:30:21 +0100 (IST) Message-ID: <53BAD92D.90901@cs.tcd.ie> Date: Mon, 07 Jul 2014 18:30:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140706235509.GZ12456@mournblade.imrryr.org> <53BAD6AE.6060301@cs.tcd.ie> In-Reply-To: <53BAD6AE.6060301@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/QF-KbhI3qIdlHCHouSaSz7uEwlY Cc: Paul Hoffman Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 17:30:25 -0000 On 07/07/14 18:19, Stephen Farrell wrote: > > Anyone feeling in the mood to be doc shepherd for this? That was quick! Thanks Paul. Cheers, S. From nobody Mon Jul 7 10:47: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 49F351A0535 for ; Mon, 7 Jul 2014 10:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKwK741hw68x for ; Mon, 7 Jul 2014 10:47:39 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 07D291A0522 for ; Mon, 7 Jul 2014 10:47:39 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 96F152007DA19 for ; Mon, 7 Jul 2014 10:47:38 -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=2X9i2dvlaRt7pizoG9O82Ag /aEw=; b=j6jQgrJLiTSF16LjRGXAOqyxl4pl2+oh7VkzFI3B7PqJ5XTKruIkoTv fbCL4vkdpbst7/MSzNrOp2QUcVPgW2ALpBLbvokMvUGFTR2xH8bJD7B81DZ7PlnL +n+AopgFr0D5XkCZiSHXE0eb1fWBQ4u8XFf1PVFBLhrtEp/SiAyQ= Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 819032007DA13 for ; Mon, 7 Jul 2014 10:47:38 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wp4so5047863obc.40 for ; Mon, 07 Jul 2014 10:47:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.160.71 with SMTP id xi7mr32839631oeb.51.1404755258143; Mon, 07 Jul 2014 10:47:38 -0700 (PDT) Received: by 10.182.234.78 with HTTP; Mon, 7 Jul 2014 10:47:37 -0700 (PDT) In-Reply-To: <20140707072918.GG12456@mournblade.imrryr.org> References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <20140702223135.GB12456@mournblade.imrryr.org> <20140707072918.GG12456@mournblade.imrryr.org> Date: Mon, 7 Jul 2014 12:47:37 -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/FYK5MBS5dLKxPB1P7C43bZi5phc Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 17:47:40 -0000 On Mon, Jul 7, 2014 at 2:29 AM, Viktor Dukhovni wrote: > On Mon, Jul 07, 2014 at 12:45:54AM -0500, Nico Williams wrote: > >> I.e., OS sets a floor of protection relative to passive attackers, but >> to opportunistically raise the floor to protection against active >> attackers has UI considerations. > > Not necessarily, SMTP opportunistic DANE TLS has no UI. Rather, > the goal is resist MiTM when possible, and secondarily to log the > resulting protection level. Unauthenticated opportunistic TLS is > vulnerable to MiTM, opportunistic DANE TLS is MiTM resistant. Right, sorry, that's like the third time I make that braino. UIs are only needed for OS when there's no mechanism like DANE for securely discovering a peer's ability to strongly authenticate. From nobody Mon Jul 7 12:06: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 D52451B287B for ; Mon, 7 Jul 2014 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MISSING_HEADERS=1.021] 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 KNoF1LlQpzlq for ; Mon, 7 Jul 2014 12:06:25 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F6F1B2879 for ; Mon, 7 Jul 2014 12:06:25 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2C3886D68C; Mon, 7 Jul 2014 15:06:20 -0400 (EDT) Message-ID: <53BAEFAA.1090905@iang.org> Date: Mon, 07 Jul 2014 20:06:18 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: saag@ietf.org References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> <53B59BC6.7020507@iang.org> <53B6FEB0.50804@iang.org> 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/_GIn3Fv2GlP89p6gix3X150etUo Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:06:27 -0000 On 7/07/2014 13:40 pm, Derek Atkins wrote: > ianG writes: > >> I wonder if it is is possible to list the potential strategies for alg >> agility? And perhaps add their pros&cons? Here's a strawman list of >> possibilities, with full intent to be rewritten entirely, just in case >> this helps: Derik comments on 1. and 5. Should we take that as endorsement for the extremes? >> 1. smorgasbord, as typified by SSL. Anyone can add an algorithm, and >> once added this tends to be supported for a long time. Crypto freedom >> taken to vanity extremes. >> >> Downside is weakness of deprecation; weak ciphers stick around forever. >> As algorithms are the component of choice, protocol errors tend to >> impact many algorithms. Lots of 'downgrade' possibility, lots of user >> confusion or ignorance, waste in maintenance of too many components. > > I hit this problem a couple weeks ago. I was trying to buy a train > ticket online but I was getting an SSL error: no common cipher. It > turns out the server *ONLY* supported a few DES ciphers, which of course > I had turned off. They didn't support any of the AES or RC4 ciphers > that firefox-30 supported. Quite annoying. "Luckily" I know how to > enable those ciphers in firefox, so I was able to get my train ticket, > but I certainly feel like I need to watch my credit card statement for > the next month or two. *shudders* As long as you don't advance that as some sort of positive experience to keep those practices going, it's a fine beer anacdote ;-) >> 5. one true cipher suite. No config fall back available, a failure in >> the suite triggers a requirement to upgrade the entire version. Simpler >> to implement, no negotiation woes. > > And no way to recover if the suite is found to be bad. C.f.: DES+MD4. Wait, someone was still using that? Post mid 1990s? That's ... irresponsible. No need to discuss, there is no good advice for that sort of stupidity. iang From nobody Mon Jul 7 12:31: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 6438B1B2870 for ; Mon, 7 Jul 2014 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS1nMMJcMIuA for ; Mon, 7 Jul 2014 12:30:59 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF101B286D for ; Mon, 7 Jul 2014 12:30:59 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 7FF961E434; Mon, 7 Jul 2014 19:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404761457; bh=NrMUP4A/V+18+lmpVSwnnpq7R41pEyBBk2a0aoRd+Qc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HRMbboHgra65MbCm9tUU1EmfTZTfJ6sxygMV70cj8fhrYm917/tMpo1m0KsUTTkKY z1/L2otJJtl+CPK1UWa9Ki/F9ku7kWqJJPgrqVKI9mXvzQmdt49O7X3FMcb9sDCuqZ pUu3Suz4kQv/CMsYuUExRe26LJzHZuHE4ZfLYCB8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BE9956001E; Mon, 7 Jul 2014 19:25:18 +0000 (UTC) From: James Cloos To: saag@ietf.org In-Reply-To: <20140707072918.GG12456@mournblade.imrryr.org> (Viktor Dukhovni's message of "Mon, 7 Jul 2014 07:29:18 +0000") References: <53B354FF.3040609@cs.tcd.ie> <53B357AE.7040207@isi.edu> <20140702005918.GL16666@mournblade.imrryr.org> <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <20140702223135.GB12456@mournblade.imrryr.org> <20140707072918.GG12456@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 07 Jul 2014 15:25:18 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140707:saag@ietf.org::J5h7EmwyfoVNYKNP:000xuvLM X-Hashcash: 1:30:140707:viktor1dane@dukhovni.org::KLDIZzJ+rKeBAvRC:000000000000000000000000000000000000+TICc Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6H2wFRQ7mBsOr7sEXGCWaRFiquo Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 19:31:00 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> SMTP opportunistic DANE TLS has no UI. Rather, the goal is resist VD> MiTM when possible, and secondarily to log the resulting protection VD> level. Some will consider forensics -- including logs -- to be a UI element for purposes such as this. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 7 12:40: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 698371B28AB for ; Mon, 7 Jul 2014 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdBqpqt80g9O for ; Mon, 7 Jul 2014 12:40:22 -0700 (PDT) Received: from mip.polyamory.org (mip.aaaaa.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id 314FB1B28A6 for ; Mon, 7 Jul 2014 12:40:22 -0700 (PDT) Received: by mip.polyamory.org (Postfix, from userid 1002) id A667010760; Mon, 7 Jul 2014 15:40:18 -0400 (EDT) Date: Mon, 7 Jul 2014 15:40:18 -0400 From: Ofer Inbar To: Derek Atkins Message-ID: <20140707194018.GZ482@mip.aaaaa.org> References: <20140702051329.GM16666@mournblade.imrryr.org> <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: American Association Against Acronym Abuse Archived-At: http://mailarchive.ietf.org/arch/msg/saag/F0a0NNsl78-W0Sy9iI_aX0h3sHc Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 07 Jul 2014 19:40:25 -0000 I like Viktor's new text, and two reasons I like it are: 1. It makes clear that one of the main goals of work on opportunistic encryption is to avoid the (now common) situation where lack of authentication capability leads to lack of encryption even though encryption capability does exist. 2. It's deliberately broad and... strategically imprecise? Something like that. It doesn't try to pin down requirements and UI elements the way a specific protocol would have to, so that it gives us a term that describes a broad strategy into which different approaches can fit. Each protocol may make different trade-offs. -- Cos From nobody Mon Jul 7 16:17: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 532091B297E for ; Mon, 7 Jul 2014 16:17:33 -0700 (PDT) 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 LxgSIzMeVWoF for ; Mon, 7 Jul 2014 16:17:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED921B28A5 for ; Mon, 7 Jul 2014 16:17:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9B3022AB00C; Mon, 7 Jul 2014 23:17:29 +0000 (UTC) Date: Mon, 7 Jul 2014 23:17:29 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140707231729.GB27568@mournblade.imrryr.org> References: <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <20140707194018.GZ482@mip.aaaaa.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140707194018.GZ482@mip.aaaaa.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QNP-dF8feF6ZzEZkzYXKDOEdjBY Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:17:33 -0000 On Mon, Jul 07, 2014 at 03:40:18PM -0400, Ofer Inbar wrote: > I like Viktor's new text, and two reasons I like it are: > > 1. It makes clear that one of the main goals of work on opportunistic > encryption is to avoid the (now common) situation where lack of > authentication capability leads to lack of encryption even though > encryption capability does exist. > > 2. It's deliberately broad and... strategically imprecise? Something > like that. It doesn't try to pin down requirements and UI elements > the way a specific protocol would have to, so that it gives us a > term that describes a broad strategy into which different > approaches can fit. Each protocol may make different trade-offs. I am pleased to see both points are sufficiently clear, and yes "strategically imprecise" is indeed intentional. -- Viktor. From nobody Mon Jul 7 17:49: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 1B7581B29A2 for ; Mon, 7 Jul 2014 17:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7cJOVUYIOxk for ; Mon, 7 Jul 2014 17:49:03 -0700 (PDT) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2AD1B2995 for ; Mon, 7 Jul 2014 17:49:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id 4CAD0E12F for ; Mon, 7 Jul 2014 20:49:01 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBCzbN1cCJzL for ; Mon, 7 Jul 2014 20:49:00 -0400 (EDT) Received: from [192.168.3.137] (24-205-93-255.dhcp.psdn.ca.charter.com [24.205.93.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id A1476E121 for ; Mon, 7 Jul 2014 20:49:00 -0400 (EDT) From: Henry B Hotz Content-Type: multipart/alternative; boundary="Apple-Mail=_0450C806-B22F-4CD5-B988-46F53EE5946E" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 7 Jul 2014 17:48:59 -0700 References: <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <20140707194018.GZ482@mip.aaaaa.org> <20140707231729.GB27568@mournblade.imrryr.org> To: saag@ietf.org In-Reply-To: <20140707231729.GB27568@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9CKqxlkHx1k5QhYtNYLkq9kFpu4 Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 00:49:05 -0000 --Apple-Mail=_0450C806-B22F-4CD5-B988-46F53EE5946E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2014, at 4:17 PM, Viktor Dukhovni = wrote: > "strategically imprecise" I think that term will see wider use, though hopefully no more that OS = itself. +1 on the new text, and I like the 01 draft. Personal email. hbhotz@oxy.edu --Apple-Mail=_0450C806-B22F-4CD5-B988-46F53EE5946E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii viktor1dane@dukhovni.org> = wrote:


I think = that term will see wider use, though hopefully no more that OS = itself.

+1 on the new text, and I like the 01 = draft.

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_0450C806-B22F-4CD5-B988-46F53EE5946E-- From nobody Mon Jul 7 18:52: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 820471B29A4 for ; Mon, 7 Jul 2014 18:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRDh9iDn-o0X for ; Mon, 7 Jul 2014 18:52:11 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D617B1B2941 for ; Mon, 7 Jul 2014 18:52:08 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-36-53bb4ec5995a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E0.11.32177.5CE4BB35; Mon, 7 Jul 2014 21:52:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s681q4r1005789; Mon, 7 Jul 2014 21:52:05 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s681q3GH003506; Mon, 7 Jul 2014 21:52:04 -0400 From: Tom Yu To: Henry B Hotz References: <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <20140707194018.GZ482@mip.aaaaa.org> <20140707231729.GB27568@mournblade.imrryr.org> Date: Mon, 07 Jul 2014 21:52:03 -0400 In-Reply-To: (Henry B. Hotz's message of "Mon, 7 Jul 2014 17:48:59 -0700") Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixG6nonvUb3ewweluTYuP9xayWEzp72Ry YPJYsuQnk8fWpr/MAUxRXDYpqTmZZalF+nYJXBm/m16xFtxhqujdfp+pgXE2UxcjB4eEgInE 9y9qXYycQKaYxIV769m6GLk4hARmM0l87njPBOFsYJR4+/YLM4TzmlHiQccBRpBuNgFpiaOL y0C6RQQUJRpbjrOBhJkFhCV2tEqDmMICBhKbPxtBdN5klvh/vosZpJxFQFXi+PvfLCA2p0C1 xIG25WwgNq+ArsSmF5fAangEOCU+Tb3CDhEXlDg58wlYPbOAlsSNfy+ZJjAKzEKSmoUktYCR aRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZQMHJK8u1g/HpQ6RCjAAejEg/v ioO7goVYE8uKK3MPMUpyMCmJ8v7x2R0sxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3xXKgct6U xMqq1KJ8mJQ0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBO95X6ChgkWp6akVaZk5JQhp Jg5OkOE8QMNrQWp4iwsSc4sz0yHypxgVpcR520AuEgBJZJTmwfXCksUrRnGgV4R5l4O08wAT DVz3K6DBTECDP7/fATK4JBEhJdXAGMB0ds2Koy1y7qe/f1vtnhFbn7pp/+R/C7YbmvwXPvxF aeubW/LLfl5ZVFvqWDSlPP81u+qEwqVbL+nocBVNOSusdfOUcr7/rirva6wu520UL3RfK/7D 9/Dmioul+SLvL6sqLLPzuHt0vecBmdsbMkQO9VzOyM38/1hZ2vpnFMc6j+4g56BFckosxRmJ hlrMRcWJABvb1iHxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/djTD_DD1je7zB7AsA_41eOu1ab0 Cc: saag@ietf.org Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 01:52:13 -0000 Henry B Hotz writes: > On Jul 7, 2014, at 4:17 PM, Viktor Dukhovni wrote: > >> "strategically imprecise" > > I think that term will see wider use, though hopefully no more that OS itself. I believe this is also known in broader contexts as "diplomatic ambiguity" or "constructive ambiguity". From nobody Mon Jul 7 21:54: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 C9BC11B2A2D for ; Mon, 7 Jul 2014 21:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 yRwL0du1AmIJ for ; Mon, 7 Jul 2014 21:54:52 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 0501D1B2A25 for ; Mon, 7 Jul 2014 21:54:51 -0700 (PDT) Received: (qmail 3149 invoked by uid 0); 8 Jul 2014 04:54:50 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 8 Jul 2014 04:54:50 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id Pmub1o00X2molgS01mueUT; Tue, 08 Jul 2014 04:54:48 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=zOy1VSPGCM8A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=8DlgOUzT2xeDgoSnnPAA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=HHE21bycryu05SSOooMvTV2ewvqyHXjMVM/zhZ1cAUY=; b=WelnMfVFIHNCX5nkN0puFjUGcKgxzwyhStu3bi28+ou/hR+O3c9tTbxmr5blcOxsYlHluDJK8f0bwpVrxZocVNR38Znmq6LLpCCaMOzTaZhd/EzPpggTGfY1vM0tYM1k; Received: from [71.231.123.189] (port=58688 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4NQL-0008AQ-E4; Mon, 07 Jul 2014 22:54:37 -0600 Message-ID: <53BB798A.3080101@tomh.org> Date: Mon, 07 Jul 2014 21:54:34 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/saag/e-O95jqyEtSViVnPaNwtGYvsAUM Subject: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 04:54:54 -0000 Hi all, Apologies for cross-posting, but Stephen Farrell raised a DISCUSS (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). Stephen asked me to raise this question for discussion on both the HIP and SAAG lists. Stephen's discuss questions the specification of "MUST to implement" for the NULL encryption option of the ESP_TRANSFORM parameter: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 Stephen asks why is this a MUST to implement? The history behind this that I'm aware of is that since HIP does not have an AH, only ESP, the ESP with NULL encryption mode can provide authentication. It was also stated in previous drafts that this mode supports debugging. Null encryption was also specified as a MUST to implement in RFC5202 and dates back to earlier versions of the HIP base draft (to 2003: http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). - Tom From nobody Tue Jul 8 03:33: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 BE8D91B2A68; Tue, 8 Jul 2014 03:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-rlfakWGjrG; Tue, 8 Jul 2014 03:33: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 EBDEE1B27E7; Tue, 8 Jul 2014 03:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BB1ABE10; Tue, 8 Jul 2014 11:33:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKIuCWuqcdXj; Tue, 8 Jul 2014 11:33:03 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.22.239]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2B65BE0F; Tue, 8 Jul 2014 11:33:02 +0100 (IST) Message-ID: <53BBC8DE.1010006@cs.tcd.ie> Date: Tue, 08 Jul 2014 11:33:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> In-Reply-To: <53BB798A.3080101@tomh.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/OilljW2ruvLi8t2XtCSAyUgd9KU Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 10:33:08 -0000 Thanks Tom, On 08/07/14 05:54, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. It was also > stated in previous drafts that this mode supports debugging. > > Null encryption was also specified as a MUST to implement in RFC5202 and > dates back to earlier versions of the HIP base draft (to 2003: > http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). Right. I guess my discuss has a generic part and a hip specific part. Generic: is it still considered a good plan to have null confidentiality suites such as these? Or for those to be Mandatory-To-Implement (MTI)? That clearly was the generic consensus as we have these in a number of protocols. The new reasons to move from that I think are: 1) we no longer need this for debugging purposes really since libraries and dev tools have moved on and are better now, and we specifically no longer need these for protocols that are no longer new, 2) BCP188 could be considered to argue against having these as they could be misused. (All the old arguments of course do still apply, but I think the above are the ones that are new.) So is that enough to shift the consensus away from having these or having them be MTI? Specific: is there anything specific about hip that would trump the general point above? Note that there could be, regardless of where consensus lies on the generic question. FWIW, my own answers for these are that its probably a better plan today to not have (or make MTI) these null confidentiality ciphersuites, and I don't know that hip would have any specific reason to diverge from that. But I'd really like to see if there is a modified consensus on this or not. (To be clear, if there's not a new consensus then the current one would seem to still apply here and I'll clear my discuss.) Cheers, S. > > - Tom From nobody Tue Jul 8 03:56: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 634A41B27F4 for ; Tue, 8 Jul 2014 03:55: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 AoqwDzfFAdyP for ; Tue, 8 Jul 2014 03:55:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83811B27E7 for ; Tue, 8 Jul 2014 03:55:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 3002F6D6F3; Tue, 8 Jul 2014 06:55:55 -0400 (EDT) Message-ID: <53BBCE39.3050308@iang.org> Date: Tue, 08 Jul 2014 11:55:53 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53B41267.9040105@bbn.com> <734.1404313874@sandelman.ca> <53B43286.6090004@fifthhorseman.net> <27060.1404340087@sandelman.ca> <53B4888F.50201@cs.tcd.ie> <20140702230800.GC12456@mournblade.imrryr.org> <53B491AF.5090202@cs.tcd.ie> <20140706133437.GW12456@mournblade.imrryr.org> <20140707194018.GZ482@mip.aaaaa.org> <20140707231729.GB27568@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/3Ul-cDXPYYY6F06MKMoDconGYmc Subject: Re: [saag] opportunistic security again X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 10:55:59 -0000 On 8/07/2014 02:52 am, Tom Yu wrote: > Henry B Hotz writes: > >> On Jul 7, 2014, at 4:17 PM, Viktor Dukhovni wrote: >> >>> "strategically imprecise" >> >> I think that term will see wider use, though hopefully no more that OS itself. > > I believe this is also known in broader contexts as "diplomatic > ambiguity" or "constructive ambiguity". That all fits nicely with win-win negotiation; You need the openness of ambiguity to find the solutions from exchange of interests, rather than headbutting with positions and discovering it hurts. iang From nobody Tue Jul 8 05:06: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 DD5D71B2853 for ; Tue, 8 Jul 2014 05:06:08 -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 cC59CVdDwwVd for ; Tue, 8 Jul 2014 05:06:06 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65041B2A29 for ; Tue, 8 Jul 2014 05:06:06 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 50AE56D613; Tue, 8 Jul 2014 08:06:02 -0400 (EDT) Message-ID: <53BBDEA8.7090706@iang.org> Date: Tue, 08 Jul 2014 13:06:00 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BB798A.3080101@tomh.org> In-Reply-To: <53BB798A.3080101@tomh.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/JPf8bmB-VWEotHyRVicZ12yPm9A Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 12:06:09 -0000 On 8/07/2014 05:54 am, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. IIUC, this derives from old arguments that encryption is expensive so there might be a use case [0] where it is desirable to turn it off, and users should have that option because it's cost free. This is more or less a deprecated argument. Encryption is no longer expensive. The history of users is that they don't have a need to turn it off, they aren't equipped to make the decision properly, and giving them one more knob to play with creates one more support headache. And, it isn't cost free: null ciphers introduce a lovely downgrade attack, and marginal internal fault possibilities. It also relates to a bygone age where active MITM was believed a greater enemy than passive eavesdropping, so auth was king. History hasn't been kind to that view. > It was also > stated in previous drafts that this mode supports debugging. If it is debugging, the advice is backwards, IMHO. NULL ciohers should not be mandatory to implement. Developers will do what they will, if they need a mode like that they will add it, they don't need to be told they must do it. Better advice would be that that production code MUST be shipped with all dangerous debugging modes stripped out, not implemented. iang [0] curiously, a modern use case might be found in Bitcoin where encryption isn't needed because the tx are all published anyway. I find this a tough mental barrier. From nobody Tue Jul 8 05:13: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 71DC81B27FD for ; Tue, 8 Jul 2014 05:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZCJIaYlE_bJ for ; Tue, 8 Jul 2014 05:13:29 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5FC1A03B0 for ; Tue, 8 Jul 2014 05:13:28 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so476418wgh.29 for ; Tue, 08 Jul 2014 05:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=h4aFOVxqm6ADFpnlw9KE7y+9wixCkgPVzDTQSz4O2j8=; b=XH7TY3bGP7dHw9Vw52HgjweYHDNn5NO7S0GCjsgXX6JSmg+7fMQslNkYYz0rVYyEni HkqDPQxuRkOOM+pK8C0pQXa6PWFWZUiArbvQb4NhJeVATkndl1Nsea1ozXN0rGJOCqD8 HGuYEV6LPp35IpwNMTTjg5nhQgBfWnnjbmb80jYJV9CWtIBLShXIm4CNPC66w8tKVC4H cb6GxLh+kvznw5ZkGzOqsDYgHBa48aSC6/LLnBm6oFxx8dnWIX4/XTja5wWOsZV2lEMk nh6pp3eXKZxrtwHmGia0vOzkkFo6EOGTW4zlnbWphckVo4uEuCeV3+92ThjZkAghe1Lg twcg== X-Received: by 10.180.83.202 with SMTP id s10mr3513006wiy.25.1404821606429; Tue, 08 Jul 2014 05:13:26 -0700 (PDT) Received: from [10.2.0.78] (89-139-50-162.bb.netvision.net.il. [89.139.50.162]) by mx.google.com with ESMTPSA id wp6sm96046164wjb.9.2014.07.08.05.13.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 05:13:25 -0700 (PDT) Message-ID: <53BBE064.7080607@gmail.com> Date: Tue, 08 Jul 2014 15:13:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> In-Reply-To: <53BBDEA8.7090706@iang.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LExfmhbcU50WTf-suGQ-KDAKWOQ Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 12:13:30 -0000 I think the debugging argument is still valid. For example, host-side debugging of IPsec with tcpdump is still somewhat broken on many Linux boxes. And please bear in mind that if NULL-auth is not implemented on BOTH peers, you cannot use it to debug your implementation even if your side does have such a debug knob. So I would recommend something like "MUST implement (or maybe SHOULD). MUST NOT negotiate by default". Thanks, Yaron From nobody Tue Jul 8 06:56: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 0DF981B27AC for ; Tue, 8 Jul 2014 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZpnmkvEy2CC for ; Tue, 8 Jul 2014 06:56:39 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1020B1B27A0 for ; Tue, 8 Jul 2014 06:56:38 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA10288; Tue, 8 Jul 2014 09:56:21 -0400 (EDT) Date: Tue, 8 Jul 2014 09:56:21 -0400 (EDT) From: Mouse Message-Id: <201407081356.JAA10288@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: Tue, 8 Jul 2014 09:40:28 -0400 (EDT) To: saag@ietf.org In-Reply-To: <53BBDEA8.7090706@iang.org> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OYO-uU3kIxmf4mRKzbMZRSiW-us Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 13:56:41 -0000 > This is more or less a deprecated argument. Encryption is no longer > expensive. [...] Kinda. It still is expensive in some fields (or, for some applications, if you prefer). The attitude that encryption is cheap is valid for only some purposes. They're important purposes, certainly, but mistaking them for the whole world evidences a rather blinkered mindset. > The history of users is that they don't have a need to turn it off, > they aren't equipped to make the decision properly, and giving them > one more knob to play with creates one more support headache. If your target audience is mass-market end users, yes. That is not the only target audience. If you want to argue that it's the only audience of relevance to 5202-bis, fine, but that's not what what you wrote sounded like to me. > It also relates to a bygone age where active MITM was believed a > greater enemy than passive eavesdropping, [...] Bygone age? For some threat models, it still is. Assuming everyone's threat model matches yours is about as good an idea as assuming everyone's value of "computationally cheap" matches yours. /~\ 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 Tue Jul 8 07:25: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 48DB81B2ACF for ; Tue, 8 Jul 2014 07:25:17 -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 se9vN03RyvCR for ; Tue, 8 Jul 2014 07:25:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5441B27AC for ; Tue, 8 Jul 2014 07:25:16 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s68EPEDj042375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Jul 2014 07:25:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <53BBE064.7080607@gmail.com> Date: Tue, 8 Jul 2014 07:25:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BAE608C-77B9-4783-BD78-268AC3007B1F@vpnc.org> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BBE064.7080607@gmail.com> To: saag X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/O-lJko7actqkTRlCnW_JE8d7avw Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 14:25:17 -0000 On Jul 8, 2014, at 5:13 AM, Yaron Sheffer wrote: > So I would recommend something like "MUST implement (or maybe SHOULD). = MUST NOT negotiate by default". If the only reason for this is debugging, then it could be "SHOULD = implement to allow debugging" and "NULL encryption MUST NOT be exposed = in the administrative interface as a normal parameter, and MUST only be = allowed when both endpoints are explicitly put into a debugging mode". --Paul Hoffman= From nobody Tue Jul 8 08:15: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 25EC11B27E5; Tue, 8 Jul 2014 03:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HJtwNEsK5rQ; Tue, 8 Jul 2014 03:04:41 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id ADAF41B27DE; Tue, 8 Jul 2014 03:04:41 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 1BF35308DEE; Tue, 8 Jul 2014 13:04:38 +0300 (EEST) Message-ID: <53BBC235.6030801@cs.hut.fi> Date: Tue, 08 Jul 2014 13:04:37 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> In-Reply-To: <53BB798A.3080101@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aIzlkOR7f9h0Xkik3cXQbaKW_oo X-Mailman-Approved-At: Tue, 08 Jul 2014 08:15:40 -0700 Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 10:04:44 -0000 Hi, On 07/08/2014 07:54 AM, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. It was also > stated in previous drafts that this mode supports debugging. > > Null encryption was also specified as a MUST to implement in RFC5202 and > dates back to earlier versions of the HIP base draft (to 2003: > http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). maybe we should keep it as it is for easier, incremental interoperability testing. The same issue was discussed earlier in this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg01779.html If you think this is a big problem, I'd suggest replacing NULL with suite id 9. From nobody Tue Jul 8 08:16: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 CCA3F1B2B0B; Tue, 8 Jul 2014 08:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdgropSepPlP; Tue, 8 Jul 2014 08:16:07 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26881B2811; Tue, 8 Jul 2014 08:16:07 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id C94701E512; Tue, 8 Jul 2014 15:16:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404832566; bh=gaX/6Wjya3yTpcfa0/Am3DODFs+M4n71RdtW18i3KTM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lwDVx2ecIMWDQxjFeXiKw7Bb0cSfDmN5vnvMuw97C1us75Jz9g1iLWs9hRtmR8LQY IaJWV1D6HgHh8mGMqPA8mkz852qgpQCdH9h8qSjHg54/fTRShDCb4Vx4oDyvjpTn+G CHt9kYLMgEdTjXhMf7LYXlYc+Cz5jmvF9IgolQV4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5D33660022; Tue, 8 Jul 2014 15:06:03 +0000 (UTC) From: James Cloos To: Tom Henderson In-Reply-To: <53BB798A.3080101@tomh.org> (Tom Henderson's message of "Mon, 07 Jul 2014 21:54:34 -0700") References: <53BB798A.3080101@tomh.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 08 Jul 2014 11:06:03 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140708:tomh@tomh.org::T0MNsVncLJB9cP2y:000cwtka X-Hashcash: 1:30:140708:hipsec@ietf.org::DfIEo4o9SvSteygn:07AmQT X-Hashcash: 1:30:140708:saag@ietf.org::Ib/LELvpe1kI9sTa:000tqHve Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r99Enjaq984G0N2FyFDAaIMoCek Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 15:16:09 -0000 >>>>> "TH" == Tom Henderson writes: TH> Stephen's discuss questions the specification of "MUST to implement" TH> for the NULL encryption option of the ESP_TRANSFORM parameter: If those doing IP over Amateur Radio are a use case, they require NULL. Encryption is illegal for most of them (I hear Australia allows it in some cases; AFAIK no other country does) but authentication has value. And that restriction is enforced. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jul 8 08:16: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 3E5141A03BA; Tue, 8 Jul 2014 05:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9JDKkOHMBE8; Tue, 8 Jul 2014 05:39:24 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96D1B2823; Tue, 8 Jul 2014 05:39:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 61E5862A64; Tue, 8 Jul 2014 12:39:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLI50DHFGLrf; Tue, 8 Jul 2014 08:39:12 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 906C6633A3; Tue, 8 Jul 2014 08:39:12 -0400 (EDT) Message-ID: <53BBE66D.2080807@htt-consult.com> Date: Tue, 08 Jul 2014 08:39:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> In-Reply-To: <53BBC8DE.1010006@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Zh_lE4krZuFbBjH8hy4PAMGK2a4 X-Mailman-Approved-At: Tue, 08 Jul 2014 08:16:16 -0700 Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 12:39:26 -0000 On 07/08/2014 06:33 AM, Stephen Farrell wrote: > Thanks Tom, > > On 08/07/14 05:54, Tom Henderson wrote: >> Hi all, >> >> Apologies for cross-posting, but Stephen Farrell raised a DISCUSS >> (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: >> Using the Encapsulating Security Payload (ESP) Transport Format with >> the Host Identity Protocol (HIP). Stephen asked me to raise this >> question for discussion on both the HIP and SAAG lists. >> >> Stephen's discuss questions the specification of "MUST to implement" for >> the NULL encryption option of the ESP_TRANSFORM parameter: >> >> http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 >> >> Stephen asks why is this a MUST to implement? The history behind this >> that I'm aware of is that since HIP does not have an AH, only ESP, the >> ESP with NULL encryption mode can provide authentication. It was also >> stated in previous drafts that this mode supports debugging. >> >> Null encryption was also specified as a MUST to implement in RFC5202 and >> dates back to earlier versions of the HIP base draft (to 2003: >> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). > Right. I guess my discuss has a generic part and a hip specific > part. > > Generic: is it still considered a good plan to have null > confidentiality suites such as these? Or for those to be > Mandatory-To-Implement (MTI)? That clearly was the generic > consensus as we have these in a number of protocols. The > new reasons to move from that I think are: 1) we no longer > need this for debugging purposes really since libraries > and dev tools have moved on and are better now, and we > specifically no longer need these for protocols that are > no longer new, 2) BCP188 could be considered to argue > against having these as they could be misused. (All the > old arguments of course do still apply, but I think the > above are the ones that are new.) So is that enough to > shift the consensus away from having these or having > them be MTI? I should point out that I lobbied hard for CMAC and GMAC added to 5202, as they are better constructs for doing auth only, or so I have been told. I seem to recall during this discussion not to add these options as we have NULL which we need anyway. I argued back that for systems that have AES-CCM or GCM in hardware, there would be a desire for CMAC or GMAC over HMAC. SO now we have 3 suites that provide auth only with selection based on what MACing works best for the system(s) in question. So given this, NULL is to balance the auth only suites or what? I should also point out that the code we have today may not be the only code we have tomorrow. That NULL does provide a valuable test tool. So finally, a best implementation practice may to caution parties to accepting NULL. Perhaps NULL when it is the only offered option. Or NULL when the list only contains NULL, CMAC, or GMAC. > > Specific: is there anything specific about hip that would > trump the general point above? Note that there could be, > regardless of where consensus lies on the generic question. > > FWIW, my own answers for these are that its probably a better > plan today to not have (or make MTI) these null confidentiality > ciphersuites, and I don't know that hip would have any specific > reason to diverge from that. But I'd really like to see if > there is a modified consensus on this or not. (To be clear, > if there's not a new consensus then the current one would > seem to still apply here and I'll clear my discuss.) > > Cheers, > S. > > > >> - Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Jul 8 08:24: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 C6C4D1A01AC; Tue, 8 Jul 2014 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i90uO_OF8OI; Tue, 8 Jul 2014 08:24: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 946571A007E; Tue, 8 Jul 2014 08:24:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86964BE07; Tue, 8 Jul 2014 16:24:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxgTZOa__BV5; Tue, 8 Jul 2014 16:24:32 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.57.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71D51BE02; Tue, 8 Jul 2014 16:24:32 +0100 (IST) Message-ID: <53BC0D30.2070507@cs.tcd.ie> Date: Tue, 08 Jul 2014 16:24:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: James Cloos , Tom Henderson References: <53BB798A.3080101@tomh.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/V1rS95vTvkJfj7bG_ZE1kz1reU4 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 15:24:36 -0000 On 08/07/14 16:06, James Cloos wrote: > > If those doing IP over Amateur Radio are a use case, they require NULL. That'd be IPsec, not IP, I guess. How many people actually use IPsec that way? For corner cases like that (and it is utterly a corner case regardless of how laudable a corner case) I'd not have an issue with there being some other RFC to which they could conform, should there be sufficient interest in writing such. I don't myself see that can ever justify an MTI for all implementations though. S. From nobody Tue Jul 8 08:34: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 DDB5C1B2826 for ; Tue, 8 Jul 2014 08:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UrgZmGyeUfm for ; Tue, 8 Jul 2014 08:34:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5076F1A020B for ; Tue, 8 Jul 2014 08:34:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2EB3BE07 for ; Tue, 8 Jul 2014 16:34:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWgemefSvnRb for ; Tue, 8 Jul 2014 16:34:44 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.57.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F0D2BE02 for ; Tue, 8 Jul 2014 16:34:44 +0100 (IST) Message-ID: <53BC0F94.8020608@cs.tcd.ie> Date: Tue, 08 Jul 2014 16:34:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> In-Reply-To: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140708150940.1412.7682.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/5RvZjhkKmjHF33eIbMCBbWldWjY Subject: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:34:48 -0000 IETF LC started as promised. Cheers, S. -------- Original Message -------- Subject: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC Date: Tue, 08 Jul 2014 08:09:40 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Opportunistic Security: some protection most of the time' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines the term "opportunistic security". In contrast to the established approach of delivering strong protection some of the time, opportunistic security strives to deliver at least some protection most of the time. The primary goal is therefore broad interoperability, with security policy tailored to the capabilities of peer systems. The file can be obtained via http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ No IPR declarations have been submitted directly on this I-D. This document and a predecessor have been the subject of discussion on the saag mailing list. [1] [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html From nobody Tue Jul 8 08:46: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 ECA211B2B30 for ; Tue, 8 Jul 2014 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=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 C-Ro3FkM6WiX for ; Tue, 8 Jul 2014 08:46:03 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E0B1B2B27 for ; Tue, 8 Jul 2014 08:46:03 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id i13so5922770veh.1 for ; Tue, 08 Jul 2014 08:46:02 -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=xtApmNcAUvT3TbTbeuqFqf4VVRyhAGbQiRB7/PuBnhY=; b=O3KpUy+rKoXUkz2QvzOcKz8HHmAYy8IKtPptB/QXSXVkW+TFlXV/xTNUGMosYvpD33 ZV7kTW/KeDzNbfxPFSpz86kHFdaJNMQpczmWg96nqoRGyk3EMaeUiDv1p/T6oAi04yMA cbysHBYqnSXoAWXOx93XLGPtbT8+sRDAjX+g4e7ZdBEvZWSrLo+YnYbtB22N/W2zb8DT pTLIVeYzI5aEpvawwd+ZckN4yORzIA5Rx0hTj6PKa8AcNyPvrp7LDj6CYdwJRSrvlWDL TnMgvjB18TnsuiNtp62wziPScY06ijS0RTNX2TPoUDpLkaWaDzng9ee5BYn8oQVyyBx8 T2rA== MIME-Version: 1.0 X-Received: by 10.52.88.44 with SMTP id bd12mr207290vdb.86.1404834362265; Tue, 08 Jul 2014 08:46:02 -0700 (PDT) Received: by 10.220.227.7 with HTTP; Tue, 8 Jul 2014 08:46:02 -0700 (PDT) In-Reply-To: <53BBDEA8.7090706@iang.org> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> Date: Tue, 8 Jul 2014 11:46:02 -0400 Message-ID: From: Jeffrey Walton To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/j12YFKgfBv2a__b9cwpKzMu204Q Cc: saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:46:04 -0000 On Tue, Jul 8, 2014 at 8:06 AM, ianG wrote: > On 8/07/2014 05:54 am, Tom Henderson wrote: >> ... >> It was also >> stated in previous drafts that this mode supports debugging. > > If it is debugging, the advice is backwards, IMHO. NULL ciohers should > not be mandatory to implement. Developers will do what they will, if > they need a mode like that they will add it, they don't need to be told > they must do it. > When we test applications, we don't force a downgrade to NULL; we set up a Burpe or Charles proxy and MitM the connection. I've only seen one person force a downgrade during ST&E. Perhaps others have different experience. That one downgrade attack was performed by Chris Paget in a mobile security talk. She built a GNU radio and cell phones in the room camped to her base station because it provided the strongest signal. The base station provided A0/0 (A5/2 probably would have worked just as well since it has nearly no security). Jeff From nobody Tue Jul 8 09:45: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 EF5461B2BDB; Tue, 8 Jul 2014 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XERkGx-4_e_B; Tue, 8 Jul 2014 09:45:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A2A1B2BD9; Tue, 8 Jul 2014 09:45:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 4F8B21E4FB; Tue, 8 Jul 2014 16:45:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404837950; bh=LyKNDrIC2MSZDnlTIUTVUl0gnsqu6lIGIsNx36ELOB4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hZal5QpXBJ2uz5mAd+tH4W6WPWCC4ClX8JvxgKJZwec0WVsbjZRvgW/OOQ2x3avmx MxDPtg0J8NrJ+8hziApcyYWI91ZqOFQmB+FCfQdrH62Zj/pzZF6cejfUvLcaPkfyMl lASD9nTRGhMsqXRv+MIGI0vPtkIQUi1tLLkwklfM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1AFA360022; Tue, 8 Jul 2014 16:37:29 +0000 (UTC) From: James Cloos To: Stephen Farrell In-Reply-To: <53BC0D30.2070507@cs.tcd.ie> (Stephen Farrell's message of "Tue, 08 Jul 2014 16:24:32 +0100") References: <53BB798A.3080101@tomh.org> <53BC0D30.2070507@cs.tcd.ie> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 08 Jul 2014 12:37:29 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140708:stephen.farrell@cs.tcd.ie::6rHADQ+2+3jnZE0d:00000000000000000000000000000000000ooP3q X-Hashcash: 1:30:140708:tomh@tomh.org::VNj3cMxYoYrYEJUS:000COA7M X-Hashcash: 1:30:140708:hipsec@ietf.org::2ftBm3dRcqFg2TKh:0oOyF7 X-Hashcash: 1:30:140708:saag@ietf.org::XWVrU0AADgxgZHQH:0009OEZW Archived-At: http://mailarchive.ietf.org/arch/msg/saag/b2CnVyYFSnoawf1F-yxLxoACxVE Cc: hipsec@ietf.org, Tom Henderson , saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 16:45:54 -0000 >>>>> "SF" == Stephen Farrell writes: SF> That'd be IPsec, not IP, I guess. How many people actually SF> use IPsec that way? I don't know. AIUI, hams have been specified as a reason for NULL for most ietf work product. For this case, though, it seems Robert's suggestion of CMAC and GMAC may be better long term. Although there is stil the issue of compatibility with existing users, if there are any. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jul 8 10:54: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 CFB5A1A035E; Tue, 8 Jul 2014 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBd2caHBxiVT; Tue, 8 Jul 2014 10:54:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AFA1A0332; Tue, 8 Jul 2014 10:54:36 -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 s68Hs79x022599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 10:54:08 -0700 (PDT) Message-ID: <53BC303F.5060300@isi.edu> Date: Tue, 08 Jul 2014 10:54:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" , IETF discussion list References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> In-Reply-To: <53BC0F94.8020608@cs.tcd.ie> 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/IiExcBHqGhcProUZfhAVyphi9Ts Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:54:37 -0000 I didn't see the post on the main list, but my view is that this doc needs to be handled in SAAG. I do not support its moving forward as an individual draft. Joe On 7/8/2014 8:34 AM, Stephen Farrell wrote: > > IETF LC started as promised. > > Cheers, > S. > > > -------- Original Message -------- > Subject: Last Call: > (Opportunistic Security: some protection most of the time) to > Informational RFC > Date: Tue, 08 Jul 2014 08:09:40 -0700 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Opportunistic Security: some protection most of the time' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering strong protection some of the > time, opportunistic security strives to deliver at least some > protection most of the time. The primary goal is therefore broad > interoperability, with security policy tailored to the capabilities > of peer systems. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > This document and a predecessor have been the subject of discussion > on the saag mailing list. [1] > > [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html > > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Jul 8 11:00: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 DA3F61A035E; Tue, 8 Jul 2014 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, 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 YpwZBvw1Gwi3; Tue, 8 Jul 2014 10:59:57 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A981A02EF; Tue, 8 Jul 2014 10:59:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FE5820028; Tue, 8 Jul 2014 14:00:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1D07E63B0E; Tue, 8 Jul 2014 13:59:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0908163B09; Tue, 8 Jul 2014 13:59:54 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53BBC8DE.1010006@cs.tcd.ie> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@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/ODqJ75EuV0VxysCwv35WM7PS5jU Cc: hipsec@ietf.org, Tom Henderson , saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 08 Jul 2014 17:59:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Stephen Farrell wrote: > Generic: is it still considered a good plan to have null > confidentiality suites such as these? Or for those to be > Mandatory-To-Implement (MTI)? That clearly was the generic consensus = as > we have these in a number of protocols. The new reasons to move from > that I think are: 1) we no longer need this for debugging purposes > really since libraries and dev tools have moved on and are better now, > and we specifically no longer need these for protocols that are no > longer new, 2) BCP188 could be considered to argue against having the= se There are an incredible number of systems (Linux with stock-in-kernel NETKEY IPsec for instance), where it is impossible or very very difficult to get a packet capture of the traffic after decryption, but before it goes up the protocol stack.=20 On such systems, if you have a problem in the field with a protocol that ru= ns over ESP (whether HIP or IKEv2 keyed), and you can't figure out how it work= s, and it appears to with without ESP, then the lack of debugging means that y= ou turn off all security. ESP-authenticated-with-NULL-encryption is debuggable in the field. Not having it, means turning off ESP; and if the problem is in the link between the ESP layer and the upper layer, then...=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7wxl4CLcPvd0N1lAQJDYAf/UNaXFLaXOUjzXPQYc5DH9qYpqRHNB6Ca QkzqYeBgpcyB/uCNcNoI9/nkiF+3Q6wlonQd3xbt1lnp/OFWTX1ifb2Qcqt7u7VT uISTSpexLad1u/OPbuLcuHNzOIAJzd+it1WX0ngdKRcf98dn6jyYQcCzy1PlT8XB rKWd2I12F3FKezPeuo9LurkYBmwo3ytkadla/UwL291M5nQ+BDG5+Ds8nHvpNvCS hBOdzm1lo6h05X9KpZgwRj4Bb8q5I6piv+YD3BsKXFpnQ/1TTZA/x+s4mhAyuK8K NmCVmFRmVQ8NRS4G5yXo88e9zPjoUnExzbTCTn+f8Xxu9rvXgjUE9w== =9bZN -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 8 12:03: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 5A8FD1A04AC; Tue, 8 Jul 2014 12:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gcVRWD5rHOL; Tue, 8 Jul 2014 12:03:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 819E91A0251; Tue, 8 Jul 2014 12:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 36B36BE04; Tue, 8 Jul 2014 20:03:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9tBiipT0kmK; Tue, 8 Jul 2014 20:03:19 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.57.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 85C3EBE09; Tue, 8 Jul 2014 20:03:18 +0100 (IST) Message-ID: <53BC4076.4040803@cs.tcd.ie> Date: Tue, 08 Jul 2014 20:03:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , "saag@ietf.org" , IETF discussion list References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> In-Reply-To: <53BC303F.5060300@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/j0ymLcr9GrYUSu7O3qzsZsFAtgI Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:03:29 -0000 Hi Joe, On 08/07/14 18:54, Joe Touch wrote: > I didn't see the post on the main list, but my view is that this doc > needs to be handled in SAAG. I do not support its moving forward as an > individual draft. saag is not an area working group, so cannot do that. Its just not the same setup as with appsawg for example. And I'm not clear what difference that'd make either, especially since this topic, and, more recently, this draft have been the subject of significant discussion on the saag list. Cheers, S. > > Joe > > On 7/8/2014 8:34 AM, Stephen Farrell wrote: >> >> IETF LC started as promised. >> >> Cheers, >> S. >> >> >> -------- Original Message -------- >> Subject: Last Call: >> (Opportunistic Security: some protection most of the time) to >> Informational RFC >> Date: Tue, 08 Jul 2014 08:09:40 -0700 >> From: The IESG >> Reply-To: ietf@ietf.org >> To: IETF-Announce >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Opportunistic Security: some protection most of the time' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering strong protection some of the >> time, opportunistic security strives to deliver at least some >> protection most of the time. The primary goal is therefore broad >> interoperability, with security policy tailored to the capabilities >> of peer systems. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> This document and a predecessor have been the subject of discussion >> on the saag mailing list. [1] >> >> [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html >> >> >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > From nobody Tue Jul 8 12:08: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 A3DC81A02D8; Tue, 8 Jul 2014 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkZwPcqcCqh9; Tue, 8 Jul 2014 12:08:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB541A0250; Tue, 8 Jul 2014 12:08:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s68J7puY011973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:07:54 -0700 Message-ID: <53BC412B.8050800@dcrocker.net> Date: Tue, 08 Jul 2014 12:06:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , IETF discussion list References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> In-Reply-To: <53BC4076.4040803@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 08 Jul 2014 12:07:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8qHkEZIU_GUswJQWebwNS6aPLuw Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:08:03 -0000 On 7/8/2014 12:03 PM, Stephen Farrell wrote: > And I'm not clear what difference that'd make either, > especially since this topic, and, more recently, this draft > have been the subject of significant discussion on the saag > list. The draft proffers definition of a term that has become central to some recent IETF work. We need a single definition about which there is strong community agreement. The topic has had lively and extended discussion through the saag mailing list, with at least one competing effort (from Steve Kent.) Developing and indicating the degree of rough consensus about this draft from the saag list would indicate the extent to which that discussed converged. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 8 12:54: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 2A3A71A03BE; Tue, 8 Jul 2014 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwffC3v1FL5K; Tue, 8 Jul 2014 12:54:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17491A0377; Tue, 8 Jul 2014 12:54:07 -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 s68Jrn7l018168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:53:49 -0700 (PDT) Message-ID: <53BC4C4D.8070307@isi.edu> Date: Tue, 08 Jul 2014 12:53:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" , IETF discussion list References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> In-Reply-To: <53BC4076.4040803@cs.tcd.ie> 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/njy91g17zSBbBCwS05GF1X8ZHDo Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:54:09 -0000 On 7/8/2014 12:03 PM, Stephen Farrell wrote: > > Hi Joe, > > On 08/07/14 18:54, Joe Touch wrote: >> I didn't see the post on the main list, but my view is that this doc >> needs to be handled in SAAG. I do not support its moving forward as an >> individual draft. > > saag is not an area working group, so cannot do that. Its > just not the same setup as with appsawg for example. That's unfortunate; it would be useful to have this have a home within the IETF. > And I'm not clear what difference that'd make either, > especially since this topic, and, more recently, this draft > have been the subject of significant discussion on the saag > list. Yes, but there was no "WGLC". Jumping straight to IETF LC seems like an end-run around this being homed in a WG - any WG - and IMO it ought to be. Joe > Cheers, > S. > > >> >> Joe >> >> On 7/8/2014 8:34 AM, Stephen Farrell wrote: >>> >>> IETF LC started as promised. >>> >>> Cheers, >>> S. >>> >>> >>> -------- Original Message -------- >>> Subject: Last Call: >>> (Opportunistic Security: some protection most of the time) to >>> Informational RFC >>> Date: Tue, 08 Jul 2014 08:09:40 -0700 >>> From: The IESG >>> Reply-To: ietf@ietf.org >>> To: IETF-Announce >>> >>> >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> - 'Opportunistic Security: some protection most of the time' >>> as Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This memo defines the term "opportunistic security". In contrast to >>> the established approach of delivering strong protection some of the >>> time, opportunistic security strives to deliver at least some >>> protection most of the time. The primary goal is therefore broad >>> interoperability, with security policy tailored to the capabilities >>> of peer systems. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> This document and a predecessor have been the subject of discussion >>> on the saag mailing list. [1] >>> >>> [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >> >> From nobody Tue Jul 8 13:09: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 28E5F1A000B; Tue, 8 Jul 2014 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjrtc3I6r6ak; Tue, 8 Jul 2014 13:09:51 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C9F7A1A0008; Tue, 8 Jul 2014 13:09:51 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 3CA676B0078; Tue, 8 Jul 2014 13:09:51 -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=oAzxprxUnx3TdNQMKtCX JalC2po=; b=jguN+N8wXoiJ/BsIQB9KzX96vHhwFdnPDvjDQcO+UZLE8LcHDUPI D//syEuWEdTWb++3G0ZJUteeZy+6CzhR2IrNI3Tf9a0hr3MQpK6v3xULRe+3E7JJ kzpcm/n3atfKPJOAXHm8a4tEYJgYNoHATTcL/MSlfFS4LHwjK1Eb9VA= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id BB5236B0070; Tue, 8 Jul 2014 13:09:50 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so6467838wes.22 for ; Tue, 08 Jul 2014 13:09:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.107.138 with SMTP id hc10mr6372111wib.47.1404850189139; Tue, 08 Jul 2014 13:09:49 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Tue, 8 Jul 2014 13:09:49 -0700 (PDT) In-Reply-To: <53BC4C4D.8070307@isi.edu> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@isi.edu> Date: Tue, 8 Jul 2014 15:09:49 -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/g4GIb7foNTABr8yYhuhJrugZLSc Cc: IETF discussion list , "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:09:53 -0000 On Tue, Jul 8, 2014 at 2:53 PM, Joe Touch wrote: > On 7/8/2014 12:03 PM, Stephen Farrell wrote: >> On 08/07/14 18:54, Joe Touch wrote: >>> I didn't see the post on the main list, but my view is that this doc >>> needs to be handled in SAAG. I do not support its moving forward as an >>> individual draft. >> >> saag is not an area working group, so cannot do that. Its >> just not the same setup as with appsawg for example. > > That's unfortunate; it would be useful to have this have a home within the > IETF. It works for apps, it could work for us, but I think that's not something we're going to deal with in this thread -- start a new thread? >> And I'm not clear what difference that'd make either, >> especially since this topic, and, more recently, this draft >> have been the subject of significant discussion on the saag >> list. > > > Yes, but there was no "WGLC". Jumping straight to IETF LC seems like an > end-run around this being homed in a WG - any WG - and IMO it ought to be. Not really: - WGLC is two weeks, and IETF LC is two weeks when the I-D was WGLCed, but for individual submissions the IETF LC is four weeks. Reviewers have the same amount of time in either case. - The security community, through saag, is *clearly* aware of this I-D. - There's no WG whose charter this I-D could have fit into. - There's no WG whose charter could reasonably have been modified to fit this I-D. - Having a BoF to start a one-document WG would have been a misuse of resources. - The individual submission track exists in part for just this sort of I-D. - You yourself are aware of the I-D and, like everyone else, have four weeks to review. - The IESG gets a crack at this I-D as well. What's the problem? How has the process been circumvented, in its letter or spirit? Nico -- From nobody Tue Jul 8 13:19: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 E9D751A000B; Tue, 8 Jul 2014 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxvEE16X1jWq; Tue, 8 Jul 2014 13:19:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF721A0002; Tue, 8 Jul 2014 13:19:36 -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 s68KJF6m022716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 13:19:16 -0700 (PDT) Message-ID: <53BC5243.20505@isi.edu> Date: Tue, 08 Jul 2014 13:19:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@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/WZ-yIs8u77QOgcUjDVqP2TV3LGE Cc: IETF discussion list , "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:19:37 -0000 On 7/8/2014 1:09 PM, Nico Williams wrote: > What's the problem? How has the process been circumvented, in its > letter or spirit? > > Nico I guess the spirit; I had thought that the security community within the IETF had a more formal process for defining new terms, but also note that its glossary is "Informational" (not BCP). So I withdraw that aspect of my objection; I'll post on the content separately. Joe From nobody Tue Jul 8 13:49: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 293BE1A0026; Tue, 8 Jul 2014 13:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WR_8rwGIyJP; Tue, 8 Jul 2014 13:49:31 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8F1A0002; Tue, 8 Jul 2014 13:49:31 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 03F8B28606F; Tue, 8 Jul 2014 13:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=q6Po7pEsrt807rHV38Lm p+6+amc=; b=xKhtLqM2ZH0WrbisI7tAWHu/TB8eu/6R5qrnPZ23q+7kPXEEWPYJ NTqAZUUNx1StNDe9ggLxEdQfoJ65puwbSG0porm7HYTThggdQ2LWzBmJ6xOAV5gO ttAcZeStVJu/6W9Y07h8B+1/1V8FxALqF4Y9oRPtB8AADwY8+Wfd6Fs= Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id CD389286059; Tue, 8 Jul 2014 13:49:30 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id va2so7080954obc.33 for ; Tue, 08 Jul 2014 13:49:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.117.39 with SMTP id kb7mr41927601oeb.5.1404852570340; Tue, 08 Jul 2014 13:49:30 -0700 (PDT) Received: by 10.182.234.78 with HTTP; Tue, 8 Jul 2014 13:49:30 -0700 (PDT) In-Reply-To: <53BC5243.20505@isi.edu> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@isi.edu> <53BC5243.20505@isi.edu> Date: Tue, 8 Jul 2014 15:49:30 -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/ZNteVLSu1M6pahxoAq-NLXFmQgw Cc: IETF discussion list , "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:49:32 -0000 On Tue, Jul 8, 2014 at 3:19 PM, Joe Touch wrote: >> What's the problem? How has the process been circumvented, in its >> letter or spirit? > > I guess the spirit; I had thought that the security community within the > IETF had a more formal process for defining new terms, but also note that > its glossary is "Informational" (not BCP). We don't have a single set of terms that everyone uses. The terminology used in the space of GSS, SASL, Kerberos (these three all in one WG now), IPsec, TLS, SSHv2, EAP, and so on all differ, sometimes subtly, sometimes radically. Unifying our sets of terminology would be so difficult as to be impossible, except over time, by piecemeal adoption of new terms. Adding new terms that we can all use is much easier, and given the state of play, shouldn't really require heavy-duty process -- otherwise we couldn't even make piecemeal progress as to common terminology. Nico -- From nobody Tue Jul 8 13:51: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 D5C4C1A005D; Tue, 8 Jul 2014 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_Otgpic-gKf; Tue, 8 Jul 2014 13:51:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23CB1A0048; Tue, 8 Jul 2014 13:51:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B0612002A; Tue, 8 Jul 2014 16:52:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 24CCC63B0E; Tue, 8 Jul 2014 16:51:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FB3163B09; Tue, 8 Jul 2014 16:51:44 -0400 (EDT) From: Michael Richardson To: Nico Williams In-Reply-To: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@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/dThnPASa-AgrCJKU7A3FFvzMqRk Cc: "saag@ietf.org" , IETF discussion list Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 20:51:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Nico Williams wrote: > - The individual submission track exists in part for just this sort = of > I-D. I think that is actually an AD-sponsored draft, which is a different stream again (with less friction). =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7xZ3YCLcPvd0N1lAQKRvgf+I3Vi/HylhyJydrcBRgvRX6ti7JiJidfM nmkYbonZQRa6DhTOx4dKuIM40D5nfss+h3Yi50Lssu4aVkjqfziLPZ6LZtnF5b7W PHQc/jeUHpOaKcnc5/MIt+EIZe1W7YcSvsceEZyRdmbKjhW90XGGSWmLh5rnh/bH oIBT/peSTen+OK9TfVuKVgbbTZEhoEpIzrn6FbLNwG+aAoU+4rlaqd1IGAjmypKn BnWHkeRNz7V6zfu6INJwG4AJyhlDVMD9ITMFIsP8ddsaGi4z21XE6ogjQHbMxR4f nkNUAF50Rs4qQXaNFkrQWqXszTamGf5KHm1Tku/C+frSJx8oVRR/SA== =t54M -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 8 14:16: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 C64A51A009C; Tue, 8 Jul 2014 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, 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 v3SMNrIbhpKW; Tue, 8 Jul 2014 14:16:39 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1E1A009A; Tue, 8 Jul 2014 14:16:39 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id EAAD867406A; Tue, 8 Jul 2014 14:16:38 -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=3suOUBNRQWKUs1zlG/hp VJjElEo=; b=HWQ11kjvaYUXzAeg4W7LnDIzJBUgVgSV2qIOHXVqysHsb762yDSq bCb+pR31ho3mGLl0/68eIklDi7h5fhqKBuw51BQu+5qJotiZf10jZaAO2SnV4UB7 KzjPH7uOUO0KD411D5MM2rSGusXgnxTEHVRVSUPPTKXTgYG7s/EqWds= Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) (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 C620C674060; Tue, 8 Jul 2014 14:16:38 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id g18so30295oah.37 for ; Tue, 08 Jul 2014 14:16:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.96.98 with SMTP id dr2mr42876166oeb.15.1404854198485; Tue, 08 Jul 2014 14:16:38 -0700 (PDT) Received: by 10.182.234.78 with HTTP; Tue, 8 Jul 2014 14:16:38 -0700 (PDT) In-Reply-To: <11048.1404852704@sandelman.ca> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@isi.edu> <11048.1404852704@sandelman.ca> Date: Tue, 8 Jul 2014 16:16:38 -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/uyd-gSbiAtRIYIVbggYYhIBAKhY Cc: "saag@ietf.org" , IETF discussion list Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 21:16:39 -0000 On Tue, Jul 8, 2014 at 3:51 PM, Michael Richardson wrote: > Nico Williams wrote: > > - The individual submission track exists in part for just this sort of > > I-D. > > I think that is actually an AD-sponsored draft, which is a different stream > again (with less friction). Yep, right you are. From nobody Tue Jul 8 17:15: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 9521D1A0196 for ; Tue, 8 Jul 2014 17:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qjL9HChbl2Q for ; Tue, 8 Jul 2014 17:15:36 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADA81A0194 for ; Tue, 8 Jul 2014 17:15:36 -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 s690FY44019702; Tue, 8 Jul 2014 17:15:34 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1n0s1y08fn-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 08 Jul 2014 17:15:34 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 8 Jul 2014 17:15:33 -0700 From: Paul Lambert To: Yaron Sheffer , ianG , "saag@ietf.org" Date: Tue, 8 Jul 2014 17:15:31 -0700 Thread-Topic: [saag] NULL encryption mode in RFC 5202-bis Thread-Index: Ac+apg+oBCx//oqpRreLSkMwWNoXjQAZGYow Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01BAB3DF65B@SC-VEXCH2.marvell.com> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BBE064.7080607@gmail.com> In-Reply-To: <53BBE064.7080607@gmail.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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_06:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090002 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/U9jp6Ey6VeeqSIFnpvr2NtzTdOQ Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 00:15:38 -0000 ]-----Original Message----- ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Yaron Sheffer ]Sent: Tuesday, July 08, 2014 5:13 AM ]To: ianG; saag@ietf.org ]Subject: Re: [saag] NULL encryption mode in RFC 5202-bis ] ]I think the debugging argument is still valid. For example, host-side ]debugging of IPsec with tcpdump is still somewhat broken on many Linux ]boxes. The boxes should be fixed rather than making available=20 such a bypass of encryption. Logging and other mechanisms could be readily used and will be developed as necessary to 'debug' systems. ] ]And please bear in mind that if NULL-auth is not implemented on BOTH ]peers, you cannot use it to debug your implementation even if your side ]does have such a debug knob. ] ]So I would recommend something like "MUST implement (or maybe SHOULD). ]MUST NOT negotiate by default". But where is the 'negotiation bit" set? Implementations should not be made= to leave such a back-door in the code just for developers to debug. Paul ] ]Thanks, ] Yaron ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Tue Jul 8 18:27: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 979AA1A01E4 for ; Tue, 8 Jul 2014 18:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQpb0pVwQJcY for ; Tue, 8 Jul 2014 18:27:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274F81A01E1 for ; Tue, 8 Jul 2014 18:27:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0C612002A; Tue, 8 Jul 2014 21:28:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CE22863B0E; Tue, 8 Jul 2014 21:27:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B73BD63B09; Tue, 8 Jul 2014 21:27:46 -0400 (EDT) From: Michael Richardson To: Paul Lambert In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01BAB3DF65B@SC-VEXCH2.marvell.com> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BBE064.7080607@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01BAB3DF65B@SC-VEXCH2.marvell.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/HT2iDu9VwbBciD99VYYlW6q9QYg Cc: "saag@ietf.org" Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 01:27:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable > ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Yaron Sheffer > ]Sent: Tuesday, July 08, 2014 5:13 AM > ]To: ianG; saag@ietf.org > ]Subject: Re: [saag] NULL encryption mode in RFC 5202-bis > ] > ]I think the debugging argument is still valid. For example, host-side > ]debugging of IPsec with tcpdump is still somewhat broken on many Lin= ux > ]boxes. > The boxes should be fixed rather than making available=20 > such a bypass of encryption. Let me know when you've done that. It's open source. Contribute a patch. Oh. BSD kernels have the same problem (so OSX, iPhone). I don't know about Solaris.=20=20 But, this is not about bypassing encryption: this is about an administrator working with to debug a protocol in the field.=20 > Logging and other mechanisms could be readily used and will be develo= ped > as necessary to 'debug' systems. Honestly: have you actually done this in the field? with a remote administrator who doesn't understand IPsec? Remember, it's not *IPsec* we are debugging, it is something else that lives on top of IPsec. > ]And please bear in mind that if NULL-auth is not implemented on BOTH > ]peers, you cannot use it to debug your implementation even if your s= ide > ]does have such a debug knob. > ] > ]So I would recommend something like "MUST implement (or maybe SHOULD= ). > ]MUST NOT negotiate by default". > But where is the 'negotiation bit" set? Implementations should not b= e made to > leave such a back-door in the code just for developers to debug. Uh. Please go read about IPsec/IKEv2 and HIP. The negotiate bit is called rfc4306 or HIP (RFC5201) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7yakICLcPvd0N1lAQIe8Af+MsECgb44RkZ1Q1ER2TbIvmAgfHSB7xNd Tr0Dtq6pOWWzThmZD1w1mwXJOyh+++Ym9cjM8LHT6QD56lsrJC2Z4kPKJSWY6+nr yWGveurQJD7agGlTmVLP3Fh5tw5qWVNMlIJ7BO3lDePe9hTZN1HIM5sIReW4H6vf 79dyO5zHt8UaVsScAGT/8XDfB2c6G9GSdWYEN1LxbaUGOdb89gd+T3/zH937Mfss uMtFgfuB8tPSiFqojOgjaYrVgu1Oxt3EfmnpoLSWTRWGzRS+WxFmtIth8zngAdpV 17HsX5+JZzSZLuw02RbiUNZKhmvbmO06ZU6au5aRLEIu/5txIJBR7g== =ckpJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 8 23:57: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 582741A037F for ; Tue, 8 Jul 2014 23:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t7r1m5gQOrp for ; Tue, 8 Jul 2014 23:57:37 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81E81A01D9 for ; Tue, 8 Jul 2014 23:57:37 -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 s696vZfe009890; Tue, 8 Jul 2014 23:57:35 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1n0sar0wwm-13 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 23:57:35 -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, 8 Jul 2014 23:57:33 -0700 From: Paul Lambert To: Michael Richardson Date: Tue, 8 Jul 2014 23:57:31 -0700 Thread-Topic: [saag] NULL encryption mode in RFC 5202-bis Thread-Index: Ac+bQw7M7dJuHQd1TkuxufjiCrRHaQ== Message-ID: References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BBE064.7080607@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01BAB3DF65B@SC-VEXCH2.marvell.com> <3209.1404869266@sandelman.ca> In-Reply-To: <3209.1404869266@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 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.12.52, 1.0.14, 0.0.0000 definitions=2014-07-09_02:2014-07-08,2014-07-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090094 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BISAGVnKNlMBN7zhalwBxHoNOlo Cc: "saag@ietf.org" Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 06:57:40 -0000 On 7/8/14, 6:27 PM, "Michael Richardson" wrote: > > > ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Yaron >Sheffer > > ]Sent: Tuesday, July 08, 2014 5:13 AM > > ]To: ianG; saag@ietf.org > > ]Subject: Re: [saag] NULL encryption mode in RFC 5202-bis > > ] > > ]I think the debugging argument is still valid. For example, >host-side > > ]debugging of IPsec with tcpdump is still somewhat broken on many >Linux > > ]boxes. > > > The boxes should be fixed rather than making available > > such a bypass of encryption. > >Let me know when you've done that. It's open source. Contribute a patch. >Oh. BSD kernels have the same problem (so OSX, iPhone). I don't know >about Solaris. =20 > >But, this is not about bypassing encryption: this is about an >administrator >working with to debug a protocol in the field. > > > Logging and other mechanisms could be readily used and will be >developed > > as necessary to 'debug' systems. > >Honestly: have you actually done this in the field? Yes. I have designed and fielded very large installations of IPsec. NULL encryption was never required. The larger systems had great debugging capability without NULL encryption. The Type I network security products I built would not even allow such a bypass for =B3security=B2 reasons. It=B9= s too easy to make a mistake or have the system made to appear to be working, but in NULL mode. >with a remote >administrator who doesn't understand IPsec? Yes. Having the remote admin turn on-and-off the encryption seems very questionable in this case. Reminds me of the phone call I got the other day from a company telling me my computer was infected and I need to let them make some changes. >Remember, it's not *IPsec* we >are debugging, it is something else that lives on top of IPsec. Yes. So what, many other tools are possible. > > > ]And please bear in mind that if NULL-auth is not implemented on >BOTH > > ]peers, you cannot use it to debug your implementation even if your >side > > ]does have such a debug knob. > > ] > > ]So I would recommend something like "MUST implement (or maybe >SHOULD). > > ]MUST NOT negotiate by default". > > > But where is the 'negotiation bit" set? Implementations should not >be made to > > leave such a back-door in the code just for developers to debug. > >Uh. Please go read about IPsec/IKEv2 and HIP. >The negotiate bit is called rfc4306 or HIP (RFC5201) Yes, I=B9ve read them =8A Of course there is a bit in the protocol. My wording seems to have missed my point, where in the configuration settings of an administrator mode are these bits set or unset in a manner that prevents accidental or malicious misuse. MUST implement is clearly designing system for the developers and not for the end-users. What real-world IPsec challanged end user would ever actually want this configuration set? There are better ways to get the information and a system debugged than to mandate NULL encryption. Paul > >--=20 >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > From nobody Wed Jul 9 05:57: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 CDFF11A0538; Wed, 9 Jul 2014 05:57:37 -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 u_5F_GJMkAZC; Wed, 9 Jul 2014 05:57:36 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2371A0527; Wed, 9 Jul 2014 05:57:36 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so2701457wiv.3 for ; Wed, 09 Jul 2014 05:57:34 -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=1l67DqyaCv0xKMd5550IXI5MwSidWuDW9QJGbDP4eBo=; b=xM0DqEHnwqTfQNoF1tKWJawzktT02Rjy8T46COgZXPHCQAA29gxDokoZMQPagxuZlE KkmML6vwJS4Uthh2nLcZdLvepYhQEYFBrGonECJBBrSP1CIooiwZ3jO0OiUdZDpaFHEn bAb0fN6d16OuOybuN0gOuVmK8Qibi8EEsgUkTVkpiMgi2pLGM9jEx500Esv6FhZJKVW/ afhkickW1FjPHFBjZkxP61TN7CL1xYasYDdvgD75HbizugRTQ71zKqMeuVrdkdQK+tdI PFDRQsyo0clfevajQMWKhQtmZQpvzkrWuJWpWITzxo0hLPyMbMHIFcaX0HsDupyLHFN2 yLCA== MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr11326641wib.24.1404910654812; Wed, 09 Jul 2014 05:57:34 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Wed, 9 Jul 2014 05:57:34 -0700 (PDT) In-Reply-To: <11048.1404852704@sandelman.ca> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BC303F.5060300@isi.edu> <53BC4076.4040803@cs.tcd.ie> <53BC4C4D.8070307@isi.edu> <11048.1404852704@sandelman.ca> Date: Wed, 9 Jul 2014 05:57:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michael Richardson Content-Type: multipart/alternative; boundary=f46d04426a6085809d04fdc24068 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zHtnAwEe9AkqvhPDtXr4RWpUBA4 Cc: "saag@ietf.org" , IETF discussion list Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:57:38 -0000 --f46d04426a6085809d04fdc24068 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 8, 2014 at 1:51 PM, Michael Richardson wrote: > > Nico Williams wrote: > > - The individual submission track exists in part for just this sort > of > > I-D. > > I think that is actually an AD-sponsored draft, which is a different stream > again (with less friction). > I think Individual Submission and AD-sponsored are the same thing. Perhaps you're thinking of Independent Submissions? If this has been thoroughly discussed in SAAG (I haven't checked) but doesn't have a working group, then the Individual route is absolutely the right way to go. The alternative is a route that doesn't have IETF consensus, which strikes me as just wrong here. -MSK --f46d04426a6085809d04fdc24068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 8, 2014 at 1:51 PM, Michael Richardson <m= cr+ietf@sandelman.ca> wrote:

Nico Williams <nico@cryptonecto= r.com> wrote:
=C2=A0 =C2=A0 > =C2=A0- The individual submission track exists in part f= or just this sort of
=C2=A0 =C2=A0 > I-D.

I think that is actually an AD-sponsored draft, which is a different = stream
again (with less friction).

I think Indi= vidual Submission and AD-sponsored are the same thing.=C2=A0 Perhaps you= 9;re thinking of Independent Submissions?

If this has bee= n thoroughly discussed in SAAG (I haven't checked) but doesn't have= a working group, then the Individual route is absolutely the right way to = go.=C2=A0 The alternative is a route that doesn't have IETF consensus, = which strikes me as just wrong here.

-MSK
--f46d04426a6085809d04fdc24068-- From nobody Wed Jul 9 07:47: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 043741A0AC5 for ; Wed, 9 Jul 2014 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J87pBwdRfZO for ; Wed, 9 Jul 2014 07:47:44 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 523511A040B for ; Wed, 9 Jul 2014 07:47:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9A17363406; Wed, 9 Jul 2014 14:47:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InesZJ2QISPf; Wed, 9 Jul 2014 10:47:32 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 11F1062A71; Wed, 9 Jul 2014 10:47:32 -0400 (EDT) Message-ID: <53BD55ED.1030405@htt-consult.com> Date: Wed, 09 Jul 2014 10:47:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: noloader@gmail.com, ianG References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> 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/3EH3ZixuameKB6oa12cJxNkyKOg Cc: saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 14:47:46 -0000 The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed payload, and in many use cases, the Initiator has pre-deteremined the Responder's HI and HIT so it can check the SIG before processing the ESP TRANSFORM parameters. In sensornets where the Initiator cannot pre-determine the Responder's (typically some sensor controller) HI and HIT, then it is a concern. Further eventhough I1 is unsigned, the Initiator 'knows' what suites it wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC back, it MUST NOT complete the exchange. If in the R1 it gets NULL, CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC. If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST NOT complete the exchange. The HIP design team spent a long time working out downgrade attacks. I have to thank Tobias Heer and Miika Komu for a couple day design when I was visiting HIIT in Helsinki. NULL, CMAC, or GMAC should only be configured as allowable suites when they are needed for debug, or the situation requires auth-only. And I should point out there are devices and situations where auth-only is the case, so those suites are needed. IMNSHO. In the worst case scenario, we could cover with text that clearifies the privacy versus auth-only suites with requirements that these suites not be mixed in an exchange and if one is expected, the other not accepted. Of course 'servers' (I say that parenthetically, as HIP is a peer exchange) MIGHT need to support both classes of customers and thus need to respond based on the unprotectable I1 packet. Even there, the Initiator still can bid back if its I1 was altered by a MiTM. From nobody Wed Jul 9 11:48: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 441031A0379 for ; Wed, 9 Jul 2014 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo98E1dZj3pC for ; Wed, 9 Jul 2014 11:48:25 -0700 (PDT) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBEA1A0332 for ; Wed, 9 Jul 2014 11:48:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id 493E0E506 for ; Wed, 9 Jul 2014 14:48:24 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3KNs4LjX22K for ; Wed, 9 Jul 2014 14:48:24 -0400 (EDT) Received: from [192.168.3.137] (24-205-93-255.dhcp.psdn.ca.charter.com [24.205.93.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id BC089E42F for ; Wed, 9 Jul 2014 14:48:23 -0400 (EDT) From: Henry B Hotz Content-Type: multipart/alternative; boundary="Apple-Mail=_7041403E-D0A4-4F70-8455-5E6268310312" Message-Id: <3DDE3DD1-6E00-4069-BFC0-223899C3D78E@oxy.edu> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 9 Jul 2014 11:48:20 -0700 References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BD55ED.1030405@htt-consult.com> To: "saag@ietf.org" In-Reply-To: <53BD55ED.1030405@htt-consult.com> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0oSK1BD3kta179hzHHTGFEIlprs Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 18:48:26 -0000 --Apple-Mail=_7041403E-D0A4-4F70-8455-5E6268310312 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking to Stephen's "generic" point: it seems to me that debugging = arguments are sufficient for a SHOULD and not "generically" for a MUST. Personal email. hbhotz@oxy.edu --Apple-Mail=_7041403E-D0A4-4F70-8455-5E6268310312 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Speaking to Stephen's "generic" point: it seems to me that debugging arguments are sufficient for a SHOULD and not "generically" for a MUST.

Personal email.  hbhotz@oxy.edu



--Apple-Mail=_7041403E-D0A4-4F70-8455-5E6268310312-- From nobody Wed Jul 9 14:25: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 E100B1B2806 for ; Wed, 9 Jul 2014 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, 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 KuHp-BTn541F for ; Wed, 9 Jul 2014 14:25:25 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1CB1B27F2 for ; Wed, 9 Jul 2014 14:25:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 81C922002D; Wed, 9 Jul 2014 17:26:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B87C463B0E; Wed, 9 Jul 2014 17:25:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A1AB463B09; Wed, 9 Jul 2014 17:25:22 -0400 (EDT) From: Michael Richardson To: Robert Moskowitz In-Reply-To: <53BD55ED.1030405@htt-consult.com> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BD55ED.1030405@htt-consult.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/jDHnqTBFAv9yAaW8cBg9mufmka4 Cc: saag@ietf.org Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 21:25:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > NULL, CMAC, or GMAC should only be configured as allowable suites whe= n they > are needed for debug, or the situation requires auth-only. And I shou= ld point > out there are devices and situations where auth-only is the case, so = those > suites are needed. IMNSHO. Exactly, I don't understand the concern. If someone thinks that the AUTH-only policy should be hidden in a UI, I don= 't care. What I care about is that the kernel implementers understand that it is important to have, because kernels are rather hard to replace on many systems, even if the choice of key manager if fungible. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU72zQICLcPvd0N1lAQIelAf/eO5KwcaavpH4ADvHuOfX36/xuwRKwUk0 NFAkMtdmKmq1K+6M7yUbSSiK57KDJ4lmhc0IhQf7EfViaGywpehYrYWT4PUj/3fn uMwxgbqDKrE2B+/j9itQUvXUIpbJjtN4lBimNZCsE8zcE5RrMxuQ8RiyX0OnzMl/ wpy/4eedKfSYPXGsDo91Fygsf2W5cuTDXxpl64CXU34K3KCMgXS65qCJGCzMyCGR vF5jNhOWZw1UlEDRDw7enbj6xj9qBg6OQ1CACTFeadruzFPioR4K0R65Cprv5mab G4M6aft8kCzaspYxhsOsG9euEDkHbmqQM5eflbbxXtfC8+CtG3X6Ng== =ckLT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 9 14:56: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 2FB6A1A0076 for ; Wed, 9 Jul 2014 14:56:45 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fxfCzPeBtwM for ; Wed, 9 Jul 2014 14:56:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9D41A0005 for ; Wed, 9 Jul 2014 14:56:42 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 9 Jul 2014 21:56: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.0959.000; Wed, 9 Jul 2014 21:56:40 +0000 From: Christian Huitema To: Michael Richardson , Robert Moskowitz Thread-Topic: [saag] NULL encryption mode in RFC 5202-bis Thread-Index: AQHPmmjM5R2QhM+EM0SCYYlTvcTmgZuWFSUAgAA9egCAAYHhgIAAb0MAgAAGx4A= Date: Wed, 9 Jul 2014 21:56:39 +0000 Message-ID: <6069dd8558e34c479f174d8e147de6cd@BLUPR03MB424.namprd03.prod.outlook.com> References: <53BB798A.3080101@tomh.org> <53BBDEA8.7090706@iang.org> <53BD55ED.1030405@htt-consult.com> <17882.1404941122@sandelman.ca> In-Reply-To: <17882.1404941122@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(24454002)(51704005)(99286002)(106356001)(85306003)(19580395003)(106116001)(76576001)(107046002)(80022001)(83322001)(105586002)(50986999)(74662001)(4396001)(21056001)(74502001)(87936001)(101416001)(54356999)(93886003)(86612001)(81342001)(2656002)(20776003)(74316001)(46102001)(95666004)(92566001)(86362001)(76176999)(79102001)(31966008)(81542001)(33646001)(99396002)(85852003)(64706001)(77982001)(76482001)(19580405001)(83072002)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB424; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 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/FQYTdPDn2QOl6WOcxnxN0TgnY2I Cc: "saag@ietf.org" Subject: Re: [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 09 Jul 2014 21:56:45 -0000 Michael Richardson wrote: > Robert Moskowitz wrote: > > NULL, CMAC, or GMAC should only be configured as allowable suites wh= en they > > are needed for debug, or the situation requires auth-only. And I sho= uld point > > out there are devices and situations where auth-only is the case, so= those > > suites are needed. IMNSHO. > > Exactly, I don't understand the concern. > If someone thinks that the AUTH-only policy should be hidden in a UI, I d= on't > care. What I care about is that the kernel implementers understand that= it > is important to have, because kernels are rather hard to replace on many= =20 > systems, even if the choice of key manager if fungible. Maybe we should not think of HIP and IPSEC the same way we think of TLS. Pa= cket-level encryption is pretty much part of the infrastructure, and is gen= erally not visible to the application. Auth-only protection has value at th= e packet level, e.g. as a protection against various intrusions and tamperi= ng attacks. It does not provide confidentiality, but we can expect applicat= ions that require confidentiality to use TLS or other application level mec= hanism. The main benefit of packet level encryption could be some protection agains= t traffic analysis. But HIP or transport-mode IPSEC do expose the actual de= stination of the packet, so there is little gain from packet level encrypti= on... -- Christian Huitema From nobody Thu Jul 10 03:14: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 2E89F1B2854 for ; Thu, 10 Jul 2014 03:14:06 -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 kVv3hUVCsxnl for ; Thu, 10 Jul 2014 03:14:04 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF2D1B2841 for ; Thu, 10 Jul 2014 03:14:03 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 5AB9D6D568; Thu, 10 Jul 2014 06:13:59 -0400 (EDT) Message-ID: <53BE6765.5080902@iang.org> Date: Thu, 10 Jul 2014 11:13:57 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> In-Reply-To: <53BC0F94.8020608@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/PSCK2xsk0f0WOgLdvXnl1bqgU-o Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:14:06 -0000 An anecdote. Last night I was asked to describe opportunistic security. After thinking about it, I realised that first I had to describe the alternate, as OS only makes full sense when contrasted. So I did that. End of anecdote. This immediately raised several issues in my mind: * What is the alternate? * What is its name? * Is there a document for this? * Shouldn't the present draft refer to it? Looking at the draft, it says: This memo defines the term "opportunistic security". In contrast to the established approach of delivering strong protection some of the time, .... Historically, Internet security protocols have prioritized strong protection for peers capable and motivated to absorb the associated costs. Since strong protection is not universally applicable, while communications traffic was sometimes strongly secured, more typically it was not protected at all. .... The draft makes a stab at calling the alternate 'strong protection' but does not go much further. So, maybe for my own curiosity, is there a name/doc/definition within IETF for the alternate, perhaps briefly known as strong protection? iang From nobody Thu Jul 10 03:40: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 C70E41B2870 for ; Thu, 10 Jul 2014 03:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c104NzuiMj8x for ; Thu, 10 Jul 2014 03:40:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 756EE1B286C for ; Thu, 10 Jul 2014 03:40:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DCE83BE17; Thu, 10 Jul 2014 11:40:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1BvRlz-Dbf4; Thu, 10 Jul 2014 11:40:20 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.20.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5995DBE14; Thu, 10 Jul 2014 11:40:20 +0100 (IST) Message-ID: <53BE6D94.309@cs.tcd.ie> Date: Thu, 10 Jul 2014 11:40:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> In-Reply-To: <53BE6765.5080902@iang.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/x6vxbQE1yFsj4vHFAOPtslJTtJ0 Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:40:23 -0000 On 10/07/14 11:13, ianG wrote: > An anecdote. Last night I was asked to describe opportunistic security. > After thinking about it, I realised that first I had to describe the > alternate, as OS only makes full sense when contrasted. So I did that. > End of anecdote. > > This immediately raised several issues in my mind: > > * What is the alternate? > * What is its name? > * Is there a document for this? > * Shouldn't the present draft refer to it? > > Looking at the draft, it says: > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering strong protection some of the > time, .... > > Historically, Internet security protocols have prioritized strong > protection for peers capable and motivated to absorb the associated > costs. Since strong protection is not universally applicable, while > communications traffic was sometimes strongly secured, more typically > it was not protected at all. .... > > > > The draft makes a stab at calling the alternate 'strong protection' but > does not go much further. > > So, maybe for my own curiosity, is there a name/doc/definition within > IETF for the alternate, perhaps briefly known as strong protection? Others are better at this than me, but I guess the combination of RFCs 3365 (BCP61) and 4107 (BCP107), and the advice from RFC 3552 (BCP72). But I think partly this also goes back to the late 1990's and earlier when many designs started to mature - up to then it was entirely reasonable to design for enterprise environments for most things and so that's what we did, and in such environments mutual authentication is a good goal still, even if doing that gets very complicated and expensive for very large enterprises. So the OS story isn't really a case of fixing something broken but more catching up with requirements that changed. At least that's how I think about it. S. > > iang > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Thu Jul 10 07:46: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 A826F1A0659 for ; Thu, 10 Jul 2014 07:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNIZTlDeTbr0 for ; Thu, 10 Jul 2014 07:46:43 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3F31A0657 for ; Thu, 10 Jul 2014 07:46:42 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rd18so7653197iec.33 for ; Thu, 10 Jul 2014 07:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HHXtOQ21AdZvWv+AAJWZZWJ0zIxJECoLiF5HVYke/dw=; b=VoijmxuqmdcCOswCpbqxxqI6hqJhAcmEoMCr3So0diNqSMbFCFglgxNQE0HQaa5DR9 nX6vrmZ0rzxdFSHCTvozqZfZnIUwzZTR0oj3PwbqjPk0TmR7cOj3YyXPUf00mKWlDotj eQBFo6guL0VXuNBy/3ypZ1ZFmJelK2PubfBxSfihA2ZpEbKwQhBELPDAwW3iZ2gz3/BU C6Cw/qrvkErcnbKNI9v6CER3un3Ls4K7Jn4fEO7+nWdtb0ufyZKZ1k77HtjdnzQlUKZn obVBbyaZef/3BTI/8U2NlYriU1N9FiRYbKoCsbc4xzDZKyIBkGIag8ENKAd6vKfJbPGr p4GA== X-Received: by 10.43.84.65 with SMTP id aj1mr38450571icc.5.1405003602254; Thu, 10 Jul 2014 07:46:42 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id p12sm25647349igx.18.2014.07.10.07.46.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 07:46:41 -0700 (PDT) Message-ID: <53BEA74D.3080207@gmail.com> Date: Thu, 10 Jul 2014 10:46:37 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , ianG , saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> In-Reply-To: <53BE6D94.309@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/Az2P5GcBK3krJOLMm0hfcclm0nk Subject: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:46:44 -0000 This raises an important question as to why "doing that gets very complicated and expensive". It would make sense to document reasons for why this is so in an I-D by itself. I often wonder whether this is a self-inflicted wound caused by the security profession itself, has economical drivers, or would be caused by lax policies, for example. In many groups, discussions on perceived or real complexity of security design elements keep coming up over and over again and this is unlikely to stop soon. To me, this seems a priority one item for saag to reflect upon. Rene == But I think partly this also goes back to the late 1990's and earlier when many designs started to mature - up to then it was entirely reasonable to design for enterprise environments for most things and so that's what we did, and in such environments mutual authentication is a good goal still, even if doing that gets very complicated and expensive for very large enterprises. So the OS story isn't really a case of fixing something broken but more catching up with requirements that changed. At least that's how I think about it. On 7/10/2014 6:40 AM, Stephen Farrell wrote: > On 10/07/14 11:13, ianG wrote: >> An anecdote. Last night I was asked to describe opportunistic security. >> After thinking about it, I realised that first I had to describe the >> alternate, as OS only makes full sense when contrasted. So I did that. >> End of anecdote. >> >> This immediately raised several issues in my mind: >> >> * What is the alternate? >> * What is its name? >> * Is there a document for this? >> * Shouldn't the present draft refer to it? >> >> Looking at the draft, it says: >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering strong protection some of the >> time, .... >> >> Historically, Internet security protocols have prioritized strong >> protection for peers capable and motivated to absorb the associated >> costs. Since strong protection is not universally applicable, while >> communications traffic was sometimes strongly secured, more typically >> it was not protected at all. .... >> >> >> >> The draft makes a stab at calling the alternate 'strong protection' but >> does not go much further. >> >> So, maybe for my own curiosity, is there a name/doc/definition within >> IETF for the alternate, perhaps briefly known as strong protection? > Others are better at this than me, but I guess the combination of RFCs > 3365 (BCP61) and 4107 (BCP107), and the advice from RFC 3552 (BCP72). > > But I think partly this also goes back to the late 1990's and earlier > when many designs started to mature - up to then it was entirely > reasonable to design for enterprise environments for most things and > so that's what we did, and in such environments mutual authentication > is a good goal still, even if doing that gets very complicated and > expensive for very large enterprises. So the OS story isn't really > a case of fixing something broken but more catching up with > requirements that changed. At least that's how I think about it. > > S. > > >> iang >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Jul 10 08:20: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 28CD31A03D7 for ; Thu, 10 Jul 2014 08:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo9nz0bl4Y9K for ; Thu, 10 Jul 2014 08:20:44 -0700 (PDT) Received: from mip.polyamory.org (mip.polyamory.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id B08231A05D1 for ; Thu, 10 Jul 2014 08:20:39 -0700 (PDT) Received: by mip.polyamory.org (Postfix, from userid 1002) id DD2D010760; Thu, 10 Jul 2014 11:20:37 -0400 (EDT) Date: Thu, 10 Jul 2014 11:20:37 -0400 From: Ofer Inbar To: ianG Message-ID: <20140710152037.GR482@mip.aaaaa.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BE6765.5080902@iang.org> User-Agent: Mutt/1.4.2.3i Organization: American Association Against Acronym Abuse Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8PdPDxSV79TzZHp41wpdUccLssc Cc: saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:20:46 -0000 ianG wrote: > Looking at the draft, it says: > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering strong protection some of the > time, .... > > Historically, Internet security protocols have prioritized strong > protection for peers capable and motivated to absorb the associated > costs. Since strong protection is not universally applicable, while > communications traffic was sometimes strongly secured, more typically > it was not protected at all. .... > > The draft makes a stab at calling the alternate 'strong protection' but > does not go much further. Disagree. "strong protection" is something opportunistic security strategies can provide when possible. Using that term for the alternate to opportunistic would be misleading. The draft doesn't present "strong" as the alternate, but if people misread the draft in this way, perhaps the draft needs some tweaking? The alternate to OS that the draft describes here, is falling back to no security when whatever your protocol was trying to do (which may be "strong") is not possible, without allowing for the case that something less strong is possible. OS is about providing "strong" when it can be done, and something less when when it cannot. The alternative to OS is falling back to less security than is available because you couldn't get something better than is available. -- Cos From nobody Thu Jul 10 08:48: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 BBA271A0A74 for ; Thu, 10 Jul 2014 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbuyQdDboVZu for ; Thu, 10 Jul 2014 08:48:20 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 412061A0385 for ; Thu, 10 Jul 2014 08:48:20 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 143451638 for ; Thu, 10 Jul 2014 08:48:20 -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=6PGOGeroU+MbLzK77N0m 6u/rvdA=; b=nGpvkAorsNuSwEltBpwUFfFiN4I2nFRWkz7kJa7+wOSN4wGK/ghC 8cW/toLB5OgqagcH2zmnePffoUUzivKkdjskFcLvt4lrXifrwD4/VmvHlwZ/N/ZG n8NCs3sXJq+iD1jzxIi8C3FCLoP8rJCk1NSTlXwmVmN1OxIjUiZrHvo= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 B3677163A for ; Thu, 10 Jul 2014 08:48:19 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so633657wib.8 for ; Thu, 10 Jul 2014 08:48:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.195 with SMTP id wo3mr4819211wjb.130.1405007296470; Thu, 10 Jul 2014 08:48:16 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Thu, 10 Jul 2014 08:48:16 -0700 (PDT) In-Reply-To: <20140710152037.GR482@mip.aaaaa.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> Date: Thu, 10 Jul 2014 10:48:16 -0500 Message-ID: From: Nico Williams To: Ofer Inbar Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aAK8s3Fq836uvuVuqvPJFk4xpb4 Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:48:23 -0000 On Thu, Jul 10, 2014 at 10:20 AM, Ofer Inbar wrote: > ianG wrote: > > [...] > > Disagree. "strong protection" is something opportunistic security > strategies can provide when possible. Using that term for the > alternate to opportunistic would be misleading. The draft doesn't > present "strong" as the alternate, but if people misread the draft > in this way, perhaps the draft needs some tweaking? +1. Alternatives (plural) to OS: - make strong authentication with introducers scale (but we've failed so far) - no security We don't need to define them where we define OS in order to define OS. In particular we don't need to define "no security"/"insecure": every one knows what that means :/ > The alternative to OS is falling back to less security than is > available because you couldn't get something better than is available. Right. From nobody Thu Jul 10 08:50: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 D397E1A0AEC for ; Thu, 10 Jul 2014 08:50:17 -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 1oeAjnT_sLfP for ; Thu, 10 Jul 2014 08:50:11 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55D1A0ACA for ; Thu, 10 Jul 2014 08:49:31 -0700 (PDT) Received: from [10.70.10.130] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 826BAF984; Thu, 10 Jul 2014 11:49:28 -0400 (EDT) Message-ID: <53BEB5FF.4050904@fifthhorseman.net> Date: Thu, 10 Jul 2014 11:49:19 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Ofer Inbar , ianG References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> In-Reply-To: <20140710152037.GR482@mip.aaaaa.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VkOvPSKv8djPWwnXW3Oo4HAQ6I3AWKOOJ" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CI8HjCfW4bvTdUUIJbzkOE3ILfc Cc: saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:50:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VkOvPSKv8djPWwnXW3Oo4HAQ6I3AWKOOJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/10/2014 11:20 AM, Ofer Inbar wrote: > ianG wrote: >> The draft makes a stab at calling the alternate 'strong protection' bu= t >> does not go much further. >=20 > Disagree. "strong protection" is something opportunistic security > strategies can provide when possible. Using that term for the > alternate to opportunistic would be misleading. The draft doesn't > present "strong" as the alternate, but if people misread the draft > in this way, perhaps the draft needs some tweaking? > The alternate to OS that the draft describes here, is falling back to > no security when whatever your protocol was trying to do (which may be > "strong") is not possible, without allowing for the case that > something less strong is possible. OS is about providing "strong" > when it can be done, and something less when when it cannot. So perhaps the alternative is "all-or-nothing" security? The two main alternatives to OS i've seen in practice are: 0) strong protection if possible, connection failure otherwise, (e.g. HTTPS attempts in most web browsers) or 1) strong protection if possible, no protection at all (but no connection failure) otherwise. (e.g. SMTP cleartext retry on STARTTLS certificate validation failure) both of these are a sort of "all or nothing" approach. --dkg --VkOvPSKv8djPWwnXW3Oo4HAQ6I3AWKOOJ 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 iQJ8BAEBCgBmBQJTvrX/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcsboQAMRHTFNxoEcqMhJUZ29qfWFv d8R0JzyjI1fmKQnGVUlP3bBPwx0MRPPMKFw0zqUwm+7ijPV4uRIWlCJ7Oxp3VnIA jEB4mbBEH4V2Sca9De7l0f8kiuJgGwA9x2ewh12mvn+xS6OUXEEmFxL6d3/kNZai WJxoSsxQQMlye0+2dwvT1f1vcLPJEcY4Us6CCpFE394xxqYssX500H044SbDGU7a 2YrFMK/zQtk3zLVJZhqqDTtD5maYmmQ34v4iE02eI+Axpqte+iy9+kQbEXaAMM0j zxXK5FyZiTyxI1AubsJKLlqDK2adYKJt1JZ0VrBK0AFO0/c3v/wD6ijYSi6iFM/k DSyGoD3dqL86ONiXXYuuX/fn6qQrW3ugaJu8TiNY4tD+JGxLjb/lkDAIJwQmbQ2H pR0jghUP9yT/2ZLfygsutQ0yoK/qcphUiP1MP1yBAyj35ES55o33HcFcMKgIAzq4 vumn63RX2b+KYLQyaybtBV3SKVv2Icw7zoXpgE7jtXt0Cf3MV0s1BbY8AO73b2lj W+E8CyE0LdXA2htJQpKnPB5Cx9leUrwatubvvgARTjztfkQEA4oSb+mtbEFLzm5t DCPiuUT2zpOtRr63GhKnhfreZVSINXLBUIZoauSRiPcMRvjUbzgBX+EQyeHW1mzy hAwm7h3enjCHTvvuiWYg =kz09 -----END PGP SIGNATURE----- --VkOvPSKv8djPWwnXW3Oo4HAQ6I3AWKOOJ-- From nobody Thu Jul 10 09:45: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 7DE091A0ABF for ; Thu, 10 Jul 2014 09:44:58 -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 zgXuBResWRNm for ; Thu, 10 Jul 2014 09:44:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1FF1A0235 for ; Thu, 10 Jul 2014 09:44:56 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 780406D4D0; Thu, 10 Jul 2014 12:44:51 -0400 (EDT) Message-ID: <53BEC2DE.9090802@iang.org> Date: Thu, 10 Jul 2014 17:44:14 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> In-Reply-To: <53BE6D94.309@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/IMtOlO_nzd1AVmUbANiIV1qB0pQ Subject: [saag] Model Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 10 Jul 2014 16:44:58 -0000 On 10/07/2014 11:40 am, Stephen Farrell wrote: >> So, maybe for my own curiosity, is there a name/doc/definition within >> IETF for the alternate, perhaps briefly known as strong protection? > > Others are better at this than me, but I guess the combination of RFCs > 3365 (BCP61) and 4107 (BCP107), and the advice from RFC 3552 (BCP72). I looked through those, and I'd say they do not come close to providing a framework that could be considered an alternate, although I sense their frustration. Here's what I had in mind, scratched out in a morning. I have one feedback which is "needs pictures". *Model Security* Abstract. The classical or accepted approach to software security systems is based on Models. These models in aggregate create a strategy of defence often called the Security Model, which addresses some threats well, others less well. The final selection of these threats and their mitigations is based on the work of expressing a Business Model, a Threat Model and a Risk Model. *The Models in Security* We start with a _Business Model_. This gives grounding to that value we are trying to protect, the players, the constraints, etc. For example, the SSL system was designed to a business model of credit card transactions over the Internet in the then-emerging field of e-commerce. The users were assumed to have no prior relationship with the merchant, and the technology of communication was assumed to be WWW. Then, we construct a _Threat Model_, being an enumeration of all the bad things that can happen to the business. Next, we construct a _Risk Model_, which develops the threats by estimating their expected cost and likelihood, and adds potential mitigations which carry their costs to employ. With some calculation, we develop an overall view of risk to the business that can be prioritised according to best cost-benefit in applying different mitigations. We can then model different subsets of mitigations for cost-benefit analysis. Finally, we select a _Security Model_ by choosing a subset of threats and mitigations from the above risk model exercise. The mitigations are proposed as the set to spend resources on, leaving the unmitigated threats to be 'accepted' as costs of business. *Strengths in Model Security* The modelled approach represents a scientific approach. It draws from various disciplines to create a pathway by which the choice of mitigations can be documented, debated, agreed and promulgated. It is extremely flexible as it can cope with many broader security scenarios; as well as infosec, the model is widely used in physical security and terrorism defence fields. When well-documented, it lends itself to wide communication, fast appreciation by newcomers and auditability. *Weaknesses in the Model-based approach to Security* Some of the models or steps can be skipped, skimmed or mishandled for various reasons: lack of understanding, appreciation or resources (e.g., time). The overall approach is very expensive. It is not infrequent for serious systems to require many man-years of work to create a fully documented set of models. A security model can become over-used. In particular, it can be misapplied to businesses that have different initial circumstances, and in the extreme, the model can make security matters worse while camouflaging the loss. The complexity of the approach gives rise to a 'guild approach' to security which is often seen as a barrier. Especially, as real security is faced by thinking attackers, their ability to migrate their tactics can exceed the ability of model security to adjust (c.f. OODA loops). Assumptions about likely attackers can become beliefs that are untested or unreal. The complexity of the models approach makes it vulnerable to being used to prove the solution. That is, a seller of a particular solution can craft a suite of models that is designed to prove on paper the efficacy of the solution, but is too complex to challenge. From nobody Thu Jul 10 10:24: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 0F9D71A0B08 for ; Thu, 10 Jul 2014 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boG2Ng-Y7x3h for ; Thu, 10 Jul 2014 10:24:07 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA6481B2904 for ; Thu, 10 Jul 2014 10:23:57 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 6E6C720078714 for ; Thu, 10 Jul 2014 10:23:57 -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=1YrPDug9XsjGY+BALqOi oRKDj2o=; b=uD5EZ0Ik7amIo1zRM2LKX1mlNfDiOpMCbMAr5G7818zHCmd3+YKA 4IppoVQG8tsa/vdfHZucQXceflOOYVVI3Na0z5q2BCTQklRi9GCGqjvat97lIVoL L0ESVzrJzqJ5TdYq8WpC/xaUdrWy88HsRGPgFxJulKkGVisgt6D1WV8= 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-a112.g.dreamhost.com (Postfix) with ESMTPSA id 21D5C20078710 for ; Thu, 10 Jul 2014 10:23:56 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so9310076wgh.35 for ; Thu, 10 Jul 2014 10:23:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.84.101 with SMTP id x5mr57948321wjy.52.1405013020581; Thu, 10 Jul 2014 10:23:40 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Thu, 10 Jul 2014 10:23:40 -0700 (PDT) In-Reply-To: <53BEA74D.3080207@gmail.com> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> Date: Thu, 10 Jul 2014 12:23:40 -0500 Message-ID: From: Nico Williams To: Rene Struik Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/R6m9cJ7czibuJuEHHuAJLvzJeQY Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:24:09 -0000 On Thu, Jul 10, 2014 at 9:46 AM, Rene Struik wrote: > This raises an important question as to why "doing that gets very ["that" == mutual authentication] > complicated and expensive". It would make sense to document reasons for why > this is so in an I-D by itself. I often wonder whether this is a > self-inflicted wound caused by the security profession itself, has > economical drivers, or would be caused by lax policies, for example. > > In many groups, discussions on perceived or real complexity of security > design elements keep coming up over and over again and this is unlikely to > stop soon. To me, this seems a priority one item for saag to reflect upon. I agree. The subject of mutual authentication has come up many, many times here (IETF security area, and IETF in general). There's a lot to say about this subject. I'll make a list later today. Nico -- From nobody Thu Jul 10 10:47: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 5684F1B2928 for ; Thu, 10 Jul 2014 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH0rz5kFZW8s for ; Thu, 10 Jul 2014 10:47:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC861B2924 for ; Thu, 10 Jul 2014 10:47:08 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LobGI-1WOnwI3Kck-00gUt2; Thu, 10 Jul 2014 19:47:05 +0200 Message-ID: <53BED198.2040804@gmx.net> Date: Thu, 10 Jul 2014 19:47:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams , Rene Struik References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C76m9c8M35UujrfNk2alUi4MTjk7dlb04" X-Provags-ID: V03:K0:YnEuUGTBtrhYCer/ocd6VTlVHv8xXNWtozpi20e7+tx/O/vrQMJ GvCSnoMFZ7y1UT/1jc6Zh8NNOYTHcJMV9KhJiaacLTJfptzi0JNBjeDRpMJEMo+nQcbyKay ri6TD1YzWe7p5cnpQvPNR9DOO0eIoNTmcx7pXvnwex+miZPcO4J+g2XgDzOi8sNuWXNYD8X OcSJdlG7EzWjxPABuA9Eg== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/S0WSlxaadYHOVVrafupL97Z6yw8 Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C76m9c8M35UujrfNk2alUi4MTjk7dlb04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rene, correct me if I am wrong but I believe you are referring to discussions that relate to the complexity of various security mechanisms on Internet of Things devices. I doubt that an abstract discussion will be the right response. I believe that this story is similar to the case with TLS a few years ago when the common (mis)believe was that TLS is prohibitively expensive. Then, Google enabled it on all their services and worries were suddenly gone. Ciao Hannes On 07/10/2014 07:23 PM, Nico Williams wrote: > On Thu, Jul 10, 2014 at 9:46 AM, Rene Struik wr= ote: >> This raises an important question as to why "doing that gets very >=20 > ["that" =3D=3D mutual authentication] >=20 >> complicated and expensive". It would make sense to document reasons f= or why >> this is so in an I-D by itself. I often wonder whether this is a >> self-inflicted wound caused by the security profession itself, has >> economical drivers, or would be caused by lax policies, for example. >> >> In many groups, discussions on perceived or real complexity of securit= y >> design elements keep coming up over and over again and this is unlikel= y to >> stop soon. To me, this seems a priority one item for saag to reflect u= pon. >=20 > I agree. The subject of mutual authentication has come up many, many > times here (IETF security area, and IETF in general). >=20 > There's a lot to say about this subject. I'll make a list later today.= >=20 > Nico > -- >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --C76m9c8M35UujrfNk2alUi4MTjk7dlb04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTvtGYAAoJEGhJURNOOiAt/dsH/064Rt8aUhopymg62DvF0vPu OjOVMjIs4yLjGXqUMukp+yBDnUbvrd8FSzl+JNjJe+im5crkJsmENYJITdahjHXm BvSYj0b7LDBfjRhgBFwtx76U6XVsP9xrFJaI2TTOiZOvw6ESUAmvyrfXyJlHCCHd JM7Mr80x5IIFactetXqnQiepmX57jP/cIY54CHm6NObxPJAMvqv7h3iVWy0iG78x uCkukjdV2oa0ISpdPlqHRPUd/bQhTZB+qHTIL3HKJ2nSb3TSVziQh9OBIqErbjZv KlT6oLXremOAnMdrgBWl662n98g0IcXth6fxpMg9t/q5pxMIpvtgRfS4Qmo1tWs= =AQRs -----END PGP SIGNATURE----- --C76m9c8M35UujrfNk2alUi4MTjk7dlb04-- From nobody Thu Jul 10 10:51: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 74B961A0649 for ; Thu, 10 Jul 2014 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeLK6jvpUmrZ for ; Thu, 10 Jul 2014 10:51:14 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6CC1A0AB2 for ; Thu, 10 Jul 2014 10:51:13 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so1515805wgg.31 for ; Thu, 10 Jul 2014 10:51:11 -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=CxtCd/70w+OZNeiNtTT9X0Dg3xWaS+qG8ZR/LVT/tM4=; b=DTvHhFjbjtNbrFxmvzBsTjIV0fM3X7cEUcQcmGMVerNlavmFJ7yndyKpHd7cRgzY8j z5NsWo4bLLCL9zUa6Z2DEctHYpohZAt/ZPwbhORI5gRUhpPYP9/LpXkYskhtYcQOy4WZ 17lLQpBpdBq7l4vLELMEoQDURUcEAHU6WSiaSfu0NRMDc8R9fVlaYJx9FGWobOV96o9z 9ZhvxarsSf9mKIx5f4gaG559fckM8vquu4Ibm0RtgCoUUkiQSna80j351myBhiOcUR17 z/6ecgNlW/zQCO2YpLJufwY/bX0gvpghotjklFFbafg4bWJosQ8lHNmGkySkxSEVN1qz HJWA== MIME-Version: 1.0 X-Received: by 10.180.92.38 with SMTP id cj6mr14694477wib.64.1405014671077; Thu, 10 Jul 2014 10:51:11 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Thu, 10 Jul 2014 10:51:10 -0700 (PDT) In-Reply-To: <53BEB5FF.4050904@fifthhorseman.net> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> <53BEB5FF.4050904@fifthhorseman.net> Date: Thu, 10 Jul 2014 10:51:10 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BIZzk3C4oPuOps18i5Y7sYvOIg8 Cc: saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:51:15 -0000 On 10 July 2014 08:49, Daniel Kahn Gillmor wrote: > The two main alternatives to OS i've seen in practice are: > > 0) strong protection if possible, connection failure otherwise, (e.g. > HTTPS attempts in most web browsers) or > > 1) strong protection if possible, no protection at all (but no > connection failure) otherwise. (e.g. SMTP cleartext retry on STARTTLS > certificate validation failure) TOFU is another option in this space, but where many of the strong protection schemes fail to scale out in numbers, TOFU fails to provide continuous protection, including the initial leap. From nobody Thu Jul 10 10:57: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 2E10A1A0AB2 for ; Thu, 10 Jul 2014 10:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baMm3JAbM3P1 for ; Thu, 10 Jul 2014 10:57:27 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2160C1A01A7 for ; Thu, 10 Jul 2014 10:57:27 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so889497igb.14 for ; Thu, 10 Jul 2014 10:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=E+E5DytXy/xJxRM/woFVcAcbD4abGUazFdsoKIT/i6k=; b=h6lY5AvQwtSmtvkmsahc5mjT90UFN2WuVFJwtc/KkcUML2wQd6gTqlXL01r5tBR+5J 0vxLeuwHQVATOE850R9CO3aEY+oXZXI0j5I48XtaZjYWO2nVGpTon9OgZ7s4KKMrxggi V5YgoWa+U4RgBcFtimRRQsxOvk1t8nYSUjiSkKrvQt1JX9YmvEDNj1KyTI1vDs9sDmWl RAfLxMTorvLeIdHvnS8gl+w/bT8CFwKLENvCBUm87DeWrYt3M3sf4+LrYbm4wiTSS7Ip 00IEAhLm1MXK53PR9FCAPWCeoTuAvV7Pqsgf8/r4vnf3raln/PFMb56ptTqJ1Zdbv+9r efBg== X-Received: by 10.50.141.199 with SMTP id rq7mr23550809igb.37.1405015046578; Thu, 10 Jul 2014 10:57:26 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id d4sm582885igc.5.2014.07.10.10.57.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 10:57:26 -0700 (PDT) Message-ID: <53BED401.90609@gmail.com> Date: Thu, 10 Jul 2014 13:57:21 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> In-Reply-To: <53BED198.2040804@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nuMigtN104ffgQ7HSXmVnUULyr4 Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:57:29 -0000 Hi Hannes: Any I-D that would dis-spell myths would of course also have value. Right now, it is hard to point at a comprehensive source; hence, my suggestion. BTW - I can imagine that you could weigh-in on this with a contribution to this suggested effort on how "raw public keys" fit into this picture. I never suggested an abstract discussion; those are your words. Best regards, Rene On 7/10/2014 1:47 PM, Hannes Tschofenig wrote: > Rene, > > correct me if I am wrong but I believe you are referring to discussions > that relate to the complexity of various security mechanisms on Internet > of Things devices. > > I doubt that an abstract discussion will be the right response. > > I believe that this story is similar to the case with TLS a few years > ago when the common (mis)believe was that TLS is prohibitively > expensive. Then, Google enabled it on all their services and worries > were suddenly gone. > > Ciao > Hannes > > > On 07/10/2014 07:23 PM, Nico Williams wrote: >> On Thu, Jul 10, 2014 at 9:46 AM, Rene Struik wrote: >>> This raises an important question as to why "doing that gets very >> ["that" == mutual authentication] >> >>> complicated and expensive". It would make sense to document reasons for why >>> this is so in an I-D by itself. I often wonder whether this is a >>> self-inflicted wound caused by the security profession itself, has >>> economical drivers, or would be caused by lax policies, for example. >>> >>> In many groups, discussions on perceived or real complexity of security >>> design elements keep coming up over and over again and this is unlikely to >>> stop soon. To me, this seems a priority one item for saag to reflect upon. >> I agree. The subject of mutual authentication has come up many, many >> times here (IETF security area, and IETF in general). >> >> There's a lot to say about this subject. I'll make a list later today. >> >> Nico >> -- >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Jul 10 11:38: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 5EEFA1B2947 for ; Thu, 10 Jul 2014 11:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy7yEtSTbZwQ for ; Thu, 10 Jul 2014 11:38:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B201B2957 for ; Thu, 10 Jul 2014 11:37:59 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mb8HX-1XKMD02xEB-00KfN4; Thu, 10 Jul 2014 20:37:57 +0200 Message-ID: <53BEDD84.9080504@gmx.net> Date: Thu, 10 Jul 2014 20:37:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Struik , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> In-Reply-To: <53BED401.90609@gmail.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="If2WwoGTd9Ueh27oA84qHWKuK5Tx8R1Mu" X-Provags-ID: V03:K0:ktu52POBJjxOhBRCiJ2n9Ec8naIsuUchMYYjwv9dy5nXxK2y4G6 UKsX4cC0a8nYEwizoWuANyHMMOuLiTH9A8oiRIWACXpTlvlsjTL6E8Q5dq7UOEm62AZvJu4 ifXaixWv0gSc4gSw9kSvHr2OWxdYRGsc75/vLYezV8KoJ3WIBNtHdSHIvwxQLn6HeLO66yy l7XykaS4a2t6qY8bh4tRA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fDDPq0I6r--g7uuveAAgYCr29YM Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:38:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --If2WwoGTd9Ueh27oA84qHWKuK5Tx8R1Mu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rene, On 07/10/2014 07:57 PM, Rene Struik wrote: > I never suggested an abstract discussion; those are your words. I was thinking about the most recent mail on the DICE mailing list and the argument "requiring more capable devices slows and limits market adoption" was brought up. The issue is of course about the type of protocol/cryptography being used for mutual authentication (instead of whether mutual authentication should be supported or not). Ciao Hannes --If2WwoGTd9Ueh27oA84qHWKuK5Tx8R1Mu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTvt2EAAoJEGhJURNOOiAtznwH/jySOVCD8CYkS3imatdhngzd pDZx8YyyK6y2Qjtd5hiHebselfHV2UKDlj//eo/bXoJYbLZu58Z7ToozqZsbQxd4 g/JjcOkKyaYUuGi3uq89ypA6zObojRsvOPTcz+pzrAt9PAIxhXz1odDpCDaSJWFU rrSV5y/iI6JvDfpW7ljoYPf/o6NqK71OEeTFQGJsN5d4mMy6ty2XRK4ewBMftj4u 3/NqBNtPTeVeUZFV4mjHJYdfNVwOR5l9/2aLq4UOkY1Wahx0fSR2LHAmEilI7quM Lf/QaGxpzyegB/zhSwR7semT/Dkj+/8gIOJ8Cx47l/QhKsgEO9H6Ue2cvY2m0/M= =lFbx -----END PGP SIGNATURE----- --If2WwoGTd9Ueh27oA84qHWKuK5Tx8R1Mu-- From nobody Thu Jul 10 11:55: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 C61151B297F for ; Thu, 10 Jul 2014 11:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL48ojz1WfwZ for ; Thu, 10 Jul 2014 11:55:24 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD1F1B2979 for ; Thu, 10 Jul 2014 11:55:15 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id c1so141727igq.9 for ; Thu, 10 Jul 2014 11:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sykJ1CtU/58a543sA7uE3vReho5ZuWnVUVMbhq9qFco=; b=x65ZW6aIX9P5mObVGPscHYql41P6xyy1aL6Sl9IufAPE07amEOKeB4gQMgUqL7FLTi 5y5qW8GCe3M1mSGuIQe84i4L77RKtscVOle+al1zTzE4upCfzedbllQjiCcULYuaiEcQ v4EUiRCP5eocjAcsiO96iUj4g6RvBijL1o150qoszY9HYYd6LWWhoyQWTOVhm8cH8sp3 VNukV8TJyqYHleO4DKFX2P5DRNXtU5+7bOCBTFjcFcHcxNwzg2w4DEyboBR2TTfYXW9t htvYEzqF6BW1IWhSbiNgNNWSgHNBMakED5kfRRaaNS1gQR2msSZOtl1ESE/A79/9+t3N pVpw== X-Received: by 10.50.23.16 with SMTP id i16mr23820345igf.24.1405018514764; Thu, 10 Jul 2014 11:55:14 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id dz3sm996870igb.3.2014.07.10.11.55.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 11:55:14 -0700 (PDT) Message-ID: <53BEE18D.1030209@gmail.com> Date: Thu, 10 Jul 2014 14:55:09 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> <53BEDD84.9080504@gmx.net> In-Reply-To: <53BEDD84.9080504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yUNYFCus1myD_qwXhdhrSWxPcvI Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:55:29 -0000 Hi Hannes: The question I raised was triggered by Stephen Farrell's suggestion that "doing that [mutual authentication] gets very complicated and expensive". There seems to be more to that than just the cost of some software or hardware on a device (for otherwise, why would Stephen bring this up in the context of opportunistic encryption and "catching up with requirements that changes" (which I read as "mass surveillance") -- after all, the code size of the TLS stack does not seem to be dominated by crypto libraries). Again, if I am wrong and it would be just the cost of some software or hardware on a device, that would be good to establish. If there is more to this, then we should list this and make sure we work towards addressing the complexities and expenses that were suggested. Stephen, any thought on this? What did you mean? Rene [BTW - if my email was on DICE issues, I would have responded to the DICE WG. It was not, though] On 7/10/2014 2:37 PM, Hannes Tschofenig wrote: > Hi Rene, > > On 07/10/2014 07:57 PM, Rene Struik wrote: >> I never suggested an abstract discussion; those are your words. > I was thinking about the most recent mail on the DICE mailing list and > the argument "requiring more capable devices slows > and limits market adoption" was brought up. > > The issue is of course about the type of protocol/cryptography being > used for mutual authentication (instead of whether mutual authentication > should be supported or not). > > Ciao > Hannes > > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Jul 10 12:17: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 E08111B2982 for ; Thu, 10 Jul 2014 12:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMKOj6O0BgZS for ; Thu, 10 Jul 2014 12:17:10 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0157C1B2979 for ; Thu, 10 Jul 2014 12:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=382; q=dns/txt; s=iport; t=1405019832; x=1406229432; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gSW1drjnkeHVuUzOKBlVtmrgLHKRIyhXKmXKQt8V1cw=; b=l4LeCb/8NmKEhUCtnrcEabDIehsuP64Ho6vbQwp47O2kKtm9EE/rseS+ 5Up58VUzhNUaOJ5W3NAGP3pkvJIDQlSKGBaEitY3iyYR48pzsHYQsUT+o p2kFsTmPbRKI3EXz83qaGzOwKi9s4GIfAIGinzoGMcdJRvtOibwvxf0hp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAI7lvlOtJssW/2dsb2JhbABZhynCK4MVAYEkdYQDAQEBAwEjVQEFCwsYAgIFFgQHAgIJAwIBAgFFBgEMAQcBAYg2CK4dmS8XgSyOGAeCd4FMAQSbAIcPjQaCAYFEOw X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208";a="103069174" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 10 Jul 2014 19:17:09 +0000 Received: from [10.61.174.20] ([10.61.174.20]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6AJH7XI016982; Thu, 10 Jul 2014 19:17:07 GMT Message-ID: <53BEE6B2.4070102@cisco.com> Date: Thu, 10 Jul 2014 21:17:06 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Ofer Inbar , ianG References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> <53BEB5FF.4050904@fifthhorseman.net> In-Reply-To: <53BEB5FF.4050904@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ImVOKFAQjYsN66phYiehucUen5A Cc: saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:17:12 -0000 On 7/10/14, 5:49 PM, Daniel Kahn Gillmor wrote: > On 07/10/2014 11:20 AM, Ofer Inbar wrote: > So perhaps the alternative is "all-or-nothing" security? I suggest we not think in such stark terms. There are going to be variants all around us. Especially in the home where registration is a challenge, but by no means impossible (I'd just call it ongoing work). Eliot From nobody Thu Jul 10 12:29: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 45CE41B2978 for ; Thu, 10 Jul 2014 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usjDUsT7if9w for ; Thu, 10 Jul 2014 12:29:21 -0700 (PDT) Received: from mip.polyamory.org (mip.polyamory.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id EC52D1B295C for ; Thu, 10 Jul 2014 12:29:20 -0700 (PDT) Received: by mip.polyamory.org (Postfix, from userid 1002) id 6D34410760; Thu, 10 Jul 2014 15:29:17 -0400 (EDT) Date: Thu, 10 Jul 2014 15:29:17 -0400 From: Ofer Inbar To: Eliot Lear Message-ID: <20140710192917.GT482@mip.aaaaa.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> <53BEB5FF.4050904@fifthhorseman.net> <53BEE6B2.4070102@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BEE6B2.4070102@cisco.com> User-Agent: Mutt/1.4.2.3i Organization: American Association Against Acronym Abuse Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MX7Jv1JarkFVdZrHvnTTIZ8iXU8 Cc: saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:29:22 -0000 Eliot Lear wrote: > On 7/10/14, 5:49 PM, Daniel Kahn Gillmor wrote: > > > On 07/10/2014 11:20 AM, Ofer Inbar wrote: > > So perhaps the alternative is "all-or-nothing" security? > > I suggest we not think in such stark terms. There are going to be > variants all around us. Especially in the home where registration is a > challenge, but by no means impossible (I'd just call it ongoing work). For the record, I didn't write that line :) The way I put it was "the alternative to OS is falling back to less security than is available because you couldn't get something better than is available." Maybe another way of looking at it is that the "alternate" is deciding in advance on a specific set of parameters you'll do, without building in flexibility to do something else when what you wanted in advance is not achievable. Either way, it's a continuum: "opportunistic" means building in more flexibility with the goal of getting the best available. Too little flexibility leading to the failure of "falling back to less security than is available" = your approach is less opportunistic. If it fails in that way frequently, then it's insufficiently opportunistic for the context it's deployed in, when looked at from the OS point of view. If it rarely fails that way, then it's sufficiently opportunistic in context. -- Cos From nobody Thu Jul 10 16:28: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 BB3F81A008A for ; Thu, 10 Jul 2014 16:28:30 -0700 (PDT) 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 hfqmHgUS35k5 for ; Thu, 10 Jul 2014 16:28:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5A41A0064 for ; Thu, 10 Jul 2014 16:28:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C36032AB2AA; Thu, 10 Jul 2014 23:28:26 +0000 (UTC) Date: Thu, 10 Jul 2014 23:28:26 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140710232826.GW27568@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> <53BEB5FF.4050904@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BEB5FF.4050904@fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/t9fgFaUZY7oW74GH5H_jdatsTk8 Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC 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, 10 Jul 2014 23:28:30 -0000 On Thu, Jul 10, 2014 at 11:49:19AM -0400, Daniel Kahn Gillmor wrote: > So perhaps the alternative is "all-or-nothing" security? > > The two main alternatives to OS i've seen in practice are: > > 0) strong protection if possible, connection failure otherwise, (e.g. > HTTPS attempts in most web browsers) or > > 1) strong protection if possible, no protection at all (but no > connection failure) otherwise. (e.g. SMTP cleartext retry on STARTTLS > certificate validation failure) > > both of these are a sort of "all or nothing" approach. Correct. In particular OS is adaptive, peer by peer, to achieve "best possible" (under the circumstances) protection with that peer. The "all-or-nothing" alternatives are not adaptive, and leave a lot of destinations unprotected. I should Note that the mail failure mode of HTTPS is HTTP, which it is my impression is still more prevalent than HTTPS. For many web sites users get to HTTPS after a redirect to HTTPS or by clicking on a "secure-login" link. So the practice of HTTPS is often different from the presumed model. -- Viktor. From nobody Thu Jul 10 17:16: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 4C5F81B2813; Thu, 10 Jul 2014 17:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIhufGLJ-V-I; Thu, 10 Jul 2014 17:16:19 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC72C1B280B; Thu, 10 Jul 2014 17:16:18 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so301644wev.20 for ; Thu, 10 Jul 2014 17:16:16 -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=WCfZQNb6YntUD9+700WGnPo1pe01dQhh/DcYmErhUvo=; b=YnokkpdaL7N1ZdEjiIbapg7fXJu06kfVO9ApRlHG9wtkJMUEFQ6+QI9bNT4IGdYQiv vfZlHZoGe8M6i8ciLwr1ujgKjQ+FwDHN1gZLQPVnHAjnSQy+DJxJ0lUh0yCGcYy7Dje7 +pltzKckZc+uWajCDEnRJMEthkebdx5cWrTa4xxN/h4HyvVu1hLOXsWdzqzUg223vE17 QyB+iX8HYgF6YfDMIGBr6vguL+KZ5BTCoxoRSwmgxZkW6WiuFhz1R/rU75BfywHEa/y/ ci+t+3vyGpmPgLHXokTT4E3J/ToTsrRyDE288wqApeebwDOWQOdGiNFbTuBBQdXeSlZ9 iWag== MIME-Version: 1.0 X-Received: by 10.194.90.7 with SMTP id bs7mr59162230wjb.25.1405037775964; Thu, 10 Jul 2014 17:16:15 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Thu, 10 Jul 2014 17:16:15 -0700 (PDT) Date: Thu, 10 Jul 2014 17:16:15 -0700 Message-ID: From: Martin Thomson To: draft-dukhovni-opportunistic-security.all@tools.ietf.org, "gen-art@ietf.org" , saag@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZvsP2O-_Y9tFTxHZDUjKPGXsKds Subject: [saag] Gen-ART review of draft-dukhovni-opportunistic-security-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, 11 Jul 2014 00:16:25 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-dukhovni-opportunistic-security-01 Reviewer: Martin Thomson Review Date: 2014-07-08 IETF LC End Date: 2014-08-05 IESG Telechat date: (if known) Summary: This reads a little like it was rushed. This needs some work before it can be considered ready. (I've cc'd saag here. That seemed appropriate, strip as you see fit.) Major issues: This misses one of the key principles behind opportunistic security: Insistence on failure, as opposed to downgrade or some lesser level of security - a characteristic of non-opportunistic security - elicits responses from users to work around the problem (accept the bad certificate, suppress certificate checking, etc...). The willingness of an opportunistic security implementation to accept unvalidated credentials means that it still benefits from resilience against passive attack. This is only really noted through an example of a "design blunder". In general, a more careful consideration of the document structure is needed. The document skirts around it's key goal: defining OS. Section 2 needs to start with a definition. The paragraph that follows the list in S2 is a reasonable attempt at that and could be tweaked fairly perform that function. The Security Considerations is a response to an unstated argument, but I think that the document needs to be clearer about what that argument is, i.e.: The willingness of an OS implementation to downgrade can be trivially exploited by an active attacker to strip an opportunistic mechanisms. The point that is made here is one that is most applicable in the aggregate, something that is implied by "users" (in the plural form), but should be explicit. Minor issues: Section 3 is unnecessary in its entirely: 1. 2119 language isn't really appropriate for this document. Many of the statements that rely on this would be much better without that language. Some of the uses are actually completely inappropriate: "When possible, opportunistic security SHOULD provide stronger security on a peer-by-peer basis." 2. I think that the description of "unauthenticated encryption" and "TOFU" belong in the text proper. TOFU is covered well enough by the text in S1; unauthenticated encryption needs to be covered in the description as a first class section, rather than piecemeal (see above). MitM and PFS are defined in RFC4949. Nits/editorial comments: References are double-bracketed "([ref])" and the "pervasive monitoring (PM[RFC7258])" reference doesn't need the "PM". From nobody Thu Jul 10 19:41: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 2E3EB1A01AD for ; Thu, 10 Jul 2014 19:41:09 -0700 (PDT) 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 V17m_yL979uK for ; Thu, 10 Jul 2014 19:41:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A4A1A0195 for ; Thu, 10 Jul 2014 19:41:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AC5EC2AB2A6; Fri, 11 Jul 2014 02:41:06 +0000 (UTC) Date: Fri, 11 Jul 2014 02:41:06 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140711024106.GZ27568@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9Wl8Zf6OVrXtRkxRKE7b5VBFbJg Subject: Re: [saag] Gen-ART review of draft-dukhovni-opportunistic-security-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, 11 Jul 2014 02:41:09 -0000 On Thu, Jul 10, 2014 at 05:16:15PM -0700, Martin Thomson wrote: > Major issues: > > This misses one of the key principles behind opportunistic security: Strongly disagree. Opportunistic security does not always downgrade to unauthenticated or unencrypted communication. For example, with opportunistic use of DANE TLS, authentication is enforced for peers with usable TLSA records, while communication with other peers is unauthenticated or perhaps even unencrypted. So in fact, this draft specifically, and deliberately leaves the door open for MiTM-resistant authentication of peers for which some suitable mechanism (DANE, TOFU, ...) makes authentication possible. > Insistence on failure, as opposed to downgrade or some lesser level > of security - a characteristic of non-opportunistic security - elicits > responses from users to work around the problem (accept the bad > certificate, suppress certificate checking, etc...). For MTA-to-MTA SMTP there is no user to click OK. Not all applications are web browsers. > The willingness > of an opportunistic security implementation to accept unvalidated > credentials means that it still benefits from resilience against > passive attack. This is only really noted through an example of a > "design blunder". Opportunistic security is NOT a synonym for unauthenticated encryption. > The document skirts around it's key goal: defining OS. Section 2 > needs to start with a definition. The paragraph that follows the list > in S2 is a reasonable attempt at that and could be tweaked fairly > perform that function. The definition is a summary of the design principles. We're defining an umbrella term for a family of protocols sharing a design philosophy. It is helpful to set out the design principles first, and then state that OS protocols are those that adhere the design principles, and amplify the key points. > The Security Considerations is a response to an unstated argument, but > I think that the document needs to be clearer about what that argument > is, i.e.: > > The willingness of an OS implementation to downgrade can be > trivially exploited by an active attacker to strip an opportunistic > mechanisms. The Security Considerations section says that some protection is strictly better than no protection. Thus it is often OK to accept some protection, even if some risks are left unmitigated. > Section 3 is unnecessary in its entirety: No terminology section required? It is a subset of the Terminology from Steve Kent's draft. If it is felt that all the requisite terms are adequately defined in-line, I am not opposed to its removal, for this draft less bloat is better. It should be a succint definition. > 1. 2119 language isn't really appropriate for this document. Many > of the statements that rely on this would be much better without that > language. Some of the uses are actually completely inappropriate: > "When possible, opportunistic security SHOULD provide stronger > security on a peer-by-peer basis." I can downcase the "SHOULD", what is the objection to 2119? > 2. I think that the description of "unauthenticated encryption" and > "TOFU" belong in the text proper. TOFU is covered well enough by the > text in S1; unauthenticated encryption needs to be covered in the > description as a first class section, rather than piecemeal (see > above). MitM and PFS are defined in RFC4949. Anyone care to suggest new language? Is there agreement that the proposed changes are needed? -- Viktor. From nobody Thu Jul 10 21:12: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 4E6E21A0277; Thu, 10 Jul 2014 21:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfrVodTZrga6; Thu, 10 Jul 2014 21:12:06 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFF11A0275; Thu, 10 Jul 2014 21:12:05 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so444114wgh.33 for ; Thu, 10 Jul 2014 21:12:04 -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=zQD1Ob2A5gFu31o6DkDtSgTf3+wVvCsHOHJQQ/RNGmI=; b=p3nMZZqnVmRPu1m235EIwrXbxFnHqsnrJP+AhhQCllxZ4XDRmR62H4y8gTW7mbdMMp C97RUCy8FyYtLehBon/D6Qo1PYiSgYnnVgAfrh04AC1BLyGWdvgyb2pSgvQ4gi7AXMI5 rS9Vxy8aUWlLxQvslHnQi3rwldUhIfO7n5x/v6i+YZknEK8eRuEh4eSROR3hicZtTuGN 80Sqw39q2PPiBQlqMKnqA+Y61cispJOY6fi3gO7jACPNKQqUdOGWmGco2HN/l+qBoSp5 BgLfnk5BSH6OM6ce4AWufDo2zSs+XSzPluiGLrj6W/T60FDUM0Lnk9OQP7a7WCgXjE71 F0Wg== MIME-Version: 1.0 X-Received: by 10.180.37.230 with SMTP id b6mr1497710wik.47.1405051923994; Thu, 10 Jul 2014 21:12:03 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Thu, 10 Jul 2014 21:12:03 -0700 (PDT) In-Reply-To: <20140711024106.GZ27568@mournblade.imrryr.org> References: <20140711024106.GZ27568@mournblade.imrryr.org> Date: Thu, 10 Jul 2014 21:12:03 -0700 Message-ID: From: Martin Thomson To: Viktor Dukhovni Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jrTZELXMynwUuz07ggu3TcXYvE8 Cc: "gen-art@ietf.org" , saag@ietf.org, draft-dukhovni-opportunistic-security.all@tools.ietf.org Subject: Re: [saag] Gen-ART review of draft-dukhovni-opportunistic-security-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, 11 Jul 2014 04:12:08 -0000 (Please keep the To/Cc; the responsible ADs/shepherds probably need to see these emails. Add ietf@ if you feel you want the larger audience; I figured saag was a large enough peanut gallery :) On 10 July 2014 19:41, Viktor Dukhovni wrote: > On Thu, Jul 10, 2014 at 05:16:15PM -0700, Martin Thomson wrote: > >> Major issues: >> >> This misses one of the key principles behind opportunistic security: > > Strongly disagree. Opportunistic security does not always downgrade > to unauthenticated or unencrypted communication. For example, with > opportunistic use of DANE TLS, authentication is enforced for peers > with usable TLSA records, while communication with other peers is > unauthenticated or perhaps even unencrypted. > > So in fact, this draft specifically, and deliberately leaves the > door open for MiTM-resistant authentication of peers for which some > suitable mechanism (DANE, TOFU, ...) makes authentication possible. Maybe I chose my words poorly, but I stand by the fact that this is an important consideration in some designs. More important than this document implies. >> Insistence on failure, as opposed to downgrade or some lesser level >> of security - a characteristic of non-opportunistic security - elicits >> responses from users to work around the problem (accept the bad >> certificate, suppress certificate checking, etc...). > > For MTA-to-MTA SMTP there is no user to click OK. Not all applications > are web browsers. > >> The willingness >> of an opportunistic security implementation to accept unvalidated >> credentials means that it still benefits from resilience against >> passive attack. This is only really noted through an example of a >> "design blunder". > > Opportunistic security is NOT a synonym for unauthenticated > encryption. I didn't suggest that it was, but it's an important feature of the potential design space. The document doesn't really describe any other features that are this prominent. >> The document skirts around it's key goal: defining OS. Section 2 >> needs to start with a definition. The paragraph that follows the list >> in S2 is a reasonable attempt at that and could be tweaked fairly >> perform that function. > > The definition is a summary of the design principles. We're defining > an umbrella term for a family of protocols sharing a design > philosophy. It is helpful to set out the design principles first, and > then state that OS protocols are those that adhere the design principles, > and amplify the key points. I stand by my comment, I think that with a title and subject matter as is, you need to at least attempt to define the subject before attempting to describe secondary things like design principles. >> The Security Considerations is a response to an unstated argument, but >> I think that the document needs to be clearer about what that argument >> is, i.e.: >> >> The willingness of an OS implementation to downgrade can be >> trivially exploited by an active attacker to strip an opportunistic >> mechanisms. > > The Security Considerations section says that some protection is > strictly better than no protection. Thus it is often OK to accept > some protection, even if some risks are left unmitigated. Yes, but as I said, that statement is an answer to a question that is only implied. I think that the document would be better if it owned up to the potential here. >> Section 3 is unnecessary in its entirety: > > No terminology section required? It is a subset of the Terminology > from Steve Kent's draft. If it is felt that all the requisite terms > are adequately defined in-line, I am not opposed to its removal, for > this draft less bloat is better. It should be a succint definition. > >> 1. 2119 language isn't really appropriate for this document. Many >> of the statements that rely on this would be much better without that >> language. Some of the uses are actually completely inappropriate: >> "When possible, opportunistic security SHOULD provide stronger >> security on a peer-by-peer basis." > > I can downcase the "SHOULD", what is the objection to 2119? That's not my point. The point is that you aren't making normative statements in this document, and nor should you. 2119 language isn't needed. For this specific sentence, you could use lowercase "should" and still basically have an unsupportable statement. stronger than what? is this a prediction? I'm not sure what the right language is here, but this reads much like the argument from the security considerations, which is - to my mind - far more precise. >> 2. I think that the description of "unauthenticated encryption" and >> "TOFU" belong in the text proper. TOFU is covered well enough by the >> text in S1; unauthenticated encryption needs to be covered in the >> description as a first class section, rather than piecemeal (see >> above). MitM and PFS are defined in RFC4949. > > Anyone care to suggest new language? Is there agreement that the > proposed changes are needed? I'm thinking that Section 3 could be deleted and the paragraph on unauthenticated encryption beefed up a little to note its key characteristics and significance (deployability, failure in the face of active attack, that it isn't the only or even necessary piece of opportunistic encryption, etc...). From nobody Fri Jul 11 03:07: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 2D7E91B2AF2 for ; Fri, 11 Jul 2014 03:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOGUQhFjdHxy for ; Fri, 11 Jul 2014 03:06:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C85651B2AF5 for ; Fri, 11 Jul 2014 03:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A450BE14; Fri, 11 Jul 2014 11:06:52 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpP3ZAmypMsC; Fri, 11 Jul 2014 11:06:52 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E963ABDCF; Fri, 11 Jul 2014 11:06:51 +0100 (IST) Message-ID: <53BFB73C.7020102@cs.tcd.ie> Date: Fri, 11 Jul 2014 11:06:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Struik , Hannes Tschofenig , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> <53BEDD84.9080504@gmx.net> <53BEE18D.1030209@gmail.com> In-Reply-To: <53BEE18D.1030209@gmail.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/U-XPSQ7UJTfYHQOiCHXQeEMNel8 Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 10:07:00 -0000 Hi Rene, On 10/07/14 19:55, Rene Struik wrote: > Hi Hannes: > > The question I raised was triggered by Stephen Farrell's suggestion that > "doing that [mutual authentication] gets very complicated and > expensive". There seems to be more to that than just the cost of some > software or hardware on a device (for otherwise, why would Stephen bring > this up in the context of opportunistic encryption and "catching up with > requirements that changes" (which I read as "mass surveillance") -- No I don't think pervasive monitoring (PM) is the main change at all though it is something we need to better mitigate, and the OS work is part of that for sure. I think the size of the Internet has been the main change. Some of our security (and other) technologies were designed 15 or so years back mostly considering enterprise networks with say 10^6 or fewer things involved and where there were folks whose day job was to mind every part of that network. A lot of reasonable assumptions in that context no longer really apply. For example, I think the ability to relatively easily set up useful mutual (or even one-way) authentication to the point where you hard-fail or go insecure when you don't get that authentication is one of those assumptions. So the OS work is not only about PM, but is also about making security mechanisms easier to use, and more likely to be used. Cheers, S. PS: I'll just note that we do not need to have consensus on the "history" bits of the above which is just my impression of what folks were mostly thinking about 15-20 years ago. So we don't need to agree that I'm right or wrong as to what went on then:-) > after all, the code size of the TLS stack does not seem to be dominated > by crypto libraries). > > Again, if I am wrong and it would be just the cost of some software or > hardware on a device, that would be good to establish. If there is more > to this, then we should list this and make sure we work towards > addressing the complexities and expenses that were suggested. > > Stephen, any thought on this? What did you mean? > > Rene > [BTW - if my email was on DICE issues, I would have responded to the > DICE WG. It was not, though] > > On 7/10/2014 2:37 PM, Hannes Tschofenig wrote: >> Hi Rene, >> >> On 07/10/2014 07:57 PM, Rene Struik wrote: >>> I never suggested an abstract discussion; those are your words. >> I was thinking about the most recent mail on the DICE mailing list and >> the argument "requiring more capable devices slows >> and limits market adoption" was brought up. >> >> The issue is of course about the type of protocol/cryptography being >> used for mutual authentication (instead of whether mutual authentication >> should be supported or not). >> >> Ciao >> Hannes >> >> >> > > From nobody Fri Jul 11 05:21: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 61EDB1B287E for ; Fri, 11 Jul 2014 05:21: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 mk3oOOfIAsL0 for ; Fri, 11 Jul 2014 05:21:38 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E325D1B2817 for ; Fri, 11 Jul 2014 05:21:37 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 674D76D77A; Fri, 11 Jul 2014 08:21:33 -0400 (EDT) Message-ID: <53BFD6CC.3070803@iang.org> Date: Fri, 11 Jul 2014 13:21:32 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <20140710152037.GR482@mip.aaaaa.org> In-Reply-To: <20140710152037.GR482@mip.aaaaa.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/z0FPhUu_5-D4bgQn8yCHwaqQIlA Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:21:39 -0000 On 10/07/2014 16:20 pm, Ofer Inbar wrote: > ianG wrote: >> Looking at the draft, it says: >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering strong protection some of the >> time, .... >> >> Historically, Internet security protocols have prioritized strong >> protection for peers capable and motivated to absorb the associated >> costs. Since strong protection is not universally applicable, while >> communications traffic was sometimes strongly secured, more typically >> it was not protected at all. .... >> >> The draft makes a stab at calling the alternate 'strong protection' but >> does not go much further. > > Disagree. "strong protection" is something opportunistic security > strategies can provide when possible. Using that term for the > alternate to opportunistic would be misleading. FTR, I entirely agree, "strong" is the wrong term. My notion of 'model security' as no more than a thought experiment on what that alternate might be. > The draft doesn't > present "strong" as the alternate, but if people misread the draft > in this way, perhaps the draft needs some tweaking? > > The alternate to OS that the draft describes here, is falling back to > no security when whatever your protocol was trying to do (which may be > "strong") is not possible, without allowing for the case that > something less strong is possible. OS is about providing "strong" > when it can be done, and something less when when it cannot. > > The alternative to OS is falling back to less security than is > available because you couldn't get something better than is available. Yep -- but *why is it acceptable to fall back to zero security* ? AFAICS, the model said that there was a minimum level of security that was needed. Else stop. Reject that business? (Hence the term, model security.) (I'm not trying to figure out a better understanding for it, just find a label and approximate flavour that we can all agree on for it.) iang From nobody Fri Jul 11 05:46: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 B893B1B2817 for ; Fri, 11 Jul 2014 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MF0Ovjql2WR for ; Fri, 11 Jul 2014 05:46:21 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528AB1A0AAE for ; Fri, 11 Jul 2014 05:46:21 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D064D6D756; Fri, 11 Jul 2014 08:46:19 -0400 (EDT) Message-ID: <53BFDC9A.5060307@iang.org> Date: Fri, 11 Jul 2014 13:46:18 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> In-Reply-To: <53BE6765.5080902@iang.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/99HiwsJG85q7ncMzb9xDPf0sbRY Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:46:22 -0000 On 10/07/2014 11:13 am, ianG wrote: ... > This immediately raised several issues in my mind: > > * What is the alternate? > * What is its name? In the below, I experiment with the term 'complete protection' rather than 'strong security'. > * Is there a document for this? > * Shouldn't the present draft refer to it? > > Looking at the draft, it says: > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering strong protection some of the > time, .... > > Historically, Internet security protocols have prioritized strong > protection for peers capable and motivated to absorb the associated > costs. Since strong protection is not universally applicable, while > communications traffic was sometimes strongly secured, more typically > it was not protected at all. .... > > > > The draft makes a stab at calling the alternate 'strong protection' but > does not go much further. Abstract. This memo defines the term "opportunistic security". In contrast to the established approach of delivering complete protection when possible, and none if not possible, ... 1. Intro. Historically, Internet security protocols have prioritized complete protection for peers capable and motivated to absorb the associated costs. Complete protection has been defined within protocol as to require full mitigation of certain agreed threats, and to fail completely if such threats could not be fully mitigated. For example, authentication. Such a complete protection is not universally applicable, and in many contexts there is an opportunity for substantial benefit from partial mitigation. E.g., in order to mitigate pervasive monitoring, opportunistic encryption without authentication would be a big step forward. Further, the complexities of defining a complete security envelope that satisfied everyone often led to a race to the top. This high standard put such pressure on the costs of implementation that the deployment of solutions fell down drastically. When the choice was all-or-nothing, far too frequently users got nothing. This draft introduces "opportunistic security" as a better way to address the needs of Internet users and mass traffic, by deploying some protection more of the time. ... Note. I was really whiteboarding here for myself, and am only sending this because of the strident response from Martin/Gen-Art. Feel free to ignore, but if there is to be a wholesale revision anyway, well... let's get it right. iang From nobody Fri Jul 11 05:56: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 390CE1B2ABD for ; Fri, 11 Jul 2014 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSN1QzhV7W_l for ; Fri, 11 Jul 2014 05:56:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8E1B2817 for ; Fri, 11 Jul 2014 05:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6B3C8BE17; Fri, 11 Jul 2014 13:56:19 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_YkfnvWawOO; Fri, 11 Jul 2014 13:56:19 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A9C5BE16; Fri, 11 Jul 2014 13:56:19 +0100 (IST) Message-ID: <53BFDEF3.7090202@cs.tcd.ie> Date: Fri, 11 Jul 2014 13:56:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> In-Reply-To: <53BFDC9A.5060307@iang.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/68MOG8zeJnIeqi9omYxM-WKCOnA Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:56:34 -0000 On 11/07/14 13:46, ianG wrote: > but if there is to be a wholesale revision anyway Too early to say that. Martin commented and Viktor responded and we'll see where that goes. And in case not everyone knows, documents in IETF LC get various directorate reviews (secdir, gen-art, etc.) which are organised in different ways but all of them ought be handled just like other LC comments sent by anyone - just because its the foo-dir review doesn't change that. Cheers, S. From nobody Fri Jul 11 06:49: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 9F8971B2ADC for ; Fri, 11 Jul 2014 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_4dODF2_gOa for ; Fri, 11 Jul 2014 06:49:07 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78101B2AC6 for ; Fri, 11 Jul 2014 06:49:07 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so1001383igc.0 for ; Fri, 11 Jul 2014 06:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qFz4t622BBQ9+/TdN4l6ESII+SYADJ09V+CmNxVkMew=; b=y0xjpwCDr3jlzD6Zcb4KBVdkgiRKyn+VzJj4bBeBOs5+JG6jGPfwPLxy62Fayv/gpK /0vpZ8HqCGYeAak+N7VFPbKUru3i5n5kNeigvbonDi6dxWOSBqV4l/Rtich6iNJlYmzD cSL8FSK5Egiz30h23byRvphd/GK6pAHyemNy0fzGzbnunR0buybsP3/hCNL5gvYcTXH6 cvw1wSJsck5JH1p+NIxgjoTPL6Kb7nsRQfByAKOIe8rd1ERS/xwlcmVib2ivbg8Y1MQT 3q1CiBpmnG+p2/5mJ9C74fzmLs12INkwPE3djLBE07EMzUdADqm8bU+/krtVsHR0nNJq fydA== X-Received: by 10.42.202.14 with SMTP id fc14mr4916599icb.8.1405086547129; Fri, 11 Jul 2014 06:49:07 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id b10sm6113512igf.20.2014.07.11.06.49.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 06:49:06 -0700 (PDT) Message-ID: <53BFEB4C.1070506@gmail.com> Date: Fri, 11 Jul 2014 09:49:00 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Hannes Tschofenig , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> <53BEDD84.9080504@gmx.net> <53BEE18D.1030209@gmail.com> <53BFB73C.7020102@cs.tcd.ie> In-Reply-To: <53BFB73C.7020102@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/mSqWXhQMqA7MelwrogBGsvC1BsY Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:49:09 -0000 Dear Stephen: Thanks for your note. Problem with your note is that it is very generic and not actionable at all. It would be good if we could document the reasons for the real or perceived complexity and cost. Only if we know what the problems are, can we solve them... Some more comments inline. Rene On 7/11/2014 6:06 AM, Stephen Farrell wrote: > Hi Rene, > > On 10/07/14 19:55, Rene Struik wrote: >> Hi Hannes: >> >> The question I raised was triggered by Stephen Farrell's suggestion that >> "doing that [mutual authentication] gets very complicated and >> expensive". There seems to be more to that than just the cost of some >> software or hardware on a device (for otherwise, why would Stephen bring >> this up in the context of opportunistic encryption and "catching up with >> requirements that changes" (which I read as "mass surveillance") -- > No I don't think pervasive monitoring (PM) is the main change at > all though it is something we need to better mitigate, and the OS > work is part of that for sure. > > I think the size of the Internet has been the main change. > > Some of our security (and other) technologies were designed > 15 or so years back mostly considering enterprise networks with > say 10^6 or fewer things involved and where there were folks > whose day job was to mind every part of that network. A lot of > reasonable assumptions in that context no longer really apply. RS>> It would help to specify and enumerate the reasonable assumptions at that time and why those "no longer really apply". BTW - it seems you are suggesting that now mutual authentication has to deal with more than 10^6 things involved and that that makes a difference. If so, it would be good to clarify whether this is in one network or administrative domain or just an aggregate of all objects out there (and articulating whether one really wants to connect two random objects in the world). Why would the 10^6 threshold make a difference. What problems creep up. Etc, etc.? Is the problem in admin-heavy architectures, witness "where there were folks whose days job was to mind every part of the network", or something else? For me, it is hard to tell. < For example, I think the ability to relatively easily set up > useful mutual (or even one-way) authentication to the point > where you hard-fail or go insecure when you don't get that > authentication is one of those assumptions. RS>> Again, it would help to describe why this assumption held up, but now apparently (your argument) does not any more. Some supporting evidence, including classification of where the source of the problems is helps (technical from security perspective, security architectural, economical, self-inflicted, due to spokes [or spooks?] in the wheel) helps here, since would provide a problem statement. <> If OS has more global revolutionary aspirations, it would be good to describe this somewhere. I got the impression that opportunistic encryption was more about administrator-less security. If wrong and this is about raising the security bar while at the same time improving ease of use and ease of deployability, that would be good to codify. To my knowledge, the ease of use argument has not been used. Or, are you referring to autonomic networking activities? If the answer is "yes, we are going to do all", that is okay, but still requires a current state, identification of deltas, etc. Now, it is hard to guess what problem you are trying to bring up, since I mostly see some fuzzy feel-good factors, which are not actionable and do not provide a problem statement. <> after all, the code size of the TLS stack does not seem to be dominated >> by crypto libraries). >> >> Again, if I am wrong and it would be just the cost of some software or >> hardware on a device, that would be good to establish. If there is more >> to this, then we should list this and make sure we work towards >> addressing the complexities and expenses that were suggested. >> >> Stephen, any thought on this? What did you mean? >> >> Rene >> [BTW - if my email was on DICE issues, I would have responded to the >> DICE WG. It was not, though] >> >> On 7/10/2014 2:37 PM, Hannes Tschofenig wrote: >>> Hi Rene, >>> >>> On 07/10/2014 07:57 PM, Rene Struik wrote: >>>> I never suggested an abstract discussion; those are your words. >>> I was thinking about the most recent mail on the DICE mailing list and >>> the argument "requiring more capable devices slows >>> and limits market adoption" was brought up. >>> >>> The issue is of course about the type of protocol/cryptography being >>> used for mutual authentication (instead of whether mutual authentication >>> should be supported or not). >>> >>> Ciao >>> Hannes >>> >>> >>> >> -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Jul 11 07:09: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 ADC411B2B06; Fri, 11 Jul 2014 07:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzqwurVxnefY; Fri, 11 Jul 2014 07:09:31 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DC91B2B1D; Fri, 11 Jul 2014 07:09:06 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so1016824iga.13 for ; Fri, 11 Jul 2014 07:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0fujVlMbsXz5EalpHWWMHSDAXF/KCjd2Spx5FQNSXjo=; b=y0IrWa81Xfs2NZaI2HHHArTxaKjUJQhxyOPjWp4lFn9dvLYtIgiUyeuTpOp7psP16O 07Fh6UAL7m5g5QdP5XPNnfq8oik5+s75mp/GB8vssXtxWy3IY94P12SUZz8TtKD6ocWx Q132pI7qOICqwP7fBv+NZJNqlkOJYel0wMAxFjzWEGRoDjuFxXOkL/yndazaCuFJY4E2 sqofmS0vuM2YiyZae/r4o2yYhXFHQhk0F2Q9lfoZrOPQ1h5KMZJw5cwaJw0lbyEEK9Bj iZJ90KG5YqEou68yC8FhxkOKt7OI3w9hAshWF3wLOUlUBr6ckjHpUjPE7SBqRI4HV72L l9vQ== X-Received: by 10.42.202.14 with SMTP id fc14mr5042096icb.8.1405087746117; Fri, 11 Jul 2014 07:09:06 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id db12sm6268697igc.14.2014.07.11.07.09.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 07:09:05 -0700 (PDT) Message-ID: <53BFEFFB.80809@gmail.com> Date: Fri, 11 Jul 2014 10:08:59 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" , "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> In-Reply-To: <53BC0F94.8020608@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/ylaMh7J_xnWHPXqZJlHnNHJncGw Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:09:33 -0000 Dear colleagues: One of my concerns with Optimistic Encryption is that it may have as side effect that it may be tempting for implementers to move from secure and authentic channel set-up to just encrypted (but unauthenticated) channels, since it - how convenient - removes the need for any admin... I can already see arguments about why one should spend money on authentication support if the attack window is so small, etc., akin to discussions I have seen rampant in industrial control settings, where some people have argued that communicating symmetric keys wirelessly over the air for bootstrapping is okay, "since nobody would listen in anyway". I think this is a major risk. If this "substitution risk" would materialize, we might actually lower the bar and set back the clock nearly 40 years, since realizing encrypted, unauthenticated channels already proposed in the 1976 paper on "New Directions in Cryptography". Shouldn't one at least add some more extensive verbiage about security policy enforcement? After all, reason to do authentication would be to have some evidence on the party one is communicating with and can then arrive at more fine-grained conclusions as to authorization and scope hereof, based on that evidence. The the day-to-day risk for security architectures may be increase of admin cost if there would ever be a lifecycle event after initial provisioning and where lack of authentication may really hurt. Rene On 7/8/2014 11:34 AM, Stephen Farrell wrote: > IETF LC started as promised. > > Cheers, > S. > > > -------- Original Message -------- > Subject: Last Call: > (Opportunistic Security: some protection most of the time) to > Informational RFC > Date: Tue, 08 Jul 2014 08:09:40 -0700 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Opportunistic Security: some protection most of the time' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering strong protection some of the > time, opportunistic security strives to deliver at least some > protection most of the time. The primary goal is therefore broad > interoperability, with security policy tailored to the capabilities > of peer systems. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > This document and a predecessor have been the subject of discussion > on the saag mailing list. [1] > > [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html > > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Jul 11 07: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 5ABF61B2B08; Fri, 11 Jul 2014 07:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fs4Qbmy77WR; Fri, 11 Jul 2014 07:10:54 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06831B28F5; Fri, 11 Jul 2014 07:10:54 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so3903640iga.16 for ; Fri, 11 Jul 2014 07:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YM03bNeihHRzvPePFENlk7q7Nv3Lt4Diuq4rBMxavMs=; b=BOm82u0Hu7qfmKeZIRW8F5oWEObuVI+7U6DZC02LPHi0jOMrLC7duNPuwmBZay8lDu EaCmHY07gcZrH1gDzJqpr3EZtP0X673JZlq+ZiVPJnti0/BdDja2joG0Om9aXM1AjFcr Csa2sWVbKGHn0KCdycrQD/f6+n30vTUhuPPwrFY2IXM20JdB3FZuI4IJLfGJGYdOO1f8 8MRDA9vNH+OV7FM0z6z+0ozYizX67XoAzhwQslNmvlaDKy1C7LhNmYF6BUwtrwk1f1IM +qRuibbb3dwUVu52Ap1mzy6l6Ar8ZqxEvMlbErRGoMRF9P6hwBMCrUuji93oCCjjNby2 0yvQ== X-Received: by 10.50.114.194 with SMTP id ji2mr4700831igb.21.1405087854177; Fri, 11 Jul 2014 07:10:54 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id y11sm6262598igp.14.2014.07.11.07.10.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 07:10:53 -0700 (PDT) Message-ID: <53BFF067.4060306@gmail.com> Date: Fri, 11 Jul 2014 10:10:47 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" , "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> In-Reply-To: <53BFEFFB.80809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/T2g1rcc9SnwhVpDbYRLbu_R0abc Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:10:57 -0000 Sorry - "optimistic encryption" should read "opportunistic security" (although, perhaps, captures this as well...) On 7/11/2014 10:08 AM, Rene Struik wrote: > Dear colleagues: > > One of my concerns with Optimistic Encryption is that it may have as > side effect that it may be tempting for implementers to move from > secure and authentic channel set-up to just encrypted (but > unauthenticated) channels, since it - how convenient - removes the > need for any admin... I can already see arguments about why one should > spend money on authentication support if the attack window is so > small, etc., akin to discussions I have seen rampant in industrial > control settings, where some people have argued that communicating > symmetric keys wirelessly over the air for bootstrapping is okay, > "since nobody would listen in anyway". I think this is a major risk. > > If this "substitution risk" would materialize, we might actually lower > the bar and set back the clock nearly 40 years, since realizing > encrypted, unauthenticated channels already proposed in the 1976 > paper on "New Directions in Cryptography". > > Shouldn't one at least add some more extensive verbiage about security > policy enforcement? After all, reason to do authentication would be to > have some evidence on the party one is communicating with and can then > arrive at more fine-grained conclusions as to authorization and scope > hereof, based on that evidence. > > The the day-to-day risk for security architectures may be increase of > admin cost if there would ever be a lifecycle event after initial > provisioning and where lack of authentication may really hurt. > > Rene > > On 7/8/2014 11:34 AM, Stephen Farrell wrote: >> IETF LC started as promised. >> >> Cheers, >> S. >> >> >> -------- Original Message -------- >> Subject: Last Call: >> (Opportunistic Security: some protection most of the time) to >> Informational RFC >> Date: Tue, 08 Jul 2014 08:09:40 -0700 >> From: The IESG >> Reply-To: ietf@ietf.org >> To: IETF-Announce >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Opportunistic Security: some protection most of the time' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2014-08-05. Exceptionally, comments >> may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering strong protection some of the >> time, opportunistic security strives to deliver at least some >> protection most of the time. The primary goal is therefore broad >> interoperability, with security policy tailored to the capabilities >> of peer systems. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> This document and a predecessor have been the subject of discussion >> on the saag mailing list. [1] >> >> [1] >> https://www.ietf.org/mail-archive/web/saag/current/maillist.html >> >> >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Jul 11 07:27:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8692E1B2B1A; Fri, 11 Jul 2014 07: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 UQOaFkwX_y1k; Fri, 11 Jul 2014 07:27:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19D91B2B0F; Fri, 11 Jul 2014 07:27:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF7F32AB2AC; Fri, 11 Jul 2014 14:27:01 +0000 (UTC) Date: Fri, 11 Jul 2014 14:27:01 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140711142701.GG27568@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BFEFFB.80809@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SuFuyWRl1PtQvBpQb2ObpzwwOsw Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:27:05 -0000 On Fri, Jul 11, 2014 at 10:08:59AM -0400, Rene Struik wrote: > One of my concerns with Optimistic Encryption is that it may have as side s/Optmistic/Opportunistic/ > effect that it may be tempting for implementers to move from secure and > authentic channel set-up to just encrypted (but unauthenticated) channels, > since it - how convenient - removes the need for any admin... Unauthenticated encryption is only appropriate where no current key management approach scales. If unauthenticated encryption is employed within an organization, that's a security failure that needs to be addressed by the organization's IT team. In parallel with advancing opportunistic security at Internet scale, we need to improve key management at enterprise scale. Make Kerberos easier to deploy. Make internal DNSSEC easier to deploy (and publish SSHFP and DANE TLSA records, ...). Making security ubiquitous is a battle on multiple fronts. I am hoping to define opportunistic security without mapping out the whole security landscape. Perhaps the larger landscape is a different document? Opportunistic security is intended to strengthen SMTP, HTTP and the like, not weaken enterprise applications or industrial control systems. I don't think the opportunistic security definition promotes sloppy internal risk management. However, if this is felt to be important to state explicitly, I think a sentence or two along those lines might be acceptable in the security considerations section. -- Viktor. From nobody Fri Jul 11 07:34: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 2C5071B2B58; Fri, 11 Jul 2014 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GiKFuejpWNa; Fri, 11 Jul 2014 07:33:54 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA9C1B2B1A; Fri, 11 Jul 2014 07:33:54 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so959781iec.16 for ; Fri, 11 Jul 2014 07:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0Ho6sZjdURvvi4VT3r+x7GuRBHzLT6WKArJSMiUgAf0=; b=RydAJMioyj8BhydSn9DHchSjIBzDsrKxGUUro2R5k7Pd36gqNPCgDY15LbdzE01hvG nwFPf0XaG+xzt/g8rdPelU6lCMBFf71TV2cQ1a47MEfW1HZSSit7O1/g2/pLT/m2CtjZ WijLQ2TGlofbgiq8NaiLVwzRATSl/5UfTxC9M8XaMebw/Wp/X6CoJlGWvjiUET70y/Ra XpMMj/FheYLn+4kqlKDolDuwQC3Y8FWJ66p6ApgwiEwjEepbnLvKccMsNMKw6crEXG4o BCHUTr9dWWmwuOe3noEndZqbPRNEAE6avnHaSoIGQz42UMwK1nUuf+sAUtKLTU3laAZ6 NZNg== X-Received: by 10.50.25.196 with SMTP id e4mr4978209igg.28.1405089234202; Fri, 11 Jul 2014 07:33:54 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id j10sm6437862igv.17.2014.07.11.07.33.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 07:33:53 -0700 (PDT) Message-ID: <53BFF5CB.8030404@gmail.com> Date: Fri, 11 Jul 2014 10:33:47 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> <20140711142701.GG27568@mournblade.imrryr.org> In-Reply-To: <20140711142701.GG27568@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/vA_EVTqT-v42IYthPI4-6IHJ9cY Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:34:01 -0000 The definition does not promote sloppy risk management, its use may (history of practical use of security is embarassingly full of sloppiness and taking shortcuts). Rene == I don't think the opportunistic security definition promotes sloppy internal risk management. However, if this is felt to be important to state explicitly, I think a sentence or two along those lines might be acceptable in the security considerations section. On 7/11/2014 10:27 AM, Viktor Dukhovni wrote: > On Fri, Jul 11, 2014 at 10:08:59AM -0400, Rene Struik wrote: > >> One of my concerns with Optimistic Encryption is that it may have as side > s/Optmistic/Opportunistic/ > >> effect that it may be tempting for implementers to move from secure and >> authentic channel set-up to just encrypted (but unauthenticated) channels, >> since it - how convenient - removes the need for any admin... > Unauthenticated encryption is only appropriate where no current > key management approach scales. If unauthenticated encryption is > employed within an organization, that's a security failure that > needs to be addressed by the organization's IT team. > > In parallel with advancing opportunistic security at Internet scale, > we need to improve key management at enterprise scale. Make Kerberos > easier to deploy. Make internal DNSSEC easier to deploy (and publish > SSHFP and DANE TLSA records, ...). > > Making security ubiquitous is a battle on multiple fronts. I am > hoping to define opportunistic security without mapping out the > whole security landscape. Perhaps the larger landscape is a > different document? > > Opportunistic security is intended to strengthen SMTP, HTTP and > the like, not weaken enterprise applications or industrial control > systems. > > I don't think the opportunistic security definition promotes sloppy > internal risk management. However, if this is felt to be important > to state explicitly, I think a sentence or two along those lines > might be acceptable in the security considerations section. > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Jul 11 07:43: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 393F71B2B3E for ; Fri, 11 Jul 2014 07:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xprTNDCa18NF for ; Fri, 11 Jul 2014 07:43:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18E1B2B17 for ; Fri, 11 Jul 2014 07:43:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76FD9BE16; Fri, 11 Jul 2014 15:43:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft0jj5_QRWxx; Fri, 11 Jul 2014 15:43:09 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51291BE14; Fri, 11 Jul 2014 15:43:09 +0100 (IST) Message-ID: <53BFF7FD.2090001@cs.tcd.ie> Date: Fri, 11 Jul 2014 15:43:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Struik , Hannes Tschofenig , Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> <53BEDD84.9080504@gmx.net> <53BEE18D.1030209@gmail.com> <53BFB73C.7020102@cs.tcd.ie> <53BFEB4C.1070506@gmail.com> In-Reply-To: <53BFEB4C.1070506@gmail.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/VEO3308kqAIbYrdQuhXQM8zp4ZE Cc: "saag@ietf.org" Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:43:14 -0000 Hiya, On 11/07/14 14:49, Rene Struik wrote: > Dear Stephen: > > Thanks for your note. Problem with your note is that it is very generic > and not actionable at all. Hmm... That's probably ok since it wasn't intended to be actionable at all. I was responding to a comment and simply gave my impression of a bit of the background. Its not really that important. And its defo. not something on which we need to (dis)agree in an IETF context. > It would be good if we could document the reasons for the real or > perceived complexity and cost. Sure. If someone did want to try document how and why all our current set of standardised security mechanisms came about, or try to characterise their strengths and weaknesses, that would be interesting. But I suspect it'd be a lot of controversial work for little benefit. And I don't plan on trying to do that fwiw:-) > Only if we know what the problems are, > can we solve them... No. I do not agree that we need an exhaustive list of problems, nor a characterisation of all that's bad about current security protocols, before we can make progress. I definitely do not agree that we need a description of why such defects may have come into existence, before we can make progress. I think its much easier than that. We think that e.g. SMTP/TLS between MTAs was used maybe about 20% of the time up to a year or so ago (from offlist mail I've gotten, dunno if there's good published info). FB published stats with that at about 60% recently, with maybe half of that being OS. That by itself is good enough for me, even though I think the argument for OS being useful could be made without that evidence. (Mind you, I'm biased as I was already convinced myself beforehand:-) By "good enough" I mean its good enough to convince me that OS has potential benefit, and hence that defining that to make it easier to use is a good idea. And via the IETF LC, we'll see if Viktor's draft that aims to do that is something on which the IETF do, or do not, have consensus. Its all pretty simple really. Now, when it comes to discussion of how and whether to use OS in some specific context (e.g. HTTP) then that should be discussed wherever the relevant protocol is being developed (httpbis in that case) and not here (which has been done in the HTTP case too). And as I commented to Eliot in the LC thread, its pretty early days in some respects so we're not at a stage where we have a worked out consensus recommending when protocols should or should not use OS. For now, we're just defining OS so that it can more easily be used without re-running the basic arguments over and over should folks want to use this appraoch. (Again, as has happened in httpbis, though if they had had this draft as an RFC, that'd have saved them some time, effort and even a little bit of angst.) > > Some more comments inline. I didn't do a blow-by-blow response to those, as I think the above covers it. Cheers, S. PS: Global revolution? Really? :-) From nobody Fri Jul 11 22:24: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 722471B29FE for ; Fri, 11 Jul 2014 22:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MvECzFlE5re for ; Fri, 11 Jul 2014 22:24:14 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6CF1A030F for ; Fri, 11 Jul 2014 22:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1405142654; x=1436678654; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qmLb3WK2dseKsYMuV51IOSAImol1d4r+goD68ONW5r8=; b=Fz8P/wH64WWAwb+y5Z9/OnpM63WRmeCU1Qz9DTY3SB+bszSf22xe/WFt LQ+Ko+qnwPFyUHsDghgYlAURinGdqWGue7Kt+DSGiYrYZKme7wRRLZAsU NhjJJtH+M4SdUEssVCCdkH3nKJETIru31rJ89ZppBVK/rOoTgQVpp1LIs g=; X-IronPort-AV: E=Sophos;i="5.01,647,1399982400"; d="scan'208";a="263423587" 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 Jul 2014 17:24:09 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.91]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 17:24:09 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC Thread-Index: Ac+dkXP4ARAZ6nWsSJ6CwcKENjzvsg== Date: Sat, 12 Jul 2014 05:24:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFA35B3@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/F3SVxJkX9soHAmlqPlyRhACCx88 Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 05:24:17 -0000 ianG writes:=0A= =0A= >This immediately raised several issues in my mind:=0A= >=0A= > * What is the alternate?=0A= > * What is its name?=0A= =0A= In the absence of any clear answers, could I propose "Voltaire Security"?= =0A= =0A= > * Is there a document for this?=0A= =0A= The usual source is "La B=E9gueule", for which line two states "le mieux es= t l'ennemi du bien".=0A= =0A= Peter.=0A= =0A= From nobody Sat Jul 12 06:23: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 A94EB1B2880 for ; Sat, 12 Jul 2014 06:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsFIg715dzAw for ; Sat, 12 Jul 2014 06:23:45 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD72F1B2A72 for ; Sat, 12 Jul 2014 06:23:45 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id E278A6D49C; Sat, 12 Jul 2014 09:23:40 -0400 (EDT) Message-ID: <53C11E49.7090003@iang.org> Date: Sat, 12 Jul 2014 12:38:49 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BE6D94.309@cs.tcd.ie> <53BEA74D.3080207@gmail.com> <53BED198.2040804@gmx.net> <53BED401.90609@gmail.com> <53BEDD84.9080504@gmx.net> <53BEE18D.1030209@gmail.com> <53BFB73C.7020102@cs.tcd.ie> <53BFEB4C.1070506@gmail.com> In-Reply-To: <53BFEB4C.1070506@gmail.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/76z8iC5JeuhULK133WG9ObqxgZ0 Subject: Re: [saag] (on need for I-D on apparent complexity and expense in mutual authentication) Re: Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 13:23:47 -0000 On 11/07/2014 14:49 pm, Rene Struik wrote: >> Some of our security (and other) technologies were designed >> 15 or so years back mostly considering enterprise networks with >> say 10^6 or fewer things involved and where there were folks >> whose day job was to mind every part of that network. A lot of >> reasonable assumptions in that context no longer really apply. > RS>> > It would help to specify and enumerate the reasonable assumptions at > that time and why those "no longer really apply". The clue I see is 'enterprise'. Many people working in the 1990s were employed by corporations (people needed to eat, right?). The corporations could afford the costs of authentication systems, and some of those corporations were the costs of the authentication systems. There was a bias towards authentication as commercially viable business model. Fast forward to now, and the cost of these authentication systems has delivered a rather mixed result. Yes, it worked in the direct case, but there are many side-effects, and poor deployment. A lot of the failures trace back to the cost-of-authentication assumptions. So, the OS strategy has it that we make authentication free. By not doing it, if necessary, and by making it available if we can. ... > Again, it would help to describe why this assumption held up, but now > apparently (your argument) does not any more. Look at HTTPS. A huge part of the problem with phishing is that the web isn't fully encrypted and authenticated. When it was first envisaged, it was hoped that everything would be covered for any retail site, and therefore we could lean more heavily on certificates. But when first deployed (1995?) the cost of encryption was too high, so the retail websites split into credit card accepting on HTTPS, and the rest on HTTP. Fast forward to 2003 and the expected phishing attacks simply launched copy sites in HTTP. Nobody could tell the difference, and the browsers couldn't help. The real solution here is to get everything onto HTTPS, the same system. Once that is done, browsers can more heavily concentrate on the reliance of the name, because it is more often there. Assumptions that have changed: cost of encryption. Need for full authentication. Discovery of pervasive monitoring. Need to serve business foremost. > RS>> > If OS has more global revolutionary aspirations, it would be good to > describe this somewhere. I got the impression that opportunistic > encryption was more about administrator-less security. If wrong and this > is about raising the security bar while at the same time improving ease > of use and ease of deployability, that would be good to codify. Yes, it's both, causally. To improve security, we want to make it administrator-free. iang From nobody Mon Jul 14 08:48: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 7DC861A0AB7 for ; Mon, 14 Jul 2014 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiCilUydZITQ for ; Mon, 14 Jul 2014 08:48:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3971A0AB5 for ; Mon, 14 Jul 2014 08:48:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2B60BE32 for ; Mon, 14 Jul 2014 16:48:01 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAD2mEK9witO for ; Mon, 14 Jul 2014 16:48:01 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8697ABE1D for ; Mon, 14 Jul 2014 16:48:01 +0100 (IST) Message-ID: <53C3FBB1.3040308@cs.tcd.ie> Date: Mon, 14 Jul 2014 16:48:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ifrv6CYlPhDW0tuHl_a4Ec5Ler8 Subject: [saag] security AD gig X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 14 Jul 2014 15:48:06 -0000 Hi all, As you may know my term as security AD ends in March and nomcom are starting off the process of picking a security AD for the following two years. While I do intend to stick my name into the hat for another turn at the wheel, as of now, and as is typical in academia, my funding for that is not certain. So I would like to really encourage anyone who's able and interested in taking on the security AD gig to think about that, talk to your sponsors/management and try to make sure your name is also there for nomcom to consider. It really is important that nomcom have a good slate from which to select regardless of whether or not a good, bad or indifferent incumbent's name is also there. If you are thinking about it, and will be in Toronto, please do feel free to chat with me or Kathleen (or Sean who's just recently finished up) and we can fill you in on what's involved and further twist your arm:-) Or, just get in touch via mail. While the AD gig is a chunk of work, its actually pretty interesting so please do think about it. Or if you know someone you think would be good at it, please try talk them into putting their name in. Thanks, Stephen. PS: Please don't reply on-list to this. From nobody Mon Jul 14 17:44: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 63F721B27C7 for ; Mon, 14 Jul 2014 17:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsCBvQVgLPGd for ; Mon, 14 Jul 2014 17:44:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 838C81B27CD for ; Mon, 14 Jul 2014 17:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DDCD7BE32 for ; Tue, 15 Jul 2014 01:44:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qu-QU63atU6 for ; Tue, 15 Jul 2014 01:44:21 +0100 (IST) Received: from [10.87.48.5] (unknown [86.46.18.234]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BD6EBE2F for ; Tue, 15 Jul 2014 01:44:21 +0100 (IST) Message-ID: <53C47965.2070004@cs.tcd.ie> Date: Tue, 15 Jul 2014 01:44:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <38464A5C-BAF6-4A89-B1E6-8248B1F8B9F8@gmail.com> In-Reply-To: <38464A5C-BAF6-4A89-B1E6-8248B1F8B9F8@gmail.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <38464A5C-BAF6-4A89-B1E6-8248B1F8B9F8@gmail.com> Content-Type: multipart/mixed; boundary="------------010908030101090001060500" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DbTGs049jVXUqrOzpA79mZv7jFA Subject: [saag] Fwd: [Cryptography] VCAT report on NIST's process review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 15 Jul 2014 00:44:29 -0000 This is a multi-part message in MIME format. --------------010908030101090001060500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI. Probably of some interest here. Apparently comments, if you have 'em, ought go to crypto-review@nist.gov Cheers, S. -------- Original Message -------- Subject: [Cryptography] VCAT report on NIST's process review Date: Mon, 14 Jul 2014 16:51:46 -0400 From: John Kelsey To: Cryptography Mailing List Everyone, The VCAT (one of our oversight committees) convened a panel of experts to look over our interactions with NSA in our past cryptographic standards, including Dual EC. For those interested in the results and the materials posted, they can be found at http://www.nist.gov/director/vcat/cryptographic-standards-guidelines-process.cfm and http://csrc.nist.gov/groups/ST/crypto-review/review_materials.html --John --------------010908030101090001060500 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography --------------010908030101090001060500-- From nobody Tue Jul 15 06:59: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 EE99A1B28B9 for ; Tue, 15 Jul 2014 06:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNOamYCeK4ZP for ; Tue, 15 Jul 2014 06:58: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 F17DA1B28B8 for ; Tue, 15 Jul 2014 06:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBC8EBE32; Tue, 15 Jul 2014 14:58:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDBQ0XC8ZnHU; Tue, 15 Jul 2014 14:58:54 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 983C4BE2F; Tue, 15 Jul 2014 14:58:54 +0100 (IST) Message-ID: <53C5339E.2040406@cs.tcd.ie> Date: Tue, 15 Jul 2014 14:58:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/a2TB5oKnLq7wXAv2RB4CtLBYeiI Cc: Lucy Lynch , Leif Johansson Subject: [saag] CrypTech lunch meeting @ IETF90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 15 Jul 2014 13:59:01 -0000 Hi all, The good folks who're working on the CrypTech [1] project are going to have another Wednesday lunchtime session at IETF90 to update on what's been happening since March when they had a session. As a reminder, they're trying to develop an open-source h/w crypto module which could have lots of interesting IETF-relevant uses. If you're interested in coming along, please let Leif, Randy or Lucy (all cc'd here) know so the room's not swamped. (I'm told there's space for about 30 in relative comfort.) Its a bring-your-own affair both in terms of lunch and questions. Room is Quebec, start time is 11:45(ish:-) Cheers, S. [1] https://cryptech.is From nobody Fri Jul 18 09:14: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 C82801B29E6 for ; Fri, 18 Jul 2014 09:14:33 -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 S2P2BuIcMz4i for ; Fri, 18 Jul 2014 09:14:32 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C051B2894 for ; Fri, 18 Jul 2014 09:14:31 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so4832012wes.28 for ; Fri, 18 Jul 2014 09:14:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CkWUjHjuPrBKjEqXZMM+f0hwLaoYUjn91DIqEv1Hg/Y=; b=BL9M/MP/GkLxo4CN1AfhQ5GWWQU9gFdapGFWX9wrUTSb5bLiQvMLUD5pK4UnGna6sy 52NthV9HfBANqj6/R6kEnNVvSnL4eBw8ifdLsYGBSFFiq8lGenLhzZvtm3LEUDsTiYMt gSecajHXlrmA63G91x4Nuhm/SlQOY6ypTPDhvmIqb8RczBZUg0nKsT/3+D8BzGLL3oT0 yDtCFp/c0eNXF0H6oh09tU4EG4xqHMPPysQegpKwIEXKMrZfZX49a/WcSL71MQj6gqVG xluirbRZ9Y/RPCFgIRINDHiv0F8pkmOjs63Pq4qgPslURtaX2wQGG1iq/nOSLkWPZpp8 5PoQ== X-Gm-Message-State: ALoCoQl4BYfc35nkXNOCl60mEG7LHpFufNFMZczprCBFWUuv28rHUCoQopYRSMxQsEeR8Brz7ZRL MIME-Version: 1.0 X-Received: by 10.194.222.230 with SMTP id qp6mr8310678wjc.23.1405700069057; Fri, 18 Jul 2014 09:14:29 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Fri, 18 Jul 2014 09:14:28 -0700 (PDT) In-Reply-To: <53C5339E.2040406@cs.tcd.ie> References: <53C5339E.2040406@cs.tcd.ie> Date: Fri, 18 Jul 2014 12:14:28 -0400 Message-ID: From: Warren Kumari To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ibxZIcwIvl1xD2x7DN3y49jWgC4 Cc: Lucy Lynch , "saag@ietf.org" , Leif Johansson Subject: Re: [saag] CrypTech lunch meeting @ IETF90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 18 Jul 2014 16:14:34 -0000 On Tue, Jul 15, 2014 at 9:58 AM, Stephen Farrell wrote: > > Hi all, > > The good folks who're working on the CrypTech [1] project > are going to have another Wednesday lunchtime session at > IETF90 to update on what's been happening since March when > they had a session. As a reminder, they're trying to develop > an open-source h/w crypto module which could have lots of > interesting IETF-relevant uses. > > If you're interested in coming along, please let Leif, Randy > or Lucy (all cc'd here) know so the room's not swamped. (I'm > told there's space for about 30 in relative comfort.) If there is still space, I'd like to attend please... W > > Its a bring-your-own affair both in terms of lunch and > questions. Room is Quebec, start time is 11:45(ish:-) > > Cheers, > S. > > [1] https://cryptech.is > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Jul 18 09: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 F3D0B1A0301 for ; Fri, 18 Jul 2014 09:29:07 -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, RP_MATCHES_RCVD=-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 PZEr0Wjd9-HH for ; Fri, 18 Jul 2014 09:29:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D6D421A0404 for ; Fri, 18 Jul 2014 09:29:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48836BEA1 for ; Fri, 18 Jul 2014 17:29:05 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsDICJihXIeN for ; Fri, 18 Jul 2014 17:29:04 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.53.207]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 087E3BE9C for ; Fri, 18 Jul 2014 17:29:04 +0100 (IST) Message-ID: <53C94B4F.4010505@cs.tcd.ie> Date: Fri, 18 Jul 2014 17:29:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VKIOkzZD19PqLQ2W3H0iJSsRGvM Subject: [saag] saag agenda posted X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 18 Jul 2014 16:29:08 -0000 Hiya, I've posted the agenda for saag next week. [1] Its quite light at the moment, as we had one presentation fall through and we're still waiting on confirmation before including another 20 minute slot. So if you have a shortish topic of general interest you'd like to present (and haven't already mailed us) please send Kathleen and I a mail offlist and we can chat about it. Cheers, S. [1] https://www.ietf.org/proceedings/90/agenda/agenda-90-saag From nobody Fri Jul 18 10:26: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 EE8EC1A055D for ; Fri, 18 Jul 2014 10:26:15 -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 4t9LFOF2hAmn for ; Fri, 18 Jul 2014 10:26:14 -0700 (PDT) Received: from nk11p14im-asmtp002.me.com (nk11p14im-asmtp002.me.com [17.158.72.161]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E341B27CC for ; Fri, 18 Jul 2014 10:26:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from unknown-b8-e8-56-34-a1-fc.home ([31.53.53.78]) by nk11p14im-asmtp002.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0N8X004CR4FJ8B90@nk11p14im-asmtp002.me.com> for saag@ietf.org; Fri, 18 Jul 2014 17:26:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-18_04:2014-07-18,2014-07-18,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-1402240000 definitions=main-1407180202 From: David Misell In-reply-to: Date: Fri, 18 Jul 2014 18:26:08 +0100 Message-id: References: <53C5339E.2040406@cs.tcd.ie> To: Warren Kumari X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HH4DNsd8E6xorX3HmjNFoigag2Q Cc: Lucy Lynch , Cornelia Boldyreff , Leif Johansson , "saag@ietf.org" Subject: Re: [saag] CrypTech lunch meeting @ IETF90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 18 Jul 2014 17:26:16 -0000 warren, Can you share your notes and I am happy to host an OS session in London if there is scope to mirror by Video with BCS OSSG (www.ossg.bcs.org) dave On 18 Jul 2014, at 17:14, Warren Kumari wrote: > On Tue, Jul 15, 2014 at 9:58 AM, Stephen Farrell > wrote: >> >> Hi all, >> >> The good folks who're working on the CrypTech [1] project >> are going to have another Wednesday lunchtime session at >> IETF90 to update on what's been happening since March when >> they had a session. As a reminder, they're trying to develop >> an open-source h/w crypto module which could have lots of >> interesting IETF-relevant uses. >> >> If you're interested in coming along, please let Leif, Randy >> or Lucy (all cc'd here) know so the room's not swamped. (I'm >> told there's space for about 30 in relative comfort.) > > If there is still space, I'd like to attend please... > > W > >> >> Its a bring-your-own affair both in terms of lunch and >> questions. Room is Quebec, start time is 11:45(ish:-) >> >> Cheers, >> S. >> >> [1] https://cryptech.is >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Jul 21 08:02: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 459D71B2AD8 for ; Sun, 20 Jul 2014 19:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 O_6wJ6_eqVQg for ; Sun, 20 Jul 2014 19:32:36 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1991B2AD7 for ; Sun, 20 Jul 2014 19:32:35 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so5733963wgh.6 for ; Sun, 20 Jul 2014 19:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ZEIHqPkC1MWNXjvpoCgB/7kNmeW8jo2z7AJm6B5RV1Y=; b=mTE7MjZNzh/EpoOC1hK2Mxwgijr8ZglfDsQeDqkWMqI1M7lBSOfheBOVgOpRHN4oi0 bltxJhg+j/Mfw3NINAhj68YAG/WpzQrgCcBji0LxFtxgXtro2QF4eseX2xftZFHjjXKp 32fgKhDx2z8tmb4HD33wqvU1q2xGaC+VUonUsoKGKjuJmv5s5lOJTVp7FwHWYwTc8git hLfNYo57d6pD4kn4dUW28S1pS8OBazw1Qs0A0v7AzeQHwF5fxpjNL1VcTBlZOdkq3bi3 7hU2gCPok7YWT7hVSd0S8xTj9JrEA5w1dtoimLf8jwQ2BR1Xv2H/taf3QngRP5g/TDEl 2z5w== MIME-Version: 1.0 X-Received: by 10.180.228.104 with SMTP id sh8mr53908240wic.64.1405909954662; Sun, 20 Jul 2014 19:32:34 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.123.167 with HTTP; Sun, 20 Jul 2014 19:32:34 -0700 (PDT) Date: Sun, 20 Jul 2014 22:32:34 -0400 X-Google-Sender-Auth: P9d-OgDIIEYZ4Oy-lms3OlQvgNQ Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ban6vFVuNYP9d_uLlk8oM2IliXo X-Mailman-Approved-At: Mon, 21 Jul 2014 08:02:21 -0700 Subject: [saag] Personal Privacy Environment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 21 Jul 2014 02:32:37 -0000 As some of you know I have been working on making secure email easy to use. As easy to use as regular email. We just did our first release at the HOPE-X conference in NYC today. A description of the project and links to all the materials (Internet drafts, you tube videos etc. etc.) can be found on the project Web Site http://prismproof.org/ By easy to use I mean absolutely no extra effort to use. Configuration is made very simple as well, just run a program and you are done. The only choice you would face is the choice of free hosting provider for your public key data. Right now the reference code only works for S/MIME and there is only effortless configuration for Windows Live Mail. But the same approach would work equally well for PGP and for other clients. The trust model is a direct trust model similar to direct exchange of PGP phingerprints. But there is provision to support TTP models including PKIX and Web of Trust as well. But both of these will benefit a lot from adopting some of the Certificate Transparency work. From nobody Mon Jul 21 11:19: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 B2ABB1A0354; Mon, 21 Jul 2014 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 weNY5gUT7CRz; Mon, 21 Jul 2014 11:19:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496BD1A0350; Mon, 21 Jul 2014 11:19:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkHAPFYzVOHCzIm/2dsb2JhbABQCYJHIyQfM1uuUgEBBpURgT8YAQmHRQGBHRZ2hAMBAQEBAQIBAQELBBs4CQQHEAIBCA0EBAEBCw4IAQYHJwsUCQgCBAENBQgaiAwDEQEMnRaaLwiHCReCYYMaiHUqLQQGARiCHw9EJIEYBY5DiESFa4VxjHGDRGwBgUQ X-IronPort-AV: E=Sophos; i="5.01,702,1400040000"; d="scan'208,217"; a="74746598" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Jul 2014 14:19:39 -0400 X-OutboundMail_SMTP: 1 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; 21 Jul 2014 14:19:38 -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, 21 Jul 2014 20:19:37 +0200 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "sacm@ietf.org" , "saag@ietf.org" Thread-Topic: Informal Gathering to discuss NSaaS (a.k.a Bar BoF) Thread-Index: AQHPpQGhcbj+vFVvcEWI5kv4slmd9Juq1hJg Date: Mon, 21 Jul 2014 18:19:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C84CF10@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.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_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hUkurhXwz7_jN0OJVjxHKB53BSY Cc: "Zarny, Myo" , 'Shaibal Chakrabarty' , "'christian.jacquenet@orange.com'" Subject: Re: [saag] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 21 Jul 2014 18:19:47 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the announcement, Linda. I encourage all interested SACM partici= pants to attend. We shall also make some room on the second SACM session on= Friday morning to discuss the outcome of the Bar BoF and relationship with= SACM. Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, July 21, 2014 7:34 PM To: sacm@ietf.org; saag@ietf.org Cc: Zarny, Myo; 'christian.jacquenet@orange.com'; 'Shaibal Chakrabarty' Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) We will have an informal gathering (a.k.a. Bar BOF) at New Brunswick room T= hurs at 8:30pm to discuss NSaaS. The purpose of this meeting is to collect comments and requirements from se= rvice providers to see there is justification for a full BOF at IETF 91. For this purpose I have invited Vodafone, DT, Cable Lab, Verizon, and Telef= onica to attend this informal gathering. Cheers, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Sunday, July 20, 2014 7:11 PM To: Linda Dunbar; 'David Harrington' Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen Moriar= ty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com' Subject: RE: Summerized differences between SACM and NSaaS Hello all, I can see why some could consider NSaaS as part of "security automation". A= fter all, NSaaS seeks to define how endpoints can request *network* securit= y services over standard protocols (or APIs), which will facilitate automat= ion. >From what I see, the current SACM charter seems mainly concerned with asses= sing endpoint posture, and how (by what protocols) requisite policies could= be pushed down to the endpoints. I see potential synergies but we'll need to iron out a few differences: * Scope: Security vs. network security services * Goal: Automating endpoint posture assessment vs. defining how ne= twork security services are requested * Security policy enforcement location: Endpoint vs network (and e= ndpoint-network security services could exist on the endpoint itself.) I'd like to add that the need to standardize how services could be requeste= d from the "cloud" goes beyond network security services. We've intentional= ly narrowed down the scope to network security in order not to chew too muc= h at once. (Indeed, one could argue network security itself already is a br= oad field.) On the other hand, we don't want to be too narrow: each IETF WG= solving essentially the same problem over and over in (slightly) different= ways isn't most productive and will create market confusion. I hope we'll = get the right balance here. Regards, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 18 July 2014 6:15 PM To: David Harrington Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakrabarty Subject: Summerized differences between SACM and NSaaS Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the announceme= nt, Linda. I encourage all interested SACM participants to attend. We shall= also make some room on the second SACM session on Friday morning to discuss the outcome of the Bar BoF and relationship with SACM. =

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Monday, July 21, 2014 7:34 PM
To: sacm@ietf.org; saag@ietf.org
Cc: Zarny, Myo; 'christian.jacquenet@orange.com'; 'Shaibal Chakrabar= ty'
Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF)<= o:p>

 

We will have an informal gathering (a.k.a. Bar BOF) = at New Brunswick room Thurs at 8:30pm to discuss NSaaS.

 

The purpose of this meeting is to collect comments a= nd requirements from service providers to see there is justification for a = full BOF at IETF 91.

For this purpose I have invited Vodafone, DT, Cable = Lab, Verizon, and Telefonica to attend this informal gathering.

 

Cheers,

 

Linda

 

 <= /p>

 <= /p>

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Sunday, July 20, 2014 7:11 PM
To: Linda Dunbar; 'David Harrington'
Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen= Moriarty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com'
Subject: RE: Summerized differences between SACM and NSaaS

 

Hello all,

 <= /p>

I can see why some could = consider NSaaS as part of “security automation”. After all, NSa= aS seeks to define how endpoints can request *network* security services over standard protocols (or APIs), which will facilitate automati= on.

 <= /p>

From what I see, the curr= ent SACM charter seems mainly concerned with assessing endpoint posture, an= d how (by what protocols) requisite policies could be pushed down to the endpoints.

 <= /p>

I see potential synergies= but we’ll need to iron out a few differences:

·     &nbs= p;   Scope:  Security vs. network security services

·     &nbs= p;   Goal:  Automating endpoint posture assessment vs. defining how= network security services are requested

·     &nbs= p;   Security policy enforcement location:  Endpoint vs network (an= d endpoint—network security services could exist on the endpoint itself.)

 <= /p>

I’d like to add tha= t the need to standardize how services could be requested from the “c= loud” goes beyond network security services. We’ve intentionall= y narrowed down the scope to network security in order not to chew too much at once. = (Indeed, one could argue network security itself already is a broad field.)= On the other hand, we don’t want to be too narrow: each IETF WG solv= ing essentially the same problem over and over in (slightly) different ways isn’t most productive and will= create market confusion. I hope we’ll get the right balance here.

 <= /p>

Regards,

 <= /p>

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 18 July 2014 6:15 PM
To: David Harrington
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakr= abarty
Subject: Summerized differences between SACM and NSaaS

 

Thanks to David H explanation and especially many thanks to Gunnar Enge= lbach’s extended examples for SACM, I summarized the major differences between SACM and NSaaS:

 

SACM: Security Assessment of End Points:

• &nbs= p;     End points can be routers, switches, clustered DB, installed piece = of software

• &nbs= p;     SACM is about “How to encode that policy in a manner where as= sessment can be automated”

• &nbs= p;     Examples:

– &nbs= p;    a Solaris 10 SPARC or Window 7 system used in a environment that re= quires adherence to a policy of Mission Critical Classified.

– &nbs= p;    rules like "The maximum password age must be 30 days" and= "The minimum password age must be 1 day"

 

NSaaS: Network Security as a Function:

• &nbs= p;     Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers<= /p>

• &nbs= p;     Firewall

• &nbs= p;     DDOS/Anti-DOS

• &nbs= p;     Access control/Authorization/Authentication

• &nbs= p;     Remote identity management

• &nbs= p;     Secure Key management

• &nbs= p;     Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

• &nbs= p;     Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc.

• &nbs= p;     Examples:

vCPE needs vFW that are hosted in the network.

vCPE provides the “Group Policies” for the vFW, like A can = talk to B & C, but B can’t talk to C.

 

Please let me know if you have comments/suggestions.

 

Thank you,

 

Linda  Dunbar

 

From: Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: RE: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

David,

 

Thank you very much for the reply.

 

 

What NSaaS intends to do is more along the line of BGP: distribute and = negotiate relevant policies to security functions, and receives supported policies for verification and coordination.

 

So it is quite different from the Data Modeling language, like SNMP or = Netconf.

 

We can discuss more at Toronto. SACM chairs have allocated a slot for u= s at Toronto meeting.

 

Linda

 

 

From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your = draft.

It appears to me, as a = contributor, that your use cases seem to fit within the scope of SACM.=

We are focused on endpo= int assessment, but in your use cases, the endpoint happens to be a virtual= endpoint in a virtual network, but an endpoint nonetheless.

And your use cases disc= uss assessing the configuration of security functionality on the virtual en= dpoint.

 

Your use cases raise so= me concerns that might be out of scope.

Inter-domain correlatio= n would be part of the functionality of the NMS/SMS/security manager applic= ation that is gathering reports of assessments.

I think SACM is focused= mainly on creating infrastructure for assessing individual endpoints, so t= hose assessments can be used by applications.

The infrastructure for = collecting data, storing data, and making the stored data accessible to app= lications would seem to be in scope.

What the application do= es with the data would seem to be out of scope.

 

Comparing this to an SN= MP ecosystem, the IETF defines a data modeling language, data models, and a= protocol for transporting the data. It assumes the data could be stored fo= r later retrieval.

But what an application= does with the collected/retrieved MIB data is not within the scope of the = SNMP infrastructure.

If the application trie= s to correlate MIB data across multiple management domains, that is not par= t of the IETF scope.

As far as I can see, al= most everything in your use cases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50= AM, Linda Dunbar <linda.dunb= ar@huawei.com> wrote:

 

SACM parti= cipants:

 

We have a draft on problem and use cases of enabling  enterprise (= or applications) to request/verify security functions hosted by network providers: http://tools.ietf.org/pdf/= draft-dunbar-nsaas-problem-statement-00.pdf.

 

We didn’t know which IETF area or WG are good fit for the propose= d work.

Security Area Director Kathleen Moriaty suggests that the proposed work= is somewhat related to SACM.

After reading through the SCAM charter, my initial feeling is that SCAM= doesn’t quite fit because SCAM is about  the language and data format for “endpoint posture assessmentR= 21;.  What we proposed is about the mech= anism to enable Network Security as a Service (NSaaS). I can see the mechan= isms provided by SCAM can be used for some attributes negotiation of NSaaS.

But I could be wrong.

 

We are seeking feedback from SACM group, in particular:

-          If what we propose fits with SACM?

-          Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-          Any other thoughts?

 

if it turns out that it is in the SCAM group scope, it is great. If it = doesn’t, we will see what else can be done.<= /o:p>

 

Linda Dunbar

 

_________= ______________________________________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C84CF10AZFFEXMB04globa_-- From nobody Mon Jul 21 16:57: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 D16EA1A02E9; Mon, 21 Jul 2014 16:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smanxjZ8-9dR; Mon, 21 Jul 2014 16:57:17 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD971A0066; Mon, 21 Jul 2014 16:57:17 -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 s6LNurFt012094; Mon, 21 Jul 2014 16:57:07 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1n8ud7k8dn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 16:57:07 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Mon, 21 Jul 2014 16:57:07 -0700 From: Paul Lambert To: Michael Richardson , Stephen Farrell Date: Mon, 21 Jul 2014 16:57:03 -0700 Thread-Topic: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis Thread-Index: Ac+kFmUEabbuV/jcQ7OvNK+uD17ktABKN8vA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> In-Reply-To: <8171.1404842394@sandelman.ca> 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.12.52, 1.0.14, 0.0.0000 definitions=2014-07-20_03:2014-07-18,2014-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407210277 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/s1VmtIML9Nyy17AY_fTNEYx8C_A Cc: "hipsec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 21 Jul 2014 23:57:20 -0000 NULL may be useful to some, but should NOT be mandated (should rather than = must). It's another knob that could be set incorrectly and bypass the encryption. = Not all products will want or need NULL. Paul ]-----Original Message----- ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael ]Richardson ]Sent: Tuesday, July 08, 2014 11:00 AM ]To: Stephen Farrell ]Cc: hipsec@ietf.org; saag@ietf.org ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis ] ] ]Stephen Farrell wrote: ] > Generic: is it still considered a good plan to have null ] > confidentiality suites such as these? Or for those to be ] > Mandatory-To-Implement (MTI)? That clearly was the generic ]consensus as ] > we have these in a number of protocols. The new reasons to move ]from ] > that I think are: 1) we no longer need this for debugging purposes ] > really since libraries and dev tools have moved on and are better ]now, ] > and we specifically no longer need these for protocols that are no ] > longer new, 2) BCP188 could be considered to argue against having ]these ] ]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very ]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack. ] ]On such systems, if you have a problem in the field with a protocol that ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how ]it works, and it appears to with without ESP, then the lack of debugging ]means that you turn off all security. ] ]ESP-authenticated-with-NULL-encryption is debuggable in the field. ]Not having it, means turning off ESP; and if the problem is in the link ]between the ESP layer and the upper layer, then... ] ]-- ]Michael Richardson , Sandelman Software Works -=3D ]IPv6 IoT consulting =3D- ] ] From nobody Mon Jul 21 17:51: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 BD1CF1A01E5; Mon, 21 Jul 2014 17:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10mUoacmDUrB; Mon, 21 Jul 2014 17:51:20 -0700 (PDT) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2407A1A0197; Mon, 21 Jul 2014 17:51:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id AE082E7D0; Mon, 21 Jul 2014 20:51:17 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYugvQ7mjF7k; Mon, 21 Jul 2014 20:51:13 -0400 (EDT) Received: from [192.168.3.137] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id E0AFBE72B; Mon, 21 Jul 2014 20:51:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> Date: Mon, 21 Jul 2014 17:51:09 -0700 Message-Id: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YVWl81fjKKDpyWKF7JVXxqd_VqM Cc: Michael Richardson , "hipsec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 00:51:21 -0000 --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The basic issue, as always, is interoperability. NULL should not be an = interoperable *operational* capability. Every implementation will have some kind of debugging capability so it = can be made operational. Do we require an interoperable debugging = capability? I believe the consensus is already leaning to "no". My own take is that we don't normally do that, and the likely debugging = benefit of mandating such a thing is insufficient to justify making it a = MUST. On Jul 21, 2014, at 4:57 PM, Paul Lambert wrote: > NULL may be useful to some, but should NOT be mandated (should rather = than must). > It's another knob that could be set incorrectly and bypass the = encryption. Not all products will want or need NULL. >=20 >=20 > Paul >=20 > ]-----Original Message----- > ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael > ]Richardson > ]Sent: Tuesday, July 08, 2014 11:00 AM > ]To: Stephen Farrell > ]Cc: hipsec@ietf.org; saag@ietf.org > ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis > ] > ] > ]Stephen Farrell wrote: > ] > Generic: is it still considered a good plan to have null > ] > confidentiality suites such as these? Or for those to be > ] > Mandatory-To-Implement (MTI)? That clearly was the generic > ]consensus as > ] > we have these in a number of protocols. The new reasons to move > ]from > ] > that I think are: 1) we no longer need this for debugging = purposes > ] > really since libraries and dev tools have moved on and are = better > ]now, > ] > and we specifically no longer need these for protocols that are = no > ] > longer new, 2) BCP188 could be considered to argue against = having > ]these > ] > ]There are an incredible number of systems (Linux with stock-in-kernel > ]NETKEY IPsec for instance), where it is impossible or very very > ]difficult to get a packet capture of the traffic after decryption, = but > ]before it goes up the protocol stack. > ] > ]On such systems, if you have a problem in the field with a protocol = that > ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out = how > ]it works, and it appears to with without ESP, then the lack of = debugging > ]means that you turn off all security. > ] > ]ESP-authenticated-with-NULL-encryption is debuggable in the field. > ]Not having it, means turning off ESP; and if the problem is in the = link > ]between the ESP layer and the upper layer, then... > ] > ]-- > ]Michael Richardson , Sandelman Software Works = -=3D > ]IPv6 IoT consulting =3D- > ] > ] >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = basic issue, as always, is interoperability. NULL should not be an = interoperable *operational* capability.

Every = implementation will have some kind of debugging capability so it can be = made operational. Do we require an interoperable debugging capability? I = believe the consensus is already leaning to = "no".

My own take is that we don't normally do = that, and the likely debugging benefit of mandating such a thing is = insufficient to justify making it a = MUST.


On Jul 21, 2014, = at 4:57 PM, Paul Lambert <paul@marvell.com> = wrote:

NULL may be useful to some, but should NOT be mandated = (should rather than must).
It's another knob that could be set = incorrectly and bypass the encryption.  Not all products will want = or need NULL.


Paul

]-----Original = Message-----
]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of = Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: = Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: = [Hipsec] [saag] NULL encryption mode in RFC = 5202-bis
]
]
]Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:
]    > Generic: is it still considered a = good plan to have null
]    > confidentiality = suites such as these? Or for those to be
]    > = Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus = as
]    > we have these in a number of protocols. = The new reasons to move
]from
]    > that I = think are: 1) we no longer need this for debugging purposes
] =    > really since libraries and dev tools have moved = on and are better
]now,
]    > and we = specifically no longer need these for protocols that are no
] =    > longer new, 2) BCP188 could be considered to = argue against having
]these
]
]There are an incredible number = of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), = where it is impossible or very very
]difficult to get a packet = capture of the traffic after decryption, but
]before it goes up the = protocol stack.
]
]On such systems, if you have a problem in the = field with a protocol that
]runs over ESP (whether HIP or IKEv2 = keyed), and you can't figure out how
]it works, and it appears to = with without ESP, then the lack of debugging
]means that you turn off = all security.
]
]ESP-authenticated-with-NULL-encryption is = debuggable in the field.
]Not having it, means turning off ESP; and = if the problem is in the link
]between the ESP layer and the upper = layer, then...
]
]--
]Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works  -=3D
]IPv6 IoT consulting = =3D-
]
]

_______________________________________________
s= aag mailing list
saag@ietf.org
https://www.ietf.org/ma= ilman/listinfo/saag

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD-- From nobody Tue Jul 22 07:29: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 C69D01B292A; Tue, 22 Jul 2014 07:29:08 -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, RP_MATCHES_RCVD=-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 qhRrT6eYfy2J; Tue, 22 Jul 2014 07:29:05 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331421B28F4; Tue, 22 Jul 2014 07:29:05 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 00D331B873E; Tue, 22 Jul 2014 07:28:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E55CA190060; Tue, 22 Jul 2014 07:28:45 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.169) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 07:28:45 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Jul 2014 10:28:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> References: <53BB798A.3080101@tomh.org> To: James Cloos X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.169] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/V6LBrG7C43L2ebOgotTu0KazLLc Cc: hipsec@ietf.org, Tom Henderson , saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 14:29:09 -0000 On Jul 8, 2014, at 11:06 AM, James Cloos wrote: > If those doing IP over Amateur Radio are a use case, they require = NULL. If Amateur Radio's prohibition on encryption is considered to be = important in making decisions about crypto in protocols, then I think we = are in a situation where we can't have crypto protocols that don't = disallow downgrade attacks, because implementations always have to be = willing to downgrade to no encryption if the other endpoint is an = Amateur Radio station. So, by reductio ad absurdum, I claim that this isn't something the = working group should consider as a deciding factor. I think the same = observation also applies to Michael's comment about debugging on stacks = with limited trace capability. If you need to disable encryption, you = should have to do something fairly extraordinary to make that happen. From nobody Tue Jul 22 07:50: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 877171B295B; Tue, 22 Jul 2014 07:50:47 -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, RP_MATCHES_RCVD=-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 mZ3m49ZCqXxy; Tue, 22 Jul 2014 07:50:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA701B2958; Tue, 22 Jul 2014 07:50:43 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 92EB81B83AB; Tue, 22 Jul 2014 07:49:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8C663190060; Tue, 22 Jul 2014 07:49:57 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.169) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 07:49:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <53CE78ED.1030602@htt-consult.com> Date: Tue, 22 Jul 2014 10:49:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.169] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jk5-i42TWPvBOEhbdjC41s1VPNA Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 14:50:47 -0000 On Jul 22, 2014, at 10:45 AM, Robert Moskowitz = wrote: > It is a switch to request integrity only. Or to only allow integrity = only. Either party MUST be able to reject an integrity only negotiation. That's not good enough. It should be the case that integrity-only = negotiations are rejected by default, unless there's no protocol = requirement for confidentiality. If there is no need for = confidentiality, then the answer to the DISCUSS should be "there is no = need for confidentiality." From nobody Tue Jul 22 08:26: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 1633A1B2996; Tue, 22 Jul 2014 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 SXWWg4buSY0a; Tue, 22 Jul 2014 08:25:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7290F1B297A; Tue, 22 Jul 2014 08:25:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E49552002D; Tue, 22 Jul 2014 11:27:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7A3A63B0E; Tue, 22 Jul 2014 11:25:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 936CC63B0A; Tue, 22 Jul 2014 11:25:48 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.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/hkJV1ax1l2hVs5EFYkEUJ46TVFY Cc: hipsec@ietf.org, Tom Henderson , saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 15:25:58 -0000 --=-=-= Ted Lemon wrote: >> If those doing IP over Amateur Radio are a use case, they require >> NULL. > If Amateur Radio's prohibition on encryption is considered to be > important in making decisions about crypto in protocols, then I think > we are in a situation where we can't have crypto protocols that don't > disallow downgrade attacks, because implementations always have to be > willing to downgrade to no encryption if the other endpoint is an > Amateur Radio station. Ted, you are assuming that there are no policy knobs at all. We are talking about IPsec ESP, as required by HIP, not UTA/TLS here. I don't understand this fear that policy knobs will accidentally get unstuck and start accepting something weaker without administrator involvement. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU86CeoCLcPvd0N1lAQL97QgAupsbjHqEbSp96K8p/PU8HoqMdy1/sg4o CWtQI2Jn3k0yTqVhF7KQ+yO3GY8jFdD/AHig+VgPINk7U5FMECf1xanuHl22nRe3 6sd2awcMajE7pYPQKyUOJ5NfHWAC/CnOobGFcq6MAax8qW951qbwbx+v1KKg7aPb Ee2lm0yEnwve4me+YsyE087brTsPGwLovIqYbb3BtznmhiWwnxyGq8QdJTazvl8I Dv76nPshpKOYnfqg3/O43wV7lFUSFoeZB+EkQ/zPBx71HtXUV4fYopFgjrQeIQoB 8qo5hODdPB62p/TezARPs1AUAUlAUEqCNMKSq+47SzL+jNxoRbs0CA== =QzKA -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 22 08:26: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 76C4E1B2980; Tue, 22 Jul 2014 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 qlQmhdtxqGIx; Tue, 22 Jul 2014 08:26:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEE41B2994; Tue, 22 Jul 2014 08:26:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BFFB72002D; Tue, 22 Jul 2014 11:28:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8877363B0E; Tue, 22 Jul 2014 11:26:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7863763B0A; Tue, 22 Jul 2014 11:26:48 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.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/Flz4RvzimT3fCYcdUcgxUXuNUf8 Cc: hipsec@ietf.org, Robert Moskowitz , saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 15:26:53 -0000 --=-=-= Ted Lemon wrote: >> It is a switch to request integrity only. Or to only allow integrity >> only. Either party MUST be able to reject an integrity only >> negotiation. > That's not good enough. It should be the case that integrity-only > negotiations are rejected by default, unless there's no protocol > requirement for confidentiality. If there is no need for > confidentiality, then the answer to the DISCUSS should be "there is no > need for confidentiality." All of those knobs, correctly labelled, are all there already. Really. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU86CtYCLcPvd0N1lAQL+gAf/Zp8G6ShHA+ISrVWRGG+k1nlNhSwEdNW8 zv0UtgBvb2VACaOPE6YurI0doR3qcElxafMCg8busY6KSugONzMDLh98asmTZhTM 4dQzmOwFI0Yw5SrKujYPh4J7eKJIafWoQzSQNTRXbGIwhGsxjpNbrlb7EqL4WIuG Hd0AZ0GEVyvuMnCfDtBw4FnwqExv/dqmNl0BLWvScM7YKl4yL+mPJjem7c6bJK3Y HmtPhHSWaP2ZrtPoN+tSApFts3ytbRXYH92jorBIScgIXLkrCMSmcjLobJEasA6l Od/6sgjDMgUTZTXi4mwWIdbpHD8p8SiSXBVqkP6WrdNzzBvwXbdXkg== =YxFv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 22 08:28: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 9D8FB1B29A3; Tue, 22 Jul 2014 08:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RthEHcEJDWuz; Tue, 22 Jul 2014 08:28:54 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F091B29AE; Tue, 22 Jul 2014 08:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=7VA32uHBSK3Lyt7BcuspCQD1H/xziBCBSZRp6txjSqM=; b=IlkE264z6U0FeKOY0T2Wk3JT45QidOkYuQbjCwv4DG2AmU4FSLSc9AMmqRuIyz9eajExFnCcB4ORvZoNcz0/fynTZlfosEseGNG/Vzi9HsGuq7fHwmYn8/VdLy7H0anmak5+Txtmj2MuMPkFCqkjy35CkCnxLiBUjNwJmjG/HUQKbqFbPxV4fYQEyEtkS3axcdVt3Ay5J19P0cNf5+/Fp4GLspg0TeET0c3mK/h4same3j6z5WnsiHFPBmS02Ml4Ry6jWK3PYMBQyg8KodmLHtjSlSxZBQxbYHL24iA7w7VLbeBxmA3W99Rz+zg1fXV7n7QLP5e7DZzlp+6qbsYVRg== From: Edward Lopez To: "saag@ietf.org" Thread-Topic: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis Thread-Index: AQHPpT+FosFAE5Hfxk6vedbZfWESXpuruOeAgAD1fIA= Date: Tue, 22 Jul 2014 15:28:52 +0000 Message-ID: <3DF58EBF-7AFA-4174-9306-2F38427C0047@fortinet.com> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> In-Reply-To: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.165.97] Content-Type: multipart/alternative; boundary="_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/i4tdJYe3dmtlkSw-mjeBprgwoac Cc: Michael Richardson , "hipsec@ietf.org" Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 15:28:56 -0000 --_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In my view, the underlying question is concerned with the value of a comm= on encryption algorithm across all implementations of ESP, NULL or otherw= ise. In my experience, the existence of mandatory common denominators in= standards results in improved interoperability between implementations. = In the particular case of ESP, I agree that virtually no one would imple= ment IPSec using NULL encryption, and we heavily rely on de-facto common = use of US NIST-approved protocols (DES, 3DES, AES) for interoperability t= oday. My point is that by removing the MUST requirement for NULL encryption, sh= ould be consider the idea that we are substituting a stated common encryp= tion protocol for a set of implied ones. We will also be eliminating imp= lementation choices over time for those requiring NULL encryption. I=92m not strongly advocating keeping the MUST, and would likely be ok to= replace it with SHOULD. But I did want to state that this surrendering = of an mandated algorithm, and its consequences relative to maintaining in= teroperability, is a factor that I considered. Ed On Jul 21, 2014, at 8:51 PM, Henry B Hotz > wrote: The basic issue, as always, is interoperability. NULL should not be an in= teroperable *operational* capability. Every implementation will have some kind of debugging capability so it ca= n be made operational. Do we require an interoperable debugging capabilit= y? I believe the consensus is already leaning to "no". My own take is that we don't normally do that, and the likely debugging b= enefit of mandating such a thing is insufficient to justify making it a M= UST. On Jul 21, 2014, at 4:57 PM, Paul Lambert > wrote: NULL may be useful to some, but should NOT be mandated (should rather tha= n must). It's another knob that could be set incorrectly and bypass the encryption= . Not all products will want or need NULL. Paul ]-----Original Message----- ]From: Hipsec [mailto:hipsec-bounces@ietf.org] O= n Behalf Of Michael ]Richardson ]Sent: Tuesday, July 08, 2014 11:00 AM ]To: Stephen Farrell ]Cc: hipsec@ietf.org; saag@ietf.org ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis ] ] ]Stephen Farrell > wrote: ] > Generic: is it still considered a good plan to have null ] > confidentiality suites such as these? Or for those to be ] > Mandatory-To-Implement (MTI)? That clearly was the generic ]consensus as ] > we have these in a number of protocols. The new reasons to move ]from ] > that I think are: 1) we no longer need this for debugging purposes= ] > really since libraries and dev tools have moved on and are better ]now, ] > and we specifically no longer need these for protocols that are no= ] > longer new, 2) BCP188 could be considered to argue against having ]these ] ]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very ]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack. ] ]On such systems, if you have a problem in the field with a protocol that= ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how= ]it works, and it appears to with without ESP, then the lack of debugging= ]means that you turn off all security. ] ]ESP-authenticated-with-NULL-encryption is debuggable in the field. ]Not having it, means turning off ESP; and if the problem is in the link ]between the ESP layer and the upper layer, then... ] ]-- ]Michael Richardson >= , Sandelman Software Works -=3D ]IPv6 IoT consulting =3D- ] ] _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1DF7020E1A0F384BB3E0E2ABF5975AB8@fortinet-us.com> Content-Transfer-Encoding: quoted-printable In my view, the underlying question is concerned with the value of a comm= on encryption algorithm across all implementations of ESP, NULL or otherw= ise.  In my experience, the existence of mandatory common denominato= rs in standards results in improved interoperability between implementations.  In the particular case of ESP, I agree th= at virtually no one would implement IPSec using NULL encryption, and we h= eavily rely on de-facto common use of US NIST-approved protocols (DES, 3D= ES, AES) for interoperability today.

My point is that by removing the MUST requirement for NULL encryptio= n, should be consider the idea that we are substituting a stated common e= ncryption protocol for a set of implied ones.  We will also be elimi= nating implementation choices over time for those requiring NULL encryption.

I=92m not strongly advocating keeping the MUST, and would likely be = ok to replace it with SHOULD.  But I did want to state that this sur= rendering of an mandated algorithm, and its consequences relative to main= taining interoperability, is a factor that I considered.

Ed



On Jul 21, 2014, at 8:51 PM, Henry B Hotz <hbhotz@oxy.edu> wrote:

The basic issue, as always, is interoperability. NULL should not be an in= teroperable *operational* capability.

Every implementation will have some kind of debugging capability so = it can be made operational. Do we require an interoperable debugging capa= bility? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugg= ing benefit of mandating such a thing is insufficient to justify making i= t a MUST.


On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:

NULL may be useful to some, but should NOT be m= andated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption= .  Not all products will want or need NULL.


Paul

]-----Original Message-----
]From: Hipsec [mailto:hipsec-bounces@= ietf.org] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <stephen= .farrell@cs.tcd.ie> wrote:
]    > Generic: is it still considered a good plan to h= ave null
]    > confidentiality suites such as these? Or for tho= se to be
]    > Mandatory-To-Implement (MTI)? That clearly was t= he generic
]consensus as
]    > we have these in a number of protocols. The new = reasons to move
]from
]    > that I think are: 1) we no longer need this for = debugging purposes
]    > really since libraries and dev tools have moved = on and are better
]now,
]    > and we specifically no longer need these for pro= tocols that are no
]    > longer new, 2) BCP188 could be considered to arg= ue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that=
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how=
]it works, and it appears to with without ESP, then the lack of debugging=
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link<= br> ]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <mcr&= #43;IETF@sandelman.ca>, Sandelman Software Works  -=3D
]IPv6 IoT consulting =3D-
]
]

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.o= rg/mailman/listinfo/saag

Personal email.  hbhotz@oxy.e= du



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


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_-- From nobody Tue Jul 22 08:40: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 14D721A031D; Mon, 21 Jul 2014 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut24-wnD_OtR; Mon, 21 Jul 2014 09:34:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE871A00FA; Mon, 21 Jul 2014 09:34:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ45581; Mon, 21 Jul 2014 16:34:34 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 17:34:32 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 09:34:23 -0700 From: Linda Dunbar To: "sacm@ietf.org" , "saag@ietf.org" Thread-Topic: Informal Gathering to discuss NSaaS (a.k.a Bar BoF) Thread-Index: AQHPpQGhcbj+vFVvcEWI5kv4slmd9A== Date: Mon, 21 Jul 2014 16:34:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA0DE9@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.168] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/A333nhVyF4hZbhpQzs95h8J8p_c X-Mailman-Approved-At: Tue, 22 Jul 2014 08:40:30 -0700 Cc: "Zarny, Myo" , "'christian.jacquenet@orange.com'" , 'Shaibal Chakrabarty' Subject: [saag] Informal Gathering to discuss NSaaS (a.k.a Bar BoF) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 21 Jul 2014 16:34:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We will have an informal gathering (a.k.a. Bar BOF) at New Brunswick room T= hurs at 8:30pm to discuss NSaaS. The purpose of this meeting is to collect comments and requirements from se= rvice providers to see there is justification for a full BOF at IETF 91. For this purpose I have invited Vodafone, DT, Cable Lab, Verizon, and Telef= onica to attend this informal gathering. Cheers, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Sunday, July 20, 2014 7:11 PM To: Linda Dunbar; 'David Harrington' Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen Moriar= ty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com' Subject: RE: Summerized differences between SACM and NSaaS Hello all, I can see why some could consider NSaaS as part of "security automation". A= fter all, NSaaS seeks to define how endpoints can request *network* securit= y services over standard protocols (or APIs), which will facilitate automat= ion. >From what I see, the current SACM charter seems mainly concerned with asses= sing endpoint posture, and how (by what protocols) requisite policies could= be pushed down to the endpoints. I see potential synergies but we'll need to iron out a few differences: * Scope: Security vs. network security services * Goal: Automating endpoint posture assessment vs. defining how netw= ork security services are requested * Security policy enforcement location: Endpoint vs network (and end= point-network security services could exist on the endpoint itself.) I'd like to add that the need to standardize how services could be requeste= d from the "cloud" goes beyond network security services. We've intentional= ly narrowed down the scope to network security in order not to chew too muc= h at once. (Indeed, one could argue network security itself already is a br= oad field.) On the other hand, we don't want to be too narrow: each IETF WG= solving essentially the same problem over and over in (slightly) different= ways isn't most productive and will create market confusion. I hope we'll = get the right balance here. Regards, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 18 July 2014 6:15 PM To: David Harrington Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakrabarty Subject: Summerized differences between SACM and NSaaS Thanks to David H explanation and especially many thanks to Gunnar Engelbac= h's extended examples for SACM, I summarized the major differences between = SACM and NSaaS: SACM: Security Assessment of End Points: * End points can be routers, switches, clustered DB, installed piece = of software * SACM is about "How to encode that policy in a manner where assessme= nt can be automated" * Examples: - a Solaris 10 SPARC or Window 7 system used in a environment that req= uires adherence to a policy of Mission Critical Classified. - rules like "The maximum password age must be 30 days" and "The minim= um password age must be 1 day" NSaaS: Network Security as a Function: * Protocols for edge devices (e.g. vCPE) or clients to request/query/= verify Security related functions from Network Providers * Firewall * DDOS/Anti-DOS * Access control/Authorization/Authentication * Remote identity management * Secure Key management * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Threat detection: Eavesdropping, Trojans, viruses and worms, Malwar= e, etc. * Examples: vCPE needs vFW that are hosted in the network. vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, b= ut B can't talk to C. Please let me know if you have comments/suggestions. Thank you, Linda Dunbar From: Linda Dunbar Sent: Wednesday, July 16, 2014 4:48 PM To: 'David Harrington' Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? David, Thank you very much for the reply. What NSaaS intends to do is more along the line of BGP: distribute and nego= tiate relevant policies to security functions, and receives supported polic= ies for verification and coordination. So it is quite different from the Data Modeling language, like SNMP or Netc= onf. We can discuss more at Toronto. SACM chairs have allocated a slot for us at= Toronto meeting. Linda From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, July 16, 2014 11:09 AM To: Linda Dunbar Cc: sacm@ietf.org; Andrew Malis; Romascanu, Dan (Dan)= ; Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or a= pplications) to request/verify virtual Security Function from network provi= ders? Hi Linda, I quickly scanned your draft. It appears to me, as a contributor, that your use cases seem to fit within = the scope of SACM. We are focused on endpoint assessment, but in your use cases, the endpoint = happens to be a virtual endpoint in a virtual network, but an endpoint none= theless. And your use cases discuss assessing the configuration of security function= ality on the virtual endpoint. Your use cases raise some concerns that might be out of scope. Inter-domain correlation would be part of the functionality of the NMS/SMS/= security manager application that is gathering reports of assessments. I think SACM is focused mainly on creating infrastructure for assessing ind= ividual endpoints, so those assessments can be used by applications. The infrastructure for collecting data, storing data, and making the stored= data accessible to applications would seem to be in scope. What the application does with the data would seem to be out of scope. Comparing this to an SNMP ecosystem, the IETF defines a data modeling langu= age, data models, and a protocol for transporting the data. It assumes the = data could be stored for later retrieval. But what an application does with the collected/retrieved MIB data is not w= ithin the scope of the SNMP infrastructure. If the application tries to correlate MIB data across multiple management d= omains, that is not part of the IETF scope. As far as I can see, almost everything in your use cases fits within SACM. David harrington ietfdbh@comcast.net On Jul 8, 2014, at 9:50 AM, Linda Dunbar > wrote: SACM participants: We have a draft on problem and use cases of enabling enterprise (or applic= ations) to request/verify security functions hosted by network providers: h= ttp://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf. We didn't know which IETF area or WG are good fit for the proposed work. Security Area Director Kathleen Moriaty suggests that the proposed work is = somewhat related to SACM. After reading through the SCAM charter, my initial feeling is that SCAM doe= sn't quite fit because SCAM is about the language and data format for "end= point posture assessment". What we proposed is about the mechanism to enab= le Network Security as a Service (NSaaS). I can see the mechanisms provided= by SCAM can be used for some attributes negotiation of NSaaS. But I could be wrong. We are seeking feedback from SACM group, in particular: - If what we propose fits with SACM? - Can the mechanism defined by SACM be used for NSaaS? - Any other thoughts? if it turns out that it is in the SCAM group scope, it is great. If it does= n't, we will see what else can be done. Linda Dunbar _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We will have an informal gathering (a.k.a. Bar BOF) = at New Brunswick room Thurs at 8:30pm to discuss NSaaS.

 

The purpose of this meeting is to collect comments a= nd requirements from service providers to see there is justification for a = full BOF at IETF 91.

For this purpose I have invited Vodafone, DT, Cable = Lab, Verizon, and Telefonica to attend this informal gathering.

 

Cheers,

 

Linda

 

 <= /p>

 <= /p>

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Sunday, July 20, 2014 7:11 PM
To: Linda Dunbar; 'David Harrington'
Cc: 'sacm@ietf.org'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen= Moriarty'; 'Shaibal Chakrabarty'; 'christian.jacquenet@orange.com'
Subject: RE: Summerized differences between SACM and NSaaS

 

Hello all,

 <= /p>

I can see why some could = consider NSaaS as part of “security automation”. After all, NSa= aS seeks to define how endpoints can request *network* security services over standard protocols (or APIs), which will facilitate automati= on.

 <= /p>

From what I see, the curr= ent SACM charter seems mainly concerned with assessing endpoint posture, an= d how (by what protocols) requisite policies could be pushed down to the endpoints.

 <= /p>

I see potential synergies= but we’ll need to iron out a few differences:

·      = ; Scope:  Secu= rity vs. network security services

·      = ; Goal:  Autom= ating endpoint posture assessment vs. defining how network security service= s are requested

·      = ; Security policy e= nforcement location:  Endpoint vs network (and endpoint—network = security services could exist on the endpoint itself.)

 <= /p>

I’d like to add tha= t the need to standardize how services could be requested from the “c= loud” goes beyond network security services. We’ve intentionall= y narrowed down the scope to network security in order not to chew too much at once. = (Indeed, one could argue network security itself already is a broad field.)= On the other hand, we don’t want to be too narrow: each IETF WG solv= ing essentially the same problem over and over in (slightly) different ways isn’t most productive and will= create market confusion. I hope we’ll get the right balance here.

 <= /p>

Regards,

 <= /p>

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 18 July 2014 6:15 PM
To: David Harrington
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakr= abarty
Subject: Summerized differences between SACM and NSaaS

 

• &nbs= p;     End points can be= routers, switches, clustered DB, installed piece of software

• &nbs= p;     SACM is about = 220;How to encode that policy in a manner where assessment can be automated= ”

• &nbs= p;     Examples:

– &nbs= p;    a Solaris 10 SPAR= C or Window 7 system used in a environment that requires adherence to a pol= icy of Mission Critical Classified.

– &nbs= p;    rules like "= The maximum password age must be 30 days" and "The minimum passwo= rd age must be 1 day"

• &nbs= p;     Protocols for edg= e devices (e.g. vCPE) or clients to request/query/verify Security related f= unctions from Network Providers

• &nbs= p;     Firewall

• &nbs= p;     DDOS/Anti-DOS

• &nbs= p;     Access control/Au= thorization/Authentication

• &nbs= p;     Remote identity m= anagement

• &nbs= p;     Secure Key manage= ment

• &nbs= p;     Intrusion Detecti= on System/ Intrusion Prevention System (IDS/IPS)

• &nbs= p;     Threat detection:= Eavesdropping, Trojans, viruses and worms, Malware, etc.

• &nbs= p;     Examples:

vCPE needs vFW that are hosted in the network.

vCPE provides the “Group Policies” for the vFW, like A can t= alk to B & C, but B can’t talk to C.

From: Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: RE: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

From: David Harrington [mailto:ietfdbh@comcast.net]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: sacm@ietf.org; Andrew Malis= ; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty<= br> Subject: Re: [sacm] Any feedback on mechanisms of enabling enterpris= e (or applications) to request/verify virtual Security Function from networ= k providers?

 

Hi Linda,

 

I quickly scanned your dr= aft.

It appears to me, as a co= ntributor, that your use cases seem to fit within the scope of SACM.

We are focused on endpoin= t assessment, but in your use cases, the endpoint happens to be a virtual e= ndpoint in a virtual network, but an endpoint nonetheless.

And your use cases discus= s assessing the configuration of security functionality on the virtual endp= oint.

 

Your use cases raise some= concerns that might be out of scope.

Inter-domain correlation = would be part of the functionality of the NMS/SMS/security manager applicat= ion that is gathering reports of assessments.

I think SACM is focused m= ainly on creating infrastructure for assessing individual endpoints, so tho= se assessments can be used by applications.

The infrastructure for co= llecting data, storing data, and making the stored data accessible to appli= cations would seem to be in scope.

What the application does= with the data would seem to be out of scope.

 

Comparing this to an SNMP= ecosystem, the IETF defines a data modeling language, data models, and a p= rotocol for transporting the data. It assumes the data could be stored for = later retrieval.

But what an application d= oes with the collected/retrieved MIB data is not within the scope of the SN= MP infrastructure.

If the application tries = to correlate MIB data across multiple management domains, that is not part = of the IETF scope.

As far as I can see, almo= st everything in your use cases fits within SACM.

 

David harrington

 

On Jul 8, 2014, at 9:50 A= M, Linda Dunbar <linda.dunbar= @huawei.com> wrote:

 

SACM partici= pants:

 <= /o:p>

endpoint posture assessment”. =  What we proposed is about the mechanism= to enable Network Security as a Service (NSaaS). I can see the mechanisms provided by SCAM can be used for some attributes negotiation of NSaaS.

-=           If what we propose fits with SACM?

-=           Can the mechanism defined by SACM be used for NSaaS?<= /o:p>

-=           Any other thoughts?

 <= /o:p>

___________= ____________________________________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645DA0DE9dfweml701chmchi_-- From nobody Tue Jul 22 08:40: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 D03751B291A; Tue, 22 Jul 2014 07:29:11 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 52hUvBdYxGpu; Tue, 22 Jul 2014 07:29:09 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB11B2929; Tue, 22 Jul 2014 07:29:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E739262A80; Tue, 22 Jul 2014 14:29:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIq7LS6wKR1D; Tue, 22 Jul 2014 10:28:56 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 36FD462A5A; Tue, 22 Jul 2014 10:28:56 -0400 (EDT) Message-ID: <53CE7526.3020702@htt-consult.com> Date: Tue, 22 Jul 2014 10:28:54 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Henry B Hotz , Paul Lambert References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> In-Reply-To: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> Content-Type: multipart/alternative; boundary="------------080207070708030309000503" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VcvT13n4nmyuYlMPySmSJes1nIc X-Mailman-Approved-At: Tue, 22 Jul 2014 08:40:30 -0700 Cc: Michael Richardson , "saag@ietf.org" , "hipsec@ietf.org" Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 14:29:12 -0000 This is a multi-part message in MIME format. --------------080207070708030309000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/21/2014 08:51 PM, Henry B Hotz wrote: > The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability. In this regard, I have a hard time distinguishing between NULL with HMAC-SHA256 and CMAC or GMAC. With this (secure communications) context NULL means no privacy but yes authenticity. > > Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no". > > My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST. > > > On Jul 21, 2014, at 4:57 PM, Paul Lambert wrote: > >> NULL may be useful to some, but should NOT be mandated (should rather than must). >> It's another knob that could be set incorrectly and bypass the encryption. Not all products will want or need NULL. >> >> >> Paul >> >> ]-----Original Message----- >> ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael >> ]Richardson >> ]Sent: Tuesday, July 08, 2014 11:00 AM >> ]To: Stephen Farrell >> ]Cc: hipsec@ietf.org; saag@ietf.org >> ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis >> ] >> ] >> ]Stephen Farrell wrote: >> ] > Generic: is it still considered a good plan to have null >> ] > confidentiality suites such as these? Or for those to be >> ] > Mandatory-To-Implement (MTI)? That clearly was the generic >> ]consensus as >> ] > we have these in a number of protocols. The new reasons to move >> ]from >> ] > that I think are: 1) we no longer need this for debugging purposes >> ] > really since libraries and dev tools have moved on and are better >> ]now, >> ] > and we specifically no longer need these for protocols that are no >> ] > longer new, 2) BCP188 could be considered to argue against having >> ]these >> ] >> ]There are an incredible number of systems (Linux with stock-in-kernel >> ]NETKEY IPsec for instance), where it is impossible or very very >> ]difficult to get a packet capture of the traffic after decryption, but >> ]before it goes up the protocol stack. >> ] >> ]On such systems, if you have a problem in the field with a protocol that >> ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how >> ]it works, and it appears to with without ESP, then the lack of debugging >> ]means that you turn off all security. >> ] >> ]ESP-authenticated-with-NULL-encryption is debuggable in the field. >> ]Not having it, means turning off ESP; and if the problem is in the link >> ]between the ESP layer and the upper layer, then... >> ] >> ]-- >> ]Michael Richardson , Sandelman Software Works -= >> ]IPv6 IoT consulting =- >> ] >> ] >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > Personal email. hbhotz@oxy.edu > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------080207070708030309000503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/21/2014 08:51 PM, Henry B Hotz wrote:
The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

In this regard, I have a hard time distinguishing between NULL with HMAC-SHA256 and CMAC or GMAC.

With this (secure communications) context NULL means no privacy but yes authenticity.


Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.


On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:


NULL may be useful to some, but should NOT be mandated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.


Paul

]-----Original Message-----
]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
]    > Generic: is it still considered a good plan to have null
]    > confidentiality suites such as these? Or for those to be
]    > Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus as
]    > we have these in a number of protocols. The new reasons to move
]from
]    > that I think are: 1) we no longer need this for debugging purposes
]    > really since libraries and dev tools have moved on and are better
]now,
]    > and we specifically no longer need these for protocols that are no
]    > longer new, 2) BCP188 could be considered to argue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but
]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
]it works, and it appears to with without ESP, then the lack of debugging
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link
]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

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

Personal email.  hbhotz@oxy.edu







_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------080207070708030309000503-- From nobody Tue Jul 22 08:40: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 D49C11B2886; Tue, 22 Jul 2014 07:45:20 -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, RP_MATCHES_RCVD=-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 JpNoynHeKD0q; Tue, 22 Jul 2014 07:45:17 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 841321A02D0; Tue, 22 Jul 2014 07:45:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5538D62AB3; Tue, 22 Jul 2014 14:45:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VouAOnm--U9; Tue, 22 Jul 2014 10:45:04 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7194662C31; Tue, 22 Jul 2014 10:45:03 -0400 (EDT) Message-ID: <53CE78ED.1030602@htt-consult.com> Date: Tue, 22 Jul 2014 10:45:01 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon , James Cloos References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Vr2giFKJ4gLVq9WSJWr-op4ndds X-Mailman-Approved-At: Tue, 22 Jul 2014 08:40:30 -0700 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 14:45:21 -0000 On 07/22/2014 10:28 AM, Ted Lemon wrote: > On Jul 8, 2014, at 11:06 AM, James Cloos wrote: >> If those doing IP over Amateur Radio are a use case, they require NULL. > If Amateur Radio's prohibition on encryption is considered to be important in making decisions about crypto in protocols, then I think we are in a situation where we can't have crypto protocols that don't disallow downgrade attacks, because implementations always have to be willing to downgrade to no encryption if the other endpoint is an Amateur Radio station. > > So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor. I think the same observation also applies to Michael's comment about debugging on stacks with limited trace capability. If you need to disable encryption, you should have to do something fairly extraordinary to make that happen. It is a switch to request integrity only. Or to only allow integrity only. Either party MUST be able to reject an integrity only negotiation. From nobody Tue Jul 22 08:43: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 254901B2819 for ; Tue, 22 Jul 2014 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-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 qwI5ThEwyBoO for ; Tue, 22 Jul 2014 08:43:31 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 45F021A0056 for ; Tue, 22 Jul 2014 08:43:31 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA29251; Tue, 22 Jul 2014 11:43:28 -0400 (EDT) Date: Tue, 22 Jul 2014 11:43:28 -0400 (EDT) From: Mouse Message-Id: <201407221543.LAA29251@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: Tue, 22 Jul 2014 11:30:09 -0400 (EDT) To: saag@ietf.org In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Yh8oAf0z5hVWk0zrPw31eDP2rwc Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 15:43:33 -0000 >> If those doing IP over Amateur Radio are a use case, they require NULL. > If Amateur Radio's prohibition on encryption is considered to be important i$ Well, can't have protocols that don't permit downgrade when configured for ham use, at least. I don't see any reason the protocol can't be configured for ham use (essentially, null encryption is the only choice) or for general-purpose Internet use (null encryption is not a choice). Mind you, as an implementor I'd ensure null encryption is available even in the latter form if suitable configuration switches are flipped, but that's a separate issue. This doesn't address the use case of one endpoint being a ham and the other not. I'm not sure what I think about that; I can think of at least three approaches, each of which would probably be preferable in some cases. > So, by reductio ad absurdum, I claim that this isn't something the working g$ Well, it does mean that protocols should at least be designed with allowance for null encryption, even if it's not part of the spec. After all, the IETF can standardize anything it wants, but if the result doesn't support what people want to do, people will simply ignore the spec. (I did that with SSH, for example; as specified, it's unimplementable on the systems I care about, so I just ignored the problematic parts of the spec.) /~\ 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 Tue Jul 22 10:34: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 CFBEE1B29AD; Tue, 22 Jul 2014 10:34:42 -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, RP_MATCHES_RCVD=-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 9IExcdB2Oyxf; Tue, 22 Jul 2014 10:34:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id B60441A0330; Tue, 22 Jul 2014 10:34:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 47F3062A8E; Tue, 22 Jul 2014 17:34:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcGHMW+zotAV; Tue, 22 Jul 2014 13:34:30 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-97b3.meeting.ietf.org [31.133.151.179]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 758DF62A71; Tue, 22 Jul 2014 13:34:29 -0400 (EDT) Message-ID: <53CEA0A4.7070605@htt-consult.com> Date: Tue, 22 Jul 2014 13:34:28 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , Ted Lemon References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.com> <3737.1406042808@sandelman.ca> In-Reply-To: <3737.1406042808@sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YR3SvNkuUqBHtIZhj4PBTq5NpFo Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 17:34:43 -0000 On 07/22/2014 11:26 AM, Michael Richardson wrote: > Ted Lemon wrote: > >> It is a switch to request integrity only. Or to only allow integrity > >> only. Either party MUST be able to reject an integrity only > >> negotiation. > > > That's not good enough. It should be the case that integrity-only > > negotiations are rejected by default, unless there's no protocol > > requirement for confidentiality. If there is no need for > > confidentiality, then the answer to the DISCUSS should be "there is no > > need for confidentiality." > > All of those knobs, correctly labelled, are all there already. Really. The code has the knobs, but Ted's question is does the spec have the knobs. Something like "default transform lists MUST NOT provide any of the integrity only suites. These MAY be offered only by explicit configuration." This discussion is about NULL which is quite a misnomer... But back in the days......... If you look at the HIP exchange, R1 contains the offered list, and I2 either contains the requested suite, or a counter list. Both are signed (in HIP-BEX) and thus can only be spoofed for anonymous HITs. From nobody Tue Jul 22 10:49: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 C9FAF1B2B12; Tue, 22 Jul 2014 10:49:36 -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, RP_MATCHES_RCVD=-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 52-jSX3RlbKX; Tue, 22 Jul 2014 10:49:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31E11A00F2; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C584CF8009; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BF31E190060; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.218) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 10:49:35 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <3510.1406042748@sandelman.ca> Date: Tue, 22 Jul 2014 13:49:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <56474639-2BF9-41C0-AC86-CEBB81316D64@nominum.com> References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <3510.1406042748@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.218] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yQgkkpeVZYRFrxZ6Gf5ytoN3JNo Cc: hipsec@ietf.org, Tom Henderson , saag@ietf.org Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 22 Jul 2014 17:49:37 -0000 On Jul 22, 2014, at 11:25 AM, Michael Richardson = wrote: > Ted, you are assuming that there are no policy knobs at all. No, I am assuming that there _are_ policy knobs, and saying what I think = their default values should be. But to be clear, I would expect surfing the web legally over a ham radio = link to be pretty unsatisfying, because you would get no encrypted = content, and lots of content is encrypted. I am saying that this = should not change. From nobody Wed Jul 23 06:54: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 13A6C1B29AD for ; Wed, 23 Jul 2014 06:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFclYO7lG_rP for ; Wed, 23 Jul 2014 06:54:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AC11B29A8 for ; Wed, 23 Jul 2014 06:54:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47584 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X9wzn-000Imj-6o for saag@ietf.org; Wed, 23 Jul 2014 09:54:15 -0400 Message-ID: <53CFBE86.5010004@bbn.com> Date: Wed, 23 Jul 2014 09:54:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IlD7kE0Yg4mga_uRtgRsYnqYw1c Subject: Re: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 23 Jul 2014 13:54:21 -0000 Ted, Mandatory support for NULL encryption in a protocol need not result in a downgrade attack vulnerability. If peers have the ability to locally configure the set of algs that they will accept, in general or on a per-peer basis, then this problem can be avoided. I believe that, in this context, this is already the case. Steve From nobody Wed Jul 23 10:26: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 A306E1A02F1 for ; Wed, 23 Jul 2014 10:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, 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 uFcg6FQLpwrE for ; Wed, 23 Jul 2014 10:26:14 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9044D1A01C6 for ; Wed, 23 Jul 2014 10:26:14 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so1606817qaj.7 for ; Wed, 23 Jul 2014 10:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=from:content-type:subject:message-id:date:to:mime-version; bh=7VSZOqHr8XAjwgq+6wPXWbkhuSmTZq8oym6YDYVujmw=; b=Ov4lTmq/awVAaZlm08CCFff9oxJqKr4VHzqGVlmBNju+g93kY3i1TdUdTGiQaWyV+c hQMJG3M/k5SbWz8g8KBbwoeAPSrpa3B2SvwTaf0PMjzyckYLWIkFSKh+qpqOn80E5EN5 zPxkRi9/SeqmaFKXFrKQNYUZzS1GmPnAgwcaJsi+h2Qmbl7Wi0O1LS2EfxbXD8xW3Xja iA6ubCz1IUH1E00bar/MQ6TX6PnymlDrxGfsY+TTvmUcNmdwTesNIoQYaeplDLRWcLVI uh3FLyX8juwcAYokRGL0UDi2mBEUuM6LFNAq8jrYNWjcD+Cz5Cf6SxenXg8csmMgsF7p WMpg== X-Received: by 10.140.96.85 with SMTP id j79mr4262662qge.5.1406136373747; Wed, 23 Jul 2014 10:26:13 -0700 (PDT) Received: from [172.16.53.32] ([206.47.221.210]) by mx.google.com with ESMTPSA id z9sm4057030qge.4.2014.07.23.10.26.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:26:12 -0700 (PDT) From: Adam W. Montville Content-Type: multipart/signed; boundary="Apple-Mail=_98248689-75B1-4F8E-9D0F-FB90D5B74213"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <93C99488-5ACC-4223-B144-E4BFBFFAB573@gmail.com> Date: Wed, 23 Jul 2014 13:26:09 -0400 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NaIylyHvcuC1LRnwU_l9mRD5Otc 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: Wed, 23 Jul 2014 17:26:15 -0000 --Apple-Mail=_98248689-75B1-4F8E-9D0F-FB90D5B74213 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 SACM met at IETF 90 at 9am and will meet again on Friday morning, also = at 9am. There were 38 attendees in the room and perhaps another 10 on Jabber = (excluding those in the room). We discussed the SACM architecture, two information model proposals, and = a transport proposal during Tuesday=92s session. Several working sessions are planned during the week between Tuesday and = Friday to make specific progress on the SACM architecture, to walk = through at least one specific usage scenario, and to begin reconciling = the two information model submissions. Work from these three sessions = (one Tuesday afternoon, one Wednesday evening, and the third on Thursday = morning) will be reviewed during Friday=92s session with appropriate = actions collected. We expect the WG will continue with interim meetings and informal = working discussions, both of which have proved to be helpful in keeping = the positive momentum of the WG. --Apple-Mail=_98248689-75B1-4F8E-9D0F-FB90D5B74213 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 iQEcBAEBCgAGBQJTz/AxAAoJEILmIVe/2cgGIUUIAL6F8cxNs77lir87DHwpy/Ua QAGbfLzi0s+g9FUtx8TYIjDpfkFS7OJSgxLjXz1/DIBsHvamcrckN/cBkAaVXRVy D7YLrJmXlFi7wm8X2PX10qjhPj5ni/OoQ+kkUMvXAn3FNjWmoFaL/m2aCwnYJ1x5 21BTiHiEN7Kb8O6gRZSfnaU50LkHv1n3Mku+BInChoGXlOZ4a6JGaXG3p54K4AP7 T3WVlJsrr8Z+NuZ6jNZip1S212brNMRC7iCvbn+8naxN9/itfX0xQhKkOpNZOp3o XILP2VTb9hYGjVHT8PYIFc1PtlPZ3o/zIqYYe/775aGdLi5hVvGmYVF0kOeMSus= =jNCG -----END PGP SIGNATURE----- --Apple-Mail=_98248689-75B1-4F8E-9D0F-FB90D5B74213-- From nobody Wed Jul 23 12:05: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 C1D981A0336 for ; Wed, 23 Jul 2014 12:05:19 -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 uAl2fnZcxGp8 for ; Wed, 23 Jul 2014 12:05:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674A91B27E0 for ; Wed, 23 Jul 2014 12:05:15 -0700 (PDT) Received: from dhcp-93c5.meeting.ietf.org (31.133.147.197) by BY2PR06MB583.namprd06.prod.outlook.com (10.141.221.149) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 23 Jul 2014 19:05:11 +0000 Message-ID: <53D0075C.6000907@isoc.org> Date: Wed, 23 Jul 2014 15:05:00 -0400 From: Karen ODonoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.133.147.197] X-ClientProxiedBy: DB4PR06CA0040.eurprd06.prod.outlook.com (25.160.40.168) To BY2PR06MB583.namprd06.prod.outlook.com (10.141.221.149) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028166BF91 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(199002)(189002)(81542001)(81342001)(50466002)(107046002)(33656002)(64126003)(107886001)(95666004)(83506001)(86362001)(66066001)(47776003)(80022001)(85306003)(102836001)(64706001)(20776003)(106356001)(229853001)(42186005)(105586002)(31966008)(76482001)(85852003)(101416001)(23756003)(2351001)(50986999)(87976001)(15975445006)(74502001)(92566001)(99396002)(77982001)(83072002)(59896001)(21056001)(19580395003)(54356999)(36756003)(92726001)(46102001)(83322001)(87266999)(65956001)(65806001)(77096002)(4396001)(110136001)(79102001)(65816999)(80316001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR06MB583; H:dhcp-93c5.meeting.ietf.org; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SDj3UnM5VCJldxGjPKh-ToV4FGQ Subject: [saag] JOSE WG @IETF90 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, 23 Jul 2014 19:05:19 -0000 The JOSE wg met on Monday 21 July 2014 from 1300-1400. The four core documents (JWA, JWE, JWK, and JWS) have finished AD reviews and been updated based on these reviews. There are two remaining issues that will be held open through the IETF Last Call period. These issues are: --- update and progression of draft-mcgrew-aead-aes-cbc-hmac-sha2 (https://tools.ietf.org/wg/jose/trac/ticket/147); --- text around the uniqueness of identifiers. The draft-ietf-jose-cookbook document was briefly discussed and updated, and a WGLC has been started for that document. Two additional topics were briefly discussed --- JSON Web Key Thumbprint --- JOSE vs. Constrained Node Networks From nobody Wed Jul 23 15:03: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 006741B284F for ; Wed, 23 Jul 2014 15:03:28 -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 S2iO8hsfaOvX for ; Wed, 23 Jul 2014 15:03:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FA21A038E for ; Wed, 23 Jul 2014 15:03:27 -0700 (PDT) Received: from dhcp-89a3.meeting.ietf.org (dhcp-89a3.meeting.ietf.org [31.133.137.163]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6NM3PRB069606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Jul 2014 15:03:26 -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: <6CDB76A4-A5FD-46D5-AE41-9AB10EC0E339@vpnc.org> Date: Wed, 23 Jul 2014 18:03:24 -0400 To: saag Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GW6jEcW_9ubPsSJyxv7j4arLo9k Subject: [saag] IPsecME meeting summary for IETF 90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 23 Jul 2014 22:03:28 -0000 Greetings. IPsecME will meet on Friday, so this is a pre-summary. We = will have presentations on three documents that are not WG items but = relate to IPsec: null authentication in IKEv2, a MOBIKE extension, and = using client puzzles to prevent DoS on IKE. --Paul Hoffman= From nobody Wed Jul 23 20:12: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 235991A8BB7 for ; Wed, 23 Jul 2014 20:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 O_ePOKpVF0tQ for ; Wed, 23 Jul 2014 20:12:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061411A0B07 for ; Wed, 23 Jul 2014 20:12:45 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6O3ChNQ029899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 03:12:44 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 s6O3CgxX000629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 03:12:42 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6O3CgGm011147; Thu, 24 Jul 2014 03:12:42 GMT Received: from dhcp-8b19.meeting.ietf.org (/10.159.72.72) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jul 2014 20:12:42 -0700 Message-ID: <53D079B3.1050809@oracle.com> Date: Wed, 23 Jul 2014 21:12:51 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <531736E4.6060906@oracle.com> In-Reply-To: <531736E4.6060906@oracle.com> X-Forwarded-Message-Id: <531736E4.6060906@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/OoGpkNygVUh5VOK9hJ6lRLWownE Subject: [saag] kitten Summary - IETF 90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 03:12:47 -0000 Co-chairs: Sam Hartman, Shawn Emery, and Josh Howlett Outgoing co-chairs: Sam Hartman and Josh Howlett (thank you) Incoming co-chairs: Ben Kaduk and Matt Miller (welcome aboard) The WG met for the Wednesday morning session. I've included the high-lighted topics on the agenda that were discussed: AES-SHA2 WGLC has expired. WGLC comments were not blocking. A suggestion was to use an AEAD based algorithm such as SIV, where the cyphertext is the same length as the plaintext. Consensus on the list was that this should be handled in a separate draft(s) if so desired. KDF values and PRF output will also be verified by the implementations. CAMMAC WGLC has expired, but with only one comment/review. Chairs have requested more review. RFC Updates bis drafts have been created to fix: 6112: KeyExchange -> KEYEXCHANGE Anonymous KDC option MUST, not SHOULD, be set when using an anonymous ticket 4402: PRF starts counter at 1, however implementations start at 0 5653: GSSException class does not provide an error token Open mic There were no dissenting comments. Shawn. -- kitten co-chair From nobody Wed Jul 23 20:15: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 01F871B27A9 for ; Wed, 23 Jul 2014 20:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-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 kZijVauViQx2 for ; Wed, 23 Jul 2014 20:15:49 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857071B27A8 for ; Wed, 23 Jul 2014 20:15:49 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id s6O3FmOR006526; Thu, 24 Jul 2014 12:15:48 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id s6O3FkxJ002686; Thu, 24 Jul 2014 12:15:47 +0900 (JST) From: "Takeshi Takahashi" To: Date: Thu, 24 Jul 2014 12:15:49 +0900 Message-ID: <003601cfa6ed$927d0300$b7770900$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+m6LD6txvRahlFSqqaXa+sxng+sA== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/saag/i--6IdRMPXyV3QI5scUmWd7xN2o Cc: mile-chairs@tools.ietf.org Subject: [saag] MILE 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, 24 Jul 2014 03:15:51 -0000 MILE met at IETF 90 at 15:20 on Wednesday. There were about 30 attendees in the room and Jabber. We discussed the three working group drafts and three non-working group drafts. [working group drafts] o IODEF-bis draft: the progress were shared for each of the issued tickets. The progress is on schedule. o Enum draft: the recent changes were shared by the author. AD review comments and AppsDir review comments were addressed. It will be requested for the IESG Last Call soon. o Implementation report draft: the author reported that this draft combined Kathleen's and Daisuke's drafts into one. [non-working group drafts] o CPS draft: the author proposed to define an extension for cyber-physical system incidents. There was interest in this work, but the document is not yet ready for WG adoption. The specific use cases are requested from the audience. o Darknet draft: the authors shared the schema of incident reports they have been using on the darknet monitoring system. The authors could develop the schema so that it can extend IODEF. o DAME draft: the author has presented the identity federation scheme based on SAML and shared its usability by sharing MILE-related use cases. Though the scope is not exactly in the exact focus of the current charter of MILE, it is closely related to MILE. Further information updates in the future will be appreciated. From nobody Thu Jul 24 04:38: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 E5D031A0203; Thu, 24 Jul 2014 04:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nVkNPQGg7S; Thu, 24 Jul 2014 04:38:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9D61A01EB; Thu, 24 Jul 2014 04:38:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKM20527; Thu, 24 Jul 2014 11:38:25 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 12:38:24 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 19:38:22 +0800 From: Likepeng To: "saag@ietf.org" Thread-Topic: ACE meeting summary for IETF 90 Thread-Index: Ac+nM8uD7XHLfW3CRdS/fcLw1y3Lvg== Date: Thu, 24 Jul 2014 11:38:21 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25817AFEA@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.85.71] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817AFEASZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nRM8CV6OMnEvLaPkXtJ6MMoU_RM Cc: "ace@ietf.org" Subject: [saag] ACE meeting summary for IETF 90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 11:38:30 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817AFEASZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ACE (Authentication and Authorization for Constrained Environments) Chairs: Kepeng Li, Hannes Tschofenig Time: Wednesday morning, 9:00 ~ 11:30 Physical attendees: ~70 1. ACE Introduction (Chairs, 10 mins): This was the first WG F2F meeting. Kepeng introduced briefly about ACE work= . Hannes gave some brief summaries about Stockholm informal meeting. 2. Design Directions 2.1: Problem Description (Ludwig Seitz, 30 mins) Most of the discussions were about different models: Pull model, Push model= , Agent model, Push & Confirm model. Different models can apply to different use cases. We need to analyze the use cases to see which model(s) to choose. 2.2: Use Cases & Design Patterns (Ludwig Seitz, 30 mins) There was discussion that there may be multiple authorization servers, and = we need to consider the case to change authorization servers. There was discussion that client joining network process should be out of s= cope. Hannes mentioned we have already called for adoption for use case draft. Th= ree volunteers were identified to review the draft and provide feedback in = the mailing list. 2.3: Design Considerations (Corinna Schmitt, 30 mins) It was discussed that we should not be scared about asymmetric key, and als= o we don't force on asymmetric key. It was also discussed that we should not narrow down to either one of the t= wo mechanisms (symmetric key vs. asymmetric key), different environments re= quire different mechanisms. We need to get more data to make decision about symmetric key and/or asymme= tric key. 2.4: Cross-domain Support (Carsten Bormann, 30 mins) It was discussed that we should consider legacy devices, and consider proxy= support. 3. Summary and Next Steps (Chairs, 10 mins) Hannes mentioned about possible interim meeting(s): conference calls or F2F= meeting. Hannes also mentioned that it will be good to use implementation experience= to collect data to help our designs. Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817AFEASZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ACE (Authentication and Auth= orization for Constrained Environments)

Chairs: Kepeng Li, Hannes Ts= chofenig

Time: Wednesday morning, 9:0= 0 ~ 11:30

Physical attendees: ~70=

 

1. ACE Introduction (Chairs,= 10 mins):

 

This was the first WG F2F me= eting. Kepeng introduced briefly about ACE work. Hannes gave some brief sum= maries about Stockholm informal meeting.

 

2. Design Directions

2.1: Problem Description (Lu= dwig Seitz, 30 mins)

 

Most of the discussions were= about different models: Pull model, Push model, Agent model, Push & Co= nfirm model.

 

Different models can apply t= o different use cases.

 

We need to analyze the use c= ases to see which model(s) to choose.

 

2.2: Use Cases & Design = Patterns (Ludwig Seitz, 30 mins)

 

There was discussion that th= ere may be multiple authorization servers, and we need to consider the case= to change authorization servers.

 

There was discussion that cl= ient joining network process should be out of scope.

 

Hannes mentioned we have alr= eady called for adoption for use case draft. Three volunteers were identifi= ed to review the draft and provide feedback in the mailing list.=

 

2.3: Design Considerations (= Corinna Schmitt, 30 mins)

 

It was discussed that we sho= uld not be scared about asymmetric key, and also we don't force on asymmetr= ic key.

 

It was also discussed that w= e should not narrow down to either one of the two mechanisms (symmetric key= vs. asymmetric key), different environments require different mechanisms.<= o:p>

 

We need to get more data to = make decision about symmetric key and/or asymmetric key.<= /p>

 

2.4: Cross-domain Support (C= arsten Bormann, 30 mins)

 

It was discussed that we sho= uld consider legacy devices, and consider proxy support.<= /p>

 

3. Summary and Next Steps (C= hairs, 10 mins)

 

Hannes mentioned about possi= ble interim meeting(s): conference calls or F2F meeting.<= /p>

 

Hannes also mentioned that i= t will be good to use implementation experience to collect data to help our= designs.

 

Kind Regards<= /p>

Kepeng

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F25817AFEASZXEMA501MBSchi_-- From nobody Thu Jul 24 04:58: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 037E71A0202 for ; Thu, 24 Jul 2014 04:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUEPWwxUE3Tb for ; Thu, 24 Jul 2014 04:58:25 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB22E1A0203 for ; Thu, 24 Jul 2014 04:58:25 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so2183876ier.27 for ; Thu, 24 Jul 2014 04:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=0JNie7ngkmJvz2CT9reHcxiQtX+zmya4Yrx3bkWN1g8=; b=ySzxenf+YHfNUu/sMrW0iFljlmztQSvN+r4BLAeYzh9GXoRrA9TgSJhdjU9Hs9YauI Imrg/3ZW+RKdBeEqXpX7L1JTk2O3qhy0tKMn5nKRzOWiWgyjCGJVP++aM/xTaqqltQA4 vu7xDtElYrKmCLFlqf/9EbahB3SNwHVD/SYCwFmBgnPkjmMiYV3YhYCKkEE32xLhnXFi cNGBIwpfrmABCEb/oTENEq5az9t1r2erzHpj7HZN4KK54ut9OW2ulXEqBtlYXElFuQIg vgquRmoWrknHcboh4aPbRcrHl76MD9hRfiSOhq4V/pplgGx++j9gRs0RMYm+f7+BAVIr KrgA== X-Received: by 10.42.90.74 with SMTP id j10mr11646428icm.29.1406203104952; Thu, 24 Jul 2014 04:58:24 -0700 (PDT) Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id t2sm69541552igs.3.2014.07.24.04.58.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 04:58:24 -0700 (PDT) Message-ID: <53D0F4DF.3010502@gmail.com> Date: Thu, 24 Jul 2014 07:58:23 -0400 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.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/xlZJSV8eDvGhcH3gJOj5QHWKeSE Subject: [saag] 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: Thu, 24 Jul 2014 11:58:27 -0000 trans will be meeting on Friday (9am, Manitoba room). We're crunching along on 6962-bis, and we'll have some brief discussion of two new logging proposals - dnssec and code signatures. Melinda From nobody Thu Jul 24 07:14: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 42F9F1A0309 for ; Thu, 24 Jul 2014 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9eHSDaeYpy4 for ; Thu, 24 Jul 2014 07:14:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6721A02EE for ; Thu, 24 Jul 2014 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=598; q=dns/txt; s=iport; t=1406211265; x=1407420865; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R3AfThNOYQqgy/pe4fohOufg0Fn1GJVbUpVvoa00+AE=; b=ZKjWN/usoFfXzwErYsKZAsTXh9iW18eZh7g1VVytAopObFoSermEV2LU Fubxs0I3H3+EhlzIFozMSVP2C1GoFeqGdmmgcjeAAEPNBt3s0J1a6HjTO JLpycRmHo42dbHLGBkQbPC8z2AU6BxEe2HrQ+A1xB98mx8NOPp8PXK618 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHwU0VOtJV2Z/2dsb2JhbABZgw6yCKEqFneECjpRARokQg8IDwEEiFWZSacQF4wJhneBGAWOSIxrlEKDSA X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208";a="342551121" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2014 14:14:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEEOa2018179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 14:14:24 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.10]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:14:24 -0500 From: "Klaas Wierenga (kwiereng)" To: "saag@ietf.org" Thread-Topic: Abfab report Thread-Index: Ac+nSV6S00Ibg1hmTiOT+l3kwD5NXA== Date: Thu, 24 Jul 2014 14:12:57 +0000 Message-ID: <602BDE79-467B-4F7E-A4AF-61DD4335A72A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <299F20F15E3F9B4DB54743D0DE008632@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AvkTtV8nUqER1qF4tpD9GmgM__w Subject: [saag] Abfab 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, 24 Jul 2014 14:14:26 -0000 Abfab met Thursday at 9am. There are 3 remaining documents until Abfab completes it's chartered tasks:= Abfab architecture, AAA-SAML and UI considerations. The architecture document was updated to ad= dress IESG review comments and is thought to be ready for resubmission. The= UI considerations needs one (?) more revision to add security and privacy = considerations and a section how to present error and success, this should= be ready by the next IETF. The AAA-SAML draft, in particular how to carry = AAA-entity information in SAML, needs more discussion. Sent from my iPad= From nobody Thu Jul 24 07:31: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 8604C1A0383 for ; Thu, 24 Jul 2014 07:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLPNywMZJ3AQ for ; Thu, 24 Jul 2014 07:31:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACD01A0030 for ; Thu, 24 Jul 2014 07:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=692; q=dns/txt; s=iport; t=1406212281; x=1407421881; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Vywq7SxVvQTp6mi3wtyPGlFzJQ+wgpGZmKInWRrxm2k=; b=b5h3jfTd0fUm8hIplfzef/gKvxZfXdu4EfvBA88EkEBH2K81p3CPlm1c TkxI7Mhjn/o/cHRJeo6QPgI7SosFOHynU3VktCRz4BLI0L2NbWGtNryO4 BtXzT+ygcR4EQeeWO7+GnfQxYytKFzkLMdUKknmF4fyNEG/qI9J+W397j 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIQX0VOtJA2I/2dsb2JhbABZgw6BLdIGFneECjpRAT5CJwSIVZlbpw4XkwCBGAWbM5RCg0iBcSQc X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208";a="63682625" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 24 Jul 2014 14:31:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEVKwv011057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 14:31:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:31:20 -0500 From: "Joseph Salowey (jsalowey)" To: saag Thread-Topic: IETF 90 TLS working group meeting summary Thread-Index: AQHPp0vvj9Vblt7S9kqDV5GI+DJ5DQ== Date: Thu, 24 Jul 2014 14:31:19 +0000 Message-ID: <18889320-8029-4337-90CE-E461704E2131@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <89A7D204C3B8B6439D5710E295FE660C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iUvpGbyQ7fCTQHStXOn5rO2cWOo Subject: [saag] IETF 90 TLS working group 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: Thu, 24 Jul 2014 14:31:25 -0000 TLS had an interim meeting on Sunday an working group meetings on Monday an= d Thursday. At the interim we refined the 1RTT flows. In addition we worke= d towards removing renegotiation and encrypting the content type header. T= he discussion has been moved to the list for confirmation. On Monday we di= scussed moving ECC to standards track, named groups for Diffie-Hellman over= a finite field and incorporating ChaCha20 with Poly1305 as a TLS cipher. W= e have asked the CFRG for help in selecting alternate curves for ECC and to= validate the construction of the ChaCha20 Poly1305 cipher. We will also b= e discussing making TLS more amenable to hardware implementations. From nobody Thu Jul 24 08:08: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 3EF641A041C for ; Thu, 24 Jul 2014 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwUbCqbgDOoM for ; Thu, 24 Jul 2014 08:08:24 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDAC1A0398 for ; Thu, 24 Jul 2014 08:08:06 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4103194wib.16 for ; Thu, 24 Jul 2014 08:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=wzZMTWUBhs//GQnHcU/h8+a4ca6fOVajyBUcocrZWI4=; b=b4ozy36UGTI9yoSDI6Dmq+pltkATWoXtmghfPE6NiKjewl9d4J25akP3JAawc+JUeb Lzk2qpI3C7CtqcGjV9d/KHbtwS2H01/E1P4JW1BrI3B1Y0mQrAgnrqGHBFuF0EZnBpjE DSPMtHI3E0ali1wt4s74UkWIo60Qbb2X6uQH6N+oc6J/QXQe37+3o4UlKkxy9qPNdzAe KZrjGEEzodINsPKJKP1YaIP9rtMcwGQB2hSOhsXwnmYLJQBf9iNaNEMFyjJMj/N1Av1E yCtiOo6zPbdh7mw0i0gMIZDb59Ojnyeeu8wXh5Uoyc/vwDRGAGa+gBeLaJDIUzSZjwID 3+Ew== X-Received: by 10.180.187.141 with SMTP id fs13mr4971138wic.57.1406214483684; Thu, 24 Jul 2014 08:08:03 -0700 (PDT) Received: from dhcp-a60e.meeting.ietf.org (dhcp-a60e.meeting.ietf.org. [31.133.166.14]) by mx.google.com with ESMTPSA id ft17sm16616139wjc.14.2014.07.24.08.08.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:08:03 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <010686C5-88A9-4F03-B50E-EE45C739DC29@gmail.com> Date: Thu, 24 Jul 2014 11:08:01 -0400 To: IETF Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HX3GK8s4sDRvaHn1tD5rRYkuCbM Subject: [saag] HTTP-Auth Summary for IETF 90 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 15:08:28 -0000 The HTTP-Auth working group met today before lunch. The Basic & Digest drafts are almost ready for WGLC, after we settle the = question of scope - it is not clear whether the group does or does not = want to enhance these protocols rather than just add = internationalization and modern hash functions. The HOBA team promised to finish work on the document over the summer. = After that, we are likely to be able to go to WGLC on that as well. We have three documents covering =93Mutual-Auth=94 that require a lot = more review and discussion.=20 Alexey will revise the SCRAM document based on feedback from Tony = Hansen. Matt & Yoav From nobody Thu Jul 24 09:30: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 EC8D61A0414 for ; Thu, 24 Jul 2014 09:30:37 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDaqG3VrxeNC for ; Thu, 24 Jul 2014 09:30:36 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6501A03F2 for ; Thu, 24 Jul 2014 09:30:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAFg00VMKOQx0/2dsb2JhbABYgkeBdNIed4QKHVEdAQx0JwQyyC0XjnQDhSEFmluYYoFwQQ X-IronPort-AV: E=Sophos; i="5.01,725,1400050800"; d="scan'208,217"; a="10712341" Received: from sfo-barrlb-02.silverspringnet.com (HELO mail.silverspringnet.com) ([10.57.12.116]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 24 Jul 2014 09:30:36 -0700 Received: from SFO-EXMB-03.silverspringnet.com ([fe80::e877:a0b0:2e8d:1b57]) by SFO-EXCA-01.silverspringnet.com ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 09:30:35 -0700 From: Dorothy Gellert To: "saag@ietf.org" Thread-Topic: IETF#90 DICE WG Summary Thread-Index: AQHPp1yXEYHeHRfLDUCV9bJp4JJExA== Date: Thu, 24 Jul 2014 16:30:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.223.131] Content-Type: multipart/alternative; boundary="_000_CFF6ACE913E6Edgellertsilverspringnetcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZQQ1YZTPMgKm_1BNJupoaenRcAk Subject: [saag] IETF#90 DICE 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: Thu, 24 Jul 2014 16:30:38 -0000 --_000_CFF6ACE913E6Edgellertsilverspringnetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable DICE IETF-90 WG summary for SAAG The Dice WG met on Tuesday, July 22nd at 13:00. Hannes Tschofenig presented slides on the DTLS Profile draft (draft-ietf-di= ce-profile-03) This revision addressed several issues on the data tracker thanks to input= from Russ, Mike St Johns and Sean Turner The current model for the profile draft is that of a constrained device/cli= ent connecting to cloud based Infrastructure/server that is not constrained= . Remaining issue regarding depth of Certificate Chain. Mike SJ said th= e depth of the chain should be dependent on the application, and suggested = 4 is reasonable but the number should be constrained. Sean suggested the = draft provides a recommendation and language here is (SHOULD). Reviewers for the profile draft are Sandeep, Ekr, Robert Craigie. Sandeep Kumar presented slides on draft-keoh-dice-multicast-security-08 & d= raft kumar-dice-groupcomm-security-00 ,documenting potential dtls and shim= layer approaches as per the London IETF#89 DiICE WG meeting. Ekr describe= d dtls layer violations as "phenomenally scary=94=85. Chairs multicast discussion: Given the issues on the list and discussion w= ith our AD, we are revisiting the secure multicast/group security and chart= er milestone by documenting requirements in a problem draft. This draft wi= ll not be standards track. The problem draft will document potential use ca= ses, key management, group membership, source authentication. Other issue= s: How to scope or limit or constrain this to coap, should we provide gui= dance to the mac layer, how can we prevent this won=92t be used for unicast= ? Latency requirements? The problem draft is open until the next meeting= in November. Next steps: Call for volunteers on the list to author the Problem draft = Keep the mailing list engaged in providing input on requirements, issues, a= nd risks we need to address for group communication/multicast security. -Dorothy --_000_CFF6ACE913E6Edgellertsilverspringnetcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
DICE IETF-90 WG summary for SAAG

The Dice WG met on Tuesday, July 22nd at 13:00.

Hannes Tschofenig presented slides on the DTLS Profile draft (draft-ie= tf-dice-profile-03)
This revision addressed several  issues on the data tracker thank= s to input from Russ, Mike St Johns and Sean Turner
The current model for the profile draft is that of a constrained devic= e/client connecting to cloud based Infrastructure/server that is not constr= ained.   Remaining issue regarding depth of Certificate Chain.   = Mike SJ said the depth of the chain should be dependent on the application, and suggested 4 is reasonable but the num= ber should be constrained.   Sean suggested the draft provides a recom= mendation and language here is (SHOULD).
Reviewers for the profile draft are Sandeep, Ekr, Robert Craigie. = ;

Sandeep Kumar presented slides on draft-keoh-dice-multicast-security-0= 8 & draft kumar-dice-groupcomm-security-00 ,documenting  potential= dtls and shim layer approaches as per the London IETF#89 DiICE WG meeting.=  Ekr described dtls layer violations as "phenomenally scary=94=85. 

Chairs multicast discussion:  Given the issues on the list and di= scussion with our AD, we are revisiting the secure multicast/group security= and charter milestone by documenting requirements in a problem draft. &nbs= p;This draft will not be standards track. The problem draft will document potential use cases,  key management,= group membership, source authentication.  Other issues:  How to = scope or limit or constrain this  to coap, should we provide guidance = to the mac layer, how can we prevent this won=92t be used for unicast?   Latency requirements?  The problem draft is open = until the next meeting in November. 

Next steps:  Call for volunteers on the list to author the Proble= m draft   Keep the mailing list engaged in providing input on requirem= ents, issues, and risks we need to address for group communication/multicas= t security. 

-Dorothy

--_000_CFF6ACE913E6Edgellertsilverspringnetcom_-- From nobody Thu Jul 24 10:04: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 A7D4D1A02DF for ; Thu, 24 Jul 2014 10:04:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vvMYZvReopFF for ; Thu, 24 Jul 2014 10:04:23 -0700 (PDT) Received: from smtp112.ord1c.emailsrvr.com (smtp112.ord1c.emailsrvr.com [108.166.43.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF641A04B8 for ; Thu, 24 Jul 2014 10:04:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 83825380262 for ; Thu, 24 Jul 2014 13:04:22 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 393BC380170 for ; Thu, 24 Jul 2014 13:04:21 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Thu, 24 Jul 2014 17:04:22 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 24 Jul 2014 13:04:20 -0400 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NCblB5LywFDAJbSr4aGKJeQmw1c Subject: [saag] DANE 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: Thu, 24 Jul 2014 17:04:24 -0000 DANE met on Tuesday in a large room.=20 Since last meeting the working group got a new charter, and work is = focused on getting a number of documents wrapped up.=20 These include the dane-srv and dane-smtp documents that define how to = use DANE with service indirection records.=20 After that we will proceed with using DANE to distribute email = certificates for SMIME and OPENPGP.=20 There are number other tasks to attack including the an Operational = Guide that is now updating the base specification based on deployment experience.=20 Olafur From nobody Thu Jul 24 11:58: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 380EB1B27DA for ; Thu, 24 Jul 2014 11:58:31 -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=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 vUCsu_2WfApm for ; Thu, 24 Jul 2014 11:58:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16151A002A for ; Thu, 24 Jul 2014 11:58:29 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 18:58:22 +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.0990.007; Thu, 24 Jul 2014 18:58:22 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" , "saag@ietf.org" Thread-Topic: CFRG@IETF90 summary Thread-Index: AQHPp3E9D6TDVep/6EOKPK8XSZUHtA== Date: Thu, 24 Jul 2014 18:58:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [31.133.156.135] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(60444003)(189002)(85852003)(81542001)(64706001)(36756003)(107886001)(101416001)(105586002)(79102001)(107046002)(81342001)(76482001)(20776003)(229853001)(83506001)(46102001)(106116001)(83072002)(54356999)(15975445006)(50986999)(19580395003)(87936001)(2656002)(4396001)(92566001)(99396002)(92726001)(77982001)(95666004)(66066001)(80022001)(74662001)(74482001)(74502001)(85306003)(106356001)(31966008)(15974865002)(83322001)(86362001)(21056001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1ACD9BC1323B9549987D324066741734@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QQsUYAF_O1tS5kW1ki8_48TKsgU Subject: [saag] CFRG@IETF90 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: Thu, 24 Jul 2014 18:58:31 -0000 CFRG met at IETF90 this week in Toronto. The agenda and meeting materials can be found at https://datatracker.ietf.org/meeting/90/agenda/cfrg/ https://datatracker.ietf.org/meeting/90/agenda/cfrg-drafts.pdf The main focus of our meeting was presentations and discussions in response to the TLS WG's request for recommendations for new elliptic curves (see www.ietf.org/mail-archive/web/cfrg/current/msg04655.html for details of the request). Tanja Lange from TU Eindhoven set the scene by giving a tutorial on ECC, old and new. Brian LaMacchia and Craig Costello from Microsoft talked about NUMS curves. Dan Bernstein from UIC/TU Eindhoven spoke about Curve25519 and friends. There was active discussion on the TLS WG's request during and after the presentations. Yoav Nir (Check Point) presented on AEAD built from ChaCha20+Poly1305 for TLS. CFRG has adopted a document describing the latter scheme, and the CFRG chairs will soon receive a formal request from TLS WG to review this document. The document itself can be found at www.ietf.org/id/draft-irtf-cfrg-chacha20-poly1305-00.txt We also had a presentation from David McGrew (Cisco Systems) on hash-based signatures, relating to the Internet Draft www.ietf.org/id/draft-mcgrew-hash-sigs-02.txt. The CFRG chairs will formally ask CFRG if we should adopt the document as a RG document. Rifaat Shekh-Yusef gave a presentation on Challenge-Response mechanisms. Under AoB, Wendy Seltzer, representing W3C, asked CFRG to consider creating a "per-algorithm" security considerations Informational RFC for the algorithms listed in the W3C Web Cryptography API (www.w3.org/TR/WebCryptoAPI). In principle, the CFRG will sponsor this work; the initial Internet Draft will be produced by Graham Steel (INRIA), with feedback from Rich Salz (Akamai) and help from the W3C staff. Once a draft is available, the CFRG chairs will formally ask the CFRG list to consider sponsoring this document. Kenny Paterson (for the CFRG chairs) From nobody Thu Jul 24 12:53: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 D176F1A0AD7 for ; Thu, 24 Jul 2014 12:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 BmNTL4VwOeDB for ; Thu, 24 Jul 2014 12:53:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05E41A0AC7 for ; Thu, 24 Jul 2014 12:53:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B1B520012 for ; Thu, 24 Jul 2014 15:54:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DF6DC63B0E; Thu, 24 Jul 2014 15:53:00 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C451E63B0A for ; Thu, 24 Jul 2014 15:53:00 -0400 (EDT) From: Michael Richardson To: saag@ietf.org X-Attribution: mcr 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/q5e4tDqd3qK3cT3aKz0cBzWV6s4 Subject: [saag] witch hunt on EUI-48/64 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: /dev/null@sandelman.ca List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:53:04 -0000 --=-=-= The words/feeling that I am experiencing was not really witch hunt. I was asked after if I was referring to the monty-python _Meaning of Life_ business with: "If it's made out of wood, it's a witch" is where I was going, and actually it was. http://montypython.50webs.com/scripts/Holy_Grail/Scene5.htm It was more about: http://en.wikipedia.org/wiki/Red_Scare It feels a bit like there is a IETF Committee on No-Globally-Unique Identifiers (akin to the House Committee on Un-American Activities). In this analogy, the IoT world are American born Asians, looking at internment. I think that the work that rfc6973 (privacy implications for IP) did is good. RFC 7217 (Stable Privacy addresses) and draft-ietf-6man-default-iids-00 (make 7217 a SHOULD) are good logical recommendations. But it now seems like there is a belief that getting rid of every use of vendor derived EUI-64 is a good thing. It's interesting that the ESSID scanning attack (which seems like a far more significant attack on privacy to me) has no dependancy at all on vendor-derived EUI-64s.... they just need to be stable for zero-zero periods of time. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9FkGoCLcPvd0N1lAQLaLAgAwKIMKxmSXh0nZRBzkp2rSo2dOH9j5xcR cHCJd0zIaRBuJnYGzLiGePhu05AXRi2/GNkJOnw6/yM++XnwMc84tfbW/l45YStm eAEu5/Jrq0ZR1YmAD05ajLQ9R1iyBo8hp1h53kV5LUy7HpCG4Ttv/YB7RRiEyPcR OVeXr05LNuCJnJZNjBEvSFt8jRb+h35bYEbhZ/tMJ8LeKIvgD/nWYEAoHJfXufOZ u33+XRYotLjHXZBsH3Xbh2aomOritRQiC0P813Bx3jWAqwHE2z+9pkEKKH5+UGV2 s+RpCV45rpeSYpQK+qHF11XUEcabL5vFQXkF+kqI3FyjXOv12AVA4g== =2DpD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 24 13: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 270591B287F for ; Thu, 24 Jul 2014 13:24:14 -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 3PdUT82dADzV for ; Thu, 24 Jul 2014 13:24:12 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869141B286A for ; Thu, 24 Jul 2014 13:24:11 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so3382236wes.0 for ; Thu, 24 Jul 2014 13:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=FZ1I0yQ2BGNXwJ3KxsPE1J5HXFgizWWIQqnkl9jK6l8=; b=OlczyWo6fvgjx2uau/XFGp7t/4b+tMavQjkLDf8mPQo7zI9+nL5aHHXm5xVT/tMHDJ fHlQK2lqmtTv6iwremuZlzeihH69QhcMsFoEEgYboQHlvfJd9g6RffRyHAQ8jT2ugLJQ Bg0cRmyOHVRteeLa/9o1IJc5K0PVKP1QN7YF24qqEPyQm9S4Nyxw16zJxm+17hjEb+ZT TsjYF8apK1GLjCOt7XxbTK6dZOapyXidJBVusTgSJtOuLtz2KW9jYQ+Yfk+G/F290kiy pP8Ez1GlHRaQHiYJLBAVSqLMFLl7yTPkMW29g/2Kl49qn2FIpX8NkHQjpOHi8tR1zDro CHAQ== MIME-Version: 1.0 X-Received: by 10.194.158.226 with SMTP id wx2mr15710845wjb.107.1406233449481; Thu, 24 Jul 2014 13:24:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.123.167 with HTTP; Thu, 24 Jul 2014 13:24:09 -0700 (PDT) Date: Thu, 24 Jul 2014 16:24:09 -0400 X-Google-Sender-Auth: nUR6oXCR9y1ZvS0LcqdUuACLwy4 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RWTQ9Be1eoNCuKhMG-n63AY3fZM Subject: [saag] Mapping from email addresses to crypto parameters X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 20:24:14 -0000 One of the issues raised in the plenary was how to go from an email address to a validated public key for encrypting email to that address. WebFinger was proposed as a solution, PPE uses a slightly different solution. This is because there is more than one problem here. lets start with terms, we actually have four types of data 1) The email address (e.g. alice.prism.proof@gmail.com) 2) A public key for encryption for that address (there is likely to be more than one to address spam issues, confidentiality levels, etc.) 3) Information to establish a root of trust (e.g. a root cert or phingerprint of a root cert, for Alice this is D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A) 4) (Optionally) A chain of certificates/assertions/etc to establish the validity of (2) with respect to (3). Depending on the precise trust model we have different ways of moving these types of data around. In the WebPKI we have a limited number of (3) and push them out to every browser and so all we need to send in band is (2) and (4). In PPE I avoid the problem of discovering (2) by binding it into the email address to create a 'strong email address': D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A?alice.prism.proof@gmail.com So in PPE we know the root of trust but not the public encryption key or the validation chain. One of the main differences between PGP and PPE is that in PGP the fingerprint is of the encryption key itself and in PPE that is only the case in PGP legacy mode. Checking cert chains in 1992 was a serious performance drag, today it is not. So in PPE the most convenient lookup mechanism to use that does not introduce a trusted party is to extract a domain from the email address and throw a .well-known query at it to pull the encryption chain and validation data. All the data is validated to the phingerprint so the Web Server is not 'trusted' except as regards service. As it turns out, this does not quite work for the general case since gmail.com does not host a phinger for Alice. So what we do instead is to put the data on orac.hallambaker.com and substitute that into the email address: D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A?alice.prism.proof@orac.hallambaker.com It would of course be better if we could avoid this and have both domains. But that turns out to start to exceed hard limits in various contacts and address book apps. The problem with involving Webfinger here is that only the strong email address is static. The encryption key will change on a monthly basis and so will the validation data. So I would not really want to have to edit my webfinger data each time there is an update. The only way it can work then is if either the webfinger service provider is pulling the key data on each update and updating its record or if the webfinger service is supplied by a keybroker type service. Adding the phingerprint to the webfinger data makes perfect sense of course. If I am attempting to send a message to alice.prism.proof@gmail.com it makes perfect sense to add the phingerprint into that record so that it can be used as a trust chain locator but I really can't use it as strong root of trust for a validation model. This is where we get out of the 'key discovery' problem which is finishing our main course and start eating desert. From nobody Thu Jul 24 13:29: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 113441B28B3; Thu, 24 Jul 2014 13:29:40 -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, HTML_MESSAGE=0.001, 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 rR_2l8hI0l1B; Thu, 24 Jul 2014 13:29:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35511B28BE; Thu, 24 Jul 2014 13:29:23 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) with Microsoft SMTP Server (TLS) id 15.0.995.11; Thu, 24 Jul 2014 20:29:22 +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.0995.011; Thu, 24 Jul 2014 20:29:22 +0000 From: "Orit Levin (LCA)" To: "saag@ietf.org" , "uta@ietf.org" , "Leif Johansson" Thread-Topic: UTA Summary Thread-Index: AQHPp33zopzlQgFvTUOnFTxwAL+ZWw== Date: Thu, 24 Jul 2014 20:29:21 +0000 Message-ID: <0cc6031385914442ae3515c3ec0766b3@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:67c:370:176:c457:cfbe:2283:cf11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(164054003)(95666004)(15975445006)(2656002)(99396002)(92566001)(74662001)(107046002)(101416001)(87936001)(86362001)(79102001)(106356001)(74502001)(46102001)(81542001)(107886001)(20776003)(76576001)(85306003)(15202345003)(74316001)(21056001)(50986999)(85852003)(83072002)(86612001)(81342001)(64706001)(54356999)(16236675004)(4396001)(76482001)(33646002)(106116001)(80022001)(99286002)(105586002)(31966008)(83322001)(19580395003)(229853001)(77982001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB290; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0cc6031385914442ae3515c3ec0766b3BL2PR03MB290namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IxkoUCRJ-HVBUC6V7FtZRbJJjaE Subject: [saag] UTA 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: Thu, 24 Jul 2014 20:29:40 -0000 --_000_0cc6031385914442ae3515c3ec0766b3BL2PR03MB290namprd03pro_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable UTA WG @IETF 90, Toronto / TUESDAY, July 22, 2014 / 0900-1130 Morning Sess= ion I Short summary The three existing UTA drafts have a broad consensus on their technical con= tent. Multiple participants promised to provide thorough editorial review (= especially of the BCP draft) in the following two weeks. All comments and s= uggestions will be integrated in the next versions of the documents. The go= al of the WG is to successfully complete final calls for all three IDs befo= re Nov 2014. In parallel, (i.e., before IETF91) the WG will start focusing = the =93EMAIL protocols using TLS=94 topic. Contributions towards this topic= , as well as additional (new) topics around using TLS with applications are= mostly welcome on the list and/or towards IETF91. Specifics Applicability to a generic application was presented remotely by Yaron Shef= fer: https://datatracker.ietf.org/doc/draft-uta-tls-attacks/ Agreement on the existing technical content of the draft. Additions will be= incorporated. https://datatracker.ietf.org/doc/draft-tls-bcp/ Broad agreement and support regarding the existing technical content of the= draft. Many comments regarding the text explaining the reasoning behind th= e recommendations and the overall document organization. "Updated TLS Server Identity Check Procedure for Email Related Protocols" w= as presented by Alexey Melnikov https://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/ Call for adoption as a WG ID has been issued on the UTA list; to be conclud= ed on Sun, July 26th, 2014. "Overview and Analysis of Overhead Caused by TLS" was presented by John Mat= tsson https://datatracker.ietf.org/doc/draft-mattsson-uta-tls-overhead/ A lot of interest from the community to collect more inputs and integrate t= hem into a single IETF document to be used by wider audience. The work will= continue on UTA, unless/until other possible venue becomes identified. "Binding Security Tokens to TLS Channels" was presented by Andrei Popov See meeting's materials at http://www.ietf.org/proceedings/90/slides/slides= -90-uta-0.pdf An introduction to a new mechanism, which is a part of a larger ecosystem. = The authors are working on a more complete draft to be submitted soon and b= e socialized with broader IETF community. Thanks, Leif and Orit. --_000_0cc6031385914442ae3515c3ec0766b3BL2PR03MB290namprd03pro_ Content-Type: text/html; charset="Windows-1252" Content-ID: <82DDAB2D9BAAE742BAA06452EA517299@microsoft.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable

UTA WG @IETF 90, Toronto / TUESDAY, July 22, 2014 / 0900-1130  Morning= Session I


Short summary

The three existing UTA drafts have a broad consensus on their technical con= tent. Multiple participants promised to provide thorough editorial review (= especially of the BCP draft) in the following two weeks. All comments and s= uggestions will be integrated in the next versions of the documents. The goal of the WG is to successfully = complete final calls for all three IDs before Nov 2014. In parallel, (i.e.,= before IETF91) the WG will start focusing the =93EMAIL protocols using TLS= =94 topic. Contributions towards this topic, as well as additional (new) topics around using TLS with applicatio= ns are mostly welcome on the list and/or towards IETF91.


Specifics

Applicability to a generic application was presented remotely by Yaron Shef= fer:

https://datatracker.ietf.org/doc/draft-uta-tls-attacks/
Agreement on the existing technical content of the draft. Additions will be= incorporated.

https://datatracker.ietf.org/doc/draft-tls-bcp/
Broad agreement and support regarding the existing technical content of the= draft. Many comments regarding the text explaining the reasoning behind th= e recommendations and the overall document organization.


"Updated TLS Server Identity Check Procedure for Email Related Protoco= ls" was presented by Alexey Melnikov
https://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/
Call for adoption as a WG ID has been issued on the UTA list; to be conclud= ed on Sun, July 26th, 2014.


"Overview and Analysis of Overhead Caused by TLS" was presented b= y John Mattsson
https://datatracker.ietf.org/doc/draft-mattsson-uta-tls-overhead/
A lot of interest from the community to collect more inputs and integrate t= hem into a single IETF document to be used by wider audience. The work will= continue on UTA, unless/until other possible venue becomes identified.


"Binding Security Tokens to TLS Channels" was presented by Andrei= Popov
See meeting's materials at http://www.ietf.org/proceedings/90/slides/slides= -90-uta-0.pdf
An introduction to a new mechanism, which is a part of a larger ecosystem. = The authors are working on a more complete draft to be submitted soon and b= e socialized with broader IETF community.     &nbs= p; 

Thanks,
Leif and Orit.
--_000_0cc6031385914442ae3515c3ec0766b3BL2PR03MB290namprd03pro_-- From nobody Thu Jul 24 15:28: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 339AE1A03B8 for ; Thu, 24 Jul 2014 15:28:49 -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 vMfeVlVb6VNJ for ; Thu, 24 Jul 2014 15:28:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85451A01E8 for ; Thu, 24 Jul 2014 15:28:46 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (25.160.96.18) with Microsoft SMTP Server (TLS) id 15.0.985.8; Thu, 24 Jul 2014 22:28:45 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.00.0985.008; Thu, 24 Jul 2014 22:28:45 +0000 From: Christian Huitema To: "/dev/null@sandelman.ca" , "saag@ietf.org" Thread-Topic: [saag] witch hunt on EUI-48/64 Thread-Index: AQHPp3jqEKSSDvP8Mky5RnQ8PhhFoZuvzQBQ Date: Thu, 24 Jul 2014 22:28:44 +0000 Message-ID: <39565143db4542d2b8f6deb974f38a8f@DM2PR0301MB0655.namprd03.prod.outlook.com> References: <13311.1406231580@sandelman.ca> In-Reply-To: <13311.1406231580@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(189002)(199002)(92566001)(83072002)(80022001)(85852003)(77096002)(106356001)(86362001)(79102001)(95666004)(87936001)(64706001)(81542001)(21056001)(107046002)(101416001)(105586002)(107886001)(99396002)(2656002)(83322001)(85306003)(20776003)(81342001)(106116001)(76176999)(50986999)(77982001)(86612001)(74316001)(4396001)(99286002)(46102001)(74662001)(31966008)(76576001)(54356999)(33646002)(76482001)(74502001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 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/Mnkwtm-7G_NDZILus56lR2-6Pxg Subject: Re: [saag] witch hunt on EUI-48/64 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 22:28:49 -0000 > But it now seems like there is a belief that getting rid of every use of = vendor derived EUI-64 is a good thing. > > It's interesting that the ESSID scanning attack (which seems like a far m= ore significant attack on privacy to me)=20 > has no dependancy at all on vendor-derived EUI-64s.... they just need to = be stable for zero-zero periods of time. In as much as the "things" are personal devices, then yes of course we shou= ld not use permanent identifiers in the IPv6 addresses. Look at the scenari= o in which your smart wrist watch periodically communicates with your smart= phone in your pocket. The low level protocol layers are probably not encry= pted. How long do you believe we need to wait before an enterprising start-= up builds a neat radio device that listens to these unencrypted exchanges, = extract the unencrypted identifiers, and builds a neat people tracker? -- Christian Huitema From nobody Thu Jul 24 16:16: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 765391A0503 for ; Thu, 24 Jul 2014 16:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS5nr-s11-DL for ; Thu, 24 Jul 2014 16:16:04 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7D61A0311 for ; Thu, 24 Jul 2014 16:16:04 -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 s6ONFm8i030489; Thu, 24 Jul 2014 16:16:04 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1naxa3jeg5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jul 2014 16:16:04 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 24 Jul 2014 16:16:03 -0700 From: Paul Lambert To: Christian Huitema , "/dev/null@sandelman.ca" , "saag@ietf.org" Date: Thu, 24 Jul 2014 16:16:00 -0700 Thread-Topic: [saag] witch hunt on EUI-48/64 Thread-Index: AQHPp3jqEKSSDvP8Mky5RnQ8PhhFoZuvzQBQgAALhiA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE4895EE4@SC-VEXCH2.marvell.com> References: <13311.1406231580@sandelman.ca> <39565143db4542d2b8f6deb974f38a8f@DM2PR0301MB0655.namprd03.prod.outlook.com> In-Reply-To: <39565143db4542d2b8f6deb974f38a8f@DM2PR0301MB0655.namprd03.prod.outlook.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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-24_06:2014-07-24,2014-07-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407240282 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IpDWVQmaJcxqjeWlxJHPeuElvL0 Subject: Re: [saag] witch hunt on EUI-48/64 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 24 Jul 2014 23:16:06 -0000 ]-----Original Message----- ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Christian Huitema ]Sent: Thursday, July 24, 2014 3:29 PM ]To: /dev/null@sandelman.ca; saag@ietf.org ]Subject: Re: [saag] witch hunt on EUI-48/64 ] ]> But it now seems like there is a belief that getting rid of every use ]of vendor derived EUI-64 is a good thing. ]> ]> It's interesting that the ESSID scanning attack (which seems like a ]> far more significant attack on privacy to me) has no dependancy at all ]on vendor-derived EUI-64s.... they just need to be stable for zero-zero ]periods of time. ] ]In as much as the "things" are personal devices, then yes of course we ]should not use permanent identifiers in the IPv6 addresses. Look at the ]scenario in which your smart wrist watch periodically communicates with ]your smart phone in your pocket. The low level protocol layers are ]probably not encrypted. How long do you believe we need to wait before ]an enterprising start-up builds a neat radio device that listens to ]these unencrypted exchanges, extract the unencrypted identifiers, and ]builds a neat people tracker? These exist already: http://tinyurl.com/qdz4t7h=20 http://www.infowars.com/wi-fi-trashcans-now-silently-tracking-your-smartph= one-data/=20 http://arstechnica.com/security/2013/08/diy-stalker-boxes-spy-on-wi-fi-use= rs-cheaply-and-with-maximum-creep-value/ https://firstlook.org/theintercept/article/2014/02/10/the-nsas-secret-role= / IPv6 then extends the 'local' tracking to be end-to-end when the MAC addres= s is used. Solutions are being proposed in Layer 2 activates (e.g. IEEE 802) to mitigate this type of problem by using Ephemeral MAC Addresses. Paul ] ]-- Christian Huitema ] ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Fri Jul 25 06:24: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 998631B2868 for ; Fri, 25 Jul 2014 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ICbRgN39Z9Z4 for ; Fri, 25 Jul 2014 06:24:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7341A027C for ; Fri, 25 Jul 2014 06:24:22 -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 s6PDOL2F004001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jul 2014 09:24:22 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6PDOKXn013522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 09:24:21 -0400 Message-ID: <53D25A83.2020607@redhat.com> Date: Fri, 25 Jul 2014 15:24:19 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jan.Pechanec@Oracle.COM References: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> In-Reply-To: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jt1WkmGA1ziY1ViriB8F1fuS2kE Cc: saag@ietf.org Subject: [saag] nitpicks about draft-pechanec-pkcs11uri-14.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, 25 Jul 2014 13:24:24 -0000 Hello, I'm implementing draft-pechanec-pkcs11uri-14 for FreeIPA project and during that work I have found two nits on draft-pechanec-pkcs11uri-14: On http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14#page-6: I would propose to split/reformulate the paragraph starting with: "The path component attribute "token" represents a token label and corresponds to the "label" member of the CK_TOKEN_INFO structure" ... The first sentence (enumeration) spans over 15 lines and I personally find it difficult to read. Maybe a table would be better: " The path component attributes and their mapping to PKCS#11 data structures: ---------------------|--------------------------------------------------- token | "label" member of the CK_TOKEN_INFO structure manufacturer | "manufacturerID" member of CK_TOKEN_INFO structure serial | "serialNumber" member of CK_TOKEN_INFO structure model | "model" member of CK_TOKEN_INFO structure library-manufacturer | "manufacturerID" member of the CK_INFO structure library-description | "libraryDescription" member of CK_INFO structure library-version | "libraryVersion" member of CK_INFO structure object | "CKA_LABEL" object attribute type | "CKA_CLASS" object attribute id | "CKA_ID" object attribute ---------------------|--------------------------------------------------- The query component attributes: ------------|------------------------------------------------------------ pin-source | Specifies where the application or library | should find the normal user's token PIN. pin-value | Provides the normal user's PIN value directly, if needed. module-name | Modifies default settings for accessing PKCS#11 providers. module-path | modifies default settings for accessing PKCS#11 providers. ------------|------------------------------------------------------------ For the definition of a "normal user", see [pkcs11_spec]. " The other nit is more rhetorical question: "Why CKA_LABEL is represented by string 'object'?" I find it a bit confusing... However I understand that it might be too late for this change. Have a nice day! Petr Spacek @ Red Hat On 21.7.2014 19:56, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The PKCS#11 URI Scheme > Authors : Jan Pechanec > Darren J. Moffat > Filename : draft-pechanec-pkcs11uri-14.txt > Pages : 15 > Date : 2014-07-21 > > Abstract: > This memo specifies a PKCS#11 Uniform Resource Identifier (URI) > Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for > identifying PKCS#11 tokens themselves, or for identifying PKCS#11 > libraries. The URI is based on how PKCS#11 objects, tokens, and > libraries are identified in the PKCS#11 Cryptographic Token Interface > Standard. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-14 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 26 04:12: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 331F31A8BB1 for ; Sat, 26 Jul 2014 04:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MEJTM_X_L05 for ; Sat, 26 Jul 2014 04:12:54 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617D01A8BAF for ; Sat, 26 Jul 2014 04:12:54 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2E7C96D71B; Sat, 26 Jul 2014 07:12:50 -0400 (EDT) Message-ID: <53D38D18.8050207@iang.org> Date: Sat, 26 Jul 2014 12:12:24 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Z25KYWqZ14_iQYz261VNdKVot24 Subject: [saag] "How to manipulate curve standards: a white paper for the black hat" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.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, 26 Jul 2014 11:12:56 -0000 http://eprint.iacr.org/2014/571 How to manipulate curve standards: a white paper for the black hat Daniel J. Bernstein and Tung Chou and Chitchanok Chuengsatiansup and Andreas Hülsing and Tanja Lange and Ruben Niederhagen and Christine van Vredendaal Abstract: This paper analyzes the cost of breaking ECC under the following assumptions: (1) ECC is using a standardized elliptic curve that was actually chosen by an attacker; (2) the attacker is aware of a vulnerability in some curves that are not publicly known to be vulnerable. This cost includes the cost of exploiting the vulnerability, but also the initial cost of computing a curve suitable for sabotaging the standard. This initial cost depends upon the acceptability criteria used by the public to decide whether to allow a curve as a standard, and (in most cases) also upon the chance of a curve being vulnerable. This paper shows the importance of accurately modeling the actual acceptability criteria: i.e., figuring out what the public can be fooled into accepting. For example, this paper shows that plausible models of the “Brainpool acceptability criteria” allow the attacker to target a one-in-a-million vulnerability. http://eprint.iacr.org/2014/571.pdf From nobody Sun Jul 27 12:24: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 AF25A1A00DA; Sun, 27 Jul 2014 12:23:58 -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 8wHxr3aQ0kmQ; Sun, 27 Jul 2014 12:23:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE2C1A00C2; Sun, 27 Jul 2014 12:23:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 166982AB2B6; Sun, 27 Jul 2014 19:23:54 +0000 (UTC) Date: Sun, 27 Jul 2014 19:23:54 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140727192353.GT15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BFDC9A.5060307@iang.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/j2kz6ShUj54C--0mvtWaVvTZdno Cc: ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 19:23:58 -0000 On Fri, Jul 11, 2014 at 01:46:18PM +0100, ianG wrote: > In the below, I experiment with the term 'complete protection' rather > than 'strong security'. > > > The draft makes a stab at calling the alternate 'strong protection' but > > does not go much further. > > Abstract. > > This memo defines the term "opportunistic security". In contrast to > the established approach of delivering complete protection when > possible, and none if not possible, ... > > [...] So is "complete protection" as proposed by "iang" a better term for the historical alternative? The plausible choices are the current language "strong security", iang's "complete security", or perhaps "comprehensive security" (which arguably avoids the maximality of "complete" or "strong"). None of the above are established terminology, so a related question is whether whatever term is used requires a brief detour to define it? My initial goal was to strive to avoid detours, and focus on defining opportustinic security. It was my hope that other terms are either sufficiently clear from context, or that defining them precisely is not essential to the task at hand. Perhaps in this particular case a sentence or two in the introduction would not be too much of a distraction, but if this does not significantly aid the clarity of the definition of opportunistic security at the bottom of section 2, maybe defining legacy practice is best done in another draft? More than anything else I want it to be clear that opportunistic security is not limited to just unauthenticated encryption. The last paragraph of section 2 attempts to address that goal. If that paragraph is not sufficiently clear, I am open to suggestions of how to make it more so. I am inclined to adopt the suggestion of the Gen-ART review to change "MUST/SHOULD" to "must/should" in the last two paragraphs of section 2. If anyone prefers the current language, please speak up. -- Viktor. From nobody Mon Jul 28 08:24: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 3867C1A01DC; Sun, 27 Jul 2014 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkdynEDYLa_U; Sun, 27 Jul 2014 12:48:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097B41A010C; Sun, 27 Jul 2014 12:48:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4766720126; Sun, 27 Jul 2014 15:45:47 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o6e3WFWx215; Sun, 27 Jul 2014 15:45:46 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Sun, 27 Jul 2014 15:45:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B91F780039; Sun, 27 Jul 2014 15:48:42 -0400 (EDT) From: Sam Hartman To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> Date: Sun, 27 Jul 2014 15:48:42 -0400 In-Reply-To: <20140727192353.GT15044@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 27 Jul 2014 19:23:54 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r15mxocerv9xpfnoGyoNbNJpneE X-Mailman-Approved-At: Mon, 28 Jul 2014 08:24:35 -0700 Cc: ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 19:48:46 -0000 I prefer the current text. From nobody Mon Jul 28 08:24: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 A64EC1A037D for ; Fri, 25 Jul 2014 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 2jfcwv9eObFe for ; Fri, 25 Jul 2014 12:52:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6555E1A03AC for ; Fri, 25 Jul 2014 12:52:00 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6PJpwGf018803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jul 2014 19:51:59 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6PJpwei001874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Jul 2014 19:51:58 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6PJpvSf006493; Fri, 25 Jul 2014 19:51:58 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Jul 2014 12:51:57 -0700 Date: Fri, 25 Jul 2014 12:51:56 -0700 (PDT) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Petr Spacek In-Reply-To: <53D25A83.2020607@redhat.com> Message-ID: References: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> <53D25A83.2020607@redhat.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/n9k5PbxIfsq--MQpOmkSuTavpVw X-Mailman-Approved-At: Mon, 28 Jul 2014 08:24:38 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] nitpicks about draft-pechanec-pkcs11uri-14.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, 25 Jul 2014 19:52:02 -0000 On Fri, 25 Jul 2014, Petr Spacek wrote: > Hello, hi Petr, > I'm implementing draft-pechanec-pkcs11uri-14 for FreeIPA project and during > that work I have found two nits on draft-pechanec-pkcs11uri-14: > > On http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14#page-6: > > I would propose to split/reformulate the paragraph starting with: > "The path component attribute "token" represents a token label and corresponds > to the "label" member of the CK_TOKEN_INFO structure" ... > > The first sentence (enumeration) spans over 15 lines and I personally find it > difficult to read. Maybe a table would be better: <...> thanks for the feedback, it's much appreciated. I will see what I can do about this one. > The other nit is more rhetorical question: "Why CKA_LABEL is represented by > string 'object'?" I find it a bit confusing... However I understand that it > might be too late for this change. we assume that most users might know close to nothing about the actual specification and how the URI attributes map to it, and that the "object" attribute name might be easier for them to use to identify the storage object in the token. We also use "type" for CKA_CLASS instead of "class" since we assume that users mostly think about types of objects instead of classes. there is another label we use, from the CK_TOKEN_INFO structure, and again we call it "token" instead of "token-label" or something else. We were making a necessary compromise between how precisely are the URI attribute names mapped to the names in the spec and the ease of use of the URI scheme. regards, Jan. > > Have a nice day! > > Petr Spacek @ Red Hat > > On 21.7.2014 19:56, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : The PKCS#11 URI Scheme >> Authors : Jan Pechanec >> Darren J. Moffat >> Filename : draft-pechanec-pkcs11uri-14.txt >> Pages : 15 >> Date : 2014-07-21 >> >> Abstract: >> This memo specifies a PKCS#11 Uniform Resource Identifier (URI) >> Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for >> identifying PKCS#11 tokens themselves, or for identifying PKCS#11 >> libraries. The URI is based on how PKCS#11 objects, tokens, and >> libraries are identified in the PKCS#11 Cryptographic Token Interface >> Standard. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-14 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > -- Jan Pechanec From nobody Mon Jul 28 15:05: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 EDA821A008E for ; Mon, 28 Jul 2014 15:05:00 -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 cfb14CZNbkiW for ; Mon, 28 Jul 2014 15:04:58 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F46B1A0080 for ; Mon, 28 Jul 2014 15:04:58 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A85C06D78F; Mon, 28 Jul 2014 18:04:50 -0400 (EDT) Message-ID: <53D6C902.50200@iang.org> Date: Mon, 28 Jul 2014 23:04:50 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> In-Reply-To: <20140727192353.GT15044@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/q5Vs_34iM82mWITGQAAo6y1omQU Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:05:01 -0000 On 27/07/2014 20:23 pm, Viktor Dukhovni wrote: > On Fri, Jul 11, 2014 at 01:46:18PM +0100, ianG wrote: > >> In the below, I experiment with the term 'complete protection' rather >> than 'strong security'. >> >>> The draft makes a stab at calling the alternate 'strong protection' but >>> does not go much further. >> >> Abstract. >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering complete protection when >> possible, and none if not possible, ... >> >> [...] > > So is "complete protection" as proposed by "iang" a better term > for the historical alternative? Yet, OS can also provide the same complete envelope in certain cases (as others have pointed out). > The plausible choices are the > current language "strong security", iang's "complete security", or > perhaps "comprehensive security" (which arguably avoids the maximality > of "complete" or "strong"). Having re-read the responses I think the term that comes closest is "all-or-nothing". But even that doesn't seem to capture all of it, because "all" isn't what they achieve, they are quite conscious of ignoring certain threats such as tracking or DOS. Perhaps "high bar" security or "fixed bar" security? The flaw with much work in the past is that the bar was set high, and those who failed to leap it where knocked back. So they walked around. Instead we want to change the paradigm. We want to lift the bar to the height that the jumper can leap, not filter the jumper by the height of the bar, set arbitrarily high. > None of the above are established terminology, so a related question > is whether whatever term is used requires a brief detour to define > it? My initial goal was to strive to avoid detours, and focus on > defining opportustinic security. It was my hope that other terms > are either sufficiently clear from context, or that defining them > precisely is not essential to the task at hand. It's a tough call. In order to better define terms, we are taken down the rabbit hole of "what's the alternative..." Gen-ART more or less suggests it. > Perhaps in this particular case a sentence or two in the introduction > would not be too much of a distraction, but if this does not > significantly aid the clarity of the definition of opportunistic > security at the bottom of section 2, maybe defining legacy practice > is best done in another draft? > > More than anything else I want it to be clear that opportunistic > security is not limited to just unauthenticated encryption. ( Just to digress on that. The requirement of unauthenticated encryption came from somewhere. It wasn't conjured out of thin air, there exists a process that concludes "and we must authenticate." It was that idea I was trying to capture with "model security" [0]. ) ... Combining words above and the Gen-ART review into the draft: Abstract This memo defines the term "opportunistic security". In contrast to the established *high bar approach of strongly protecting some of the time*, opportunistic security strives to deliver at least some protection most of the time. The primary goal is therefore broad interoperability, with security policy tailored to the capabilities of peer systems. .... 1. Introduction Historically, Internet security protocols have set a high bar for security of communicating peers, often based on a shared understanding of what threats were important [1]. Setting a high bar created an insistence on failure for those peers which were not capable and motivated to absorb the associated costs. This insistence on failure elicited many responses from users to work around the problem (accept bad certificates, suppress certificate checking, use totally unsecured means, etc), resulted in many peers abandoning security altogether, and ultimately facilitated nation-state pervasive monitoring ([RFC7258]). In contrast to the high bar approach, an OS implementation can accept unvalidated credentials, weak credentials or even no credentials and still deliver a secured communication that delivers resilience against a passive attacker. Protecting most traffic against passive attacks would render nation state pervasive monitoring non-cost-effective. Indiscriminate collection of communications traffic would be substantially less attractive if security protocols were designed to operate at a range of protection levels with encrypted transmission accessible to most if not all peers, and stronger security still available where required by policy or opportunistically negotiated. .... Just some words hacked in to the existing text, I'm sure others can do better. iang [0] http://www.ietf.org/mail-archive/web/saag/current/msg05194.html [1] one of the RFCs that Steve Farrell pointed to described the ITM or Internet Threat Model, being a shared understanding that included the requirement to authenticate. Whether it is worth referencing or even commenting on the notion of a shared threat model, I don't know. From nobody Wed Jul 30 08:08: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 BFA271A01D0; Wed, 30 Jul 2014 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o4KIPAqRYlU; Wed, 30 Jul 2014 08:08:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6F91A01AF; Wed, 30 Jul 2014 08:08:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 62BE92AB0A8; Wed, 30 Jul 2014 15:08:19 +0000 (UTC) Date: Wed, 30 Jul 2014 15:08:19 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140730150819.GA15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D6C902.50200@iang.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5w3umklY1SSXgCULMWP2_IJUAho Cc: ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:08:24 -0000 On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote: > Having re-read the responses I think the term that comes closest is > "all-or-nothing". But even that doesn't seem to capture all of it, > because "all" isn't what they achieve, they are quite conscious of > ignoring certain threats such as tracking or DOS. > > Perhaps "high bar" security or "fixed bar" security? The flaw with much > work in the past is that the bar was set high, and those who failed to > leap it where knocked back. So they walked around. I like "all or nothing", "all" here is sensibly read as "everything implemented", not "everything possible". Thus simply a binary choice. However, in trying to work this into the text I am finding that it becomes more verbose, and spends too much time on inessential details. Perhaps this is just failure to craft the right text on my part, but I am having a hard time actually improving the text overall, even though "all or nothing" is perhaps better than "strong". There is a tension here between a quick informal description of existing practice, that should be clear to most, with a clear focus on the new model, and a more accurate/detailed description of past practice, that might detract from the focus of the document. Is anyone willing to take the time to carefully update the Introduction to find the sweet spot between the current cursory nod to the past on one extreme, and potentially an overly elaborute detour on the other? I tried a couple of times, but have not yet succeeded. Writers block and shortage of cycles perhaps... I think that if we change nothing, though the document could likely be improved, that the improvements are inessential. Perhaps we can leave well enough alone? -- Viktor. From nobody Wed Jul 30 08:43: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 9E12F1A00E9 for ; Wed, 30 Jul 2014 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpDci_zbz_xY for ; Wed, 30 Jul 2014 08:43:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EBB1A005C for ; Wed, 30 Jul 2014 08:43:50 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50150) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCW2s-0006I3-UX for saag@ietf.org; Wed, 30 Jul 2014 11:44:03 -0400 Message-ID: <53D912B6.8040906@bbn.com> Date: Wed, 30 Jul 2014 11:43:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> In-Reply-To: <20140727192353.GT15044@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/7Z4D9OIPjE-SXxBlFYTGI0-Jm7U Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:43:51 -0000 The phrase "complete protection" is misleading, and, as Viktor, notes, not established terminoogy. Some protocols (e.g., ESP) offer optional TFS measures, most don't. So a protocol that doesn't offer any TFS is incomplete, even though it may require mutual authentication. Steve From nobody Wed Jul 30 08:54: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 56CDE1A01AF; Wed, 30 Jul 2014 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNCLKlu_GI3B; Wed, 30 Jul 2014 08:54:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8091C1A0048; Wed, 30 Jul 2014 08:54:22 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50157) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCWD4-0006Mh-SY; Wed, 30 Jul 2014 11:54:34 -0400 Message-ID: <53D9152D.80903@bbn.com> Date: Wed, 30 Jul 2014 11:54:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> In-Reply-To: <53D2D7F6.7080306@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JN2A_wMGJDkSaNK-3Wy8vHQXMXU Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:54:27 -0000 Dave, > On 7/8/2014 11:09 AM, The IESG wrote: >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Opportunistic Security: some protection most of the time' >> as Informational RFC > ... >> Abstract >> >> This memo defines the term "opportunistic security". In contrast to > > This document will be important. Overall, it is a reasonable discussion > of a timely and useful construct. It's basic organization and basic > writing are reasonable, although it does need additional and diligent > wordsmithing. (I will send those suggestions to the author separately.) > > However the document is not yet ready for publication. It suffers a > number of significant deficiencies that need to be remedied. I believe > all of these have been cited by others, but here are my characterizations: > > > 1. In a technical context the word 'security' is, at most, an > umbrella term that encompasses a range of possible capabilities, such as > integrity, authentication, encryption and so on. By itself, the word > has no technical meaning, other than as a reference to an "area" of > technical work. since we're trying to be precise, those are called "security services." > Consequently the term "opportunistic security" falls somewhere > near the intersection of meaningless, confusing and wrong. We do not > serve technical or non-technical communities well by using terminology > that is so vague or misleading (or both.) I believe most folks now agree that it's a marketing term, and thus suffers from the shortcomings you note. > > The actual focus of the draft is encryption and -- unless I've > significantly misread the draft -- the term that covers what is > discussed therefore should be "opportunistic encryption". My doc, which pre-fdated this one, provides an extensive explanation for why the term "opportunistic encryption" is not technically appropriate. > I believe at least one other note did raise the possibility that > the term might /also/ include authentication -- distinct from > encryption. While that's a reasonable idea on its own, it does not > appear to be consonant with any of the discussion around opportunistic > encryption. So I suggest it be deferred. > > The topic of this draft needs to be changed to "opportunistic > encryption". preferably not. > 2. The document says it is providing a definition, but it does not > do that. It needs to. agreed, and I offered one a few weeks ago. > What it does do is to provide an extended discussion of the > topic. The discussion is useful, but it is not a definition. agreed. > Viktor has commented on this concern with: > > > The definition is a summary of the design principles. > > This is the second major security-related document to assert such > a philosophy for a denotation exercise. However a definition is a few > sentences; it is not multiple pages. When the text gets into multiple > pages, it is a specification or a discussion. It is not a definition. I concur and agree that a real definition is needed. > Fortunately, the draft provides some text that looks like a good > basis for a definition, which I've mildly reworked into: > > Opportunity encryption is an umbrellas term for efforts > to increase the use of encryption by permitting variable > protection strength during a session. It attempts to use > the strongest capability possible, but permits falling back > to a weaker option. In particular it permits the use of > unauthenticated encryption when authentication is not > available. > > The phrasing "variable protection strength during a session" probably > needs improvement... agreed. > 3. The draft variously permits or prohibits use of cleartext within > the context of the defined term. This needs to be resolved, and carefully. I would say: "OS strives to greatly broaden the use of encryption in IETF protocols, to combat PM. To facilitate incremental deployment, OS operates in a fashion that may result in a plaintext connection/session." > ... > > > 4. The draft's references to authentication are almost certainly > meant to be limited to server-side authentication. That is, the > authentication that is attempted is of the side being contacted. As I > understand actual Internet practices, mutual or client authentication is > typically NOT part of the process when setting up authenticated > encryption. This needs to be clarified in the text. Typically true for TLS; not true for IPsec, not true for SSH, ... > 5. The document uses the term 'strong' as a form of protection, but > doesn't really define it. However it seems to be used with some > significant meaning intended. The term gets used frequently an casually > about security, but here it seems to be intended to have a specific > meaning. That meaning should be provided explicitly. agreed. From nobody Wed Jul 30 10:22: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 E26551A02F3; Wed, 30 Jul 2014 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwlGEr0oiT7F; Wed, 30 Jul 2014 10:22:30 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1651A032C; Wed, 30 Jul 2014 10:22:25 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so1511524wgh.1 for ; Wed, 30 Jul 2014 10:22:23 -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=vE/tQqWhbk40ZqnQBg4mgwKuekdA0iKXyIyKZWzpQY0=; b=OsZRYbFf83nLUAF6Xgu3wH1V8sCAdoGxJJOi/hlO8MSpI07ARso+T4SqfreuOfwvqO 424LnSUhe5WrioLPRKyxXssEB8YYiX3ceQUgGVdGPUuE0v697qaoUKE2M5iDXF4CS/Ir DCCzTHmXObEsUeTLLEiDfgvkT6bbH1ThgwO/70FVOTx8xlp9e6zULFmrbQulBGSkB5rc CXm6eG3s1+zM6M38TzhG2m1gMxHmRLevC+J5IKUoBqfH+MOObpTOPqhr2jonLrzvV54B 0IUojYJLngVyY5B5El6XSKDG/iSAgPDi+iLWBGLY4thwEZuIiePdv1s9RzBZu6zC38gB Y4WA== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr8240484wjb.59.1406740942416; Wed, 30 Jul 2014 10:22:22 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 10:22:22 -0700 (PDT) In-Reply-To: <53D9152D.80903@bbn.com> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> Date: Wed, 30 Jul 2014 10:22:22 -0700 Message-ID: From: Martin Thomson To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-Q_mTp7XfuoL8c9CmRGhpgvobsw Cc: "ietf@ietf.org" , saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:22:33 -0000 On 30 July 2014 08:54, Stephen Kent wrote: > I would say: > "OS strives to greatly broaden the use of encryption in IETF protocols, > to combat PM. To facilitate incremental deployment, OS operates in > a fashion that may result in a plaintext connection/session." That's a good description of OE, but wasn't the whole point of using OS as the term to cover other opportunistic mechanisms, like maybe opportunistic authentication (which I just invented, but I hope is self-explanatory). From nobody Wed Jul 30 10:31: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 C92CE1A032D; Wed, 30 Jul 2014 10:31:18 -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 KqaGTom2pdIm; Wed, 30 Jul 2014 10:31:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C6E1A0323; Wed, 30 Jul 2014 10:31:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 236332AB2B9; Wed, 30 Jul 2014 17:31:15 +0000 (UTC) Date: Wed, 30 Jul 2014 17:31:15 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag Message-ID: <20140730173114.GB15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D9152D.80903@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/B75YOjJDx4GVbJLRsG7_WCH7YVo Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC 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, 30 Jul 2014 17:31:19 -0000 On Wed, Jul 30, 2014 at 11:54:21AM -0400, Stephen Kent wrote: > > 3. The draft variously permits or prohibits use of cleartext within > > the context of the defined term. This needs to be resolved, and carefully. > > I would say: > > "OS strives to greatly broaden the use of encryption in IETF protocols, > to combat PM. To facilitate incremental deployment, OS operates in > a fashion that may result in a plaintext connection/session." This is I think addressed by the "Encrypt by default" principle, but perhaps the below change helps to get the point across: diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security index a708120..f957e25 100644 --- a/draft-dukhovni-opportunistic-security +++ b/draft-dukhovni-opportunistic-security @@ -128,7 +128,10 @@ An opportunistic security protocol MUST interoperably achieve at least unauthenticated encryption between peer systems that don't explicitly disable this - capability. Over time, as peer software is updated to support + capability. To facilitate incremental deployment, opportunistic + security protocols may tolerate cleartext connections or sessions + with peers that don't support + encryption. Over time, as peer software is updated to support opportunistic security, only legacy systems or a minority of systems where encryption is disabled should be communicating in cleartext. Whenever possible, opportunistic security should employ I am careful to avoid suggesting that there is a single protocol called "opportunistic security", umbrella (marketing) term and all that... So I used the phrase "opportunistic security protocols", which is already used elsewhere in the document. -- Viktor. From nobody Wed Jul 30 10:38: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 D89761A0271; Wed, 30 Jul 2014 10:38:10 -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 Om_AN06SQOJ7; Wed, 30 Jul 2014 10:38:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4601A01C5; Wed, 30 Jul 2014 10:38:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 91A262AB2B9; Wed, 30 Jul 2014 17:38:08 +0000 (UTC) Date: Wed, 30 Jul 2014 17:38:08 +0000 From: Viktor Dukhovni To: saag@ietf.org, "ietf@ietf.org" Message-ID: <20140730173808.GC15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/x1HkJStzt_VgqbWRGrl5AqWLi-g Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC 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, 30 Jul 2014 17:38:11 -0000 On Wed, Jul 30, 2014 at 10:22:22AM -0700, Martin Thomson wrote: > On 30 July 2014 08:54, Stephen Kent wrote: > > I would say: > > "OS strives to greatly broaden the use of encryption in IETF protocols, > > to combat PM. To facilitate incremental deployment, OS operates in > > a fashion that may result in a plaintext connection/session." > > That's a good description of OE, but wasn't the whole point of using > OS as the term to cover other opportunistic mechanisms, like maybe > opportunistic authentication (which I just invented, but I hope is > self-explanatory). Since opportunistic security subsumes opportunistic unauthenticated encryption (where applicable), the proposed text is technically sound. What remains to determine is to what extent the point is already covered, and the exact language or location in the document to update. Yes, opportunistic security also subsumes designs with "opportunistic authentication", such as proposed in the DANE SMTP draft, which specifies "opportunistic DANE TLS" for SMTP. I hope that other OS protocols will indeed find a way to do "opportunistic authentication" whenever possible and not just be limited to unauthenticated encryption. OS is a "golf umbrella" term... :-) -- Viktor. From nobody Wed Jul 30 13:15: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 382B01A0339; Wed, 30 Jul 2014 13:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtm7mAp7zTUS; Wed, 30 Jul 2014 13:15:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875CA1A032C; Wed, 30 Jul 2014 13:15:48 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50828) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCaI4-0008ud-AB; Wed, 30 Jul 2014 16:16:00 -0400 Message-ID: <53D95273.5020505@bbn.com> Date: Wed, 30 Jul 2014 16:15:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@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/9_4xgZFcPm788cnShYMIdZuz6h0 Cc: "ietf@ietf.org" , saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:15:50 -0000 Martin, > On 30 July 2014 08:54, Stephen Kent wrote: >> I would say: >> "OS strives to greatly broaden the use of encryption in IETF protocols, >> to combat PM. To facilitate incremental deployment, OS operates in >> a fashion that may result in a plaintext connection/session." > That's a good description of OE, but wasn't the whole point of using > OS as the term to cover other opportunistic mechanisms, like maybe > opportunistic authentication (which I just invented, but I hope is > self-explanatory). I don't think so. Steve From nobody Wed Jul 30 19:08: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 40D871A03BA; Wed, 30 Jul 2014 19:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 lv52iZEDc_8Y; Wed, 30 Jul 2014 19:08:52 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25A51A03AC; Wed, 30 Jul 2014 19:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id B49D1E108; Wed, 30 Jul 2014 22:08:38 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqAltwqJCNqw; Wed, 30 Jul 2014 22:08:37 -0400 (EDT) Received: from [192.168.3.137] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 0651CE104; Wed, 30 Jul 2014 22:08:36 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3ABCDB9B-91A6-499D-B94C-24EEFE8D8E43" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <53D95273.5020505@bbn.com> Date: Wed, 30 Jul 2014 19:08:25 -0700 Message-Id: <951AB5C2-6A18-4090-BAE9-94A94E051AC1@oxy.edu> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> <53D95273.5020505@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/z9mgaeHBYTrFfapSBGWA8hFD3DY Cc: "ietf@ietf.org" , saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 02:08:54 -0000 --Apple-Mail=_3ABCDB9B-91A6-499D-B94C-24EEFE8D8E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2014, at 1:15 PM, Stephen Kent wrote: > Martin, >> On 30 July 2014 08:54, Stephen Kent wrote: >>> I would say: >>> "OS strives to greatly broaden the use of encryption in IETF = protocols, >>> to combat PM. To facilitate incremental deployment, OS operates in >>> a fashion that may result in a plaintext connection/session." >>=20 >> That's a good description of OE, but wasn't the whole point of using >> OS as the term to cover other opportunistic mechanisms, like maybe >> opportunistic authentication (which I just invented, but I hope is >> self-explanatory). >=20 > I don't think so. Perhaps not, but it sounds a bit too binary for my taste. Without = proposing an alternative (sorry!) I'd want it clearer that there may be = an increasing number of multiple interoperable modes and a session = should use the "best" one that can be agreed on. As others have pointed out "best" may be ill-defined and you might need = to trade e.g. better authentication against better encryption. I'm = perfectly happy to leave the value function undefined, and I think we = should be able to make the general principle clear. Personal email. hbhotz@oxy.edu --Apple-Mail=_3ABCDB9B-91A6-499D-B94C-24EEFE8D8E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii kent@bbn.com> wrote:
Martin,
On 30 July 2014 = 08:54, Stephen Kent <kent@bbn.com> wrote:
I would say:
"OS strives to greatly broaden the use of = encryption in IETF protocols,
to combat PM. To facilitate incremental = deployment, OS operates in
a fashion that may result in a plaintext = connection/session."

That's a good description of OE, = but wasn't the whole point of using
OS as the term to cover other = opportunistic mechanisms, like maybe
opportunistic authentication = (which I just invented, but I hope = is
self-explanatory).

I don't think = so.

Perhaps not, but it sounds a bit too = binary for my taste. Without proposing an alternative (sorry!) I'd want = it clearer that there may be an increasing number of multiple = interoperable modes and a session should use the "best" one that can be = agreed on.

As others have pointed out "best" = may be ill-defined and you might need to trade e.g. better = authentication against better encryption. I'm perfectly happy to leave = the value function undefined, and I think we should be able to make the = general principle clear.

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_3ABCDB9B-91A6-499D-B94C-24EEFE8D8E43-- From nobody Wed Jul 30 21:15: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 7B8471A0123; Wed, 30 Jul 2014 21:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbv99yhXi9qi; Wed, 30 Jul 2014 21:15:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74AF1A00EF; Wed, 30 Jul 2014 21:15:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D39312AB0CD; Thu, 31 Jul 2014 04:15:37 +0000 (UTC) Date: Thu, 31 Jul 2014 04:15:37 +0000 From: Viktor Dukhovni To: "ietf@ietf.org" , saag Message-ID: <20140731041537.GL15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D95273.5020505@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rlTHAVOD6D0ptRVUM3IH8YU9rM0 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 04:15:42 -0000 On Wed, Jul 30, 2014 at 10:22:22AM -0700, Martin Thomson wrote: > On 30 July 2014 08:54, Stephen Kent wrote: > > > I would say: > > "OS strives to greatly broaden the use of encryption in IETF protocols, > > to combat PM. To facilitate incremental deployment, OS operates in > > a fashion that may result in a plaintext connection/session." > > That's a good description of OE, but wasn't the whole point of using > OS as the term to cover other opportunistic mechanisms, like maybe > opportunistic authentication (which I just invented, but I hope is > self-explanatory). On Wed, Jul 30, 2014 at 04:15:47PM -0400, Stephen Kent wrote: > I don't think so. I am not sure what the "I don't think so" refers to. If it is a response to the question of whether the term "OS" was chosen specifically to be more open-ended, then it depends on whom you ask. On the one hand a key constraint was to avoid using "OE" which was already taken, so one might narrowly say that this is the reason for the choice. On the other hand, as the person who advocated most strongly for this choice I did in fact have in mind a definition that is more open-ended than than mere encryption when possible. And that more open-ended view is a key feature of the resulting draft. -- Viktor. From nobody Thu Jul 31 01:39: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 84A151A04C5 for ; Thu, 31 Jul 2014 01:38:58 -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 iTCuEc_nUFNT for ; Thu, 31 Jul 2014 01:38:49 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2B61A0496 for ; Thu, 31 Jul 2014 01:38:47 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D21AE6D797; Thu, 31 Jul 2014 04:38:42 -0400 (EDT) Message-ID: <53DA0091.1000005@iang.org> Date: Thu, 31 Jul 2014 09:38:41 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> In-Reply-To: <20140730150819.GA15044@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/Q-AUphcyASEEO3PvuE5u2Bv7QA0 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 08:38:58 -0000 On 30/07/2014 16:08 pm, Viktor Dukhovni wrote: > On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote: > >> Having re-read the responses I think the term that comes closest is >> "all-or-nothing". But even that doesn't seem to capture all of it, >> because "all" isn't what they achieve, they are quite conscious of >> ignoring certain threats such as tracking or DOS. >> >> Perhaps "high bar" security or "fixed bar" security? The flaw with much >> work in the past is that the bar was set high, and those who failed to >> leap it where knocked back. So they walked around. > > I like "all or nothing", "all" here is sensibly read as "everything > implemented", not "everything possible". Thus simply a binary choice. How about "minimum standard" ? That is, the previous design approach set a minimum standard, below which communication was rejected. "Minimum standard" also has the benefits of being a widely established term, and less emotionally charged than others. > However, in trying to work this into the text I am finding that it > becomes more verbose, and spends too much time on inessential > details. Perhaps this is just failure to craft the right text on > my part, but I am having a hard time actually improving the text > overall, even though "all or nothing" is perhaps better than "strong". > > There is a tension here between a quick informal description of existing > practice, that should be clear to most, with a clear focus on the new > model, and a more accurate/detailed description of past practice, that > might detract from the focus of the document. Yes, noted, definitely so. Taking "minimum standard" for a road test: Introduction - Historically, Internet security protocols have prioritized strong - protection for peers capable and motivated to absorb the associated - costs. Since strong protection is not universally applicable, while - communications traffic was sometimes strongly secured, more typically - it was not protected at all. + Historically, Internet security protocols have set a minimum + standard of strong protection for peers capable and motivated + to absorb the associated costs. + While some communications traffic met the minimum standard and + was strongly protected, more typically the standard was not + met and traffic was not protected at all. The fact that most traffic is unprotected facilitates nation-state pervasive monitoring (PM [RFC7258]) by making it cost-effective (or at least not cost- prohibitive). Indiscriminate collection of communications traffic would be substantially less attractive if security protocols were designed to operate at a range of protection levels with encrypted transmission accessible to most if not all peers, and stronger security still available where required by policy or opportunistically negotiated. > Is anyone willing to take the time to carefully update the Introduction > to find the sweet spot between the current cursory nod to the past on > one extreme, and potentially an overly elaborute detour on the other? > > I tried a couple of times, but have not yet succeeded. Writers > block and shortage of cycles perhaps... I have also tried, without success. > I think that if we change nothing, though the document could likely > be improved, that the improvements are inessential. Perhaps we > can leave well enough alone? (The only reason I tinker here is because I saw the Art-Gen critique. It makes a fair point that the definition is not as satisfying as hoped for. I guess that doesn't matter if the draft can be pushed through that political process.) iang From nobody Thu Jul 31 08:24: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 E3A4B1A0AB2; Thu, 31 Jul 2014 04:40:19 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv8SAMy4o4oV; Thu, 31 Jul 2014 04:40:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00B91A0AAD; Thu, 31 Jul 2014 04:40:16 -0700 (PDT) Received: from pc6 (86.140.229.189) by DB4PR07MB251.eurprd07.prod.outlook.com (10.242.231.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 11:40:09 +0000 Message-ID: <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> From: t.p. To: , References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> Date: Thu, 31 Jul 2014 12:32:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.140.229.189] X-ClientProxiedBy: DB4PR05CA0033.eurprd05.prod.outlook.com (25.160.40.43) To DB4PR07MB251.eurprd07.prod.outlook.com (10.242.231.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0289B6431E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(24454002)(51704005)(189002)(199002)(81686999)(76482001)(23756003)(62966002)(105586002)(77096002)(33646002)(77982001)(46102001)(85306003)(14496001)(79102001)(95666004)(20776003)(81816999)(93886003)(76176999)(44736004)(106356001)(83322001)(4396001)(84392001)(83072002)(87286001)(62236002)(50466002)(42186005)(64706001)(81542001)(61296003)(81342001)(19580405001)(19580395003)(50226001)(74502001)(89996001)(47776003)(74662001)(104166001)(77156001)(88136002)(92726001)(50986999)(107046002)(87976001)(102836001)(101416001)(80022001)(93916002)(31966008)(85852003)(66066001)(21056001)(44716002)(92566001)(86362001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR07MB251; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QUTPrN9JqEbHHKwF243S4fHAYEM X-Mailman-Approved-At: Thu, 31 Jul 2014 08:23:57 -0700 Cc: ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 11:40:20 -0000 ----- Original Message ----- From: "Viktor Dukhovni" To: Cc: Sent: Wednesday, July 30, 2014 4:08 P > On Mon, Jul 28, 2014 at 11:04:50PM +0100, ianG wrote: > I like "all or nothing", "all" here is sensibly read as "everything > implemented", not "everything possible". Thus simply a binary choice. > > However, in trying to work this into the text I am finding that it > becomes more verbose, and spends too much time on inessential > details. Perhaps this is just failure to craft the right text on > my part, but I am having a hard time actually improving the text > overall, even though "all or nothing" is perhaps better than "strong". > > There is a tension here between a quick informal description of existing > practice, that should be clear to most, with a clear focus on the new > model, and a more accurate/detailed description of past practice, that > might detract from the focus of the document. > > Is anyone willing to take the time to carefully update the Introduction > to find the sweet spot between the current cursory nod to the past on > one extreme, and potentially an overly elaborute detour on the other? > > I tried a couple of times, but have not yet succeeded. Writers > block and shortage of cycles perhaps... How about " Opportunistic security encourages peers to employ as much security as possible, without falling back to unnecessarily weak options. In particular, opportunistic security encourages unauthenticated encryption when authentication is not possible. Without key management at an Internet scale, authentication is often not possible. When, as a result, protocols only offer the options of either strongly authenticated secure channels, or else no security, traffic commonly gets no security. Therefore, in order to make encryption more ubiquitous, authentication needs to be optional. When strongly authenticated communication is not possible, unauthenticated encryption is preferable to clear text. Historically, Internet security protocols have prioritized strong protection, for peers capable and motivated to absorb the associated costs and this has lead to most traffic being unprotected. The fact that most traffic is then unprotected facilitates pervasive monitoring (PM [RFC7258]) by nation states, by making such practices cost-effective (or, at least, not cost- prohibitive). Such indiscriminate [widespread?] collection of communications traffic would be substantially less attractive to nation states if security protocols offered a range of protection levels, offering encrypted transmission to most, if not all, peers and offering stronger security when required by policy or by opportunistic negotiation. Encryption remains easy, key management is difficult. Key management at Internet scale is an incompletely solved problem. The PKIX ([RFC5280]) key management model introduces costs that not all peers are willing to bear and also cannot secure communications when either the reference identity of the peer is obtained indirectly over an insecure channel or the communicating parties cannot agree on a [root?] certification authority (CA). Thus DNSSEC is not at this time sufficiently widely adopted to make DANE a viable alternative at scale, while trust on first use (TOFU) key management models (such as with saved SSH fingerprints and various certificate pinning approaches) fail to protect initial contact; and, also, require user intervention when there is a failure of key continuity. " I think that the paragraph order is key! Currently it is deductive, fine for academic texts, less so for RFC, hence my switch to inductive. Tom Petch > > I think that if we change nothing, though the document could likely > be improved, that the improvements are inessential. Perhaps we > can leave well enough alone? > > -- > Viktor. > > From nobody Thu Jul 31 08:43: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 D700C1A0208 for ; Thu, 31 Jul 2014 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZDTFFwrdGx2 for ; Thu, 31 Jul 2014 08:43:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294EA1A00D5 for ; Thu, 31 Jul 2014 08:43:40 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51290) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCsW3-0007wS-7d for saag@ietf.org; Thu, 31 Jul 2014 11:43:39 -0400 Message-ID: <53DA642B.8050608@bbn.com> Date: Thu, 31 Jul 2014 11:43:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> <53D95273.5020505@bbn.com> <951AB5C2-6A18-4090-BAE9-94A94E051AC1@oxy.edu> In-Reply-To: <951AB5C2-6A18-4090-BAE9-94A94E051AC1@oxy.edu> Content-Type: multipart/alternative; boundary="------------080007020705070706040707" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8vQrIONvphn_dUvRchIIR1r6f5s Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:43:42 -0000 This is a multi-part message in MIME format. --------------080007020705070706040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Henry, > ... > Perhaps not, but it sounds a bit too binary for my taste. Without > proposing an alternative (sorry!) I'd want it clearer that there may > be an increasing number of multiple interoperable modes and a session > should use the "best" one that can be agreed on. Perhaps my very brief response was too terse. My point is that the motivation for the doc that I wrote, and the subsequent doc that Viktor has written, is encouraging development of protocols that remove barriers to widespread use of encryption, as an anti-PM measure. If authentication, integrity, or any other service is provided, it's gravy. Thus I think it's a distraction to focus on these other security services, when confidentiality is the primary driver for this work. > As others have pointed out "best" may be ill-defined and you might > need to trade e.g. better authentication against better encryption. > I'm perfectly happy to leave the value function undefined, and I think > we should be able to make the general principle clear. I'm not in complete agreement with Viktor on this point (i.e., doing the best we can wrt a broad set of security services). As I said above, lets' not confuse the message we're trying to send to a very broad audience. Steve --------------080007020705070706040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry,

...
Perhaps not, but it sounds a bit too binary for my taste. Without proposing an alternative (sorry!) I'd want it clearer that there may be an increasing number of multiple interoperable modes and a session should use the "best" one that can be agreed on.
Perhaps my very brief response was too terse.

My point is that the motivation for the doc that I wrote, and the subsequent doc that
Viktor has written, is encouraging development of protocols that remove barriers to
widespread use of encryption, as an anti-PM measure. If authentication, integrity, or any
other service is provided, it's gravy. Thus I think it's a distraction to focus on these
other security services, when confidentiality is the primary driver for this work.
As others have pointed out "best" may be ill-defined and you might need to trade e.g. better authentication against better encryption. I'm perfectly happy to leave the value function undefined, and I think we should be able to make the general principle clear.
I'm not in complete agreement with Viktor on this point (i.e., doing the best we can wrt
a broad set of security services). As I said above, lets' not confuse the message we're
trying to send to a very broad audience.

Steve
--------------080007020705070706040707-- From nobody Thu Jul 31 08:57: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 376501A0127 for ; Thu, 31 Jul 2014 08:57:49 -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 3wJigROois5C for ; Thu, 31 Jul 2014 08:57:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123881A00B5 for ; Thu, 31 Jul 2014 08:57:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 339BD2AB2B6; Thu, 31 Jul 2014 15:57:45 +0000 (UTC) Date: Thu, 31 Jul 2014 15:57:45 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140731155744.GO15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> <53D95273.5020505@bbn.com> <951AB5C2-6A18-4090-BAE9-94A94E051AC1@oxy.edu> <53DA642B.8050608@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53DA642B.8050608@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tdJUAeBPhyH7pCFbfD_bQnSUdPE Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC 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, 31 Jul 2014 15:57:49 -0000 On Thu, Jul 31, 2014 at 11:43:39AM -0400, Stephen Kent wrote: > My point is that the motivation for the doc that I wrote, and the subsequent > doc that Viktor has written, is encouraging development of protocols that > remove barriers to widespread use of encryption, as an anti-PM measure. > If authentication, integrity, or any other service is provided, it's gravy. > Thus I think it's a distraction to focus on these other security services, > when confidentiality is the primary driver for this work. I agree that we want to promote widespread use of encryption. I don't agree that leaving it at that is the right long-term objective. We want *at least* counter-measures to pervasive monitoring, but that's just a beginning. That said, I believe the draft under discussion is careful to not get bogged down in detailed discussion of what additional security might entail. Rather it is careful to leave the door open to more security, and encourages protocol designers to consider stronger options. > I'm not in complete agreement with Viktor on this point (i.e., doing the > best we can wrt a broad set of security services). As I said above, lets' > not confuse the message we're trying to send to a very broad audience. Well the message is don't resort cleartext just because you've failed to reach some fixed high bar, find the "strongest" interoperable security level, which may often be unauthenticated encryption, but ideally is more than that. So yes we disagree on the subleties of the emphasis. I want to promote widespread encryption, without limiting the resulting security, by explicitly allowing for and encouraging additional security services where applicable between suitably capable peers. The key different from the current fixed high bar, is that now the bar is set individually for each peer. -- Viktor.