From nobody Fri Aug 5 10:07:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156512D783 for ; Fri, 5 Aug 2016 10:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9bsKvys5opS for ; Fri, 5 Aug 2016 10:07:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E68B12D67E for ; Fri, 5 Aug 2016 10:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BB5A3BE58 for ; Fri, 5 Aug 2016 18:07:21 +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 2QK3mbTlEQl3 for ; Fri, 5 Aug 2016 18:07:21 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3438DBE56 for ; Fri, 5 Aug 2016 18:07:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470416841; bh=bTNCG+XYSPeuITl2M95+Ycr8tYvE9Fz84EK51fqLUzQ=; h=To:From:Subject:Date:From; b=gPb2TOWN8TNCYMj4s5ghbX0FwDkttItCybQt91t3DKe2loaqycE2zxfVh23VPiLb5 R7dBfgzMCFdxmWfix88xij5CWLm3gHokyqcwIophMTP+Vv6FZm1jLqgJhcRRnkimRo i9CnRDK+wtuZ493OYytkV2gTy7nM6d+w4MMRAgjw= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> Date: Fri, 5 Aug 2016 18:07:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080802090606040905020906" Archived-At: Subject: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 17:07:29 -0000 This is a cryptographically signed message in MIME format. --------------ms080802090606040905020906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, I've just asked to start IETF last call for drafts that document pkcs#5 [1] and pkcs#1. [2] The main purpose of these drafts is to hand change control to the IETF, as we've recently done with other pkcs series documents. (That's a good thing, and thanks to those who've made the not-inconsiderable effort to make it happen.) For pkcs#5 I think there are only nits to consider but I do have a question to ask wrt the pkcs#1 draft. [2] Please send responses here or in response to the last call on ietf@ietf.org, which should pop out shortly. If you look at the diff [3] between this draft and RFC 2437, there are substantial differences, including to some data structures, the older versions of which may be in widespread use, e.g., RSAPrivateKey is extended in a way that I think could lead to interop issues in [2]. So my question is: what's the right way to handle getting pkcs#1 under IETF change control without breaking anything? Should we for example, not formally OBSOLETE RFC2347 perhaps, or should we ask to add some statement to [2] that explains that even though this is newer, it's the older version that's widely implemented. Bear in mind that we are in any case trying to move entirely away from pkcs#1v1.5 so this shouldn't be too much of an issue for future RFCs, which are likely to just use pkcs#1v.5 as-is (if that's needed due to legacy h/w) or to use something else entirely, e.g. based on the cfrg curves. So, that's a bit long winded, but please take a look, in particular at [2] and [3] and say what you think we should be doing here. Thanks, S. PS: Please note that it's taken the folks doing this work quite a bit of effort, e.g. dealing with their legal folks to get permission to move change control to the IETF, so we should really try to avoid imposing more work (and delay) on those folks if we can. IOW, minimal change here is really good, and if the IETF wants to and has the energy, we can modify whatever we like after this transition has happened. [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ [2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/ [3] https://tools.ietf.org/rfcdiff?url1=3Drfc2437&url2=3Ddraft-moriarty-pkcs1= -01.txt --------------ms080802090606040905020906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDUx NzA3MjFaMC8GCSqGSIb3DQEJBDEiBCA6sNy7n9FutVmNC9upk+DzSd7PRO6BRzZPmmMj8DcM kTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCyYx7HOOFM8DGxWKB5WqJrHW8rp7iLb0E+JGWGUlZQeFYSQ40z+CuQ HOcrN3znwUxRErVNcovxSpejMRHJ9+F2MjCfO5KAjBmAs+wBeDC5jmKrVARPmEXSs6ovzuon xsCxodSQzIQ6OKev0GjdOcONA326y8sfGcAB1T40qJeMt56FZ1K6z4Wq6zLAXRfPtusbrgTr JOOSwms1ifc89XIK+TWAYy9kcEdGaqQBQQxTFFj+5IwNl1eh+UY9TrsMwzb5XwIGT6rRXtLR ej6JYpvDrTCRwP27mjullMtTNxdeRtmRx4BtTty/K58dMtPRC601GtGjjvzuomRoBVAfwZdO AAAAAAAA --------------ms080802090606040905020906-- From nobody Fri Aug 5 10:58:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714812D753 for ; Fri, 5 Aug 2016 10:58:11 -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 autolearn_force=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 dy-amWLbSAdj for ; Fri, 5 Aug 2016 10:58:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF6312D0F0 for ; Fri, 5 Aug 2016 10:58:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7BD75300596 for ; Fri, 5 Aug 2016 13:58:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LJOc1AwEItqC for ; Fri, 5 Aug 2016 13:58:05 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id C84B93002B1; Fri, 5 Aug 2016 13:58:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> Date: Fri, 5 Aug 2016 13:58:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SAAG Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 17:58:11 -0000 PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more = than two prime factors. Multi-prime RSA can provide lower computational = cost for the decryption and signature primitives when the CRT (Chinese = Remainder Theorem) is used. Further, one can get better performance in a = multiprocessor environment where the modular exponentiations can be done = in parallel. The big changes in the PKCS#1 v2.2 data structures are to support = multi-prime RSA. I believe that the changes were done in a way that is = backward compatible with the non-multi-prime RSA. Russ On Aug 5, 2016, at 1:07 PM, Stephen Farrell = wrote: > Folks, >=20 > I've just asked to start IETF last call for drafts that > document pkcs#5 [1] and pkcs#1. [2] The main purpose > of these drafts is to hand change control to the IETF, > as we've recently done with other pkcs series documents. > (That's a good thing, and thanks to those who've made > the not-inconsiderable effort to make it happen.) >=20 > For pkcs#5 I think there are only nits to consider but > I do have a question to ask wrt the pkcs#1 draft. [2] >=20 > Please send responses here or in response to the last > call on ietf@ietf.org, which should pop out shortly. >=20 > If you look at the diff [3] between this draft and RFC > 2437, there are substantial differences, including to > some data structures, the older versions of which may be > in widespread use, e.g., RSAPrivateKey is extended in a > way that I think could lead to interop issues in [2]. >=20 > So my question is: what's the right way to handle getting > pkcs#1 under IETF change control without breaking anything? >=20 > Should we for example, not formally OBSOLETE RFC2347 perhaps, > or should we ask to add some statement to [2] that explains > that even though this is newer, it's the older version that's > widely implemented. >=20 > Bear in mind that we are in any case trying to move entirely > away from pkcs#1v1.5 so this shouldn't be too much of an issue > for future RFCs, which are likely to just use pkcs#1v.5 as-is > (if that's needed due to legacy h/w) or to use something else > entirely, e.g. based on the cfrg curves. >=20 > So, that's a bit long winded, but please take a look, in > particular at [2] and [3] and say what you think we should > be doing here. >=20 > Thanks, > S. >=20 > PS: Please note that it's taken the folks doing this > work quite a bit of effort, e.g. dealing with their > legal folks to get permission to move change control to > the IETF, so we should really try to avoid imposing > more work (and delay) on those folks if we can. IOW, > minimal change here is really good, and if the IETF > wants to and has the energy, we can modify whatever we > like after this transition has happened. >=20 > [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ > [2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/ > [3] = https://tools.ietf.org/rfcdiff?url1=3Drfc2437&url2=3Ddraft-moriarty-pkcs1-= 01.txt From nobody Fri Aug 5 11:28:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1E12D17E for ; Fri, 5 Aug 2016 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBQx09MeKFL6 for ; Fri, 5 Aug 2016 11:28:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B3212B049 for ; Fri, 5 Aug 2016 11:21:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7BA7BE56; Fri, 5 Aug 2016 19:21: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 BV-FS21x2EFU; Fri, 5 Aug 2016 19:21:20 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B75C4BE55; Fri, 5 Aug 2016 19:21:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470421280; bh=8yCvNJXme4OP4xoqgRuaXZ+e2NsnVN4pXmFrMaMqFm8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A+OrZ4U/NO5yEceYFuN7H5TPyyEiLJuhB4RFm2EmyzYlqkjS1EXT0Sdq1krnHRacm 7ATss8C/ZLCWGsZT7vqDB5WvBNckzalvpVBE+fvmmwRrDMoSE5uizMlzuClD9h9K+D /Y3ioaFyt+Wo6gyAAzA6JRyYZICCFout4z3N1RtA= To: Russ Housley References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> Date: Fri, 5 Aug 2016 19:21:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000008090808080007090007" Archived-At: Cc: IETF SAAG Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 18:28:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000008090808080007090007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/08/16 18:58, Russ Housley wrote: > PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more > than two prime factors. Multi-prime RSA can provide lower > computational cost for the decryption and signature primitives when > the CRT (Chinese Remainder Theorem) is used. Further, one can get > better performance in a multiprocessor environment where the modular > exponentiations can be done in parallel. >=20 > The big changes in the PKCS#1 v2.2 data structures are to support > multi-prime RSA. I believe that the changes were done in a way that > is backward compatible with the non-multi-prime RSA. >=20 I agree with the above, except I think for the changes to RSAPrivateKey (at least that's the one I noted). Now that's not a huge deal for interop, but would bite for private key import/export, I don't think old code could ever usefully accept the multi-prime structure, so I think it is an issue there at least. So if we OBSOLETE 2347 then new code is likely to be less interoperable with current code. I think maybe best might be to just not OBSOLETE 2347 for now and then if/when multi-prime is desired (for pkcs#1) we can figure that out then. Cheers, S. > Russ >=20 >=20 > On Aug 5, 2016, at 1:07 PM, Stephen Farrell > wrote: >=20 >> Folks, >>=20 >> I've just asked to start IETF last call for drafts that document >> pkcs#5 [1] and pkcs#1. [2] The main purpose of these drafts is to >> hand change control to the IETF, as we've recently done with other >> pkcs series documents. (That's a good thing, and thanks to those >> who've made the not-inconsiderable effort to make it happen.) >>=20 >> For pkcs#5 I think there are only nits to consider but I do have a >> question to ask wrt the pkcs#1 draft. [2] >>=20 >> Please send responses here or in response to the last call on >> ietf@ietf.org, which should pop out shortly. >>=20 >> If you look at the diff [3] between this draft and RFC 2437, there >> are substantial differences, including to some data structures, the >> older versions of which may be in widespread use, e.g., >> RSAPrivateKey is extended in a way that I think could lead to >> interop issues in [2]. >>=20 >> So my question is: what's the right way to handle getting pkcs#1 >> under IETF change control without breaking anything? >>=20 >> Should we for example, not formally OBSOLETE RFC2347 perhaps, or >> should we ask to add some statement to [2] that explains that even >> though this is newer, it's the older version that's widely >> implemented. >>=20 >> Bear in mind that we are in any case trying to move entirely away >> from pkcs#1v1.5 so this shouldn't be too much of an issue for >> future RFCs, which are likely to just use pkcs#1v.5 as-is (if >> that's needed due to legacy h/w) or to use something else entirely, >> e.g. based on the cfrg curves. >>=20 >> So, that's a bit long winded, but please take a look, in particular >> at [2] and [3] and say what you think we should be doing here. >>=20 >> Thanks, S. >>=20 >> PS: Please note that it's taken the folks doing this work quite a >> bit of effort, e.g. dealing with their legal folks to get >> permission to move change control to the IETF, so we should really >> try to avoid imposing more work (and delay) on those folks if we >> can. IOW, minimal change here is really good, and if the IETF wants >> to and has the energy, we can modify whatever we like after this >> transition has happened. >>=20 >> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/=20 >> [2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/ [3] >> https://tools.ietf.org/rfcdiff?url1=3Drfc2437&url2=3Ddraft-moriarty-pk= cs1-01.txt > >>=20 >=20 --------------ms000008090808080007090007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDUx ODIxMTlaMC8GCSqGSIb3DQEJBDEiBCAwCEFnnxHSfSDuUOGB2++fEuIycZyRXzI4ujIlilzX 1zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBX/dTBjbE3M9ftZyqZGWtfuYl7Kwz1+2z92XyaaX7NrtoPBBkq6JWf 58fpSQaxFhkQnNvtEOIhoEmoJZmaAAxJJ605okMHVKzdvNVFtZLlXc+JhxSqQwiCRoxN4Rj6 UuKeQrm95QXRR79l2ycIQrFhiaSlkynluZaEpu5w6UJYq/20YoMsfb4G+v9KVxSF0QyBBeWp 5CKLqYXJsi6iJzibJ4zDbalcuYfFly7Gs1acPVaUlAPAGUjeIdIJ15ObyMhyWhWNGxRzx5XM oVbiy/H92Oq5WqHIkKKI+Heg4AILW7vc3S/uSIQ0gfKM3jZOkRYct4tSz1RRvXfVbkcVRbfL AAAAAAAA --------------ms000008090808080007090007-- From nobody Sat Aug 6 07:18:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4112D0FA for ; Sat, 6 Aug 2016 07:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 H5MhErP6yqmm for ; Sat, 6 Aug 2016 07:18:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4ADD12D0BA for ; Sat, 6 Aug 2016 07:18:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C56F83005AB for ; Sat, 6 Aug 2016 10:18:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vozUXOgCR90d for ; Sat, 6 Aug 2016 10:18:29 -0400 (EDT) Received: from [192.168.1.28] (nc-71-50-129-15.dyn.embarqhsd.net [71.50.129.15]) by mail.smeinc.net (Postfix) with ESMTPSA id 45C6A3000E0; Sat, 6 Aug 2016 10:18:29 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4EC65B3B-DB17-489A-9F57-0E9ADD8FECAA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> Date: Sat, 6 Aug 2016 10:18:29 -0400 Message-Id: <74677F56-28FC-4F0C-BC6A-9527ABE37A27@vigilsec.com> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SAAG Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 14:18:34 -0000 --Apple-Mail=_4EC65B3B-DB17-489A-9F57-0E9ADD8FECAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 5, 2016, at 2:21 PM, Stephen Farrell = wrote: >=20 >=20 > On 05/08/16 18:58, Russ Housley wrote: >> PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more >> than two prime factors. Multi-prime RSA can provide lower >> computational cost for the decryption and signature primitives when >> the CRT (Chinese Remainder Theorem) is used. Further, one can get >> better performance in a multiprocessor environment where the modular >> exponentiations can be done in parallel. >>=20 >> The big changes in the PKCS#1 v2.2 data structures are to support >> multi-prime RSA. I believe that the changes were done in a way that >> is backward compatible with the non-multi-prime RSA. >>=20 >=20 > I agree with the above, except I think for the changes to = RSAPrivateKey > (at least that's the one I noted). Now that's not a huge deal for > interop, but would bite for private key import/export, I don't think > old code could ever usefully accept the multi-prime structure, so I > think it is an issue there at least. So if we OBSOLETE 2347 then new > code is likely to be less interoperable with current code. >=20 > I think maybe best might be to just not OBSOLETE 2347 for now and then > if/when multi-prime is desired (for pkcs#1) we can figure that out = then. The RSAPrivateKey structure is: RSAPrivateKey ::=3D SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL } If multi-prime RSA is used, then the OPTIONAL otherPrimeInfos is = present. If multi-prime RSA is not used, then the OPTIONAL otherPrimeInfos is = absent. In this way, a private key with two primes can be used by older software = that does not support multi-prime RSA. The text on version warns about = this; version must be 1 if otherPrimeInfos present. =20 Russ --Apple-Mail=_4EC65B3B-DB17-489A-9F57-0E9ADD8FECAA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MDYxNDE4MjlaMCMGCSqGSIb3DQEJBDEWBBSzLKqm1tl+UZe8+KT3UUbVQjL2ujCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQBt90jQHPncdlaaG7JaI0pu7GAh+s5hSVWq2Ly8idJ3+RFT2E5s88WxzPrj8Ulm kbjeqLyokq2yBmLxkftWsBOb051Wg0Kt5hEViTP+Bo/SnNRrN2cd77jcAj6jwcONol6lWRyXUQzp F6pWBXC8AhLmucXEY7BpIJkTocQd38VR/BqwMLsbQXglAs0smTf83vO6ln9b1K+WbFBu2ZpLIyfZ W1BB72FUCb2cYxJMaAp1KhodlT1WUfXalU6/mBVrUkta8uUOze6z7bWcdQLfwHbIbB1zne9dot4+ Y+D49CazJh0iVGbJ0HTKCex7PEbrHJQqzlZuLX0WxdkaBZUA5rHWAAAAAAAA --Apple-Mail=_4EC65B3B-DB17-489A-9F57-0E9ADD8FECAA-- From nobody Sat Aug 6 09:09:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D6012B013 for ; Sat, 6 Aug 2016 09:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 mBv_Q9dHnLiq for ; Sat, 6 Aug 2016 09:09:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8305912B026 for ; Sat, 6 Aug 2016 09:02:12 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 6 Aug 2016 09:14:04 -0700 From: Jim Schaad To: 'Stephen Farrell' , 'Russ Housley' References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> In-Reply-To: <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> Date: Sat, 6 Aug 2016 09:02:06 -0700 Message-ID: <012301d1effb$e2c5d220$a8517660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 thread-index: AQILUV4J8gLHNAIB5MCGWmcXTjonHQG7Sk8oASPywL+fslkMsA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'IETF SAAG' Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 16:09:49 -0000 > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Friday, August 05, 2016 11:21 AM > To: Russ Housley > Cc: IETF SAAG > Subject: Re: [saag] pkcs#1 -> IETF change control >=20 >=20 >=20 > On 05/08/16 18:58, Russ Housley wrote: > > PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have = more > > than two prime factors. Multi-prime RSA can provide lower > > computational cost for the decryption and signature primitives when > > the CRT (Chinese Remainder Theorem) is used. Further, one can get > > better performance in a multiprocessor environment where the modular > > exponentiations can be done in parallel. > > > > The big changes in the PKCS#1 v2.2 data structures are to support > > multi-prime RSA. I believe that the changes were done in a way that > > is backward compatible with the non-multi-prime RSA. > > >=20 > I agree with the above, except I think for the changes to = RSAPrivateKey (at least > that's the one I noted). Now that's not a huge deal for interop, but = would bite > for private key import/export, I don't think old code could ever = usefully accept > the multi-prime structure, so I think it is an issue there at least. = So if we > OBSOLETE 2347 then new code is likely to be less interoperable with = current > code. >=20 > I think maybe best might be to just not OBSOLETE 2347 for now and then > if/when multi-prime is desired (for pkcs#1) we can figure that out = then. I am not sure that I am following your logic. If the old code only supports using two primes, then it will import the = new structure just fine if the new structure only has two primes. If the old code only supports using two primes, then it will fail to = import the new structure if it has three primes. However, even if the = code is fixed to allow for having three primes in the parsed structure = it would fail to import the key because it does not support having three = primes in the code. I don't think that I am worried that old code would fail when trying to = import a three prime RSA private key beause it is going to fail either = doing the ASN.1 parsing of the RSAPrivateKey structure or it is going to = reject it because it does not support doing multiprime RSA. Either way = it has to fail. If we obsolete 2347, then new code will correctly parse the multiprime = structure. But it will possibly still reject the private key because it = does not support multiprime RSA. I don't know how many places implement = multiprime RSA today. And many of those places are probably moving = towards ECDSA or EdDSA anyway. =20 I would say go ahead and obsolete 2347. Jim >=20 > Cheers, > S. >=20 > > Russ > > > > > > On Aug 5, 2016, at 1:07 PM, Stephen Farrell > > wrote: > > > >> Folks, > >> > >> I've just asked to start IETF last call for drafts that document > >> pkcs#5 [1] and pkcs#1. [2] The main purpose of these drafts is to > >> hand change control to the IETF, as we've recently done with other > >> pkcs series documents. (That's a good thing, and thanks to those > >> who've made the not-inconsiderable effort to make it happen.) > >> > >> For pkcs#5 I think there are only nits to consider but I do have a > >> question to ask wrt the pkcs#1 draft. [2] > >> > >> Please send responses here or in response to the last call on > >> ietf@ietf.org, which should pop out shortly. > >> > >> If you look at the diff [3] between this draft and RFC 2437, there > >> are substantial differences, including to some data structures, the > >> older versions of which may be in widespread use, e.g., = RSAPrivateKey > >> is extended in a way that I think could lead to interop issues in > >> [2]. > >> > >> So my question is: what's the right way to handle getting pkcs#1 > >> under IETF change control without breaking anything? > >> > >> Should we for example, not formally OBSOLETE RFC2347 perhaps, or > >> should we ask to add some statement to [2] that explains that even > >> though this is newer, it's the older version that's widely > >> implemented. > >> > >> Bear in mind that we are in any case trying to move entirely away > >> from pkcs#1v1.5 so this shouldn't be too much of an issue for = future > >> RFCs, which are likely to just use pkcs#1v.5 as-is (if that's = needed > >> due to legacy h/w) or to use something else entirely, e.g. based on > >> the cfrg curves. > >> > >> So, that's a bit long winded, but please take a look, in particular > >> at [2] and [3] and say what you think we should be doing here. > >> > >> Thanks, S. > >> > >> PS: Please note that it's taken the folks doing this work quite a = bit > >> of effort, e.g. dealing with their legal folks to get permission to > >> move change control to the IETF, so we should really try to avoid > >> imposing more work (and delay) on those folks if we can. IOW, = minimal > >> change here is really good, and if the IETF wants to and has the > >> energy, we can modify whatever we like after this transition has > >> happened. > >> > >> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ > >> [2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/ [3] > >> = https://tools.ietf.org/rfcdiff?url1=3Drfc2437&url2=3Ddraft-moriarty-pkcs1= > >> -01.txt > > > >> > > From nobody Sat Aug 6 09:38:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D988812D52F for ; Sat, 6 Aug 2016 09:38:49 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL-IWkvBxd_S for ; Sat, 6 Aug 2016 09:38:48 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AE312D520 for ; Sat, 6 Aug 2016 09:38:47 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 74so33290897uau.0 for ; Sat, 06 Aug 2016 09:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uK6JTyPd3IlCnL5yEvGVj9H+eg5xcVI0SFG8S+EzdSs=; b=fV2wy2CfRb5ipoxz1Gei28awPKxY+Hmm9tqjb3R4oTjmalcHAyE27glx2fg3MkCQBE w8VzPsZYdmQ+XhczcxiwPvKtLTHHYAIrTBfobI4DQ6e44W8t/xOeZ94eHONXru18LkmC IR4+lAHKqfiz5USfem36N3TCZP0ffe36kPV5JO+NPdF2Q7jD1hspmLb6iaXKfXcfwZ8o ulT1RG75a6xAHq+v844dMu2ULnEG7Tdt7vKDc8R3pk5PkTDCA7sP99CGlJ3ayFKrCBoO XdT5cuogPb2wDanzkckbCD79CRfWa+rHiCw7jexRG9vP/QTVtFBB56JMnBt/bqOgysAV yahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uK6JTyPd3IlCnL5yEvGVj9H+eg5xcVI0SFG8S+EzdSs=; b=gmgbgDtF8hOZj5xVQqUqq7DCGjG/Jg85TCFcBoBO+ZWMsyCW8up/6RKQpLMgKDWpYm soLrz+S1QnrcSewCy1V+hv8wXnL4jtMFOQeAR7Yod8xdQVRjH3IWspq0FwnKWYY/A6JT JYZ5gQHT901k2VhmqCJBtbFJlCywqdwLAtBNXoltSvLmdPXqCPO4d3HE0ev5CS5noj/z R6cnAQyZsKs5TU5IX661Pw0+dDar87PGzRqxa1+teBWfEtgMRRMPTSQlQU9KHv1xViQp 2vPP2JeY9sN/FWftExZ2xOR3LQnsUnIyPTaLNbi7/6UHfOt7ERmDT8UOWOH+glgKt+4J V9lw== X-Gm-Message-State: AEkooutqHAIMrc8d9e2pEJatoWPLMVienGwEORS9PCoYzgfgJPiMVMs7TXuW2kYW/fITjSjkEyB8KDbmFwm80A== X-Received: by 10.176.4.85 with SMTP id 79mr5347144uav.56.1470501526777; Sat, 06 Aug 2016 09:38:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Sat, 6 Aug 2016 09:38:46 -0700 (PDT) In-Reply-To: References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> From: Watson Ladd Date: Sat, 6 Aug 2016 09:38:46 -0700 Message-ID: To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 16:38:50 -0000 On Aug 5, 2016 10:58 AM, "Russ Housley" wrote: > > PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more tha= n two prime factors. Multi-prime RSA can provide lower computational cost f= or the decryption and signature primitives when the CRT (Chinese Remainder = Theorem) is used. Further, one can get better performance in a multiprocess= or environment where the modular exponentiations can be done in parallel. > > The big changes in the PKCS#1 v2.2 data structures are to support multi-p= rime RSA. I believe that the changes were done in a way that is backward c= ompatible with the non-multi-prime RSA. And the changes that weren't made were taking the PKCS 1.5 padding out back, merely NOT RECOMMENDING it. The text is woefully optimistic in its description of Bleichenbacher's result. There are no key size recommendations. > > Russ > > > On Aug 5, 2016, at 1:07 PM, Stephen Farrell w= rote: > > > Folks, > > > > I've just asked to start IETF last call for drafts that > > document pkcs#5 [1] and pkcs#1. [2] The main purpose > > of these drafts is to hand change control to the IETF, > > as we've recently done with other pkcs series documents. > > (That's a good thing, and thanks to those who've made > > the not-inconsiderable effort to make it happen.) > > > > For pkcs#5 I think there are only nits to consider but > > I do have a question to ask wrt the pkcs#1 draft. [2] > > > > Please send responses here or in response to the last > > call on ietf@ietf.org, which should pop out shortly. > > > > If you look at the diff [3] between this draft and RFC > > 2437, there are substantial differences, including to > > some data structures, the older versions of which may be > > in widespread use, e.g., RSAPrivateKey is extended in a > > way that I think could lead to interop issues in [2]. > > > > So my question is: what's the right way to handle getting > > pkcs#1 under IETF change control without breaking anything? > > > > Should we for example, not formally OBSOLETE RFC2347 perhaps, > > or should we ask to add some statement to [2] that explains > > that even though this is newer, it's the older version that's > > widely implemented. > > > > Bear in mind that we are in any case trying to move entirely > > away from pkcs#1v1.5 so this shouldn't be too much of an issue > > for future RFCs, which are likely to just use pkcs#1v.5 as-is > > (if that's needed due to legacy h/w) or to use something else > > entirely, e.g. based on the cfrg curves. > > > > So, that's a bit long winded, but please take a look, in > > particular at [2] and [3] and say what you think we should > > be doing here. > > > > Thanks, > > S. > > > > PS: Please note that it's taken the folks doing this > > work quite a bit of effort, e.g. dealing with their > > legal folks to get permission to move change control to > > the IETF, so we should really try to avoid imposing > > more work (and delay) on those folks if we can. IOW, > > minimal change here is really good, and if the IETF > > wants to and has the energy, we can modify whatever we > > like after this transition has happened. > > > > [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ > > [2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/ > > [3] https://tools.ietf.org/rfcdiff?url1=3Drfc2437&url2=3Ddraft-moriarty= -pkcs1-01.txt > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Aug 7 02:25:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A3812D0E4 for ; Sun, 7 Aug 2016 02:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZANX3XwgtN9 for ; Sun, 7 Aug 2016 02:25:53 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA7812B029 for ; Sun, 7 Aug 2016 02:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470561952; x=1502097952; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aDmaCYbhGITytvr1ZKCoPrUnOMClVJZXU4NUGpAKE64=; b=R4ezgsHZ4FsFiZ8fF9LQ4nXIjsCNJPSc9hlll/4kki4JCDSZefMdwqiL xbAk61V4qZeHI0E7qNmjBs6PYEiNunt2n4kqwQX8MYmhytPaNUUq65uCY faOcotorm0l4PdjfsrprOrhdntkXIAbtQ5PTdmnXwd547TbVTSd20PjBy cru2qpNUn6tDjcrnXA97zrF/mZJz677Kzpx/W7vRjopIQXpMzkbGIuEJs p2DmfdUutdkBnNqCMe6w7QFzsdKQhM3h/4tug4I1soXIVLwHKpLqotZ1s qp+Tg/ZJCFxNw1JN01L5+cF9c+CKNGT7v3ib404Dr9NXLg5zjPXCC4A9m g==; X-IronPort-AV: E=Sophos;i="5.28,483,1464609600"; d="scan'208";a="101192464" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2016 21:25:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sun, 7 Aug 2016 21:25:49 +1200 From: Peter Gutmann To: Watson Ladd , Russ Housley Thread-Topic: [saag] pkcs#1 -> IETF change control Thread-Index: AQHR7zvhy8FYucb7hUyrJqj16Wv696A53jEAgAF8LQCAAeJmQw== Date: Sun, 7 Aug 2016 09:25:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 09:25:57 -0000 Watson Ladd writes:=0A= =0A= >And the changes that weren't made were taking the PKCS 1.5 padding out bac= k,=0A= >merely NOT RECOMMENDING it. =0A= =0A= The current text is fine, using encode-then-compare with PKCS 1.5 signature= =0A= padding solves all (known) attacks, and while the crypto padding is still= =0A= problematic, the fact that neither SSH nor TLS nor IPsec use it any more=0A= (apart from some old legacy stuff) means it's not such a big deal. In any= =0A= case the alternative, OAEP, is pretty much impossible to implement without= =0A= side-channels, so it's probably worse than PKCS 1.5 no matter how=0A= theoretically perfect it is.=0A= =0A= >There are no key size recommendations.=0A= =0A= That's a matter of policy for each application domain. The problem with=0A= keysize recommendations is that they're often driven by numerologists who, = in=0A= splendid isolation from reality, decide everyone has to use ludicrous-lengt= h=0A= keys, even if it's securing a printer on an isolated LAN.=0A= =0A= Peter.= From nobody Sun Aug 7 05:49:39 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BEF12B074; Sun, 7 Aug 2016 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.801 X-Spam-Level: **** X-Spam-Status: No, score=4.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 tFobohqr7XD3; Sun, 7 Aug 2016 05:49:36 -0700 (PDT) Received: from server.inlakscomputers.com (server.inlakscomputers.com [192.163.242.49]) (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 DA25F12B01C; Sun, 7 Aug 2016 05:49:36 -0700 (PDT) Received: from [159.253.189.239] (port=60527 helo=syew.net) by server.inlakscomputers.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bWMru-00088v-7b; Sun, 07 Aug 2016 13:07:51 +0100 From: ietf To: "saag" , "sarikaya" , "secdir" , "stbryant" Date: Sun, 7 Aug 2016 15:07:15 +0300 Message-ID: <0000b6af5268$f0c79e10$174392b1$@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0013_014FA189.1E602BED" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH2B8SwRVwxJgvcqXCNimX4pI5+uA== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.inlakscomputers.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - frobbit.se X-Get-Message-Sender-Via: server.inlakscomputers.com: authenticated_id: okoyejo@inlakscomputers.com X-Authenticated-Sender: server.inlakscomputers.com: okoyejo@inlakscomputers.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [saag] =?utf-8?q?that_is_so_nice?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 12:49:38 -0000 ------=_NextPart_000_0013_014FA189.1E602BED Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_014FA189.1E602BED" ------=_NextPart_001_0014_014FA189.1E602BED Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIA0KDQpIYXZlIHlvdSBhbHJlYWR5ICBzZWVuIHRoYXQgbmljZSBzdHVmZj8gT2gsIHlv dSd2ZSBnb3QgdG8gdGFrZSBhICBsb29rIDxodHRwOi8vb3B0aW9uLmFieXNhY2suY29tL2U0dml3 eT4NCg0KU3BlYWsgdG8geW91IGxhdGVyLCBpZXRmDQo= ------=_NextPart_001_0014_014FA189.1E602BED Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hello,

 

Have you already seen that nice stuff? Oh, you've got = to take a look http://op= tion.abysack.com/e4viwy

=  

Speak to you later, ietf

<= p class=3DMsoNormal> 

------=_NextPart_001_0014_014FA189.1E602BED-- ------=_NextPart_000_0013_014FA189.1E602BED Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCACAAIADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9M5Ha OuW8U61fDU9L0HTJfs+oan5sj3QUM1paxgebMqsNrPukhjUHOGmDlXVGU9HJvrkNM/f/ABc1zzP3 n2XQ9P8AI3c+V5txeebs/u7/ACYd2PveUmc7Rj5mPc9ZjJYm+HN5p0lvdX11oN9dx2d1HqN7Ndva yyHZDMkkrPIQ8hihaPJUeYrjYFkMnayTvs+SuQ+MPyfCnxfMvE1tpVzdQSD70U0cbSRSKf4XR1Vl YchlBGCBXZlN9N6pMNEyDzZKfJ1SiSOjL/3KgoETzE+/R5f+3RHH8lP2fP8A7dBBYST+/RIRJVd5 KZHPmtOcnkCT+/TJJPnp874SmR1maE+/zEoj3/cqOP8AeVJ5iVqSHl0tO++KT7ifLQK494d9cZf2 yaF8UNOuzxba/Ytpru3OLm3Lz26IByN0Ul8zE5H7lBlScP2G/P3XqhrWl2mvadLY30TPDJgkBirK ykMrqykMjqwDKykMrKCCCAa1TpomzOZ+KqfafC/9gJzN4inTR9g4YwyAm5ZSeFdLZbiRS3G5AMMS Fbr/ADPkrntF8KDSLt7681O917UjGYUvdREIeKIkExosUcaKCwBYhdzbV3EhEC7qf6w1zt9EaLzJ /lpknWjy/nqU9KkYu2momKd/DT460UCCtJH/AAUz7P8A3KuTOmyqfmU5gncelp8n36kTZv2VBG7x vVp3wlAED0Uf8Dp/yx1kWMj61Mjp/wADqGTrRHJ8n3KIEvUI5NlD/vH+SmR/vKsoiUQArf79R/6u rT7E/wB+ofL/AHlBQRyVN2/v1D5fz7KI/wB3QA+T5/kqPzNn3KnfvVKT/WUTAuxyefTPL8x6gt5H 31aRMVpAkHj+d6Z5fz1Z2H1NM3lKfIK5D/q6Z5n7yrWBTPL+esuQdyOT++lEibPn/jp7/wB/+CmT vvoAZ5f7yp46jj/eP9+jy/LetQJE+8al2JTNi/fpjz4o/hi3Cb7wpRIn8FG/f9+oPL+f5KBll/kT 5KZJH5m/fTI/9+pk+4KBbFb5PMq1uqDy/Lf5EooGPST+9T5upqt/HU0H9yl7QB8NOqP/AHEoL7Kz 5xWHyfx1U+z/AD/PU8bvvofZG/361DYXZs+/T2++KN/yZqOOfzE+5QAyPfs2U94Pnp8ju/yLTfn2 UwDY9P8AL/2Kg/1cdM+0PvpDJ3/v0nmeW3z0zzKe8fn/AD0ADz4qrHJ5j1agj3w7Ho+yeX9ylyc4 iG4jp/l/J89TOlVY4/n2PR7MZJG+yPfRJGkn+/VnZ8lQvJ/do5BXDZ8uKZ/rPkR6ZHI/8dTRps+9 WYyGnx/f2VJ5fyURx/x0cgD/ALgpju+P9ukkn/2Pnp6fOlai9St5nmUSfvPnqbyEP3qJETZ9+lyD GeX/AN9095/k2JTJP9ZTPn37KYD4/wDWVP8APUcaPHUjps/jpiGI+Xojf5P9uneYm/ZnmmPB/wB8 UgIfnkf/AKZ09JNlM8t9nyU+PolZDH/LRvFMk/1dEm+RE2UAEcjmrP30pdiPUE52PWv8MncWSPzH qOp9/mJTI6Bj9n956g/1j/PUkj4pn8dAxJN9PgGQj0v+sTZRJ8j/AC0wJd6PQ5xVaP8Av1NG7fc/ jq+cm1hfLR/9+jY+/wC/8lQXH7unpOhT/bqBhOn8dM+z+XSySUn2j+5SGLJHTk/do++mR9anKb6B Mc+16h+Sepv9779RP/s0VAQBNlR/8s9+yl/jqwifLS5AbsZ8f7x6upsRaZ5ab/uU/euadMGCJ8m6 oZJHxvSrPnJULp82xK0mCfcPPT+4aZv/AI6PstEkf9ysvfGEkm+iOPy6ZT/9ZWYBJ8n++9M/1aVa +zmmSW/7utOQXOV0/wBYavx/JVDzHR/kqx5j+XRAJn//2Q== ------=_NextPart_000_0013_014FA189.1E602BED-- From nobody Sun Aug 7 07:26:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EEC12B01B for ; Sun, 7 Aug 2016 07:26:02 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHAnaA91mAbv for ; Sun, 7 Aug 2016 07:26:01 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC6712D0A2 for ; Sun, 7 Aug 2016 07:26:00 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 74so43597331uau.0 for ; Sun, 07 Aug 2016 07:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l+qVC1EOVnFrV9Q5yXuAG0KALWZRsZ857QMsr7kck0M=; b=Lxpac2xeilxOQ90mOm3HtueB4IkEliUcsCTTQJLA7oHYveHSezmtCr0tzP8R6v5oNr yT+/Fcx2kpSTKN281v0g4AB9s1dxwYpAIhkdx2eh7La2hVwcrP5BcyoFKc4YPYlSUxRs eNwk6SjUvdrnyAHvDMTL9ZiiiI8GLjxo/bDGllayGUCIUR24OojHiGLU6HxgT3u8Plxl EuFmwbKh2QwD8EpqQPj/QiTsml4ki8P1qUADgT+8EMrMyLaancX27YG9dr4jkconpaDQ UMEjpPnUmsP2vv7J5+MQr/49P08kI65s/7GxKPwR0wv7StbUE/hVUS/SA08e0RD70Kuc bBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l+qVC1EOVnFrV9Q5yXuAG0KALWZRsZ857QMsr7kck0M=; b=C7gIrSkrmK4AmmK1ARexqFuKVk5mO7J+X6WfCq5H4yjrOwD37qyRy1TB4ZVAmv3A7U tyj3jB3y35tsNI17jlB7EFrEJGIIVM2EI5gTi8t4KqFaPBNYWEYfN7DNEuBqZXXD0WgI j2eij9YJzBAzU87uSX/Qdsqwz2rFGMBr+/ZnOIMiwk0yZKDF98SAm7ygUNVI8A2cc6Ei eYpWckv6Qv/tagmnGyYn9CgCI2rXVoTgY1389wpdsucxiuzSAf/A8Ck4XZeBQKOcj9Vw uA5a+Jrw0JlrjUN4ZyFJuYqqDspxnDgnbmFgES2LTvRtDToFfgsvKjDJBnG57T3XiV7R 0Rwg== X-Gm-Message-State: AEkoouvRwypTYK1FAYC4oEDxR+fKh2faXdetlTZwUpe+/I1zMLe8dF3eyTYK6raxcESQ7culvoa7Atq7I8AcEQ== X-Received: by 10.159.55.199 with SMTP id q65mr45326982uaq.125.1470579538315; Sun, 07 Aug 2016 07:18:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Sun, 7 Aug 2016 07:18:57 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Sun, 7 Aug 2016 07:18:57 -0700 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 14:26:02 -0000 On Sun, Aug 7, 2016 at 2:25 AM, Peter Gutmann wrote: > Watson Ladd writes: > >>And the changes that weren't made were taking the PKCS 1.5 padding out back, >>merely NOT RECOMMENDING it. > > The current text is fine, using encode-then-compare with PKCS 1.5 signature > padding solves all (known) attacks, and while the crypto padding is still > problematic, the fact that neither SSH nor TLS nor IPsec use it any more > (apart from some old legacy stuff) means it's not such a big deal. In any > case the alternative, OAEP, is pretty much impossible to implement without > side-channels, so it's probably worse than PKCS 1.5 no matter how > theoretically perfect it is. The alternative for signatures (where there is no problem) is PSS. PKCS 1.5 encryption has a problem. OAEP without side-channels is very possible: you have to carry out the operations unconditionally, and then mask based on the high byte. Of course, if you really cared about simplifying standards and eliminating this problem we would simply apply the private key operation and hash the output with the input to obtain a symmetric key. > >>There are no key size recommendations. > > That's a matter of policy for each application domain. The problem with > keysize recommendations is that they're often driven by numerologists who, in > splendid isolation from reality, decide everyone has to use ludicrous-length > keys, even if it's securing a printer on an isolated LAN. We can't kill RSA-1024 in libraries, thus ensuring no one uses it, because of the need to support these applications. Until we remove the code, it's only a flag away. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Aug 7 20:58:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE04612D7E4 for ; Sun, 7 Aug 2016 20:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6bYG5hcbalN for ; Sun, 7 Aug 2016 20:58:54 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2648B12D7E2 for ; Sun, 7 Aug 2016 20:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470628734; x=1502164734; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qenWCODqq5e3dNEcF5KKDNyQWVDi1OoaTybLFg9nF8E=; b=A6yZ/cdgTqlG8qVdy39f+CbLDNjtWYfoaHTfUC6yBJhUNqfvuRN3+dyO FGACJdCVy6EmCo1SyuEP6iD3/fxQqgqjhZVBenPveLoivBGAXjzxLn1S6 ZDaTXI8AjTH+S6ac+I7JEP4rTchQdQLfuMXRxRistZocmR0u2UJ5WPMhz U0qN8l/+/8MJCctFavVBH6Bkhz5/La6SOQ3WXUcz5oce9IbTLTnfTRlFj /da0rU4hwq8m4UOfa9vB11mtwQalL2DuqMChNmSQ70Ux7aKsHbmAUwX1A ASssKJhx0f+tH9WXb70ebJyTw0uau5RQViUq7bemSGYyBj3MBOPc3BSo7 A==; X-IronPort-AV: E=Sophos;i="5.28,488,1464609600"; d="scan'208";a="101376074" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Aug 2016 15:58:51 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 8 Aug 2016 15:58:51 +1200 From: Peter Gutmann To: Watson Ladd Thread-Topic: [saag] pkcs#1 -> IETF change control Thread-Index: AQHR7zvhy8FYucb7hUyrJqj16Wv696A53jEAgAF8LQCAAeJmQ///iN6AgAGuI90= Date: Mon, 8 Aug 2016 03:58:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 03:58:58 -0000 Watson Ladd writes:=0A= =0A= >OAEP without side-channels is very possible: you have to carry out the=0A= >operations unconditionally, and then mask based on the high byte.=0A= =0A= That's a generic answer that you can throw at any algorithm. Can you provi= de=0A= actual real code (or pseudocode) for doing OAEP in constant-time, branchles= s=0A= manner? You can do it with 1.5 because it's just a simple scan of a string= =0A= for which the above strategy works (I don't know what you mean by "mask bas= ed=0A= on the high byte" but I assume it's that you accumulate all the compares in= to=0A= a single byte and check for zero/nonzero at the end). You can't do that wi= th=0A= OAEP.=0A= =0A= Peter.= From nobody Sun Aug 7 21:56:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5A412D7EE for ; Sun, 7 Aug 2016 21:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69wNxdkArDf3 for ; Sun, 7 Aug 2016 21:56:26 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7054126579 for ; Sun, 7 Aug 2016 21:56:26 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z8so299104473ywa.1 for ; Sun, 07 Aug 2016 21:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pl97dojpg6SFX7Pq3Pkc+9gEklJSn5CxeebxjBrQ+/k=; b=XoXb+t3JTAURcAWcBDuGZQFH19v4js9W2173+Sz7D6JBF/T+sYxmqYJba3ks24Qw07 hM2Xe5Zo/aLW8N/lpmb5y0D68lztSgoVG6r+b1xa1CMVkkxL0phqwv/dPCJoHDfbUW0S 0FaOcLiDEoveZ14/nISFibXF0eV+eta+nv8Bz8Bg0o70mo/YpgYX3JaKXHoCYz0Rbc2w muqmjyznJR9bfiVyS+EbM7dcgDa5fcp+DHx9psAkc3lKtVXvgspBuQtw9YPLO/zYxLiR b2LxekDrI/63/aiZOiaA4rMUA4ivQDyKypHQYyuYvuAbhDkUauG+n6fyTG+QiPr/KF2p +0ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pl97dojpg6SFX7Pq3Pkc+9gEklJSn5CxeebxjBrQ+/k=; b=hHZ6djdIEhhBWhwEewM+r4tuqKBXRtfeubN0bHiUktLpPayk/zLj0JG2abL/iVh0FC eC95OheXc5yYOVba/ILvHLAZcuEec7pCdYWlqu47c6wXIXefmSSwgNHlUDgECWIamZax 4bC6ASdXGNHsUd0EDhcvp/+Zk6os7iObnDiWn30xoHeuIKBmrikmAKpiSDrGQ+ArIjeY DwKmcmz8Nv6Q862NMiSL7I+TvAqDOc64ucyqOYSKkYWEF4NAon6LvcFCLLSZ55NaqeY8 uQyHrpej26h/R7oxJhm5ViAkvWLE0PHEXCjFZlmgnT3s5vbn5Z6MOa1m+HIQmHcviXS4 dqSQ== X-Gm-Message-State: AEkoout5XJppNjowqiSSYDm3SywSV4UeM/WoeEv3kRgqkPlEbtjiUOO6zs9Pv9vk6cGsuXFPd0Vvj4VcJTLyBQ== X-Received: by 10.176.69.210 with SMTP id u76mr40084434uau.16.1470632185939; Sun, 07 Aug 2016 21:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Sun, 7 Aug 2016 21:56:25 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Sun, 7 Aug 2016 21:56:25 -0700 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 04:56:29 -0000 On Sun, Aug 7, 2016 at 8:58 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>OAEP without side-channels is very possible: you have to carry out the >>operations unconditionally, and then mask based on the high byte. > > That's a generic answer that you can throw at any algorithm. Can you provide > actual real code (or pseudocode) for doing OAEP in constant-time, branchless > manner? You can do it with 1.5 because it's just a simple scan of a string > for which the above strategy works (I don't know what you mean by "mask based > on the high byte" but I assume it's that you accumulate all the compares into > a single byte and check for zero/nonzero at the end). You can't do that with > OAEP. http://www.inf.pucrs.br/~calazans/graduate/TPVLSI_I/RSA-oaep_spec.pdf Page 14. Your "solution" to RSA 1.5 doesn't actually solve the problem. TLS implementations have had to carefully handle parsing errors in the data encrypted with RSA 1.5. That doesn't work for encrypting arbitrary data without carefully designing the entire program around the need for uniform errors, which is sort of the point of encryption. Bleichenbacher oracles are regularly exploited in TLS implementations. How about we follow Bernstein's advice and instead of blaming the implementor, blame those who made their task hard. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Aug 7 23:04:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A748412D50A for ; Sun, 7 Aug 2016 23:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU9yX_KpmtsM for ; Sun, 7 Aug 2016 23:04:54 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E692C12D15F for ; Sun, 7 Aug 2016 23:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470636294; x=1502172294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2FuHnCYKPufuj5DWV2Zk2MxkR9mNU9lNUHy48QxadpI=; b=ot/fo2MhZRpxpnwOoh12UsmEfreQtPRH8Yq29c1E0s9wJHLJlNuRf3vf j0FjLu373FQBhtq6CeUrtNafJNXp7OYMOJhX2pbGtdxUxHixCAE0WQN3q BRnJUWW5c9+E121uV5EsVxSQcRMVNfggs/gQ29UbXRsFUfeYV5pSiKobl OsONFuwyARwBgF89hpKij0wzJc5Px2CjkoyVPsfr3N1n/Fh8RgNuVAlTd 6dkcRZzkzEkPqvT1iIlr7Bv5wuSTpqhS8k6nJVOXMv+F/DstvnXhdodUc KlVK0kFg/2F3onkCSuWF2aQkbAFCcdDraBeXw5B9RuQK9S2+kvI/EjA+N g==; X-IronPort-AV: E=Sophos;i="5.28,488,1464609600"; d="scan'208";a="101396597" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Aug 2016 18:04:52 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 8 Aug 2016 18:04:52 +1200 From: Peter Gutmann To: Watson Ladd Thread-Topic: [saag] pkcs#1 -> IETF change control Thread-Index: AQHR7zvhy8FYucb7hUyrJqj16Wv696A53jEAgAF8LQCAAeJmQ///iN6AgAGuI93//0cGgIAA3ChN Date: Mon, 8 Aug 2016 06:04:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE385A@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 06:04:57 -0000 Watson Ladd writes:=0A= =0A= >http://www.inf.pucrs.br/~calazans/graduate/TPVLSI_I/RSA-oaep_spec.pdf Page= 14.=0A= =0A= That's an abstract description of OAEP, not a constant-time implementation.= =0A= I'll repeat my question:=0A= =0A= Can you provide actual real code (or pseudocode) for doing OAEP in consta= nt-=0A= time, branchless manner?=0A= =0A= In fact lets make it a requirement for real code, because in pseudocode you= =0A= can always just say "perform the padding check in constant time; // magic= =0A= happens here".=0A= =0A= >Your "solution" to RSA 1.5 doesn't actually solve the problem. TLS=0A= >implementations have had to carefully handle parsing errors in the data=0A= >encrypted with RSA 1.5. =0A= =0A= Right, and if you know that you need to do that, it's quite possible with 1= .5.=0A= For example my TLS code has never provided anything other than a single err= or=0A= type for a decrypt issue (or any crypto problem in general, it just says=0A= "failed" and disconnects). However this isn't possible with OAEP, because = you=0A= can't do the checking in constant time.=0A= =0A= Peter.= From nobody Sun Aug 7 23:15:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371012D688 for ; Sun, 7 Aug 2016 23:15: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: 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-XUnl7bajUN for ; Sun, 7 Aug 2016 23:15:55 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8512212D091 for ; Sun, 7 Aug 2016 23:15:55 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 74so53522544uau.0 for ; Sun, 07 Aug 2016 23:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZKpoGY787p/Rsa75mAOrxVKF67fY8BOSlQ5qLuUP8bk=; b=toInI/TIxfgxjKuO6YWG/C26L6dqY+lMCnYeVS+GcBfYuhlSdm3Xgo7+4YfXyFznP5 evtROn7PtSKOo62LjU0GPRGS84Lall7low5Gh0uTO93yund8Ewa8V/tiOAv/c+08Orhl VnI+Nl4NWj2L9ZSR44uQcmMckmBPaq7QW8ibGAdihFy5CinypvxWAChgOokLAiWmMzNI 7wHHiiWFT85o0wXvq7xCHm5a51aHJrz2jGxnVbAwU7rULFuW4rJ86wJPVBGWA3SBsw7F NQg8xWIe8tmSG3joO2nMatCyCum+Wm/JJwm+CG/UoXP8uAyRFA3jzR5gwIwhW1ExmZ7X fy8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZKpoGY787p/Rsa75mAOrxVKF67fY8BOSlQ5qLuUP8bk=; b=dA8blP9YE5zI2GVzLVXd5yxCgG1HkFUt2FyDbNc6EZ8RIW8KLPsMKT/JdzgqqgtMIf q1u9CU5qafHioCRvBVF5j4KJ6z3RD7ZduwUkHNmlvC2AkbOZhl3IBNPx1Pc8ALeadCGJ TaVhKeXilBLx918ayPQm3fibOEfDo6bdfE1zQQXJl7vroTsvW5+q/ZKT4np1sK5dt6Jp HaNddwB34Xtp4aAhejRv9tcS3GGLuplhJPM1+u0NpRDm8fHK52aT76APAUwMiA5QfPMh jDxxJlWz8yYMt7IdIEbW/sxGAtHHlmA4t1KvQyqrWrrHv5BOXzKHTOV4wX3+G2Yz4d4d sjAg== X-Gm-Message-State: AEkoouvLvtQ70Hot5dduv95IeXXHdjDScwivhUFIZuFakt37+2pqRNexZkBF/DJ5L6x4TLfpIEKEwTUlNA51cw== X-Received: by 10.159.55.199 with SMTP id q65mr46638320uaq.125.1470636954575; Sun, 07 Aug 2016 23:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Sun, 7 Aug 2016 23:15:53 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CE385A@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE385A@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Sun, 7 Aug 2016 23:15:53 -0700 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 06:15:57 -0000 On Sun, Aug 7, 2016 at 11:04 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>http://www.inf.pucrs.br/~calazans/graduate/TPVLSI_I/RSA-oaep_spec.pdf Page 14. > > That's an abstract description of OAEP, not a constant-time implementation. > I'll repeat my question: > > Can you provide actual real code (or pseudocode) for doing OAEP in constant- > time, branchless manner? https://golang.org/src/crypto/rsa/rsa.go?s=16896:17021#L558 There is still a leak, but it's clear that this can be fixed by a small modification to the bignum library. > > In fact lets make it a requirement for real code, because in pseudocode you > can always just say "perform the padding check in constant time; // magic > happens here". > >>Your "solution" to RSA 1.5 doesn't actually solve the problem. TLS >>implementations have had to carefully handle parsing errors in the data >>encrypted with RSA 1.5. > > Right, and if you know that you need to do that, it's quite possible with 1.5. > For example my TLS code has never provided anything other than a single error > type for a decrypt issue (or any crypto problem in general, it just says > "failed" and disconnects). However this isn't possible with OAEP, because you > can't do the checking in constant time. No, it's not possible for a library that provides a 1.5 PKCS decryption primitive to ensure that application code treats the error uniformly. That your TLS implementation can handle this problem doesn't say anything about the scheme in any other protocol that assumed it had an encryption primitive. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Aug 8 04:38:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F89412D598 for ; Mon, 8 Aug 2016 04:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCaNOlVGoVRt for ; Mon, 8 Aug 2016 04:38:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2EA12D0DD for ; Mon, 8 Aug 2016 04:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470656309; x=1502192309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=u5sFvxB7K16rH5H9SMk2EnfB/S8jb2zcK9CV/B3546U=; b=uEUI5YEv4NNY540ZPWdkSb5zURGC7Na4PSMfbjwYD2hA6X1laUcst3b7 a4pnwg2Fd5FT7/mDWWzgAAqxDh4Rjk8SAoUDc2ULiYnZ6uOCirQ+iH6J8 BSAjZR9jjqsggZ18CMeq87ZPP25HxB+HBzFnmljdwCum1AC7Na3BcgnT3 kMX95MGj9XkSMLY0eVkxoeHCooG7D2+NtYGACOKBrG0ZCyjwRyc68mdM7 kn5sxnGh4vmKlk/x0heINduwV3i3dLOwn40sq+HoHRp8+XWLqdg67uEh7 pfGHe0Jy3WvcAFeC53WlmIqiwVKvAGGhqaSFOFYcgfHjOnL15iKa5hDJk A==; X-IronPort-AV: E=Sophos;i="5.28,489,1464609600"; d="scan'208";a="101429483" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Aug 2016 23:38:26 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Mon, 8 Aug 2016 23:38:27 +1200 From: Peter Gutmann To: Watson Ladd Thread-Topic: [saag] pkcs#1 -> IETF change control Thread-Index: AQHR7zvhy8FYucb7hUyrJqj16Wv696A53jEAgAF8LQCAAeJmQ///iN6AgAGuI93//0cGgIAA3ChN//86DIAAIpZeTg== Date: Mon, 8 Aug 2016 11:38:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE3AD6@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE385A@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 11:38:34 -0000 Watson Ladd writes:=0A= =0A= >https://golang.org/src/crypto/rsa/rsa.go?s=3D16896:17021#L558=0A= =0A= Ah OK. I assume go has built-in range/bounds checks, since the problems I = had=0A= with constant-time eval were due to performing strict bounds-checking on=0A= operations.=0A= =0A= >No, it's not possible for a library that provides a 1.5 PKCS decryption=0A= >primitive to ensure that application code treats the error uniformly.=0A= =0A= But the same applies for OAEP, or any other scheme. What I was saying was= =0A= that the simplicity of 1.5 makes it easier to get right than the complex OA= EP=0A= or other padding schemes.=0A= =0A= Peter.= From nobody Mon Aug 8 06:29:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9812D831 for ; Mon, 8 Aug 2016 06:29: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU3gdAGztTup for ; Mon, 8 Aug 2016 06:29:25 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F9512D7FD for ; Mon, 8 Aug 2016 06:29:25 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id i31so107184201uai.2 for ; Mon, 08 Aug 2016 06:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tursUftE9YODjxf4cVb7Ui/L55xSlgKy93cQ38cskIQ=; b=inLMRZaLSoxnzXozfLUu7k1OtrC80S72ye8GshjUguxdjuFrLOYHc517DlH0ZkQ5wg nDE1lpq+5u41x14GC0PglDATCk5TmaGPuEzz8Pr+2YmS1FCoTlNpZEkBu6XUpMzgFD7y 6Q4Ul7Qb6axovhudW8AcEEikYfLb2QsVZ9xdzawKJbEYphCLocX/wAeWO/C9Nqjb0KS4 iVohHYa2aWRKeS/wAThwY1rApTD6Ne57//fHpujvD9JX4/UbaqJ++6hyRSkY76nCpxUk kk6w/Rl9BJgf8m5o0R9Ld5zXSHhuYO9Alsb8N/zhAHIWlGy+tfYAMo/6s+541Zy5p1lN GboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tursUftE9YODjxf4cVb7Ui/L55xSlgKy93cQ38cskIQ=; b=Mut9/8Pm+zzYRFvVOdd+TsXxG42ZhyqwihNuqX2iE+LTxUE6b7q/Wjvc1/bLxxXPIF /vQwSHe/GewzXkhV8aYbd6XTNtfgED5GWz8yH7TljWUy8QT3nNiI13qOZ7XU8dniJIrB 3PmOJI9VObRFK72q5unOScmRahCb9UetSLNx6xiYxxBP94Ax1iy+XGumVGJFlc6CMt7T UdgVmm1u2KTjnyeS6KadJlbsoeiRyvWLeAczKgNM499R05XHdrp0u3alOsNmgz/FNZ/8 LB1/nOZ6BvX0rcguzLAn1r2IJzQvKWsmmNvzDvxjWj1WV4LWVbQSuzkbRE3hVW/zcrQD jqPA== X-Gm-Message-State: AEkoouvfOvl4rEaKpM1gwM2+8g9kpGXrX9FoHqAH6jrjQotIYxB5O2B+y5ZVju2TD5bKbdFgORo8w0fVEJi1pA== X-Received: by 10.176.4.85 with SMTP id 79mr8672682uav.56.1470662964570; Mon, 08 Aug 2016 06:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Mon, 8 Aug 2016 06:29:23 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CE3AD6@uxcn10-5.UoA.auckland.ac.nz> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73F4CE2D19@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3711@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE385A@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CE3AD6@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Mon, 8 Aug 2016 06:29:23 -0700 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:29:27 -0000 On Mon, Aug 8, 2016 at 4:38 AM, Peter Gutmann wrote: > Watson Ladd writes: > >>https://golang.org/src/crypto/rsa/rsa.go?s=16896:17021#L558 > > Ah OK. I assume go has built-in range/bounds checks, since the problems I had > with constant-time eval were due to performing strict bounds-checking on > operations. > >>No, it's not possible for a library that provides a 1.5 PKCS decryption >>primitive to ensure that application code treats the error uniformly. > > But the same applies for OAEP, or any other scheme. What I was saying was > that the simplicity of 1.5 makes it easier to get right than the complex OAEP > or other padding schemes. Except that an application using OAEP doesn't need to be carefully written to ensure errors are uniform. The library author can take care of all the tricky work themselves, once, and then everyone else enjoys the fruits of their labor. Bleichenbacher oracles are a real problem, routinely exploited. Manger oracles less so, but I'm sure it still happens. PKCS should have used a better RSA scheme that would avoid this whole mess: hopefully we will be able to do this now that we have change control. Sincerely, Watson From nobody Mon Aug 8 09:32:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4234212D134 for ; Mon, 8 Aug 2016 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX4h2_amr8E3 for ; Mon, 8 Aug 2016 09:32:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0803C12D10B for ; Mon, 8 Aug 2016 09:32:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48329BE80; Mon, 8 Aug 2016 17:32:25 +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 kqCpFub28lzq; Mon, 8 Aug 2016 17:32:25 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B6264BE7D; Mon, 8 Aug 2016 17:32:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470673945; bh=PE/iwQWWlJ0o5FAL61j58F8LRv3cODxi/tdVVl08DMw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jvP4mWTCDPFIIy42jUvTaj1/vTWoKnHXqCz+0kgfVo3DCYHeqVUriHpnctURd97PH AhC3ekkSabF83V6nyJUr49WI7e4HOw757mf+bYYGWZ8tPWZ7V4T3Q4AGtl0qmC9aJ2 BqSKdlaeqTbKmioZYK0Nt5CrcFI6oxuJ5xIXdBPs= To: Russ Housley References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> <74677F56-28FC-4F0C-BC6A-9527ABE37A27@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8f9df840-2ab9-2396-84d5-d67022c35566@cs.tcd.ie> Date: Mon, 8 Aug 2016 17:32:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <74677F56-28FC-4F0C-BC6A-9527ABE37A27@vigilsec.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050109030701050705030506" Archived-At: Cc: IETF SAAG Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:32:30 -0000 This is a cryptographically signed message in MIME format. --------------ms050109030701050705030506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So looks like the "OBSOLETED" thing turns out to be a non-issue, at least for this draft. In an offlist mail, Burt Kaliski pointed out that: "The "obsoletes" needs to be updated to refer to RFC3447 rather than RFC2437." And yes 3447 has indeed already obsoleted 2347, so this draft creates no new problems, once the header's fixed:-) The reason being that 3447 already has the multi-prime support, so if there's any issues with RSAPrivateKey, then we already have those, and they've not caused breakage that I've noticed. Sorry - I should've spotted that when doing my AD review. I'll make sure the draft is updated to obsolete 3447. (And the diff vs. 3447 [1] also looks much cleaner at first sight, as it ought.) Cheers, S. [1] https://tools.ietf.org/rfcdiff?url1=3Drfc3447&url2=3Ddraft-moriarty-pkcs1= -01.txt On 06/08/16 15:18, Russ Housley wrote: >=20 > On Aug 5, 2016, at 2:21 PM, Stephen Farrell = wrote: >=20 >> >> >> On 05/08/16 18:58, Russ Housley wrote: >>> PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more= >>> than two prime factors. Multi-prime RSA can provide lower >>> computational cost for the decryption and signature primitives when >>> the CRT (Chinese Remainder Theorem) is used. Further, one can get >>> better performance in a multiprocessor environment where the modular >>> exponentiations can be done in parallel. >>> >>> The big changes in the PKCS#1 v2.2 data structures are to support >>> multi-prime RSA. I believe that the changes were done in a way that >>> is backward compatible with the non-multi-prime RSA. >>> >> >> I agree with the above, except I think for the changes to RSAPrivateKe= y >> (at least that's the one I noted). Now that's not a huge deal for >> interop, but would bite for private key import/export, I don't think >> old code could ever usefully accept the multi-prime structure, so I >> think it is an issue there at least. So if we OBSOLETE 2347 then new >> code is likely to be less interoperable with current code. >> >> I think maybe best might be to just not OBSOLETE 2347 for now and then= >> if/when multi-prime is desired (for pkcs#1) we can figure that out the= n. >=20 > The RSAPrivateKey structure is: >=20 > RSAPrivateKey ::=3D SEQUENCE { > version Version, > modulus INTEGER, -- n > publicExponent INTEGER, -- e > privateExponent INTEGER, -- d > prime1 INTEGER, -- p > prime2 INTEGER, -- q > exponent1 INTEGER, -- d mod (p-1) > exponent2 INTEGER, -- d mod (q-1) > coefficient INTEGER, -- (inverse of q) mod p > otherPrimeInfos OtherPrimeInfos OPTIONAL > } >=20 > If multi-prime RSA is used, then the OPTIONAL otherPrimeInfos is presen= t. >=20 > If multi-prime RSA is not used, then the OPTIONAL otherPrimeInfos is ab= sent. >=20 > In this way, a private key with two primes can be used by older softwar= e that does not support multi-prime RSA. The text on version warns about= this; version must be 1 if otherPrimeInfos present. =20 >=20 > Russ >=20 --------------ms050109030701050705030506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDgx NjMyMjRaMC8GCSqGSIb3DQEJBDEiBCDkJEmjzcBpERWzY4cgxOBZ95PGDKeg/ke+PqWQtOuC HjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBAv0gW/hw2HAy6cE2luaOR9j1n73yQI8AkMxZg4/TkwKIkyF0EDfTO OEidXWE/Rk9qeg3n+4AOOYsXwoPBzsioNgEBomDbnJoVP2BO7hueYFXo7/fMtrxov9KwYau+ P3aQJ9QBsvDBDxhIeD45FzhOqwqeR5snsxzZR0+ENAxoKNJn5Z0fYUTIjcJt4PK7kihaxO/+ x4uO5T+TmIw5EHQr0Ztwx1mH3QN9eKdDuIAosV7UcB2sej+ZRHDU1PvDwDXZffBj3AZZuASc L6ZJO1wmqzb4JLkktCAfCqkOlJxxjRIh7+UXxiF6LG/fgpaGGYPhZ3ujPvJm3XKz2ySqFzRd AAAAAAAA --------------ms050109030701050705030506-- From nobody Mon Aug 8 10:29:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE112B013 for ; Mon, 8 Aug 2016 10:29:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7hd3id8zfUB for ; Mon, 8 Aug 2016 10:28:54 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C563112D1B7 for ; Mon, 8 Aug 2016 10:28:52 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 74so78923304uau.0 for ; Mon, 08 Aug 2016 10:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DkcwsfB3nRMPZcTIg52Z/qE2eQaz2Ae39xn1ArzMH2s=; b=hkRAqaOWgJUS72racnp1bJtiT1Hv1/zZSb/qD27O/NIgFihPt/Q6UOLphMFZ230NnM hmNNsZqZ+Jxwpx1sP4NNBMsRs7We6qSSr+dnis5uvh0XiV7/adbwH+yMHWRgpZMxbdXY kRE3F+7wwsWuQqpEuCgovmKULj0nfLFYaIl28t3Bxc5kmL7769z4BwTnnKtVH5PV3rW6 0jqmlGaayIYKHtqTMKHIaXyHgD/ySHWUfmq70m3WTat3gCBMkXNT1SgOIPgi8D71q3bw qkv84zoTBfjPRcdDIQGcX7WZxu19vA6yvFTntH5ednHXVzndcOp326lU7oGZSToXxucP 9Mow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DkcwsfB3nRMPZcTIg52Z/qE2eQaz2Ae39xn1ArzMH2s=; b=EpYxnFZwgctIBcsCwDNZ89RiCvFfDv6SzS/oOWwKMN39FR7OI4pMcFMfgSHFJmmuM9 D5lgPd/JOkHj/qAPk6w8TSRSEw6/Q1GwhT28oiWrUSr7qmYoSALKLL+vgQ0E4JRctHPI iYdybPXupTuOQb1UeegLEa0z56KK1S6lPqW3yY6T3XV+YFF8omtqF/AgmAf6CBJH8b0r EAKX1P4btLTb4k/INZLrH2D2g+gjk21pNifrw89UEvPDn1u436Z1RWZRm4m3U29uMHSC y9wCZU7RQ9Ddifnnc6AgE2fROQCPXB9VkMXEGti1fOGqSnEOROiLmuUzrQUHE+GwP84A Ucrw== X-Gm-Message-State: AEkoousajPwsjR/oS745tYZC0m3qSAcxm8/FlqVLVtVKNYF9w4HJDwGPhoVWdBiIGoeMbFbfz1qT4Fv4iOimQw== X-Received: by 10.176.1.67 with SMTP id 61mr544438uak.99.1470677331810; Mon, 08 Aug 2016 10:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Mon, 8 Aug 2016 10:28:51 -0700 (PDT) In-Reply-To: <8f9df840-2ab9-2396-84d5-d67022c35566@cs.tcd.ie> References: <5f51ddd2-238b-d134-78a0-06671846bfdc@cs.tcd.ie> <79e8dd6e-ecf5-1aef-c392-579754be5e1f@cs.tcd.ie> <74677F56-28FC-4F0C-BC6A-9527ABE37A27@vigilsec.com> <8f9df840-2ab9-2396-84d5-d67022c35566@cs.tcd.ie> From: Kathleen Moriarty Date: Mon, 8 Aug 2016 13:28:51 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF SAAG Subject: Re: [saag] pkcs#1 -> IETF change control X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 17:29:02 -0000 On Mon, Aug 8, 2016 at 12:32 PM, Stephen Farrell wrote: > > So looks like the "OBSOLETED" thing turns out to be a non-issue, > at least for this draft. > > In an offlist mail, Burt Kaliski pointed out that: > > "The "obsoletes" needs to be updated to refer to RFC3447 rather > than RFC2437." > > And yes 3447 has indeed already obsoleted 2347, so this draft > creates no new problems, once the header's fixed:-) The reason > being that 3447 already has the multi-prime support, so if > there's any issues with RSAPrivateKey, then we already have > those, and they've not caused breakage that I've noticed. > > Sorry - I should've spotted that when doing my AD review. I'll > make sure the draft is updated to obsolete 3447. (And the diff > vs. 3447 [1] also looks much cleaner at first sight, as it > ought.) Sorry we didn't catch that prior to your review. Thanks, Kathleen > > Cheers, > S. > > [1] > https://tools.ietf.org/rfcdiff?url1=rfc3447&url2=draft-moriarty-pkcs1-01.txt > > On 06/08/16 15:18, Russ Housley wrote: >> >> On Aug 5, 2016, at 2:21 PM, Stephen Farrell wrote: >> >>> >>> >>> On 05/08/16 18:58, Russ Housley wrote: >>>> PKCS#1 v2.2 supports multi-prime RSA, where the modulus may have more >>>> than two prime factors. Multi-prime RSA can provide lower >>>> computational cost for the decryption and signature primitives when >>>> the CRT (Chinese Remainder Theorem) is used. Further, one can get >>>> better performance in a multiprocessor environment where the modular >>>> exponentiations can be done in parallel. >>>> >>>> The big changes in the PKCS#1 v2.2 data structures are to support >>>> multi-prime RSA. I believe that the changes were done in a way that >>>> is backward compatible with the non-multi-prime RSA. >>>> >>> >>> I agree with the above, except I think for the changes to RSAPrivateKey >>> (at least that's the one I noted). Now that's not a huge deal for >>> interop, but would bite for private key import/export, I don't think >>> old code could ever usefully accept the multi-prime structure, so I >>> think it is an issue there at least. So if we OBSOLETE 2347 then new >>> code is likely to be less interoperable with current code. >>> >>> I think maybe best might be to just not OBSOLETE 2347 for now and then >>> if/when multi-prime is desired (for pkcs#1) we can figure that out then. >> >> The RSAPrivateKey structure is: >> >> RSAPrivateKey ::= SEQUENCE { >> version Version, >> modulus INTEGER, -- n >> publicExponent INTEGER, -- e >> privateExponent INTEGER, -- d >> prime1 INTEGER, -- p >> prime2 INTEGER, -- q >> exponent1 INTEGER, -- d mod (p-1) >> exponent2 INTEGER, -- d mod (q-1) >> coefficient INTEGER, -- (inverse of q) mod p >> otherPrimeInfos OtherPrimeInfos OPTIONAL >> } >> >> If multi-prime RSA is used, then the OPTIONAL otherPrimeInfos is present. >> >> If multi-prime RSA is not used, then the OPTIONAL otherPrimeInfos is absent. >> >> In this way, a private key with two primes can be used by older software that does not support multi-prime RSA. The text on version warns about this; version must be 1 if otherPrimeInfos present. >> >> Russ >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen From nobody Wed Aug 10 10:52:32 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A518012D830 for ; Wed, 10 Aug 2016 10:52:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYrAQuutNMG6 for ; Wed, 10 Aug 2016 10:52:30 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D8812D0B0 for ; Wed, 10 Aug 2016 10:52:29 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id k90so82267918uak.1 for ; Wed, 10 Aug 2016 10:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=A2Z6mYpOBF+9fmu3in3+4snbunoW942EBuTx+jxET+0=; b=zRzxmnqX2X2tgqMGWeJUdZhzkTJsyzkpLgWpE2sGjZwNbcqMgak+rfA0JKDl8Zu0DJ SOMXXKB0dOyXBNnh6jB1zPMiLx8lUjilMD9HI/zDlyLjI2+d5zLKfEEouFXvGzIzUW4B pDRE0On0fHO7re+iLVCHmb6acLJ7HcM5FrXm3oGoWnIvEHxuL8R4Sb8RRa68gxGbyZ9C phnEfizvhRDMKqkLpwOLoWjzdmR1omIedEsQrzu/pgCf6oUOkP49xG8XGbOF2HI8BEUg +Lx1a9MRl0CoPVYPVely4NSgRhv6nZ+t9Wg+f7mVD9jebsGjUSdNMzhuSLBM2doAiKit OXZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A2Z6mYpOBF+9fmu3in3+4snbunoW942EBuTx+jxET+0=; b=EkQDe0eAM5B9yq6ls89uIEoZucwskFdkl90z+4+IWU9fs9vn0weiYemwDdTcJY3KYZ l6z+D5rsweLyQyOZv+d+YUQgG+1VgYhPPQ2p+QBBNTqQSOz44pBIrpXC1kFuEIL0JGNe bnhUXKSYclh4wJltt/nK/E1LSjBhDwVP40JzxBkYK9fdFQbb/84bea82n8LHEWuKGf0u O+5pATOwFclJTEtnOCRZMLbOX6YOA3b0+iJW7iVuxWKbvYLqR4oT9iwC+CRuFK3/KdU6 hZr0FyT0AsQg+BEddnY7+6a/1P8FHzWJb26EXHLKZGm+/LUSyzW6wiz6Q+zZ6rqrFSsE sv8g== X-Gm-Message-State: AEkoout/f7xj5X/2tljWAW9WOL6CaZ9yEcJ+fVnysutudP8jaswpSz2wDwFi5LF9buJCXF/hfJCywSui3gq5Fw== X-Received: by 10.31.50.86 with SMTP id y83mr2602299vky.81.1470851549017; Wed, 10 Aug 2016 10:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 10 Aug 2016 10:52:28 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 10 Aug 2016 13:52:28 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 17:52:31 -0000 Hello, The SAAG minutes are now posted. A big thank you to Carsten Bormann and Chris Inacio for taking minutes. If you see anything that needs to be corrected, please let me know and I'll take care of it. https://www.ietf.org/proceedings/96/minutes/minutes-96-saag Thank you! -- Best regards, Kathleen From nobody Sat Aug 13 06:44:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B308B12B02D for ; Sat, 13 Aug 2016 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imR9cKYF61cq for ; Sat, 13 Aug 2016 06:44:39 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C20D12B01D for ; Sat, 13 Aug 2016 06:44:39 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id l2so10434502qkf.3 for ; Sat, 13 Aug 2016 06:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ErKF/HCZeEm1hnbhqqDfuecdIYUduczWZStPJl7z2c4=; b=JDFmaTutXF1nRbyX9fLZW4kuqQolkq66KY9L9aT2vKEz0/1B7LT7ANBB5aLKrQ+KBm ZadND7OdvCReocs/JGyIYPlhl1LEbT9DHJT4CqPZGneyn54NsdeSVcvRP2veAK4yaT+6 KUQ6KBUOx8oK0GkqrPUE6ERa8CIzPrnH+oAQQQdj1wlMiMxrsoOkXg0XZdh7n0BKdDAm b9/PIu28+OlqLidE272XH//N1nkjjNWc2Mw6re0771KOPY1S6DaKQiPmkLjb2PrBCD/q sKGQZYskjRbG0quxLjv1NZp0yyRUkA9FoyqN8FCBJ1GQRqiiSnbIZ1HRXASN6TmNc1Zu M4Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ErKF/HCZeEm1hnbhqqDfuecdIYUduczWZStPJl7z2c4=; b=F691OSWV9hyCmIYIM6HRB0d1PjHdCT68Olr3BCeHwdkc9Izij5JPyEz4yFlPoTt7eU j20rZf9IWJ2ponduarsqz3PQ5oHqNGz0gCqhbOdegcftppk22jmeRy8VNRMQIB324XYP jTB8HzPe0EYmW5kmj733ZTO1tujrrXi2ztAFkmFlQ7ES+UE8lg0hkcFCGrskCGqCm5xC FQ6dzagAbVCDKytgkeNyveCeKqmlDfGA3MDrFOyaBK8WL3h4pmuEjxSeQ01NSCywVkkL 9UUEhNacnnp2rlPmErXIQnA0NT1jrGQgOGIWhyDo5udYftfWm4id4yGb/7v1n2x75T0d eHSg== X-Gm-Message-State: AEkoousRkQRsnCwZjtAtXIZaIoRjtK5xbjsjXv4Nozk71if4RGbch7GQJsKwkTlRadUTRA== X-Received: by 10.55.175.3 with SMTP id y3mr22573567qke.150.1471095878253; Sat, 13 Aug 2016 06:44:38 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id o131sm5966293qke.20.2016.08.13.06.44.37 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 06:44:37 -0700 (PDT) From: kathleen.moriarty.ietf@gmail.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> Date: Sat, 13 Aug 2016 09:44:36 -0400 To: saag@ietf.org X-Mailer: iPhone Mail (13F69) Archived-At: Subject: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 13:44:41 -0000 Hello, Some of you may have seen the Linux flaw announced a couple of days ago from= an implementation of RFC5961. Here's a pretty good description with the te= xt from those that found the flaw: https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor_us= ers_open_corrupted_communications/ RFC5961 doesn't specify the use of a global counter. Should we make that cl= ear with errata or is it worth an update? Since Stephen & I read it as an i= mplementation problem (that might be an issue elsewhere), I think errata is f= ine. It would be good to have some other opinions on this in case we are mi= ssing something. Thanks, Kathleen=20 Sent from my iPhone= From nobody Sat Aug 13 07:56:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738DF12D59D for ; Sat, 13 Aug 2016 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRpuhOlISjd1 for ; Sat, 13 Aug 2016 07:56:55 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E99712D1E6 for ; Sat, 13 Aug 2016 07:56:54 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id i138so2663149wmf.3 for ; Sat, 13 Aug 2016 07:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r0WpY3PfXu0U4sMUNklVYIEPysiy0KKO1XxknTj0Cjo=; b=jTQlqTLsiiUAtBYOR3MZWr0Zjad34DpgSjRXMSXPuqXRnHpAgWPGbQ/Azl8OEzSwZ1 Bn4qdBEYyiY5caGg36EzL+/4peTk4PfQbSQCo/y6u/RYQ6hS0YLpfATY5QCoFWEhqO9i Hw+VobU4emkHQBNT6gA2HOe88yoqj94T3p++FGQQfdXzHQJhdHzKm+SiMiMzKA8c0Yt5 on0Eh7hCEkjl6JAJC4Ys6DXV6Encwg9niVHwnhPD3BFFCkTMnvfdBE5RFXouOzyK2uUm Wzo8hlFtWVfkOGUG6Fkf0Tf6IxhpwJrsYvxkVivSKXC+BeNrxk2rHob3bqQHCqsZo+8f IZtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r0WpY3PfXu0U4sMUNklVYIEPysiy0KKO1XxknTj0Cjo=; b=UPlPuv5F+871eXqMPxIh0uoD37xLq2ha0DW8ZHcPVlp/D4w/7/IgZPQyAdwWOHOdKR iD4CLZG22eauDMVHV/BWBLfmI8J0T6JR87e6mJ8Rp70PKPyB9/sDS4MrBhl2Oheh1Gc8 rsUEymCzPx7naNOl7CgAlcgazfA9ky7pR9g6P7HczWproMQktPnfZYOg4E/+75Q+upK4 eh3nCIVv+El9T4/nJu4cCByXhCImMUjMvaZD9qb4AS/8fRwRaAUUftgNsbT5wwsnZP+R bnTKKxaTDjP2ugXgHHRnXM9Nt76cs0L/c4je86uZIYxnrk51M0vWeCS9cACfnyBVL38t Mc8Q== X-Gm-Message-State: AEkoouuAvet9gjnhd+7lIlabVnsps9+GR1YCnnwiVTrlJ7ghZ9RVTOSBAUJjj2/RDRv/Qg== X-Received: by 10.194.11.72 with SMTP id o8mr23368870wjb.10.1471100213073; Sat, 13 Aug 2016 07:56:53 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 3sm7538411wms.1.2016.08.13.07.56.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 07:56:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> Date: Sat, 13 Aug 2016 17:56:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> To: Kathleen.Moriarty.ietf@gmail.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 14:56:56 -0000 > On 13 Aug 2016, at 4:44 PM, Kathleen.Moriarty.ietf@gmail.com wrote: >=20 > Hello, >=20 > Some of you may have seen the Linux flaw announced a couple of days = ago from an implementation of RFC5961. Here's a pretty good description = with the text from those that found the flaw: >=20 > = https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor_= users_open_corrupted_communications/ >=20 > RFC5961 doesn't specify the use of a global counter. =20 Well, not is no many words, but see section 7 [1]: In order to alleviate multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK throttling mechanism is suggested as follows: 1) The system administrator can configure the number of challenge ACKs that can be sent out in a given interval. For example, in any 5 second window, no more than 10 challenge ACKs should be sent. 2) The values for both the time and number of ACKs SHOULD be tunable by the system administrator to accommodate different perceived levels of threat and/or system resources. I think it=E2=80=99s pretty clear from both the above and the rest of = the section that these rate-limits are intended to be global. Anyone = following this spec would understand it that way.=20 > Should we make that clear with errata or is it worth an update? Since = Stephen & I read it as an implementation problem (that might be an issue = elsewhere), I think errata is fine. =20 I don=E2=80=99t think this is a buggy implementation of RFC 5961. I = think that=E2=80=99s RFC 5961 specifying a bug. According to guideline = number 7 of [2] this should not be an erratum. Nevertheless, those = guidelines are not immutable rules, so you and Stephen can decide that a = verified erratum is fine. But I=E2=80=99m not convinced that = implementers read errata.=20 > It would be good to have some other opinions on this in case we are = missing something. I think this will affect every implementation by any implementer who = hasn=E2=80=99t read the research by those =E2=80=9Ceggheads at the = University of California, Riverside=E2=80=9D or the Register article. I = think an update is the correct path. > Thanks, > Kathleen=20 Just my 2 cents Yoav [1] https://tools.ietf.org/html/rfc5961#section-7 [2] https://www.ietf.org/iesg/statement/errata-processing.html From nobody Sat Aug 13 08:27:06 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9E12D605 for ; Sat, 13 Aug 2016 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2vEdmwyMO-0 for ; Sat, 13 Aug 2016 08:27:02 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6EC12D1E4 for ; Sat, 13 Aug 2016 08:27:02 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so11811652qkf.3 for ; Sat, 13 Aug 2016 08:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q8kKcxQJvSdBj4qi9D/c0BXAwJvph/PFBwLCRe9oi0U=; b=gPtplWA9EAaRfERH1aI4+Ni2aiJEfjJCBBMCTDtKWdde8PZ9DBoE8v2mdN+5/C7KzQ uF26tlfRR6oKlEUa73nZrCGtUXrSqXX7ZhiQp8Y9JwnPqI52NhLYOw2X4xjWkQRV58ii kyZ8OAROmLTU8OpZtxJuaHhE/Em9adu3AlePBrpCXDZ/DESQ26ahn9sUy+W9pt7Dz9EK iVO2hl2gdG8I11NErAJx0m5Sw2Z4H2QzZhXrpFGUATNr9+vVfzKWIZx2bAaty38AMrae b2VZaTE+GjhCHxYA5ZGfZ6EUt9SIB+9oVZZ0m7PB5fHQty/xahub5RUAqJB5RSEPONaY bZ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q8kKcxQJvSdBj4qi9D/c0BXAwJvph/PFBwLCRe9oi0U=; b=a8/2f458nV42GbHlPJiR169nRnNgUXvMOjmpW4RtiIXtiK7LkD38ss1HV01flayN6c Tg6aJicMatgCkWlCQs4ldzIy2jJD5smFn7+IcQsidOYdQk2V4YhB3A7j3gfbCzdXREUa KXgo2wH4SgQBkpjptKOQB/BMNxS/TqUR9ioW8b4hYzZBDdP+LHrcFr0yBO4Ys1NN/uy0 lEZtKWj8RFapf5fcU0yE3MQ2nhvn0FvqWXz324EyDeQg4NNCJaBm7ybcBeTxMMx23tVP oc7ppw5J9Ej+hy34SJnBO9DSl4d8y8ZeDK6AgTD2Bk/8A+Jiu4CXDhdicO4bL4NbrO6U eUfw== X-Gm-Message-State: AEkoouv7UpEbdrSsSFzzuBn0vp/xy9NpySOSRCdt+3VPNrch46S6t/rhcspvDpLjogcUkg== X-Received: by 10.55.175.134 with SMTP id y128mr24326826qke.134.1471102021448; Sat, 13 Aug 2016 08:27:01 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id j67sm6131625qkf.41.2016.08.13.08.27.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 08:27:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sat, 13 Aug 2016 11:26:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <737EB5C2-491F-4429-A63A-CC2BEF7735AB@gmail.com> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> To: Yoav Nir Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 15:27:05 -0000 Sent from my iPhone > On Aug 13, 2016, at 10:56 AM, Yoav Nir wrote: >=20 >=20 >> On 13 Aug 2016, at 4:44 PM, Kathleen.Moriarty.ietf@gmail.com wrote: >>=20 >> Hello, >>=20 >> Some of you may have seen the Linux flaw announced a couple of days ago f= rom an implementation of RFC5961. Here's a pretty good description with the= text from those that found the flaw: >>=20 >> https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor= _users_open_corrupted_communications/ >>=20 >> RFC5961 doesn't specify the use of a global counter. =20 >=20 > Well, not is no many words, but see section 7 [1]: >=20 > In order to alleviate multiple RSTs/SYNs from triggering multiple > challenge ACKs, an ACK throttling mechanism is suggested as follows: >=20 > 1) The system administrator can configure the number of challenge > ACKs that can be sent out in a given interval. For example, in > any 5 second window, no more than 10 challenge ACKs should be > sent. >=20 > 2) The values for both the time and number of ACKs SHOULD be tunable > by the system administrator to accommodate different perceived > levels of threat and/or system resources. >=20 > I think it=E2=80=99s pretty clear from both the above and the rest of the s= ection that these rate-limits are intended to be global. Anyone following th= is spec would understand it that way.=20 >=20 >> Should we make that clear with errata or is it worth an update? Since St= ephen & I read it as an implementation problem (that might be an issue elsew= here), I think errata is fine. =20 >=20 > I don=E2=80=99t think this is a buggy implementation of RFC 5961. I think t= hat=E2=80=99s RFC 5961 specifying a bug. According to guideline number 7 of [= 2] this should not be an erratum. Nevertheless, those guidelines are not imm= utable rules, so you and Stephen can decide that a verified erratum is fine.= But I=E2=80=99m not convinced that implementers read errata.=20 >=20 >> It would be good to have some other opinions on this in case we are missi= ng something. >=20 > I think this will affect every implementation by any implementer who hasn=E2= =80=99t read the research by those =E2=80=9Ceggheads at the University of Ca= lifornia, Riverside=E2=80=9D or the Register article. I think an update is t= he correct path. >=20 Thanks, Yoav. I'm happy to go with consensus and get this updated. Kathleen=20 >> Thanks, >> Kathleen >=20 > Just my 2 cents >=20 > Yoav >=20 > [1] https://tools.ietf.org/html/rfc5961#section-7 > [2] https://www.ietf.org/iesg/statement/errata-processing.html >=20 From nobody Sat Aug 13 08:35:43 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100F212D0F0 for ; Sat, 13 Aug 2016 08:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.167 X-Spam-Level: X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 s7OA2Qumcyv7 for ; Sat, 13 Aug 2016 08:35:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CBF12B01B for ; Sat, 13 Aug 2016 08:35:40 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7DFZPn5023454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 13 Aug 2016 08:35:26 -0700 (PDT) To: kathleen.moriarty.ietf@gmail.com, saag@ietf.org References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> From: Joe Touch Message-ID: Date: Sat, 13 Aug 2016 08:35:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 15:35:42 -0000 Hi, all, This issue is already been discussed in TCPM. Please review the existing thread and continue discussion there. A quick summary from my viewpoint: a) there already is a draft b) IMO, the Linux code is just (and yet another) bug based on an incorrect read of RFC 5961, not worthy of even an errata All of this is in the thread on TCPM. Please discuss it there. Joe On 8/13/2016 6:44 AM, kathleen.moriarty.ietf@gmail.com wrote: > Hello, > > Some of you may have seen the Linux flaw announced a couple of days ago from an implementation of RFC5961. Here's a pretty good description with the text from those that found the flaw: > > https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor_users_open_corrupted_communications/ > > RFC5961 doesn't specify the use of a global counter. Should we make that clear with errata or is it worth an update? Since Stephen & I read it as an implementation problem (that might be an issue elsewhere), I think errata is fine. It would be good to have some other opinions on this in case we are missing something. > > Thanks, > Kathleen > > Sent from my iPhone > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Aug 13 10:45:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1048712D10D for ; Sat, 13 Aug 2016 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CsVYhs0ZXcW for ; Sat, 13 Aug 2016 10:45:32 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0F612D0B4 for ; Sat, 13 Aug 2016 10:45:32 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id i5so3335220wmg.2 for ; Sat, 13 Aug 2016 10:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XG2OLVJn7dkkexBm3BppIAccAuZw7p6k551f47tQ/wM=; b=gMLeyH7UJxp0AcdUaL1Nxh9sAjIvAbRJ/jhWB1d3pof57L+uRnH8Hw+FpzD71j3S5p 2pVWJZEBLMEUkC4pFxXNt16s55pJ7hm8lAIaXwIriwWn+7+V8ExoW+YzqFvCpBuThVY0 x5pQAyeciPj9V/Q+cK1rPsVSaW2vLW+MBcKZ8CR4xOPyzQ84HCHW3UuMm29Bq9aSdJ+K kvPVQWXVEd4c3ScPc4AS1Xw17e4ssNsjf3BQFxomKJgBJEWmTYCG6cYopIgPN9/MXTfj DggEyXytQNbkIJG01Qbu5kg41YlluHIPVZBsn5t35Tczbj2G4WZSh33SlL0xdzEAjEng WmhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XG2OLVJn7dkkexBm3BppIAccAuZw7p6k551f47tQ/wM=; b=W1sClPEam3kI62Qvij/7f8prrowrNK7acnjl3+7kGglnbS4jlJWoHmxFJehMZbzbw5 h5SWfzpmPmhYmt8JZt0jis8CObk5+1jZof3v9X7v3n4ZN4moR8B5tZOZmM/cSKikeZFb dIS0a4D+QLZ4syXjKheMkpnLMInlFwQDentYdN9yz3Ck7r7yuk6PhaTF1nTMq9KFJzO9 F/2D5NG3ykkjX5qA94FW7tELLgQ/dxbqyLq3M5PJed+JfbIw8aBHwIEHSP6Dcklv0fzW rn5l6famWWSpISoIE3WJmVmPdOnEXKcbSBmqHkvGhdVPC9/PBOeC+ZCgSE/q94s/vjKu 4WYw== X-Gm-Message-State: AEkoouvgV1vLEWvn/xQBv+QV7aXK6DomJpXANv+vVZJuSk97in6zopFo9jddnGMJPbb4Ew== X-Received: by 10.194.205.166 with SMTP id lh6mr25275577wjc.114.1471110330607; Sat, 13 Aug 2016 10:45:30 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i7sm13012597wjg.42.2016.08.13.10.45.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 10:45:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Sat, 13 Aug 2016 20:45:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD95DAD-5278-4252-B179-7EE5F82CA038@gmail.com> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 17:45:34 -0000 > On 13 Aug 2016, at 6:35 PM, Joe Touch wrote: >=20 > Hi, all, >=20 > This issue is already been discussed in TCPM. Please review the = existing > thread and continue discussion there. >=20 > A quick summary from my viewpoint: >=20 > a) there already is a draft >=20 > b) IMO, the Linux code is just (and yet another) bug based on an > incorrect read of RFC 5961, not worthy of even an errata >=20 > All of this is in the thread on TCPM. Please discuss it there. Hi, Joe I=E2=80=99ve read the thread, but I disagree with your conclusion there = ([1]) for several reasons. First, RFCs should be clear enough that reasonably competent = implementers will get it right. I think it=E2=80=99s safe to say that = Linux kernel developers are reasonably competent as a whole, so if they = got it wrong the RFC is not clear enough and requires a clarification in = one form or another. The fact that Microsoft got it right is not proof = that any competent developer will get it right. Second, section 7 talks about rate-limiting to prevent DoS. It talks = about protecting bandwidth and CPU utilization. It states that "An = implementation may take an excessive number of invocations of the = throttling mechanism as an indication that network conditions are = unusual or hostile.=E2=80=9D All of this is global to the system, not = specific to one connection or another. As far as bandwidth is concerned, = there is no difference between sending 5 Challenge Acks on each of 20 = connections, or 100 Challenge Acks on a single connection.=20 Third, if a machine has enough CPU and bandwidth to allow X challenge = acks per second, then dividing X by the number of concurrent connections = sets a per-connection limit is too low for the mechanism to function = well.=20 Of course, now that we know about the attack it seems obvious that the = limit should be per-connection and that we shouldn=E2=80=99t let one = connection starve other connections for challenge-acks. But it=E2=80=99s = not so obvious that the RFC did not need to mention it. Yoav [1] = https://mailarchive.ietf.org/arch/msg/tcpm/nSdJbewUxer4GLfKJic924XXryE= From nobody Sat Aug 13 10:59:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531612D13F for ; Sat, 13 Aug 2016 10:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQJb1bUSYAne for ; Sat, 13 Aug 2016 10:59:51 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6FA12D0CA for ; Sat, 13 Aug 2016 10:59:51 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id f123so13777281qkd.1 for ; Sat, 13 Aug 2016 10:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jLYcYtrMvE/v8d9a5e/LOggrpgT8E6gM5YXwrwcy0Ys=; b=PXACtj4hUVqQlMVPnQ5FzxTfgOFwMJMV42e+XIeIk5zCOTzn7/5Z0CEBT7/kBJ27PL sItOrm/rGIcoljmgYxEYOJXtsYbGlpFkCrcQ9svWfye9dqni2TIhVBzV13hlTuunKX4/ RK9DfYdfZj8uM8VJZVXzKbw9n6Tq22xd4rgAraO8FsOlieg+YcgxlfjgCe4YffrZUPEo gJFYXq5y0Q4YWNkMeS3kKqzGRevOY2jos99sNMGFmWFEJ/+/I9Wj2T3C258Klkop6CJh Anfh5RVnwagRAZkf3+OMZN5GuSusdUUWKrHVam/bQjDaQ+9oHX85cKUs0Z3W74Y+l76W IZmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jLYcYtrMvE/v8d9a5e/LOggrpgT8E6gM5YXwrwcy0Ys=; b=be9AQac1gOcAks/XPuA/d2uWcdkhq8wDg9CkXBtfoo64zOyE9MdXk2Mp8BHNkEftam NbXRt/FdjL8fPBfgbiyqOCods6NKN/ibsjVuktUjp5SQPDWBaeLHok/wkhdalv2Z6QX5 qIyiRd6mKeSE+ANkgeZ4+X9EPvv/vMBfzGAobRCIE2bWKHIQ3Qq2uWJdQPQVEiYc+tSV nR2nWzZ5cIUuszHPNwK41cOwX3xjjvwh1unFxwJm5RzKtN9xCykVvzO+aKPpKtnI3XcA 051IbFAkA9nWsDn0FhQnRxeiWbB//QCWisAjjSCwf6wi3pQZ7jZdrt4sMan9rV5yKjYV Daeg== X-Gm-Message-State: AEkoousjbk7C9M/lJGcfTkC9tG4tTPT9xbSG5UAr41sHzYUQocu5T8M4XSq3DsE2S+OyfQ== X-Received: by 10.55.122.65 with SMTP id v62mr24262387qkc.120.1471111190503; Sat, 13 Aug 2016 10:59:50 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id c26sm7777430qte.1.2016.08.13.10.59.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 10:59:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sat, 13 Aug 2016 13:59:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77C933DE-1F7A-40DE-B903-5DDCEAAC2FCE@gmail.com> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> To: Joe Touch Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 17:59:54 -0000 Sent from my iPhone > On Aug 13, 2016, at 11:35 AM, Joe Touch wrote: >=20 > Hi, all, >=20 > This issue is already been discussed in TCPM. Please review the existing > thread and continue discussion there. >=20 > A quick summary from my viewpoint: >=20 > a) there already is a draft >=20 > b) IMO, the Linux code is just (and yet another) bug based on an > incorrect read of RFC 5961, not worthy of even an errata >=20 > All of this is in the thread on TCPM. Please discuss it there. >=20 Thank you, Joe! > Joe >=20 >=20 >=20 >> On 8/13/2016 6:44 AM, kathleen.moriarty.ietf@gmail.com wrote: >> Hello, >>=20 >> Some of you may have seen the Linux flaw announced a couple of days ago f= rom an implementation of RFC5961. Here's a pretty good description with the= text from those that found the flaw: >>=20 >> https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor= _users_open_corrupted_communications/ >>=20 >> RFC5961 doesn't specify the use of a global counter. Should we make that= clear with errata or is it worth an update? Since Stephen & I read it as a= n implementation problem (that might be an issue elsewhere), I think errata i= s fine. It would be good to have some other opinions on this in case we are= missing something. >>=20 >> Thanks, >> Kathleen=20 >>=20 >> Sent from my iPhone >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 From nobody Sat Aug 13 11:02:14 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC8112D0B7 for ; Sat, 13 Aug 2016 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bw1Ih1CCphU for ; Sat, 13 Aug 2016 11:02:11 -0700 (PDT) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7832A12B071 for ; Sat, 13 Aug 2016 11:02:11 -0700 (PDT) Received: by mail-qt0-x243.google.com with SMTP id u25so658651qtb.3 for ; Sat, 13 Aug 2016 11:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gw/kutUaeD2mUa1yJVX+qF//2/wwVINh1Az3KOjbEUI=; b=Kw4ZeP2ExGuOBPuX3CSt1Th3OHL8zcYlCTd4Y/QSWO1IbZEWRJwuQljXU6NJqbL+4u 7QIlDS/7sW8V8VgAezelThpvF5hXN66m1wmSlHVeE33r9/My1JQS8PFmEcamCDZf0bNW gLQBYJLRLJuWIFA5t0aquRsD3E+A9omMZ5k2GIQ+sLbgdlQGJbcFkPU75mc/pMT9ZYt5 s7H9Pn4dajBsmo268/GwZ9LdkhV6dsw5k2SGeHv/VwplQKxzT+7Vo/PpAAQ8ChHofXuA Plbo2AHH8oDvwLBj0+fFDwdA8SUt1eHVepTw7ZdfZ9rnPuBBWcEL0Avm7u77bW9LPxzf GZHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gw/kutUaeD2mUa1yJVX+qF//2/wwVINh1Az3KOjbEUI=; b=jtMRRDZcAAhlFp3Ib0G6OgnTQxPTtjlAiWXYLJvygoZbMNpQ+FJ7y9KBCcifSaBF3l KTWAgT7lE+XZdZPNYrcLK7sMmv70lTInGJOjwvsHS7uDVFVrq/V1KIcGsZqJMv+tCctz 3O10K1mpNOLdUrwZB0YcEverqxuM1DUBhOku/29wk2ijuriFeRDx11fX2v0rzIz9CT7D URorDTVGgfSwFhmaLrd6Gq/IYje9LRM28Qhm533OWkGt8FjYS2jzMBupTAPkB73Fwm5t AMOHuImB8UA+48KihJaFwcWcqQIWfYyWoP49Lb3Cx2ep70GzOjMjQWzl6UIeKE4kzYSq 294w== X-Gm-Message-State: AEkoouvhBcUp/EiTKIOzS7CWXPtxlDi3zHJA6pK0uPYNog8SHMGlDSSXyktrLMMInRKigg== X-Received: by 10.200.56.90 with SMTP id r26mr23135877qtb.37.1471111330484; Sat, 13 Aug 2016 11:02:10 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id j188sm6492467qke.22.2016.08.13.11.02.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Aug 2016 11:02:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: <9BD95DAD-5278-4252-B179-7EE5F82CA038@gmail.com> Date: Sat, 13 Aug 2016 14:02:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <9BD95DAD-5278-4252-B179-7EE5F82CA038@gmail.com> To: Yoav Nir Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 18:02:13 -0000 Sent from my iPhone > On Aug 13, 2016, at 1:45 PM, Yoav Nir wrote: >=20 >=20 >> On 13 Aug 2016, at 6:35 PM, Joe Touch wrote: >>=20 >> Hi, all, >>=20 >> This issue is already been discussed in TCPM. Please review the existing >> thread and continue discussion there. >>=20 >> A quick summary from my viewpoint: >>=20 >> a) there already is a draft >>=20 >> b) IMO, the Linux code is just (and yet another) bug based on an >> incorrect read of RFC 5961, not worthy of even an errata >>=20 >> All of this is in the thread on TCPM. Please discuss it there. >=20 > Hi, Joe >=20 > I=E2=80=99ve read the thread, but I disagree with your conclusion there ([= 1]) for several reasons. >=20 > First, RFCs should be clear enough that reasonably competent implementers w= ill get it right. I think it=E2=80=99s safe to say that Linux kernel develop= ers are reasonably competent as a whole, so if they got it wrong the RFC is n= ot clear enough and requires a clarification in one form or another. The fac= t that Microsoft got it right is not proof that any competent developer will= get it right. >=20 > Second, section 7 talks about rate-limiting to prevent DoS. It talks about= protecting bandwidth and CPU utilization. It states that "An implementation= may take an excessive number of invocations of the throttling mechanism as a= n indication that network conditions are unusual or hostile.=E2=80=9D All of= this is global to the system, not specific to one connection or another. As= far as bandwidth is concerned, there is no difference between sending 5 Cha= llenge Acks on each of 20 connections, or 100 Challenge Acks on a single con= nection.=20 >=20 > Third, if a machine has enough CPU and bandwidth to allow X challenge acks= per second, then dividing X by the number of concurrent connections sets a p= er-connection limit is too low for the mechanism to function well.=20 >=20 > Of course, now that we know about the attack it seems obvious that the lim= it should be per-connection and that we shouldn=E2=80=99t let one connection= starve other connections for challenge-acks. But it=E2=80=99s not so obviou= s that the RFC did not need to mention it. You may want to chime in on the TCPM thread to keep this in one place. Thanks, Kathleen=20 >=20 > Yoav >=20 > [1] https://mailarchive.ietf.org/arch/msg/tcpm/nSdJbewUxer4GLfKJic924XXryE= From nobody Mon Aug 15 11:05:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867C612D500 for ; Mon, 15 Aug 2016 11:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APxf-4CmfNnN for ; Mon, 15 Aug 2016 11:04:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EF412B009 for ; Mon, 15 Aug 2016 11:04:59 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id b62so86189957iod.3 for ; Mon, 15 Aug 2016 11:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ltd11PH94DyE5e/KhO3TqtZ+MHraDJV7UmZMc3f5+ac=; b=qH1257h/ZIo3Vj8FuZaL3KpAfn/hmhwB8cjYklOJsu2v9LaYUIYf/Ky7DntLYv1XCE UA6pFVPF3KXikXeIGLXv4u4pglaEuZ+nKvEpu+0moRq4vBoxDm6j/PMs5bX0gMPhLtPS zwZBJKHt+8/kBjPCEeRi+hj20RT9/MDEH1GjlknKlywDnYjzFTkNSal3gIKcOMOQu6I2 E1ojJLwExyOjtACAj8hHblaXmpij+WPROnJuP+ngJ/ckyAqUr5lGhMLhgdC/kjqo/3rg uxhoKnkxZlczA5H72n8rDqSwlPgOgEvoTqP8pZygW9cexiyXs2nEdQ1frxENRVbeQCTk jLlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ltd11PH94DyE5e/KhO3TqtZ+MHraDJV7UmZMc3f5+ac=; b=Bw9Sz/fdqesuuH/XmKxLoIL7fJMR+B9ITuPIeygM/erxbgVX2ysjsj7kDlhHAh/uWe LU8zzkRKMPo4Af3aVWqtsy46HNCJohrIj3oxfnlZbtEwh/u+JZX+3WERH0O2rbuDE1rn DAFn56FynLSH43rdszMaKXiXW7Zy/Rh2ZcFLatjDatt8W1tfL93/ElVq7p52V/bC2Tj5 +3dZVFC97Det/Qn7yYIW/ANES4td1N4kYNBZmrT/CA2ew6VXgtvuEEBzjjkoewR21E4/ uXe0Mtob92EBkquKSsuJCjUxbgHgO+61MqZT5rQW2ZNA2nEM2S47Y3q6ORprr6OldHTz SgQw== X-Gm-Message-State: AEkoouvwMpc/KrvC94B+bSA3u9R2F+HG68ezlQEV8c/VST4cy1iClIXguqkz5OclhElAsI4XVRU8rBEUflg8gg== X-Received: by 10.107.129.97 with SMTP id c94mr35201230iod.102.1471284298552; Mon, 15 Aug 2016 11:04:58 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.133.28 with HTTP; Mon, 15 Aug 2016 11:04:57 -0700 (PDT) In-Reply-To: References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <9BD95DAD-5278-4252-B179-7EE5F82CA038@gmail.com> From: Daniel Migault Date: Mon, 15 Aug 2016 14:04:57 -0400 X-Google-Sender-Auth: eNWv3RiFIUQV4Q7hm-hFHulAkjs Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113e8ab2faa24d053a2011b7 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:05:01 -0000 --001a113e8ab2faa24d053a2011b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, My understanding is that the current specification can lead - and has lead to - to unsecured implementations on major systems. I am not either convinced that it is an implementation specific issue, and in the worst case, specifications should have provided more guidance. As a result, specifications should be updated in some ways, and we should make sure future implementers are aware of the update. I think an update is a safer path than the errata. BR, Daniel On Sat, Aug 13, 2016 at 2:02 PM, wrote: > > > Sent from my iPhone > > > On Aug 13, 2016, at 1:45 PM, Yoav Nir wrote: > > > > > >> On 13 Aug 2016, at 6:35 PM, Joe Touch wrote: > >> > >> Hi, all, > >> > >> This issue is already been discussed in TCPM. Please review the existi= ng > >> thread and continue discussion there. > >> > >> A quick summary from my viewpoint: > >> > >> a) there already is a draft > >> > >> b) IMO, the Linux code is just (and yet another) bug based on an > >> incorrect read of RFC 5961, not worthy of even an errata > >> > >> All of this is in the thread on TCPM. Please discuss it there. > > > > Hi, Joe > > > > I=E2=80=99ve read the thread, but I disagree with your conclusion there= ([1]) > for several reasons. > > > > First, RFCs should be clear enough that reasonably competent > implementers will get it right. I think it=E2=80=99s safe to say that Lin= ux kernel > developers are reasonably competent as a whole, so if they got it wrong t= he > RFC is not clear enough and requires a clarification in one form or > another. The fact that Microsoft got it right is not proof that any > competent developer will get it right. > > > > Second, section 7 talks about rate-limiting to prevent DoS. It talks > about protecting bandwidth and CPU utilization. It states that "An > implementation may take an excessive number of invocations of the > throttling mechanism as an indication that network conditions are unusual > or hostile.=E2=80=9D All of this is global to the system, not specific to= one > connection or another. As far as bandwidth is concerned, there is no > difference between sending 5 Challenge Acks on each of 20 connections, or > 100 Challenge Acks on a single connection. > > > > Third, if a machine has enough CPU and bandwidth to allow X challenge > acks per second, then dividing X by the number of concurrent connections > sets a per-connection limit is too low for the mechanism to function well= . > > > > Of course, now that we know about the attack it seems obvious that the > limit should be per-connection and that we shouldn=E2=80=99t let one conn= ection > starve other connections for challenge-acks. But it=E2=80=99s not so obvi= ous that > the RFC did not need to mention it. > > You may want to chime in on the TCPM thread to keep this in one place. > > > Thanks, > Kathleen > > > > Yoav > > > > [1] https://mailarchive.ietf.org/arch/msg/tcpm/ > nSdJbewUxer4GLfKJic924XXryE > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a113e8ab2faa24d053a2011b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My understanding is that = the current specification can lead - and has lead to - to unsecured impleme= ntations on major systems. I am not either convinced that it is an implemen= tation specific issue, and in the worst case, specifications should have pr= ovided more guidance. As a result, specifications should be updated in some= ways, and we should make sure future implementers are aware of the update.= I think an update is a safer path than the errata.

BR,
Daniel

On Sat, Aug 13, 2016 at 2:02 PM, <kathleen.moriarty.iet= f@gmail.com> wrote:


Sent from my iPhone

> On Aug 13, 2016, at 1:45 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>
>> On 13 Aug 2016, at 6:35 PM, Joe Touch <touch@isi.edu> wrote:
>>
>> Hi, all,
>>
>> This issue is already been discussed in TCPM. Please review the ex= isting
>> thread and continue discussion there.
>>
>> A quick summary from my viewpoint:
>>
>> a) there already is a draft
>>
>> b) IMO, the Linux code is just (and yet another) bug based on an >> incorrect read of RFC 5961, not worthy of even an errata
>>
>> All of this is in the thread on TCPM. Please discuss it there.
>
> Hi, Joe
>
> I=E2=80=99ve read the thread, but I disagree with your conclusion ther= e ([1]) for several reasons.
>
> First, RFCs should be clear enough that reasonably competent implement= ers will get it right. I think it=E2=80=99s safe to say that Linux kernel d= evelopers are reasonably competent as a whole, so if they got it wrong the = RFC is not clear enough and requires a clarification in one form or another= . The fact that Microsoft got it right is not proof that any competent deve= loper will get it right.
>
> Second, section 7 talks about rate-limiting to prevent DoS. It talks a= bout protecting bandwidth and CPU utilization. It states that "An impl= ementation may take an excessive number of invocations of the throttling me= chanism as an indication that network conditions are unusual or hostile.=E2= =80=9D All of this is global to the system, not specific to one connection = or another. As far as bandwidth is concerned, there is no difference betwee= n sending 5 Challenge Acks on each of 20 connections, or 100 Challenge Acks= on a single connection.
>
> Third, if a machine has enough CPU and bandwidth to allow X challenge = acks per second, then dividing X by the number of concurrent connections se= ts a per-connection limit is too low for the mechanism to function well. >
> Of course, now that we know about the attack it seems obvious that the= limit should be per-connection and that we shouldn=E2=80=99t let one conne= ction starve other connections for challenge-acks. But it=E2=80=99s not so = obvious that the RFC did not need to mention it.

You may want to chime in on the TCPM thread to keep this in one plac= e.


Thanks,
Kathleen
>
> Yoav
>
> [1] https://mailarchive.i= etf.org/arch/msg/tcpm/nSdJbewUxer4GLfKJic924XXryE
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a113e8ab2faa24d053a2011b7-- From nobody Mon Aug 15 11:33:41 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4602112B071 for ; Mon, 15 Aug 2016 11:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 8QHLmX6nFx9P for ; Mon, 15 Aug 2016 11:33:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8441E12B02D for ; Mon, 15 Aug 2016 11:33:37 -0700 (PDT) Received: from [128.9.184.74] ([128.9.184.74]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u7FIXO8U023617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Aug 2016 11:33:25 -0700 (PDT) To: Yoav Nir , Kathleen.Moriarty.ietf@gmail.com References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> From: Joe Touch Message-ID: <0287e9de-948c-951f-8aff-65e48c85c99f@isi.edu> Date: Mon, 15 Aug 2016 11:33:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:33:39 -0000 Take this to TCPM. Again. On 8/13/2016 7:56 AM, Yoav Nir wrote: >> On 13 Aug 2016, at 4:44 PM, Kathleen.Moriarty.ietf@gmail.com wrote: >> >> Hello, >> >> Some of you may have seen the Linux flaw announced a couple of days ago from an implementation of RFC5961. Here's a pretty good description with the text from those that found the flaw: >> >> https://www.google.com/amp/www.theregister.co.uk/AMP/2016/08/10/linux_tor_users_open_corrupted_communications/ >> >> RFC5961 doesn't specify the use of a global counter. > Well, not is no many words, but see section 7 [1]: > > In order to alleviate multiple RSTs/SYNs from triggering multiple > challenge ACKs, an ACK throttling mechanism is suggested as follows: > > 1) The system administrator can configure the number of challenge > ACKs that can be sent out in a given interval. For example, in > any 5 second window, no more than 10 challenge ACKs should be > sent. > > 2) The values for both the time and number of ACKs SHOULD be tunable > by the system administrator to accommodate different perceived > levels of threat and/or system resources. > > I think it’s pretty clear from both the above and the rest of the section that these rate-limits are intended to be global. Anyone following this spec would understand it that way. > >> Should we make that clear with errata or is it worth an update? Since Stephen & I read it as an implementation problem (that might be an issue elsewhere), I think errata is fine. > I don’t think this is a buggy implementation of RFC 5961. I think that’s RFC 5961 specifying a bug. According to guideline number 7 of [2] this should not be an erratum. Nevertheless, those guidelines are not immutable rules, so you and Stephen can decide that a verified erratum is fine. But I’m not convinced that implementers read errata. > >> It would be good to have some other opinions on this in case we are missing something. > I think this will affect every implementation by any implementer who hasn’t read the research by those “eggheads at the University of California, Riverside” or the Register article. I think an update is the correct path. > >> Thanks, >> Kathleen > Just my 2 cents > > Yoav > > [1] https://tools.ietf.org/html/rfc5961#section-7 > [2] https://www.ietf.org/iesg/statement/errata-processing.html > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Aug 18 03:13:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6D12D8B1 for ; Thu, 18 Aug 2016 03:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.148 X-Spam-Level: **** X-Spam-Status: No, score=4.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RCVD_IN_SBL_CSS=3.335, SPF_FAIL=0.001] autolearn=no autolearn_force=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 KkNlTdzzJ3KI for ; Thu, 18 Aug 2016 03:13:08 -0700 (PDT) Received: from p3nlsmtpcp01-02.prod.phx3.secureserver.net (p3nlsmtpcp01-02.prod.phx3.secureserver.net [184.168.200.140]) (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 46D0A12D8DB for ; Thu, 18 Aug 2016 03:13:06 -0700 (PDT) Received: from p3plcpnl0094.prod.phx3.secureserver.net ([184.168.200.203]) by : HOSTING RELAY : with SMTP id aKGzbhB2ALfDGaKGzbnhh4; Thu, 18 Aug 2016 03:10:05 -0700 Received: from [201.55.176.198] (port=45491 helo=wuvs.org) by p3plcpnl0094.prod.phx3.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1baKGy-0003BG-Co; Thu, 18 Aug 2016 03:10:05 -0700 From: ietf To: "vinays" , "ietf" , "sarikaya" , "lloyd.wood" , "saag" Date: Thu, 18 Aug 2016 13:09:54 +0300 Message-ID: <0000cd2c22c0$a9ca2296$7a9281ad$@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_011A466E.3CD5A2C8" X-Mailer: Microsoft Office Outlook, Build 17.551210 Thread-Index: AdHywtC8XILOdnGCUnPUVi+76bSBbg== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - p3plcpnl0094.prod.phx3.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - frobbit.se X-Get-Message-Sender-Via: p3plcpnl0094.prod.phx3.secureserver.net: authenticated_id: jdempsey@cadusys.com X-Authenticated-Sender: p3plcpnl0094.prod.phx3.secureserver.net: jdempsey@cadusys.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfCHw4mwMEw125EejzohSDKG92as2UX/hzO/EOrXP0GWGnHla//ehPQK3hngMBbjMo8h02Oyf74W3eXeGFXwyfRXe4xcjzrh4elmJaZYc46OadP0TIYzw rMYbqqtV7FLKkJzsfgg5OfUsV2CX5ulBlUCCwukG+k6OybjXzBHQyppLCH2O+J5ZXhobvYXFVFoNtw== Archived-At: Subject: [saag] just hard facts X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 10:13:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0002_011A466E.3CD5A2C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, I've just made a report that is based just on hard facts, you can find it here ietf ------=_NextPart_000_0002_011A466E.3CD5A2C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Greetings,

 

= I've just made a report that is based just on hard= facts, you can find it here http://trehequanky.elmresource.org/e4tdlp=

 

ietf

------=_NextPart_000_0002_011A466E.3CD5A2C8-- From nobody Thu Aug 25 06:25:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB512D15F for ; Thu, 25 Aug 2016 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og5EY_3cSL_H for ; Thu, 25 Aug 2016 06:24:59 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40AB12D137 for ; Thu, 25 Aug 2016 06:24:58 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id q128so239152992wma.1 for ; Thu, 25 Aug 2016 06:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:references:to:message-id:mime-version; bh=QxNMmBXYPyjpVa4/AUMjes064xK2iylW0cxVjzWI56E=; b=L5Grtcha7joIUS2p2okxivQR4AJPEpjOfgcmunk1D9PfP3F0QJ0/K+r+j8+inM/QA2 YGisvA5IZkPqNS4xhttLIedG2f0sm3Tbq4ICl8ryyW9OF4xBq4fIEG6qWLlM2plsXa6U DQsPoixIUoD42Af4izJI9TyltbWXt//OmDziFMQm9cHtYgQrVUpoTISbsPJpOf/XRQtp 9sAvWa8J0dpM3Z5CFdLuICCZCWZDcFnkvL8iYrAdSEdhb2UQb6tnhj7u/3YL3sBQUSFP l/hIwmr083NVc7trOVAl5Xl1DilDAoLKPoXSTgMIUZDzA5y69l6eg9K8tVH9JWim3oLJ Q6qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=QxNMmBXYPyjpVa4/AUMjes064xK2iylW0cxVjzWI56E=; b=dYIMWLMTliI7xuvzIyJ8i6EYyAJG9OQIJUV0uGtyM1nvffbMpzuhS9gv32MwkNXbvc QrWX477i5WWA494ihaz8Y48S1mLaXDuxQ4EXSbvTR3Ygs+P7KlHxKaY+2iIuV7Ba+jvu 9IDg1oA2w7hDi+Ata2bQIsT4dO81P/JfADAFngPx7tGq9liRWKai+oju/tDXGPTTDehE pxH3t8w3K1CU79PY5TRjd5KBsPw5yqqipXW+Y52b+J9NZJW8G8lgVO79kQGiQxN9E6XV Ammr3R3vaE8LZet5nmm6c2WI/xqb9WHzh+Z+iY+Aoy0BVH+wZN/NFSpQ0dB2MyfC+yOR yMlA== X-Gm-Message-State: AE9vXwMoboK5ihUupoGCuC+fWUaldx/lnOf736dBxLAdnMzvhlXFB/BhKo2lSgGw4eDRrA== X-Received: by 10.28.52.135 with SMTP id b129mr8364011wma.107.1472131497141; Thu, 25 Aug 2016 06:24:57 -0700 (PDT) Received: from [172.24.249.152] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id q137sm38829359wmd.19.2016.08.25.06.24.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 06:24:56 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_6E07C264-10CE-464D-A070-0657F27BFFF6" Date: Thu, 25 Aug 2016 16:24:54 +0300 References: <147213091252.13606.11582747034718728356.idtracker@ietfa.amsl.com> To: Security Area Advisory Group Message-Id: <603E2302-FFF8-4A0B-9D21-5A63F2A56302@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [saag] Fwd: New Version Notification for draft-nir-saag-rfc3552bis-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:25:03 -0000 --Apple-Mail=_6E07C264-10CE-464D-A070-0657F27BFFF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. As discussed at the SAAG meeting in Berlin, this is version -00 of the = the revision of RFC 3552 (=E2=80=9CGuidelines for Writing RFC Text on = Security Considerations=E2=80=9D). This version is mostly RFC 3552 with minor changes: Updated references where the original referenced RFCs have been = obsoleted Added missing references Moved several references from Normative to Informative.=20 Minor nit fixes New authors; old authors acknowledged in section 7. Now we can start talking about changes that need to be made. The XML is maintained in GitHub: https://github.com/IETF-SAAG/RFC3552bis = Feel free to suggest changes using PRs or emails to this list. Please = email this list with a link even if you submit a PR, because discussions = happen on list, not on GitHub. Regards Yoav > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nir-saag-rfc3552bis-00.txt > Date: 25 August 2016 at 4:15:12 PM GMT+3 > To: "Yoav Nir" , "Magnus Westerlund" = >=20 >=20 > A new version of I-D, draft-nir-saag-rfc3552bis-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-saag-rfc3552bis > Revision: 00 > Title: Guidelines for Writing RFC Text on Security = Considerations > Document date: 2016-08-25 > Group: Individual Submission > Pages: 44 > URL: = https://www.ietf.org/internet-drafts/draft-nir-saag-rfc3552bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-nir-saag-rfc3552bis/ > Htmlized: = https://tools.ietf.org/html/draft-nir-saag-rfc3552bis-00 >=20 >=20 > Abstract: > All RFCs are required to have a Security Considerations section. > Historically, such sections have been relatively weak. This = document > provides guidelines to RFC authors on how to write a good Security > Considerations section. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_6E07C264-10CE-464D-A070-0657F27BFFF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

As discussed at the SAAG meeting in Berlin, this is version = -00 of the the revision of RFC 3552 (=E2=80=9CGuidelines for Writing RFC = Text on Security Considerations=E2=80=9D).

This version is mostly RFC 3552 with = minor changes:
  • Updated references where the original referenced RFCs have = been obsoleted
  • Added missing references
  • Moved several references from Normative to = Informative. 
  • Minor nit fixes
  • New authors; old authors acknowledged in section = 7.

Now we = can start talking about changes that need to be made.

The XML is maintained in = GitHub: https://github.com/IETF-SAAG/RFC3552bis

Feel free to suggest = changes using PRs or emails to this list. Please email this list with a = link even if you submit a PR, because discussions happen on list, not on = GitHub.

Regards

Yoav

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nir-saag-rfc3552bis-00.txt
Date: = 25 August 2016 at 4:15:12 PM = GMT+3
To: = "Yoav Nir" <ynir.ietf@gmail.com>, "Magnus Westerlund" <magnus.westerlund@ericsson.com>

A new version of I-D, draft-nir-saag-rfc3552bis-00.txt
has been successfully submitted by Yoav Nir and posted to = the
IETF repository.

Name: = draft-nir-saag-rfc3552bis
Revision: 00
Title:= = Guidelines for Writing RFC Text on Security Considerations
Document date: 2016-08-25
Group:= = Individual Submission
Pages: 44
URL: =            https://www.ietf.org/internet-drafts/draft-nir-saag-rfc3552bis-= 00.txt
Status: =         https://datatracker.ietf.org/doc/draft-nir-saag-rfc3552bis/=
Htmlized:       https://tools.ietf.org/html/draft-nir-saag-rfc3552bis-00

Abstract:
=   All RFCs are required to have a Security Considerations = section.
  Historically, such sections have = been relatively weak.  This document
=   provides guidelines to RFC authors on how to write a good = Security
  Considerations section.




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.

The IETF = Secretariat


= --Apple-Mail=_6E07C264-10CE-464D-A070-0657F27BFFF6-- From nobody Thu Aug 25 12:47:37 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5547F12D0EA for ; Thu, 25 Aug 2016 12:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu7FDwHzMKxs for ; Thu, 25 Aug 2016 12:47:35 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5792D12D0A0 for ; Thu, 25 Aug 2016 12:47:35 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id l2so56603002qkf.3 for ; Thu, 25 Aug 2016 12:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Cx3MwG2Px+m9WMM08hbFjnMcEgfKYv4M4lCjK0rgWMI=; b=DekH36Fr49PHt0B4y4Qkv02oHbm9z+zV4sgdSQqdOSyevPKg2XsFRgToI1W7CCwnyA vtI05e6DY3Txzniev3vLTPbupnk4cHW2IuCTWiD4PGcfRHh7JbUnsvwx8vX3zudwxOOw XEVf4B7xlz0ACA4CzuAzG/1QRXKJjaNenG7hr+lzo1zYGE1cup9Gna1SpXT51e6Km3dh HDxoOfS9pWwetIJiaQXjH1/VJRHJXOjRbx766AjRXN2SKH9VqzrrAqyyyVYgO5vBupC2 U1bGKopqbgYtbrFtHbXpvX1daN+m7L7SHXLiwnqgV2CC6jJytkm+HIQml96UbKOd36r5 6Frg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Cx3MwG2Px+m9WMM08hbFjnMcEgfKYv4M4lCjK0rgWMI=; b=iRBtVmsowE7SY5qn8zoP+Ttxn18f3FxFAyjsi6QDFQ/4zT2d9mHkVmcWIEa6CDmoKt rE4XWbgj/OMQj2SKGznfMvkcGx5v1rd9MhADplA6u2ZXROr3gSAbwp63pCKyupcGNgP6 P+gfgZvs+s1eBf/xprKVc9rzOxEWZODpAKcPip9L/aG8tcMmQkFE6mchCbSjxu7Glfh5 a0PdWspypEDhfzGgz3fZ9rJJ80gnMdlj759lokM45LM/BvxBlSpRiJF0fQtAuLsQUMbX XxDcy+6d28b5DqqDxn7swFdmB8W8Vv2uErtADPICCPJNRTT8Grow+O9u6NHwbNjWcYEZ SQJA== X-Gm-Message-State: AE9vXwM/4XCT86RccgGaaSWN2vffqDuj+NwxAM0VPA8lM9Rc/385y/8eihYkiiDOeOyxgNCfsHTC0Mdk0m+erQ== X-Received: by 10.55.59.202 with SMTP id i193mr11683807qka.125.1472154454361; Thu, 25 Aug 2016 12:47:34 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Thu, 25 Aug 2016 12:47:33 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 25 Aug 2016 15:47:33 -0400 X-Google-Sender-Auth: miWCiii1-5pMwtyZr79vfPPB4ak Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a1148bd6a4e8d17053aeaabab Archived-At: Subject: [saag] Little Encoding Gotcha X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 19:47:36 -0000 --001a1148bd6a4e8d17053aeaabab Content-Type: text/plain; charset=UTF-8 Not sure where this comes in. However lots of specs have started using Base64URLEncoded in place of Base64 because the / and + characters have special meaning in URLs and lots of other stuff. So instead of those we have - and _. Great, problem solved! Umm... no... aUkn1IisRZGtQ/o9aFrjyNnsNQkfIQbnCUWXWUA3fYEWIoh+YtoE6jYpu54mbO/J r0LKgdWiyBBR5olKpNKxPmTt2sjcklYHCly3KeJ1GUZwAth1GA== -----END RSA PRIVATE KEY----- Its not just OpenPGP that uses this style of armor, it is all over the place. --001a1148bd6a4e8d17053aeaabab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not= sure where this comes in. However lots of specs have started using Base64U= RLEncoded in place of Base64 because the / and + characters have special me= aning in URLs and lots of other stuff.

So instead of those we have - and _. Great, problem solved!

Umm... no...

aUkn1IisR= ZGtQ/o9aFrjyNnsNQkfIQbnCUWXWUA3fYEWIoh+YtoE6jYpu54mbO/J
r0LKgdWiyBBR5olKpNKxPmTt2sjcklYHCly3KeJ1GUZwAth1GA=3D=3D
-----END RSA PRIVATE KEY-----

Its not just Ope= nPGP that uses this style of armor, it is all over the place.
--001a1148bd6a4e8d17053aeaabab-- From nobody Mon Aug 29 14:04:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9112D817 for ; Mon, 29 Aug 2016 14:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F2cDBUiL6rl for ; Mon, 29 Aug 2016 14:04:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333DC12B032 for ; Mon, 29 Aug 2016 14:04:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F3AD5BE29 for ; Mon, 29 Aug 2016 22:04:23 +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 GNVPu06SNw8d for ; Mon, 29 Aug 2016 22:04:22 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 91963BE25 for ; Mon, 29 Aug 2016 22:04:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472504662; bh=lz+1qFai/8HP6Tefn8uj+e+exc9KI5b2zX1pK6qpDn8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=sTI37oPGz1vyDwUsa+T2kgtUpdoJjlBbEozWVtkeSi1DB9GC04k7v4mGCUHIRYGSj c0GDZ1q+m+MLaX0Q7MoYam1FV8zJqBmpJIdtHpfkb/Y7wkgfDDtwLRTUsm3YANoZPB v5lYO8QMbPbl/4jtrX4EcvZhBtttuTtmqqNXgX0U= References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Message-ID: <1d448260-78fa-e397-ac6c-be7f5346c843@cs.tcd.ie> Date: Mon, 29 Aug 2016 22:04:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080603050307090301000902" Archived-At: Subject: [saag] Fwd: [irsg] NomCom 2016-2017: Call for Nominations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 21:04:27 -0000 This is a cryptographically signed message in MIME format. --------------ms080603050307090301000902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI - please consider nominating yourself or others! As you can see from the below, I'm not re-upping for another go around, so a new security area director is needed. S. -------- Forwarded Message -------- Subject: [irsg] NomCom 2016-2017: Call for Nominations Date: Mon, 29 Aug 2016 13:37:08 -0700 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: Working Group Chairs Please forward on to your Working Groups - The 2016-17 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2016. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2016/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2016 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2016/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom-16@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaire= s will be available on September 2, 2016 and have a submission deadline of October 13, 2016. NomCom 2016-17 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark = the field we won=E2=80=99t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 8, 2016. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Lou Berger IAB Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler* Suzanne Woolf IESG Jari Arkko (GEN)* Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2016/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2016/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-16@ietf.org. Thank you for your help in identifying qualified nominees! Lucy Lynch Nomcom Chair 2016-17 nomcom-chair-2016@ietf.org llynch@civil-tongue.net --------------ms080603050307090301000902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4Mjky MTA0MjFaMC8GCSqGSIb3DQEJBDEiBCDIjZPOvmKa9lIGj5qmj1BQZ2KXPnqejQXr1cbi4ZTs lTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA9u/IFu85i/KIk4fZc1nndppvZjTZqsG8GANqxAxiWShW4+dgJmGjC +KA/P8A9QatoX2yrpwTto5zn+WE76jD4iCCWInG97NPor0pU+RkDn2muSOLu5CizmgMcdJ1L 7OecwCUUHffYMJoCkFbMK+yVDiLZttR7gQDYYTJ7a4N/I8+m8pgn5Q19My+MTyS6PJytdujf 4yjve3ehaWjZ7iJ0+39mb8xoL3bbJZTbWZexWgxfTCEacyPYkm6HrAqnoPilcO4ZHApSCUIA NJtIe62eE2KX69ezXv7WpyldGeKVcRHDzNQFZ+3MOlR27IUx27o6iIrxjQI1DXO8u9o5Sk+d AAAAAAAA --------------ms080603050307090301000902-- From nobody Tue Aug 30 18:37:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94FD12D851 for ; Tue, 30 Aug 2016 18:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY66_u1ZYpvG for ; Tue, 30 Aug 2016 18:36:59 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBD012D1AF for ; Tue, 30 Aug 2016 18:36:58 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id l2so37509244qkf.3 for ; Tue, 30 Aug 2016 18:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wmWYzmGW/NW9Ep+cU3s89kQIxCzkHrtYk8GMBP6R6Vg=; b=NcdkPeTfW04wFGawrVBIf+nx4rsqurZdr9hwCKWiXwOWyw4hHYjNmNO45xbn2FjVk4 BnrBmiUKhNdk3PbqeTDfAungPt7WGvsYeNP0q4BwHY8IpRSl0utJ0v69x/bFgGpawFRw FyChHG/8wG+HeTv8DStE7BsN3tRX9FcKS/MNLyHXRI/V5vQgARzmLrCmkfeJ1Ea0IHcZ S6oBKYjp8MftBzSgxWo6KyZA6zY0SrVNurqMVfm7/ivy8cwX99Vsr3jtIimqacdumSnd hcPSOSgaQSCrzeQEtPUzcYprGgK2UuGs2nRAGK93fMvwafY8wJwFpUo3R26Ip1oIkMvm b41g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wmWYzmGW/NW9Ep+cU3s89kQIxCzkHrtYk8GMBP6R6Vg=; b=Mn/V+vLHyHdlNa93FCdqBTx6Xb2/dG2sl2gbjKx8Tiaf3yBmCe3m8GauiKRsfIFbzj rMQjpbWkeJsv6pSCzPOYVp1ESTnptuES7YYHDwHboNzc2EQ/XNJ6X7ehdqcrHdhNO66o LnEjCmzZFdrWT0jgqE9bebXtmbHKR5o7VqPmb5y/SXUVIcXIye+2En+Q0KJnlGX848sJ /AIssSGGVevAizr1Axwc5VdXady9S8tzNrnqMoOj0Jv7R6o0FnY9X8nNFioz6ew/JsKt wz4N2i3HO5RiVAw/QEBauEw/u8+stAxeZgzsY5B+V828K5SpDapslrDwa0e2NvZg2dJi ueKg== X-Gm-Message-State: AE9vXwMsefJoT1E8KNjMIAk3N+S1aMsabR/CkirC6AnzoctgB5aXEBuwP0ERtXzHEuR13OMUtbvigyOea0FhoT1+ X-Received: by 10.55.146.134 with SMTP id u128mr8222337qkd.203.1472607417283; Tue, 30 Aug 2016 18:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.176.7 with HTTP; Tue, 30 Aug 2016 18:36:26 -0700 (PDT) In-Reply-To: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Warren Kumari Date: Tue, 30 Aug 2016 21:36:26 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 01:37:01 -0000 On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell wrote: > > Hiya, > > We had a thread about a year ago on this topic. [1] The feedback iirc > was "go do it right and use D-H." The authors figure they've now gone > and done that [2] and have asked me to consider AD sponsoring the work. > > I've told them I would so long as we don't find any gotchas and it > doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks > to check/ensure that that latter is ok via lots of lovely liaising;-) > > In the meantime, comments here on the technical meat of this would be > appreciated if you have time to review. Having heard no comments in ~1month, Dan and I are forced to assume that the document is absolutely perfect in every way. Now, I'm a little surprised by this - I was thinking that there would be at least one minor typo or something, but apparently not... Seriously, please review -- it is short, and (I believe) a really good idea. This gets you (unauthenticated) encryption wherever people use "open" Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), coffeeshops, airports, etc. Now, like much opportunistic stuff, it doesn't protect against active attacker - but it does force the attacker to be active (and many controller based wifi deployments will notice and try protect against "rouge APs"). It explicitly does *NOT* solve all the worlds ills - we are not claiming that it does; it doesn't remove the need for things like VPNs, TLS, etc -- but it does make open wifi suck a bit less, and that's a good incremental step. We suggest that users not be informed that they are getting this protection, so that they don't think that they are getting more than they actually are... So, please, thoughts, feedback, etc. W > > Cheers, > S. > > [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html > [2] https://tools.ietf.org/html/draft-harkins-owe > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 30 19:09:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE712D8FE for ; Tue, 30 Aug 2016 19:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrjtjvxEJj8W for ; Tue, 30 Aug 2016 19:09:21 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BFE12D8F2 for ; Tue, 30 Aug 2016 19:09:20 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id m60so64764700uam.3 for ; Tue, 30 Aug 2016 19:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fOBGHk1r8SnmWGrlVCOaoPrG5VXZW5+glhXkSM20534=; b=TWh3tofVFjpE3FwYq09x3kmQRPE2v4z1Tmy4vfbHcC8+iRG6DnErpjRzOaTg9Ls547 1V4KUmMQTw461VBCOLjshSiABuGoamvdUnMaLvXKqppszq3pusnc0xTTbUVl05n6mchj hN8reJk7BqKsv1GAjQw/lH0XUo949i+xqcw7HJnJyxS6BSpxVhIr7eTnnByJHF8Dh2ZC pVuWibFsXeX6pjlkfmNIC/63cwBqrjLM91BCihYRWiVEgqD2mXa29i6GxJSX0Vurme46 sB/1J9eScrgA/c0I2MegFX1dKsAhNiDoS8y91ypDD3m/VgUNM5+EzJnd2ZQupO/IBo3A XIGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fOBGHk1r8SnmWGrlVCOaoPrG5VXZW5+glhXkSM20534=; b=MQf9fTS26J+rdA/TlPRN08BOn6KTCZdzcNv8ZZjsuqcBl//idHZvoXd4vOwGKyjv8K jvxwobndUEAEhZf8DKMoxhP04SKXgvxqY1diolb2nE6ZjhTT8HJMmer71cRkIN7NhbgE qIY12tzh+qQzc+yHmxn29EJWt4B+NhxxePvBcqOvFmRc1EFQ29IwrpnGzGy5OdJ+K/19 wEKsSjODDCBT+My5EXjRVS4T/Jsvi27QTWM+4I1IVc/EDShSBm/d2fcUe9F2JMYAocve /stdN+sdvbHxsz9hGX1Iqq/0cbVdIVGI5+RxiKKAwDAq6oe+rsvORjS2Oyxk59T9gFx2 2O+A== X-Gm-Message-State: AE9vXwMud75G5drw2wnDTw+omR1C0H8SDP9QKFrq3dBwms0WlcSMOXIwLAC2NHRjzCpzGpDbQQKbncIXm4WKWQ== X-Received: by 10.31.227.196 with SMTP id a187mr4077945vkh.89.1472609359472; Tue, 30 Aug 2016 19:09:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.135 with HTTP; Tue, 30 Aug 2016 19:09:18 -0700 (PDT) Received: by 10.176.2.135 with HTTP; Tue, 30 Aug 2016 19:09:18 -0700 (PDT) In-Reply-To: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Bernard Aboba Date: Tue, 30 Aug 2016 19:09:18 -0700 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=001a114e0198c3af47053b54958a Archived-At: Cc: "Dan Romascanu \(Dan\)" , saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 02:09:23 -0000 --001a114e0198c3af47053b54958a Content-Type: text/plain; charset=UTF-8 I have read the document. It is not a bad idea. As things stand, IEEE 802.11 security/.1X leaks meta-data (e.g. the initial EAP-Request/Identity exchange) that the proposal would protect. So it has benefits beyond "opportunistic security", such as in WPA2/Enterprise scenarios. The problem is something very much like this was originally suggested for IEEE 802.11 (and rejected) years ago, as part of the work on IEEE 802.11i. The reason for the rejection at the time was the claim that it was too "heavy weight" - that a circa 2004 AP implementing the proposal would consume too much CPU. Processing power has increased considerably in the 10+ years since then so one could make the claim that the original objections are no longer valid (if they were even valid at the time). So to make this more than just "words for the wind" it would be nice to have a path not just to publishing this document in the RFC series, but getting it implemented within IEEE 802.11 STAs and APs, which typically requires inclusion in the IEEE 802.11 standards (or at least work within WFA). Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming that this draft has been put on the agenda so that some progress can be made in that direction, and that discussions have been initiated with the IEEE 802 leadership as described in RFC 7241. If not, Dan Romascanu (the IETF's liaison to IEEE 802) can make that happen. On Aug 30, 2016 6:37 PM, "Warren Kumari" wrote: > On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell > wrote: > > > > Hiya, > > > > We had a thread about a year ago on this topic. [1] The feedback iirc > > was "go do it right and use D-H." The authors figure they've now gone > > and done that [2] and have asked me to consider AD sponsoring the work. > > > > I've told them I would so long as we don't find any gotchas and it > > doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks > > to check/ensure that that latter is ok via lots of lovely liaising;-) > > > > In the meantime, comments here on the technical meat of this would be > > appreciated if you have time to review. > > > Having heard no comments in ~1month, Dan and I are forced to assume > that the document is absolutely perfect in every way. > Now, I'm a little surprised by this - I was thinking that there would > be at least one minor typo or something, but apparently not... > > Seriously, please review -- it is short, and (I believe) a really good > idea. > This gets you (unauthenticated) encryption wherever people use "open" > Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), > coffeeshops, airports, etc. > Now, like much opportunistic stuff, it doesn't protect against active > attacker - but it does force the attacker to be active (and many > controller based wifi deployments will notice and try protect against > "rouge APs"). > > It explicitly does *NOT* solve all the worlds ills - we are not > claiming that it does; it doesn't remove the need for things like > VPNs, TLS, etc -- but it does make open wifi suck a bit less, and > that's a good incremental step. > We suggest that users not be informed that they are getting this > protection, so that they don't think that they are getting more than > they actually are... > > So, please, thoughts, feedback, etc. > > W > > > > > > > > Cheers, > > S. > > > > [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html > > [2] https://tools.ietf.org/html/draft-harkins-owe > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a114e0198c3af47053b54958a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have read the document.

It is not a bad idea.=C2=A0 As things stand, IEEE 802.11 sec= urity/.1X leaks meta-data (e.g. the initial EAP-Request/Identity exchange) = that the proposal would protect.=C2=A0 So it has benefits beyond "oppo= rtunistic security", such as in WPA2/Enterprise scenarios.

The problem is something very much like this was originally = suggested for IEEE 802.11 (and rejected) years ago, as part of the work on = IEEE 802.11i.=C2=A0
The reason for the rejection at the time was the claim that it was too &quo= t;heavy weight" - that a circa 2004 AP implementing the proposal would= consume too much CPU.=C2=A0 Processing power has increased considerably in= the 10+ years since then so one could make the claim that the original obj= ections are no longer valid (if they were even valid at the time).

So to make this more than just "words for the wind"= ; it would be nice to have a path not just to publishing this document in t= he RFC series, but getting it implemented within IEEE 802.11 STAs and APs, = which typically requires=C2=A0 inclusion in the IEEE 802.11 standards (or a= t least work within WFA).

Given the upcoming IETF/IEEE 802.11 cooperation meeting, I&#= 39;m assuming that this draft has been put on the agenda so that some progr= ess can be made in that direction, and that discussions have been initiated= with the IEEE 802 leadership as described in RFC 7241.=C2=A0=C2=A0 If not,= Dan Romascanu (the IETF's liaison to IEEE 802) can make that happen.


On Aug 30, 2016 6= :37 PM, "Warren Kumari" <= warren@kumari.net> wrote:
On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie<= /a>> wrote:
>
> Hiya,
>
> We had a thread about a year ago on this topic. [1] The feedback iirc<= br> > was "go do it right and use D-H." The authors figure they= 9;ve now gone
> and done that [2] and have asked me to consider AD sponsoring the work= .
>
> I've told them I would so long as we don't find any gotchas an= d it
> doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE = folks
> to check/ensure that that latter is ok via lots of lovely liaising;-)<= br> >
> In the meantime, comments here on the technical meat of this would be<= br> > appreciated if you have time to review.


Having heard no comments in ~1month, Dan and I are forced to assume
that the document is absolutely perfect in every way.
Now, I'm a little surprised by this - I was thinking that there would be at least one minor typo or something, but apparently not...

Seriously, please review -- it is short, and (I believe) a really good idea= .
This gets you (unauthenticated) encryption wherever people use "open&q= uot;
Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID),
coffeeshops, airports, etc.
Now, like much opportunistic stuff, it doesn't protect against active attacker - but it does force the attacker to be active (and many
controller based wifi deployments will notice and try protect against
"rouge APs").

It explicitly does *NOT* solve all the worlds ills - we are not
claiming that it does; it doesn't remove the need for things like
VPNs, TLS, etc -- but it does make open wifi suck a bit less, and
that's a good incremental step.
We suggest that users not be informed that they are getting this
protection, so that they don't think that they are getting more than they actually are...

So, please, thoughts, feedback, etc.

W




>
> Cheers,
> S.
>
> [1] https://www.ietf.org/mail-<= wbr>archive/web/saag/current/msg06595.html
> [2] https://tools.ietf.org/html/draft-harkins= -owe
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--001a114e0198c3af47053b54958a-- From nobody Wed Aug 31 02:09:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1576B12DA65 for ; Wed, 31 Aug 2016 02:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k97nSrl1D1A8 for ; Wed, 31 Aug 2016 02:09:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8260E12DA64 for ; Wed, 31 Aug 2016 02:09:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46526BE39; Wed, 31 Aug 2016 10:09:07 +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 a6eeetGE5sMi; Wed, 31 Aug 2016 10:09:05 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55ABEBE32; Wed, 31 Aug 2016 10:09:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472634545; bh=jDhChVMcdYIVxzLm/Yd5EUcEcNl/VVBhUbb6WqsyZ6M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pq94C8Go46Wc4goHf3A9X2JXWWj/6lgm2lPdaIu0dCkAUqKneXLPIYT9oFUWjXbq9 5qrPa+np3pG2QfDf2JsNUWMO/B98VBZlp/L6eYOAIw2G1ckk4ZCb33AIoSYgQPCl3x U+JTdmSvVPeVKcqPzU5yK3iXB95OTpxeAAwBpg9M= To: Bernard Aboba , Warren Kumari References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> Date: Wed, 31 Aug 2016 10:09:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050407030604040509020107" Archived-At: Cc: "Dan Romascanu \(Dan\)" , saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 09:09:10 -0000 This is a cryptographically signed message in MIME format. --------------ms050407030604040509020107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bernard, On 31/08/16 03:09, Bernard Aboba wrote: > So to make this more than just "words for the wind" it would be nice to= > have a path not just to publishing this document in the RFC series, but= > getting it implemented within IEEE 802.11 STAs and APs, which typically= > requires inclusion in the IEEE 802.11 standards (or at least work with= in > WFA). I agree about implementation and deployment being the key here. In terms of getting IEEE's "blessing" as a part of that, we did a chunk of that in and around the last IETF meeting, sent IEEE a liaison [1] and Dan went to the subsequent IEEE meeting where they agreed to allocate ANA codepoints for the OWE scheme. (Dan can elaborate if needed and I'm sure the document will need at least that update.) So I think we have the formal inter-SDO bits well in hand. Any ideas as to how to get running code would be most welcome though. (BTW, in terms of AD sponsoring this, IEEE's reaction to [1] is enough to make me sanguine that we're not causing a fuss by doing this.) >=20 > Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming t= hat > this draft has been put on the agenda so that some progress can be made= in > that direction, and that discussions have been initiated with the IEEE = 802 > leadership as described in RFC 7241. If not, Dan Romascanu (the IETF'= s > liaison to IEEE 802) can make that happen. Yep, that was done, and the topic is on Dan's list of things to monitor I think. Cheers, S. [1] https://datatracker.ietf.org/liaison/1486/ --------------ms050407030604040509020107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MzEw OTA5MDVaMC8GCSqGSIb3DQEJBDEiBCBj6G9CRVQ2RWNCTJcJ88wpKe2ID3m37eCDxvR05UTV vzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQChZGhbi6cP/m7H/59dQDAGqLQ0whfJvG9dykytoCMfQxAW/1XnFxzo 5ndx+fPriepKUN1NNVjbLgVgJ6yfLKwuRtHc7D2ATth4VW0oQJ9of3ftZFy7Ydow7vw1QN1l 0x47rehsaMBiqy6y0HkJA3zQirAXqQMPqkCFmm9j+GBQ8DxIixZC3BirzxHJwV/GzX938glw 7YcybeUzZG85iZllScRaQt8YFyeZpyi2XRPYqcGyMQwPT0zoCIYIqWnGluRxWfAOr1BimQ7y BJWbC/F59lwZm2Sm9Vg9tJjS3lCk38VGIHcxhDjgbmcEiqLwIlzzA6n59U6AqsF714T0dsxe AAAAAAAA --------------ms050407030604040509020107-- From nobody Wed Aug 31 02:47:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0D312D122 for ; Wed, 31 Aug 2016 02:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kgWwGcp60pS for ; Wed, 31 Aug 2016 02:47:53 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7D6127078 for ; Wed, 31 Aug 2016 02:47:53 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u25so22441484qtb.1 for ; Wed, 31 Aug 2016 02:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=tpuBMpC2p8O1SS2eloy6HKnQNHFy157v8tkTm8AlJNI=; b=pCioicALjTx/2EaaOaTUtyK2iIFSKpxq997ifwiqi2CACHe1co5iBpXgWCd6P+iVSb bpsAOEMYGHYYYZNezr93ZAqyHTwa7dXIrge9Ju90bJGtwElTbu2pZ+cKTnM8EJfUx8sF TBfECq2gnO5weONxSiky3zzo1RY5uJyCHQcyqoWdoCwIj7cKLzP5wUCixZwkczxEsblE nrNYemOOhIiP9gM3dazIEkIdp7p86HMUN3WuD7x5Ajs908IXfnjlVPk8KGseqrgDeP29 c6XEx6gNUuRRsXx5NAaETw9a3BYUwSQYFBn7UzPEiLGC9szs2upBVKEvFmUPN01/Gy7H pAiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tpuBMpC2p8O1SS2eloy6HKnQNHFy157v8tkTm8AlJNI=; b=CfYxaWgUrMhez2WT8TOSehWrplteDMgdJw4FHbHvUNEfdMUlMntgFJS8TLRA6s8+PG hs00Xz9MMjjQUYAO+GjZzypT5qOJ1JhlLAV0/vlgjoT5qGGb7D/c1a59M8dWUXSXiE2q F7dtAvIg6Y8JG9s08xKGtt/e81Geq6uw5pyrq7aJILNcKNiUyLtJrjMi82eVlgHwGx+4 O9tGJYVNe+ys/bgUXJmLHW5tnRgma8y8r2qjL30oaUyEpsWBuOsAygva4fiHnjtHDZ73 ExHde5g50VK4IeEmFJ6EHtae+3/bleR8QAQNFzLhv/2A1bl0iyj971reGTT6ubPQ/P4E QKbw== X-Gm-Message-State: AE9vXwNNBX2w2qo82ZvENdSeQV1p7C0/sXr6d4Ctk9Qw1V9OcuebzTzbE9DRRyVWeK79a9Vy/FITUbtROyuNZg== X-Received: by 10.200.51.101 with SMTP id u34mr9280685qta.54.1472636872538; Wed, 31 Aug 2016 02:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Wed, 31 Aug 2016 02:47:52 -0700 (PDT) From: Lishan Li Date: Wed, 31 Aug 2016 17:47:52 +0800 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary=001a1137cfd2abc06c053b5afd1e Archived-At: Subject: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 09:47:54 -0000 --001a1137cfd2abc06c053b5afd1e Content-Type: text/plain; charset=UTF-8 Dear all, According to the comments from Stephen and Randy, we have updated secure DHCPv6. Thanks a lot for your previous help and guidance. we previously dropped the idea of using TOFU for the authentication part of dhcpv6, but we are now considering re-introducing it. We dropped the idea mainly based on a suggestion from Randy, and we are now revisiting the decision based on a suggestion from Stephen. We'd like to resolve this conflict by understanding these suggestions in more detail and by seeing if we can find some middleground/compromise/whatever that everyone can at least live with. So, it would be great if - Randy could re-explain why we should drop TOFU, and whether it's acceptable to re-introduce it (and any conditions we should meet to do so). - Stephen could explain why we should include TOFU, and whether it's acceptable to keep it out of scope. Thanks Lishan --001a1137cfd2abc06c053b5afd1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

According to t= he comments from Stephen and Randy, we have updated secure=C2=A0
= DHCPv6. Thanks a lot for your previous help and guidance.

we previously dropped the idea of using TOFU for the authentication= part
of dhcpv6, but we are now considering re-introducing it.=C2= =A0 We dropped
the idea mainly based on a suggestion from Randy, = and we are now
revisiting the decision based on a suggestion from= Stephen.=C2=A0 We'd like
to resolve this conflict by underst= anding these suggestions in more
detail and by seeing if we can f= ind some middleground/compromise/whatever
that everyone can at le= ast live with.

So, it would be great if
= - Randy could re-explain why we should drop TOFU, and whether it's
=C2=A0 acceptable to re-introduce it (and any conditions we should me= et to
=C2=A0 do so).
- Stephen could explain why we sho= uld include TOFU, and whether it's
=C2=A0 acceptable to keep = it out of scope.

Thanks
Lishan
--001a1137cfd2abc06c053b5afd1e-- From nobody Wed Aug 31 04:37:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1E12DAF5 for ; Wed, 31 Aug 2016 04:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 88dkx2GKlvEM for ; Wed, 31 Aug 2016 04:37:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A84812DAEC for ; Wed, 31 Aug 2016 04:37:52 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7VBbgAS022566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2016 14:37:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7VBbg5k006365; Wed, 31 Aug 2016 14:37:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22470.49542.85452.748009@fireball.acr.fi> Date: Wed, 31 Aug 2016 14:37:42 +0300 From: Tero Kivinen To: Warren Kumari In-Reply-To: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 11:37:56 -0000 Warren Kumari writes: > Seriously, please review -- it is short, and (I believe) a really good idea. > This gets you (unauthenticated) encryption wherever people use "open" > Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), > coffeeshops, airports, etc. > Now, like much opportunistic stuff, it doesn't protect against active > attacker - but it does force the attacker to be active (and many > controller based wifi deployments will notice and try protect against > "rouge APs"). This protocol seems to be using IKEv2 IANA registry, but the protocol does not look like IKEv2, so I think you should fix that by replacing the protocol and just reuse IKEv2 in OWE, in similar ways than 802.15.9 does for 802.15.4. Or the other option would be to make your own IANA registry for this protocol, and not reuse the IKEv2 registry for some protocol that does not have anything to do with IKEv2 or IPsec, then there would be no need to change the protocol. IANA registries are cheap, there is no point of reusing registries for something that are not releated to the original intention of the registry. -- kivinen@iki.fi From nobody Wed Aug 31 04:43:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6812DB01 for ; Wed, 31 Aug 2016 04:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a06XzFEBKDBz for ; Wed, 31 Aug 2016 04:43:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15B812DAF3 for ; Wed, 31 Aug 2016 04:42:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68333BE35; Wed, 31 Aug 2016 12:42:51 +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 bPNcVRKdR8Fo; Wed, 31 Aug 2016 12:42:51 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D9BAEBE29; Wed, 31 Aug 2016 12:42:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472643771; bh=6m0I/0mskv91wDCtjWDbfFSa+GVRRF/2ffddemWjo3A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QK1CcLqwcAcX6qr5vLpm+ihRSO8BDAjPUMayfAzmLTxnE0wrUjgTMK7pRRZxXOEOf zc3L1KDktF3/bNYXPJ8pUQwTaxWj8EK6F4phHthDcUp63qMKV5xA/lRQyst2RKf7Hs HBL0KAT7YSGomn7uqNMf/GMOgC11vLQb/WWe3eSg= To: Lishan Li , saag@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> Date: Wed, 31 Aug 2016 12:42:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060801040001010400090408" Archived-At: Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 11:43:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060801040001010400090408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 31/08/16 10:47, Lishan Li wrote: > Dear all, >=20 > According to the comments from Stephen and Randy, we have updated secur= e > DHCPv6. Thanks a lot for your previous help and guidance. And thanks for doing the work. >=20 > we previously dropped the idea of using TOFU for the authentication par= t > of dhcpv6, but we are now considering re-introducing it. We dropped > the idea mainly based on a suggestion from Randy, and we are now > revisiting the decision based on a suggestion from Stephen. We'd like > to resolve this conflict by understanding these suggestions in more > detail and by seeing if we can find some middleground/compromise/whatev= er > that everyone can at least live with. >=20 > So, it would be great if > - Randy could re-explain why we should drop TOFU, and whether it's > acceptable to re-introduce it (and any conditions we should meet to > do so). > - Stephen could explain why we should include TOFU, and whether it's > acceptable to keep it out of scope. My basic argument here is that earlier specs for DHCP security have not been deployed, so I think we should focus now on specifying something that can be deployed easily, even if that is not as good as one might desire. That's basically following the logic of RFC 7435 [1] and, I think, argues for supporting ToFU. If, however, there's a good argument that something else is what is more likely to be deployed, then I'd be convinced by that. Cheers, S. [1] https://tools.ietf.org/html/rfc7435 >=20 > Thanks > Lishan >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms060801040001010400090408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MzEx MTQyNTBaMC8GCSqGSIb3DQEJBDEiBCDE5ft3GJkQD3aRpYo2MAm8MkQDJNppWzWqkxBO/XPF 6jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB1348cZPcFyTu2OuQaXfNgvNqOvQ6iTQaTq9Rvqi++mKHgzHiG4/i0 WqHfrde0fjTOgRIoy8BzM+KmtRtn2BaXRM00ug992Dfnd2c0Ly130xES99KSIFUff/8z+3vp 0c9rulayeOMFtfAkrePmDcdDpOkIvmb5xtLOWFFFzlFnPZ+CIehkdKGacHqhxCtZWeI1am4r FB7DZhzQ/p7AAjDEx3mFDZSq61V6Y3unC29/PNiMUOD4uZy1k8vLwU/+FjLZOtZu/Se7zRG+ L8qpyXG6hyI/3+9vAYLnu/eOtCFPc5y4CksnHbV5hHiF4IysGqlqLQJcNj0eyuH0fPMaowuX AAAAAAAA --------------ms060801040001010400090408-- From nobody Wed Aug 31 05:00:56 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A092C12B071 for ; Wed, 31 Aug 2016 05:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dsLBLxD02wK6 for ; Wed, 31 Aug 2016 05:00:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56AC12DB13 for ; Wed, 31 Aug 2016 05:00:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bf4CA-0006V5-9h; Wed, 31 Aug 2016 12:00:42 +0000 Date: Wed, 31 Aug 2016 21:01:15 +0900 Message-ID: From: Randy Bush To: Lishan Li In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:00:54 -0000 > - Randy could re-explain why we should drop TOFU, and whether it's > acceptable to re-introduce it (and any conditions we should meet to > do so). tofu is a food; i often have it for breakfast with negi and shoyu. i suspect that this is GMOBD, get married on blind date , with a best man in the middle who has downgrade intentions. [ please excuse extreme use of idiomatic american, but it was hard to resist ] randy From nobody Wed Aug 31 05:38:38 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7E12DB1A for ; Wed, 31 Aug 2016 05:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dapc4S9vp9q for ; Wed, 31 Aug 2016 05:38:34 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7220212DB26 for ; Wed, 31 Aug 2016 05:38:34 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v123so49143521qkh.2 for ; Wed, 31 Aug 2016 05:38: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:from:date:message-id:subject:to :cc; bh=HDL9K/lq1+7ckT5gFqqQCqG+77fKOGp9zph5pLj4qaM=; b=u/JPFxklZ3scVx1oEmdQCBGj76RvtkGRtOEhIoWDPKp7vI1uj71J5AtHxxP3nVjtYW C5Ou/eIYM0nkiOAW45sEy/V07FYnNx60HneHgzhB+eX9L2aQfLLuFrH+hriMpGmakDp6 eKkvc1upeMVbfCbr7GypH5VR6wnrry86HFC6DjWpYvWNcSdWlqwknWAvrlJC7UMUbPhW K2XMGEhe/X70RpK50hDMhi/pZdl9t8ijf9WP+auUqQRJVVZFB6ygAwf9/vwli5+wUaXF oZTzMe0BtlMmzkOYXcgLq7BDqNUIyzEeeNQuWJD5NuSjRUGdPt56kwV4RJM98xCTVIWu LJDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HDL9K/lq1+7ckT5gFqqQCqG+77fKOGp9zph5pLj4qaM=; b=I5cGyk4+uj04KbUbCCz1WYu7ET5FFNzWj0A3zfgzZfM8cvbD0t9dp8WGLzdlNyiVFl hnwy1OwIKFqnUqW+nn78NVbt5i+AvaBviUzQqwG/X4V1INYvK3BWUJ63miA9e62FqaOW BNNkJ8jQPXSzqM9YykWyJGxGm+s4jo3emFh9xe23PKqmg4WL0O9XZUYxR8Q7XTbC32/5 KeOvMEjNRwTpfGt4G1GtcxD/Ff8wzDSVja0G6JQkE24aY2p2AOFSCGcb5QpNuI7eIGkx MC/usliChxyaPSg6NJT6/9c1m9mfF3nb8K80rwZRErwQ9aPUwjKHzTnubB+CryOF+v5O LeTA== X-Gm-Message-State: AE9vXwOXxGHfTot7aV2nbrghR4kMab28r0lYI84PZwS6TeGLu8z7jIxxmJozNbumZdorzVA07oqaYOOu5gLdCA== X-Received: by 10.55.112.193 with SMTP id l184mr10878273qkc.116.1472647113379; Wed, 31 Aug 2016 05:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Wed, 31 Aug 2016 05:38:32 -0700 (PDT) In-Reply-To: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> From: Lishan Li Date: Wed, 31 Aug 2016 20:38:32 +0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114fe870129441053b5d602d Archived-At: Cc: JINMEI Tatuya , saag@ietf.org, Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:38:36 -0000 --001a114fe870129441053b5d602d Content-Type: text/plain; charset=UTF-8 Dear Stephen, Thanks a lot for your kind reply. In the current version, we describe the applicability part as follows: The mechanism provides encryption in all cases, and can be used for authentication based either on pre-sharing of authorized certificates, or else using trust-on-first-use. In the body of the draft, we mainly describes one possible scenario based on pre-sharing of authorized certificates in detail. In this way, the secure DHCPv6 can be deployed easily. Best Regards, Lishan 2016-08-31 19:42 GMT+08:00 Stephen Farrell : > > Hiya, > > On 31/08/16 10:47, Lishan Li wrote: > > Dear all, > > > > According to the comments from Stephen and Randy, we have updated secure > > DHCPv6. Thanks a lot for your previous help and guidance. > > And thanks for doing the work. > > > > > we previously dropped the idea of using TOFU for the authentication part > > of dhcpv6, but we are now considering re-introducing it. We dropped > > the idea mainly based on a suggestion from Randy, and we are now > > revisiting the decision based on a suggestion from Stephen. We'd like > > to resolve this conflict by understanding these suggestions in more > > detail and by seeing if we can find some middleground/compromise/ > whatever > > that everyone can at least live with. > > > > So, it would be great if > > - Randy could re-explain why we should drop TOFU, and whether it's > > acceptable to re-introduce it (and any conditions we should meet to > > do so). > > - Stephen could explain why we should include TOFU, and whether it's > > acceptable to keep it out of scope. > > My basic argument here is that earlier specs for DHCP security > have not been deployed, so I think we should focus now on > specifying something that can be deployed easily, even if that > is not as good as one might desire. That's basically following > the logic of RFC 7435 [1] and, I think, argues for supporting > ToFU. > > If, however, there's a good argument that something else is > what is more likely to be deployed, then I'd be convinced by > that. > > Cheers, > S. > > [1] https://tools.ietf.org/html/rfc7435 > > > > > Thanks > > Lishan > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > --001a114fe870129441053b5d602d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Stephen,

Thanks a lot f= or your kind reply.

In the current version, we des= cribe the applicability part as follows:
The mechanism provides e= ncryption in all cases, and can be used for
authentication based = either on pre-sharing of authorized certificates, or
else using t= rust-on-first-use.

In the body of the draft, we ma= inly describes one possible scenario=C2=A0
based on pre-sharing o= f authorized certificates in detail. In this way,=C2=A0
the secur= e DHCPv6 can be deployed easily.=C2=A0

Best Regard= s,
Lishan

2016-08-31 19:42 GMT+08:00 Stephen Farrell &= lt;stephen.f= arrell@cs.tcd.ie>:

Hiya,

On 31/08/16 10:47, Lishan Li wrote:
> Dear all,
>
> According to the comments from Stephen and Randy, we have updated secu= re
> DHCPv6. Thanks a lot for your previous help and guidance.

And thanks for doing the work.

>
> we previously dropped the idea of using TOFU for the authentication pa= rt
> of dhcpv6, but we are now considering re-introducing it.=C2=A0 We drop= ped
> the idea mainly based on a suggestion from Randy, and we are now
> revisiting the decision based on a suggestion from Stephen.=C2=A0 We&#= 39;d like
> to resolve this conflict by understanding these suggestions in more > detail and by seeing if we can find some middleground/compromise/= whatever
> that everyone can at least live with.
>
> So, it would be great if
> - Randy could re-explain why we should drop TOFU, and whether it's=
>=C2=A0 =C2=A0acceptable to re-introduce it (and any conditions we shoul= d meet to
>=C2=A0 =C2=A0do so).
> - Stephen could explain why we should include TOFU, and whether it'= ;s
>=C2=A0 =C2=A0acceptable to keep it out of scope.

My basic argument here is that earlier specs for DHCP security
have not been deployed, so I think we should focus now on
specifying something that can be deployed easily, even if that
is not as good as one might desire. That's basically following
the logic of RFC 7435 [1] and, I think, argues for supporting
ToFU.

If, however, there's a good argument that something else is
what is more likely to be deployed, then I'd be convinced by
that.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7435

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


--001a114fe870129441053b5d602d-- From nobody Wed Aug 31 10:12:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C812D565 for ; Wed, 31 Aug 2016 10:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSgzKyjo8uCN for ; Wed, 31 Aug 2016 10:12:20 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A12F12D1DE for ; Wed, 31 Aug 2016 10:12:12 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id h186so21405797pfg.3 for ; Wed, 31 Aug 2016 10:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KHbobgIrlljVJp3ok5Mc8EJ4uxGljvynAxA59HWs+kM=; b=oN6uMVwKEa7CUKc26UISb2do8nSw3EQApUyY1sLrmc3Mq7jbB8QRwy0QLNw2IVl6Mo rJs+nL/HLPPWBJmB+TI5kjX9Mrp/3HQk2PCrdqRQP1FUmLsKDv4xi7P6aEeoFQkSiBTG sM9P5DEsBPuAg8NgeiBp7J78550IWbnr/yPfxR3mMtMi4qfK4w6tKyeMfcDHhZgDTlk/ VkjisjByHRYG8BgTrBqcFETqFd7zgg19LcRf+bHmbP4XWNpKeYHrCI0S2an2flaR2vsR B/5ay5PuAxAhGdS6uwN7K5VfM+w2GJs8YhePA1YwjiG+r6YEn2NrtHK37vCvaIVk4RbA 9BSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KHbobgIrlljVJp3ok5Mc8EJ4uxGljvynAxA59HWs+kM=; b=UnWLHs/6xu9xX2LYQBzE+MEPWOPszCdN/j5rhLQZ7oFHVUUKrwjM0v9xqOH0y8w4lm hyLSO0GYv016BRadPmXpr5uJbvsP+OeYS1DFYs5gUDP/13ZGwXvCBOQKZw78Lz0zmUsR n4WaKX84BeMlaV56y3NhNY8tqy5CBCQOib6Srbm6+E44A1CO5z86bKBBIltJBXeQOSfn 6yBmXSsRYvsmqpabCkCzFWb+jlw/rXoJhQZ61sRha0IyvoJFxz5YJJY8uVYet9SP487t AVdyh1VKBQhJUoVRtOkm36YUiPCRp+TAAs9hT2TMmf9HV9liYVpKysGhQ0+CnPPmAXGa WtsQ== X-Gm-Message-State: AE9vXwMBVnLoJlU2Ws5c5+ex3oCybjUUn+oTywv6AccDJKCKCBwsR1q3JRB3OU8JuD1v4g== X-Received: by 10.98.89.23 with SMTP id n23mr18734097pfb.34.1472663531981; Wed, 31 Aug 2016 10:12:11 -0700 (PDT) Received: from [10.104.92.10] ([167.220.102.183]) by smtp.gmail.com with ESMTPSA id kx13sm1121564pab.0.2016.08.31.10.12.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 10:12:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13G36) In-Reply-To: <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> Date: Wed, 31 Aug 2016 10:12:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0092EBB5-2019-4515-ACE4-17AE25F5B624@gmail.com> References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: "Dan Romascanu \(Dan\)" , saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:12:22 -0000 On Aug 31, 2016, at 2:09 AM, Stephen Farrell wro= te: >=20 > Hi Bernard, >=20 > I agree about implementation and deployment being the key here. >=20 > So I think we have the formal inter-SDO bits well in hand. [BA] Traditionally the trickiest part of modifications to IEEE 802.11 securi= ty has been the state machine analysis. =46rom what I read in the liaison no= tes the folks from UM and Stanford who did the validation of the 802.11i sta= te machines have not reviewed this draft.=20 As an example, their previous analysis suggested that key exchange occur in a= uthentication so it could provide DoS protection. The way DH is integrated i= n the draft does not protect against either DoS against the Association exch= ange or metadata collection. Also adding unauthenticated PMKs to the same ca= che as authenticated ones could create new vulnerabilities if authorizations= are not correctly handled. > Any ideas as to how to get running code would be most welcome though. [BA] In practice, the quickest way to get running code would be to introduce= it into one of the open source AP distributions. Getting it deployed in exi= sting STAs will be more complicated since this typically requires updates to= drivers, many of which are closed source. But perhaps an implementation cou= ld be done to an open source driver.= From nobody Wed Aug 31 11:31:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310C12D608 for ; Wed, 31 Aug 2016 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8NyyuxUtH6Z for ; Wed, 31 Aug 2016 11:31:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C87F12B04B for ; Wed, 31 Aug 2016 11:31:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4D6CABEB3; Wed, 31 Aug 2016 19:31:23 +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 Y_Z6KFECN5Mg; Wed, 31 Aug 2016 19:31:22 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A612FBEB2; Wed, 31 Aug 2016 19:31:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472668282; bh=wGC4zUtQ+bL0mgVdyXgF05T8HGzs00wXTT87gcUMXZE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dKbyNzMUEqBD1jXPB9MrpRRHvqB75NJLf8m9sT9EhLxSOEPkYIq2yDwakkfwZFXZG S8XjHJeLuZahN+t36Edh9Yl/X+XmjZKoBN0bMZY2MKBtp4t7oMPPqVq7Pd55lwdjxM P+DdzKO1zRFVfWckQOFzNJw3HwpgVmpj1zp32/PU= To: Bernard Aboba References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> <0092EBB5-2019-4515-ACE4-17AE25F5B624@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <851f82ee-4861-f6f2-4b08-4fb0689a271a@cs.tcd.ie> Date: Wed, 31 Aug 2016 19:31:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0092EBB5-2019-4515-ACE4-17AE25F5B624@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090704080001020207060205" Archived-At: Cc: "Dan Romascanu \(Dan\)" , saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 18:31:53 -0000 This is a cryptographically signed message in MIME format. --------------ms090704080001020207060205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31/08/16 18:12, Bernard Aboba wrote: > [BA] Traditionally the trickiest part of modifications to IEEE 802.11 > security has been the state machine analysis. From what I read in the > liaison notes the folks from UM and Stanford who did the validation > of the 802.11i state machines have not reviewed this draft. Ah, didn't know about that. If you could ask 'em to review that draft or send me contact info, that'd be great. One of the concerns I had was how to get good review for this if we process it in the IETF and that sounds like it'd help Cheers, S. --------------ms090704080001020207060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MzEx ODMxMjFaMC8GCSqGSIb3DQEJBDEiBCDw6jKxyG1p/EmyYlMbj659tfdLU9tRoZqflg298ruf ETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCrWCcbfybros7gqrFytQr6Q90cTmnK473scM4VgTSU4aStZYpgPC5/ B8+r//9b7jBIMqsZ1e+QDrMeyIrTWbCuEIsPv45ylO0pog+D66G4Z8GsrwFSrlQG8kdj14NR 50kNkIW1q5rRMaomUJkNylQTIlAUyHnmUK9MGpDiNXj8YGtl7O5Z4DQ9NBV06oRkPdJLTTrK M6tRJyQvPCMuVog8qj6bFMVe+tpfMPLNHO2Q3e4HHXYkotYf+BrvTaQtQADM1n+tCC1mp1rN rhlSKY/Ym4AjFKO0bwMh1SrltvBQJTfGNgmL9ZX2G2Cp4lfzBPNncD1aK8UzuthUF6F2Oe0G AAAAAAAA --------------ms090704080001020207060205-- From nobody Wed Aug 31 17:19:34 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0012D7CF for ; Wed, 31 Aug 2016 17:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 SXt6nwBGlHbj for ; Wed, 31 Aug 2016 17:19:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D8012D7AC for ; Wed, 31 Aug 2016 17:19:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfFj7-0000hR-Gf; Thu, 01 Sep 2016 00:19:29 +0000 Date: Thu, 01 Sep 2016 09:20:01 +0900 Message-ID: From: Randy Bush To: Lishan Li In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 00:19:32 -0000 lishan, > used for authentication based ... using trust-on-first-use. uh, what is wrong with this picture? From nobody Wed Aug 31 18:38:04 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B43412D7EB for ; Wed, 31 Aug 2016 18:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBo_V6bG0P8M for ; Wed, 31 Aug 2016 18:38:01 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D9A12D7C5 for ; Wed, 31 Aug 2016 18:37:37 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id t7so70661159qkh.1 for ; Wed, 31 Aug 2016 18:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0/XTBZAwQKStvMubzqjTTmxRiQvkFGaeRvifsgfl0C4=; b=RCbWeVpQUBS/sefYmHMTRHBjO2BxCD9seHLJcn3E3OGFhweYbzIuoyMq4XHOkDJ70F 7Fc+lJ+k3/o+p3Fa6r/t+/vJ2iO1Our+5eyer/sK3ZuQGrcpugSlvRPHW+CFQRb2rvjp /6Si9R8TJPv8ogtnzt07e1Br0nsYAqEMK6U+Z4VPOMvRnDW0ViMITDF3eOrj6490+mdH 6z5T9RloaCWmiUt1WQI1fUStfCbbgPuNB0HBv5986S2mKgM2nRYb8lJS5qHX99JeV8uW Xgux+ovFcmopvUbktY2KUF41I7pvrcuV0FOrfFHaPpBBaqjvECXwpDoGYdW7MeXkEi8S lSRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0/XTBZAwQKStvMubzqjTTmxRiQvkFGaeRvifsgfl0C4=; b=Ll8z8dYIu6d8239/uNBJpYCJ23OjcJx4jKBYZslh8iiysjUaobcAnBZYbKPzi7VMTX ciViGO8AEiNlnFYp16BDRFtq92uT2LoSgEpsMWLCXbzgGoD0ZGqTD+zFAErA1rpRlifE jPv5BQY6XIqL9lPOrweUJptoPnxGkzGXMe5Xhj+maxNeu2EZRTT4KerwGjecLeq8/IoS kOJLnz20Y36DQEKJ5LhdfcYwlednC6NmimeNtw/7GF5DoCx/bN1UpVfLw8yTxUzGquX9 m7Kzh+Wx/3mjDcyCTsHaQQhft/2fAgHkVC9GVH1gGLfTPkhUM2x9U8B+jmHScdSMfD04 sMIQ== X-Gm-Message-State: AE9vXwMG7eTe94AZDmBZ8oNRZzSRCHVq1GPblvbK8j57ntGNLqn8TTfuTHdH/WXidZOBZWYOs1iY+UEK6l1/8A== X-Received: by 10.55.207.150 with SMTP id v22mr13230513qkl.157.1472693857084; Wed, 31 Aug 2016 18:37:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Wed, 31 Aug 2016 18:37:36 -0700 (PDT) In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> From: Lishan Li Date: Thu, 1 Sep 2016 09:37:36 +0800 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1145a32436ec1a053b6842ef Archived-At: Cc: JINMEI Tatuya , saag@ietf.org, Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:38:02 -0000 --001a1145a32436ec1a053b6842ef Content-Type: text/plain; charset=UTF-8 Dear Randy, This picture makes sense to all authors. But we don't know whether it makes sense to you and Stephen or not. So we want to get the precious comments from you and Stephen on this. Thanks, Lishan 2016-09-01 8:20 GMT+08:00 Randy Bush : > lishan, > > > used for authentication based ... using trust-on-first-use. > > uh, what is wrong with this picture? > --001a1145a32436ec1a053b6842ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Randy,

This picture makes sense to= all authors. But we don't know whether it makes sense to you and Steph= en or not.=C2=A0
So we want to get the precious comments from you= and Stephen on this.

Thanks,
Lishan
=

2016-09-01 8:20 G= MT+08:00 Randy Bush <randy@psg.com>:
lishan,

> used for authentication based ... using trust-on-first-use.

uh, what is wrong with this picture?

--001a1145a32436ec1a053b6842ef-- From nobody Wed Aug 31 18:43:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268F12D807 for ; Wed, 31 Aug 2016 18:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JrRUqldRukmO for ; Wed, 31 Aug 2016 18:43:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F5C12D7FB for ; Wed, 31 Aug 2016 18:42:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfH1C-00016l-OP; Thu, 01 Sep 2016 01:42:15 +0000 Date: Thu, 01 Sep 2016 10:42:47 +0900 Message-ID: From: Randy Bush To: Lishan Li In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: JINMEI Tatuya , saag@ietf.org, Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:43:41 -0000 > This picture makes sense to all authors. But we don't know whether it makes > sense to you and Stephen or not. >>> used for authentication based ... using trust-on-first-use. >> >> uh, what is wrong with this picture? what is authenticated? tofu and authentication are antithetical. randy From nobody Wed Aug 31 18:59:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C512B064 for ; Wed, 31 Aug 2016 18:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TVAAREaHqwg for ; Wed, 31 Aug 2016 18:59:23 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E8B12B030 for ; Wed, 31 Aug 2016 18:59:22 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so71062462qkc.0 for ; Wed, 31 Aug 2016 18:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=14+tHFOXFi4ZmNryubb9QZI5r93XxMfb66fGz+SLtjE=; b=ddJ1wbB1MZqYvw3j3P1kshcilTHpdB4pUHORoAzZToKdeTcreS6Z3K9iZD0nZl7HbK /V1P5mM7UdROOspWJloEmkay2ltLu58AZ6kmMb2KqBSgVIr/oPjvkkqb0UF22nG1zYHw ZeL1QS+2ofSHnnl+mtONS0WMwTqcZMP3kIy3hi9tSuFbmfb/9ka2osV0AKZXKTq1biHn LcuDNPbbF8AlIOXdFGiGb3o1epEYyLJwIfJ3DbonpqsBSiEaai7dVXAGQrGjfLV9jEaN KYS5sO+QfVbbMx4DEz2kFHK+yqVPcj6Q7oymIjErbG2JCukRKbfTmM8PoJKPf/TmuYqE xhqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=14+tHFOXFi4ZmNryubb9QZI5r93XxMfb66fGz+SLtjE=; b=ACWPN2UvOdB7YPST9aUMGC9cqFW06KvwHnDtqBRIvrrcPAUe6Sx+uTytqrhtYIR3G8 PL6eTna83xI+xcc5mRRMTvsYip0di+o2HRm6+ihz4c02AeHEtd6pJ23JB9ygSQUbHKUL wnO5lko+F49vmO5kQdaW5jbE8hjO3nyzkzD4OQPmJ5seUmBV9jDD8HMTBHZtjJkvo+pv LCb3fidnMD/UiLZgsL/XI3mcoXRn9+AGM8LZdTskoOYrQQ2SavA4OsosHApl3CbFxRnh Yg/MQwnjJH3tXfU9QMMp3UoulDYiC4WCaEt2AH26xuJRnBx3fPoT2uHHdlmhO+vULg4u 3HzA== X-Gm-Message-State: AE9vXwPQ39hXWVnoRKtMkDHGoZwCyUW2C3z/YbOm+43VtE5rVJG+bmnKF2aj8xZI4xYH3mnRGrMq2O0v5WKpFA== X-Received: by 10.55.207.150 with SMTP id v22mr13306834qkl.157.1472695161571; Wed, 31 Aug 2016 18:59:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Wed, 31 Aug 2016 18:59:21 -0700 (PDT) In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> From: Lishan Li Date: Thu, 1 Sep 2016 09:59:21 +0800 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1145a324f7e1ef053b688f0c Archived-At: Cc: JINMEI Tatuya , saag@ietf.org, Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:59:24 -0000 --001a1145a324f7e1ef053b688f0c Content-Type: text/plain; charset=UTF-8 Dear Randy, In my initial thought, tofu is one method to achieve authentication. Looking forward to your further guidance. Best Regards, Lishan 2016-09-01 9:42 GMT+08:00 Randy Bush : > > This picture makes sense to all authors. But we don't know whether it > makes > > sense to you and Stephen or not. > >>> used for authentication based ... using trust-on-first-use. > >> > >> uh, what is wrong with this picture? > > what is authenticated? tofu and authentication are antithetical. > > randy > --001a1145a324f7e1ef053b688f0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Randy,

In my initial thought, tofu= is one method to achieve authentication. Looking forward to your further g= uidance.

Best Regards,
Lishan

2016-09-01 9:42 GMT+08:0= 0 Randy Bush <randy@psg.com>:
> This picture makes sense to all authors. But we don&= #39;t know whether it makes
> sense to you and Stephen or not.
>>> used for authentication based ... usin= g trust-on-first-use.
>>
>> uh, what is wrong with this picture?

what is authenticated?=C2=A0 tofu and authentication are antithetica= l.

randy

--001a1145a324f7e1ef053b688f0c-- From nobody Wed Aug 31 19:04:29 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F335B12D7DD for ; Wed, 31 Aug 2016 19:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hmq6oy3sionk for ; Wed, 31 Aug 2016 19:04:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC09412B064 for ; Wed, 31 Aug 2016 19:04:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfHMe-0001Ec-8w; Thu, 01 Sep 2016 02:04:24 +0000 Date: Thu, 01 Sep 2016 11:04:55 +0900 Message-ID: From: Randy Bush To: Lishan Li In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: JINMEI Tatuya , saag@ietf.org, Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 02:04:28 -0000 > In my initial thought, tofu is one method to achieve authentication. it is not. you have zero assurance of any authenticity. calling it "secure" dhcpv6 when the parties will accept anything from any monkey in the middle attacker is oxymoronic. but i have had my say. randy From nobody Wed Aug 31 19:07:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6940012D7B0 for ; Wed, 31 Aug 2016 19:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 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_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhkdL6rdkU4X for ; Wed, 31 Aug 2016 19:07:28 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCA12D78D for ; Wed, 31 Aug 2016 19:07:28 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7700D3F4022; Thu, 1 Sep 2016 02:07:27 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5AC1F3F401C; Thu, 1 Sep 2016 02:07:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472695647; bh=XHm5qsOKDJBVqVDBaKIMX7Zo1p+1/e9VG0wnja8KzYI=; l=1216; h=From:To:CC:Date:References:In-Reply-To:From; b=ovXdXzsiMmY2uzYOzByc+JUrSuxp44BhnjhBo2te5i7gXTvrp5YrDw6OoiNI9I0S2 TJwezNxiizXZfwbS7HAL40cQqhACU9xi/ymHCaaMSNQZqeapXhzK9K3zLqyzCzrML+ m1pz8aQHhLV4+eRL5BRBPd2lW+nIZl2YUx+FB/KI= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 54C581FC9F; Thu, 1 Sep 2016 02:07:27 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 22:07:27 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 31 Aug 2016 22:07:26 -0400 From: "Salz, Rich" To: Lishan Li , Randy Bush Thread-Topic: [saag] Whether TOFU should be considered in secure DHCPv6? Thread-Index: AQHSA2zEfGNkYV+700e+5Ux4m5UU8qBjNc4AgAAPkACAAMP+gIAAFa4AgAABcoCAAAShgP//vjIw Date: Thu, 1 Sep 2016 02:07:25 +0000 Message-ID: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Lemon , JINMEI Tatuya , "saag@ietf.org" Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 02:07:29 -0000 PiBJbiBteSBpbml0aWFsIHRob3VnaHQsIHRvZnUgaXMgb25lIG1ldGhvZCB0byBhY2hpZXZlIGF1 dGhlbnRpY2F0aW9uLiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmdXJ0aGVyIGd1aWRhbmNlLi0N Cg0KQXV0aGVudGljYXRpb24gaXM6ICB5b3UgY29ubmVjdCB0byBzb21ldGhpbmcsIGFuZCB2ZXJp ZnkgdGhhdCB0aGUgaWRlbnRpdHkgaXQgZ2l2ZXMgeW91IGlzIHRoZSBvbmUgeW91IGV4cGVjdC4g IEZvciBleGFtcGxlLCB0aGUgRE5TIG5hbWUgaW4gYSBjZXJ0aWZpY2F0ZSwgd2hlbiBwcm9wZXJs eSBwcmVzZW50ZWQgYnkgYSB3ZWIgc2VydmVyLCBhbGxvd3MgeW91IHRvIGF1dGhlbnRpY2F0ZSB0 aGF0IHNlcnZlci4NCg0KSW4gVE9GVSwgaG93IGFyZSB5b3UgdmVyaWZ5aW5nIHRoZSBpZGVudGl0 eSBvZiB0aGUgc2VydmVyPyBGb3IgZXhhbXBsZSwgd2l0aCBTU0gsIHVubGVzcyB5b3UgaGF2ZSBv dXQtb2YtYmFuZCB2ZXJpZmljYXRpb24gb2YgdGhlIHNlcnZlcidzIFNTSCBrZXksIHlvdSBoYXZl IG5vIGlkZWEgaWYgdGhlIHNlcnZlciB5b3UgYXJlIGNvbm5lY3RlZCB0byBpcyB0aGUgb25lIHlv dSB3YW50IHRvIGNvbm5lY3QgdG8uIA0KDQpUT0ZVIGdpdmVzIHlvdSAid2VsbCBpZiB5b3UgY29t ZSAgYmFjayBoZXJlLCB5b3UncmUgY29taW5nIGJhY2sgdG8gdGhlIHNhbWUgZW50aXR5IHlvdSBm aXJzdCBjYW1lIHRvLiIgIEJ1dCBob3cgZG8gSSBrbm93IHRoYXQgaXQncyByZWFsbHkgUmFuZHkg QnVzaCdzIHNlcnZlciwgYW5kIG5vdCBoaXMgZXZpbCB0d2luIFJhbmR5IFNocnViPw0KIA0KLS0g IA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJpY2hzYWx6QGph YmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCg== From nobody Wed Aug 31 19:43:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71412D7E5 for ; Wed, 31 Aug 2016 19:43: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 autolearn_force=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 RfzZ7ZWO5HTL for ; Wed, 31 Aug 2016 19:43:48 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6115312D7C1 for ; Wed, 31 Aug 2016 19:43:48 -0700 (PDT) Received: from [10.32.60.15] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u812hjIO010279 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Aug 2016 19:43:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.15] From: "Paul Hoffman" To: saag@ietf.org Date: Wed, 31 Aug 2016 19:43:45 -0700 Message-ID: <1D3A13C7-F744-4279-A0EF-EB71ABFECABB@vpnc.org> In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 02:43:49 -0000 On 31 Aug 2016, at 17:20, Randy Bush wrote: >> used for authentication based ... using trust-on-first-use. > > uh, what is wrong with this picture? Uh, the fact that you removed relevant parts of the quotation? For those of you who want to follow more completely, the Abstract of draft-ietf-dhc-sedhcpv6-13 says: The mechanism provides encryption in all cases, and can be used for authentication based either on pre-sharing of authorized certificates, or else using trust-on-first-use. So, we're back to the same problem described in glorious detail in RFC 7435. In this case, if a DHCPv6 client wants to only use fully-authenticated security, and the DHCPv6 server has a certificate that the client can't validate, the client fails to communicate with the server. Some people will want that result and thus want to be able to configure to always require validation; others won't want to be blocked from the Internet and therefore will want either TOFU or (more likely) a warning each time an unvalidated connection is made. --Paul Hoffman From nobody Wed Aug 31 20:37:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B971412B02E for ; Wed, 31 Aug 2016 20:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxM72mXtOatc for ; Wed, 31 Aug 2016 20:37:55 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2870128B44 for ; Wed, 31 Aug 2016 20:37:54 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id l2so72553649qkf.3 for ; Wed, 31 Aug 2016 20:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i0GidrPz/7z542dmptiyqsVHw5g9iWzOSM+grIRa2IY=; b=QwXH3St8NdkJ+g9oZ0vFayPrWEp1Ed/G6NWrEUSPZod+DpYqOzYt8VTYA7VuA8tDu2 i76Zvjad+HXHcbnteKbpsLZLtAyH/4+WGjtC2pf6OvLenzneAqg4ZVfIqkORLSufKseF ljZgNg/r2Y4UFTRh+mPmajWI7v/SJUR82J9r0K1R2uY1DRjFwvKiYDV252iIfot5UPux ylhtU1lJiG3LyBT86/AL3w9rl9YXuTZrY0YmFCZtVVRuUSCA+TG/RHyERHWWCfXYmaoP ZSvgVbBZ1/qcGPqTJMIdVRSExDfN1cE9J1yh4MrDutiTdop1vicE3P6tUVAtQFZQfrSS XggQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i0GidrPz/7z542dmptiyqsVHw5g9iWzOSM+grIRa2IY=; b=jvVt5iF4Qv4VlZzScLYLAkqhvmF9D9/D5CGxtrC9lCBFKl1p9smivDUIDyW7I7rbQA sHwRQ5G57Akij64SSFspICJEvz6KYrOhjIOyjU0eNkwPDjhBUL/AzWjKSuLnZdD4ZP/o yCB4AcaHTyofmNzlf+yegXWzTozzwxKZsAoKAuT92RrtX1++dTZzwth+ILYzuqpvfnqs 6WVFTaFgadf3lR3gmi88/Ay2TyUJ/KMNYYaAosGu0oaQOpFXl6M0fUCknupY89Ic9BZA umikCwm20kEwjYaWtz+Swe9hCwDNuonP3om2aoFkcLaSdafQqhrJ6dkPvjI2XpENvkt0 YVOw== X-Gm-Message-State: AE9vXwPaY5Q9EaC+CQCBdL5KPCO22DTz5nzY2tuyLBbYA7QqdT3U+Bq72vP/M9jhy/oXB18jYarjeng3QC6PDw== X-Received: by 10.55.19.39 with SMTP id d39mr14952114qkh.240.1472701073994; Wed, 31 Aug 2016 20:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Wed, 31 Aug 2016 20:37:53 -0700 (PDT) In-Reply-To: <1D3A13C7-F744-4279-A0EF-EB71ABFECABB@vpnc.org> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <1D3A13C7-F744-4279-A0EF-EB71ABFECABB@vpnc.org> From: Lishan Li Date: Thu, 1 Sep 2016 11:37:53 +0800 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a114016306042cb053b69f0d8 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 03:37:56 -0000 --001a114016306042cb053b69f0d8 Content-Type: text/plain; charset=UTF-8 Dear Paul, Thanks a lot for your nice reply and guidance. We just want to apply opportunistic security into secure DHCPv6 deployment. So, how about the following policy for secure DHCPv6 deployment? 1. If the client/server is pre-configured with authorized certificates, then it can achieve the authentication. 2. If the certificate cannot be validated and require validation, then it is blocked from the Internet. 3. If the certificate cannot be validated and don't want to blocked from the Internet, then it may want either TOFU or a warning each time an un-validated connection is made. Looking forward to your further guidance. Best Regards, Lishan 2016-09-01 10:43 GMT+08:00 Paul Hoffman : > On 31 Aug 2016, at 17:20, Randy Bush wrote: > > used for authentication based ... using trust-on-first-use. >>> >> >> uh, what is wrong with this picture? >> > > Uh, the fact that you removed relevant parts of the quotation? > > For those of you who want to follow more completely, the Abstract of > draft-ietf-dhc-sedhcpv6-13 says: > > The mechanism provides encryption in all cases, and > can be used for authentication based either on pre-sharing of > authorized certificates, or else using trust-on-first-use. > > So, we're back to the same problem described in glorious detail in RFC > 7435. In this case, if a DHCPv6 client wants to only use > fully-authenticated security, and the DHCPv6 server has a certificate that > the client can't validate, the client fails to communicate with the server. > Some people will want that result and thus want to be able to configure to > always require validation; others won't want to be blocked from the > Internet and therefore will want either TOFU or (more likely) a warning > each time an unvalidated connection is made. > > --Paul Hoffman > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a114016306042cb053b69f0d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Paul,

Thanks a lot for = your nice reply and guidance.
We just want to apply opportunistic= security into secure DHCPv6 deployment. So, how about the following policy= for secure DHCPv6 deployment?
1. If the client/server is pre-con= figured with authorized certificates, then it can achieve the authenticatio= n.
2. If the certificate cannot be validated and require validati= on, then it is blocked from the Internet.
3. If the certificate c= annot be validated and don't want to blocked from the Internet, then it= may want either TOFU or a warning each time an un-validated connection is = made.

Looking forward to your further guidance.

Best Regards,
Lishan
=C2=A0
2016-09-01 10:4= 3 GMT+08:00 Paul Hoffman <paul.hoffman@vpnc.org>:
On 31 Aug 2016, at 17:20, Randy Bush w= rote:

used for authentication based ... using trust-on-first-use.

uh, what is wrong with this picture?

 Uh, the fact that you removed relevant parts of the quotation?

For those of you who want to follow more completely, the Abstract of draft-= ietf-dhc-sedhcpv6-13 says:

=C2=A0 =C2=A0The mechanism provides encryption in all cases, and
=C2=A0 =C2=A0can be used for authentication based either on pre-sharing of<= br> =C2=A0 =C2=A0authorized certificates, or else using trust-on-first-use.

 So, we're back to the same problem described in glorious detail in RFC = 7435. In this case, if a DHCPv6=C2=A0 client wants to only use fully-authen= ticated security, and the DHCPv6 server has a certificate that the client c= an't validate, the client fails to communicate with the server. Some pe= ople will want that result and thus want to be able to configure to always = require validation; others won't want to be blocked from the Internet a= nd therefore will want either TOFU or (more likely) a warning each time an = unvalidated connection is made.

--Paul Hoffman


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

--001a114016306042cb053b69f0d8-- From nobody Wed Aug 31 22:58:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6D612D094 for ; Wed, 31 Aug 2016 22:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kzGdm8fCsIaX for ; Wed, 31 Aug 2016 22:58:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD2512D08F for ; Wed, 31 Aug 2016 22:58:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfL11-00028Z-Ln; Thu, 01 Sep 2016 05:58:20 +0000 Date: Thu, 01 Sep 2016 14:58:51 +0900 Message-ID: From: Randy Bush To: Viktor Dukhovni In-Reply-To: <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 05:58:23 -0000 [ moving this back to saag. multiple escalations are too much for me ] > When uses TOFU for SSH to a small set of servers, or to connect > to a small, mostly stable set of networks, it can be a reasonable > fit. ssh referrs to this as a "leap of faith," (which n weaver prefers to my gmobd) not authentication. users are strongly advised not to go there. otoh, if you get the target host's ssh key fingerprints out of band, you have whatever level of authenticity the out of band mechanism has. randy