From nobody Thu Dec 1 10:13:59 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB86129857; Thu, 1 Dec 2016 10:13:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148061603150.2968.4468099330156791072.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 10:13:51 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-04.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 18:13:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) Author : Russell Housley Filename : draft-ietf-curdle-cms-chacha20-poly1305-04.txt Pages : 8 Date : 2016-12-01 Abstract: This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-chacha20-poly1305-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-chacha20-poly1305-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 1 10:20:14 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5A129841 for ; Thu, 1 Dec 2016 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 XWk8aoFOqtzn for ; Thu, 1 Dec 2016 10:20:09 -0800 (PST) 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 2ACAB129801 for ; Thu, 1 Dec 2016 10:20:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87AB930024B for ; Thu, 1 Dec 2016 13:09:51 -0500 (EST) 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 5IPHFIvZcUC6 for ; Thu, 1 Dec 2016 13:09:50 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7DECB3001FC; Thu, 1 Dec 2016 13:09:50 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_A1EDB0AF-1BAD-4960-934C-616839D7C5AB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 1 Dec 2016 13:15:19 -0500 Message-Id: References: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 18:20:11 -0000 --Apple-Mail=_A1EDB0AF-1BAD-4960-934C-616839D7C5AB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > My AD review of this draft is below. I think a revised I-D is > needed before IETF LC for at least section 4, but please argue with > me if I'm wrong about that. I just posted -04. I believe that it addresses all of your comments. Russ --Apple-Mail=_A1EDB0AF-1BAD-4960-934C-616839D7C5AB 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 Fw0xNjEyMDExODE1MjBaMCMGCSqGSIb3DQEJBDEWBBSBbWG6y8dAtz8FiYFg9Q0sFLADNTCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQC0JuHTzueWUsXi3viCvevrbl2ReZuZvhqlYqMwTdj/NN6ihwjzG2jrWx8iou+L yIb0Tck5ZdJmqRpx5a9IanFSgfWu9HiDQKxMchoB4jd72fMGgClPMNf1bld4Wef1jdOxx2pd3ZcO 8gX+t5/pYuS3jYxAB7NypKPN4dr3lVwrmYXqGnq64AG4NaBUUbZSROsnZnsXunYFLq+IIa9oBb68 OU2UX6C96RoYxAiLsWBaQ3mr4DfMJkf7RNRShG7Misb6SzJNKokmrZIajAcdFNVscrdFbZwsZPum 24HYje+tnbTBZM8Astjzk8My5NqcqYPLNupVuEFTxVJ3GOjUXOrvAAAAAAAA --Apple-Mail=_A1EDB0AF-1BAD-4960-934C-616839D7C5AB-- From nobody Fri Dec 2 02:39:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4421295F1 for ; Fri, 2 Dec 2016 02:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 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=-2.896, 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 ZiS87q7OqYc0 for ; Fri, 2 Dec 2016 02:39:48 -0800 (PST) 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 2322B12960C for ; Fri, 2 Dec 2016 02:39:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC779BE5D; Fri, 2 Dec 2016 10:39:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1i-n6T9seRh; Fri, 2 Dec 2016 10:39:42 +0000 (GMT) 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 277B7BE56; Fri, 2 Dec 2016 10:39:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480675182; bh=8R5xl7piiFGPjbWgn7M6M11j8ZDvbAaHvjcSBJIPVug=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=X2/9MCf2krnnTA4/lxb8WCP8gPstb1G6t2/X8NtYt98MCbk3657PKjkSRkK4M1w64 7Yv8Pe8dxpEIvQ4sbUFv6dmBN9svzsBV8p8t+EJvyKvaMyLRQn348RllCP21GX6nv2 o52ObAtMdnAyz2Ks7U48/JqDXbrQMeZtRUn0TJwY= To: Russ Housley References: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8856c6d6-8942-62e4-c8ef-a8dbb94c7aa9@cs.tcd.ie> Date: Fri, 2 Dec 2016 10:39:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050200050902070908020202" Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 10:39:51 -0000 This is a cryptographically signed message in MIME format. --------------ms050200050902070908020202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/12/16 18:15, Russ Housley wrote: >=20 >> My AD review of this draft is below. I think a revised I-D is >> needed before IETF LC for at least section 4, but please argue with >> me if I'm wrong about that. >=20 > I just posted -04. I believe that it addresses all of your comments. Thanks Russ, I've requested last call be started. Cheers, S. >=20 > Russ >=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --------------ms050200050902070908020202 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDIx MDM5NDJaMC8GCSqGSIb3DQEJBDEiBCAGnkxu2Ozfm99V/PRK5oqwqxUeiGhV+7GtuAXk5+ai gjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBxqqpkMUjiztZTgDafvTyWzxtZyjgXkhQBD49j9R1knjJIn76hB++u Xx0ueZNL5mR0lRkg2yJX9t4IHWVWFvJhv1t1hG441JuUL8mIDUgb/bxyyH6I4GssQhoCiW+3 vfQJ4FZfMrObUrA7gCLMIgqsXHXmGvwAHWDiXUlkQwDISFH7iNmObFQnAsi8VXM7jrCAoWHp UdMO7ddBhVwqGqQr4NpyAR2ZQ9R5Kq1a2VOJ8KxbyOHfLw7QNEVnUIAr/RafS4Xjf7khIzXL MXmYRHXww7Wr5MXA+uATebGBAXee3zxLlPOeg148W64FcpU76wTvnsB+z2i2gQErs2s7HV4r AAAAAAAA --------------ms050200050902070908020202-- From nobody Fri Dec 2 07:06:12 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D708C129735; Fri, 2 Dec 2016 07:06:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148069116483.29721.15313406238122608686.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 07:06:04 -0800 Archived-At: Cc: draft-ietf-curdle-cms-chacha20-poly1305@ietf.org, curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , stephen.farrell@cs.tcd.ie Subject: [Curdle] Last Call: (Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 15:06:07 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - Independent Submission Editor stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Fri Dec 2 07:07:29 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FADE1294BE; Fri, 2 Dec 2016 07:07:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148069124342.29737.4699635715517741091.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 07:07:23 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa@ietf.org, curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , stephen.farrell@cs.tcd.ie Subject: [Curdle] Last Call: (EdDSA for DNSSEC) to Internet Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 15:07:23 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'EdDSA for DNSSEC' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream) draft-irtf-cfrg-eddsa: Edwards-curve Digital Signature Algorithm (EdDSA) (None -IRTF stream) rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - IETF stream) rfc7748: Elliptic Curves for Security (Informational - IRTF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Fri Dec 2 07:34:10 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C040129468; Fri, 2 Dec 2016 07:34:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148069284930.29701.5188528862476516647.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 07:34:09 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa@ietf.org, curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , stephen.farrell@cs.tcd.ie Subject: [Curdle] CORRECTED Last Call: (EdDSA for DNSSEC) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 15:34:09 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'EdDSA for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-irtf-cfrg-eddsa: Edwards-curve Digital Signature Algorithm (EdDSA) (None - Independent Submission Editor stream) rfc7748: Elliptic Curves for Security (Informational - Independent Submission Editor stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Fri Dec 2 07:35:50 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F351294EA for ; Fri, 2 Dec 2016 07:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 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=-2.896, 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 uT77saEe0qnI for ; Fri, 2 Dec 2016 07:35:45 -0800 (PST) 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 6965B1294E5 for ; Fri, 2 Dec 2016 07:35:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB27DBE5D for ; Fri, 2 Dec 2016 15:35:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjd2fcP5WdjD for ; Fri, 2 Dec 2016 15:35:41 +0000 (GMT) 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 F1248BE3E for ; Fri, 2 Dec 2016 15:35:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480692941; bh=jJChud8RJGECJepV04/ZdPmTzrR87C2gzDAqG652Wss=; h=Subject:References:To:From:Date:In-Reply-To:From; b=a4VDNk/RUxtMOEv75XniGQetNvqbt2+KrJ/G6UnDdcr8RfKzO5WtudLYGIDJB+l92 3tiqYNUIodxzwKLguqfCpaxCZ7XRZC74av5Hf2mv5rPSIg/W2ex4z+rrWpVYDHQrSD oGU6NiZQW7kr1AGJSlNH48ZwMZRnOSy8QZnz8hbo= References: <148069284930.29701.5188528862476516647.idtracker@ietfa.amsl.com> To: "curdle@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <148069284930.29701.5188528862476516647.idtracker@ietfa.amsl.com> Message-ID: <63be4f48-13ea-9844-ff92-556f5bffa4b2@cs.tcd.ie> Date: Fri, 2 Dec 2016 15:35:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148069284930.29701.5188528862476516647.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010004090708080305040001" Archived-At: Subject: [Curdle] Fwd: CORRECTED Last Call: (EdDSA for DNSSEC) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 15:35:48 -0000 This is a cryptographically signed message in MIME format. --------------ms010004090708080305040001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, The 1st last-call announcement incorrectly stated this was going for Internet Standard. This one is correct and says Proposed Standard. Sorry for not spotting that, Cheers, S. -------- Forwarded Message -------- Subject: [Curdle] CORRECTED Last Call: (EdDSA for DNSSEC) to Proposed Standard Date: Fri, 02 Dec 2016 07:34:09 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: draft-ietf-curdle-dnskey-eddsa@ietf.org, curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , stephen.farrell@cs.tcd.ie The IESG has received a request from the CURves, Deprecating and a Little= more Encryption WG (curdle) to consider the following document: - 'EdDSA for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be= sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-irtf-cfrg-eddsa: Edwards-curve Digital Signature Algorithm (EdDSA) (None - Independent Submission Editor stream) rfc7748: Elliptic Curves for Security (Informational - Independent Submission Editor stream) Note that some of these references may already be listed in the acceptable Downref Registry. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --------------ms010004090708080305040001 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDIx NTM1NDFaMC8GCSqGSIb3DQEJBDEiBCBtUvOU/2r3nBtCxc3cI6zaPXymemRACSto+Ay5pKEW fjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCdoUMHIIhPDivg4ULapJEzYhUGLlMsaZKgnP+cEzIRgYnJQExN5OH+ fc1UwzZxnOwWos7H44BqxPPb9KF/ecC3H6vlYS8KxcH+G9ML22uEcC9xYYIRyeR1C63G3DEu zwmoCMomcUgP2Ua4gMRKG4nUBOFaRciE3l5NcrQ6guA0uOeJ2rYAOB8TnDwmHhiyObbZ6ukC 8bU5bMsLlJZHyhqu6dChbMJx5zavKWtUyzlt4YCygqogA2WuGfeFfWDaurHDSIRuAz7xxavN AIKDHJ5pLt5ej/a3FurVuXdMkibv6lCWKP4CSmVZlTg948t0RspVBtdwlTOsCLo2QH1ebM5I AAAAAAAA --------------ms010004090708080305040001-- From nobody Thu Dec 8 16:23:16 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AC2129F49 for ; Thu, 8 Dec 2016 16:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 JcTXXiVVe_f2 for ; Thu, 8 Dec 2016 16:23:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 73A26129EB2 for ; Thu, 8 Dec 2016 16:23:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6016A433421 for ; Fri, 9 Dec 2016 00:23:03 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 3441E43341A for ; Fri, 9 Dec 2016 00:23:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481242983; bh=FvOVU0/T5Ofy0EX1lW+HY8ge69xFtoto5py+as+89P8=; l=5260; h=From:To:Date:From; b=aSaFPN0gf9p2JdFiU6jX/JgnxYPr06C0ldmigx2ZgazHlnzDCuNDUp2csTWe+SUu1 C8j/znKkjjsdJWILdlAdVJvqXCTigY+M2uFs7TdqPgYAvRVSsYIh6ewH9k7YRX1ffs /PQ7zQRyWghd+l5DEYbny1s+WvojX/+UsXkM9/7M= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C3C1F1FC9D for ; Fri, 9 Dec 2016 00:23:01 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 8 Dec 2016 16:23:01 -0800 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; Thu, 8 Dec 2016 19:23:01 -0500 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Some work for the group Thread-Index: AdJRrwJY3PWVL7wFScuPYdGzcgHHmA== Date: Fri, 9 Dec 2016 00:23:00 +0000 Message-ID: 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.32.121] Content-Type: multipart/alternative; boundary="_000_ada1784daf4349afae3ec29414bb4444usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 00:23:15 -0000 --_000_ada1784daf4349afae3ec29414bb4444usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there! We are looking for feedback on the following items, my memory spurred by th= e draft minutes found here: https://datatracker.ietf.org/doc/minutes-97-cu= rdle/ Please review the minutes by the end of the month. Speak up on the list if= anything's wrong. Thanks to Ben Kaduk for taking them. Has anyone (besides Kyle Rose) reviewed curdle-rsa-sha2 ? Are we ready for= WGLC? Please respond within a week. The text in draft-ietf-curdle-pkix says CA's MUST NOT use pre-hash version = of signatures. Does anyone object to this? There is a mention of the trad= e-offs in doing that at the end of section 5. Please respond within a week= . curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh-modp-dh-sha2 Has anyone read these? Will one or more people commit to doing so within a= week? (Commit, not actually read) Contexts - has anyone got a use for signature contexts? See the minutes. I= f you're opposed to the (slight) consensus, speak up. Thanks. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_ada1784daf4349afae3ec29414bb4444usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

 

We are looking for feedback on the following items, = my memory spurred by the draft minutes found here:  https://datatracker.ietf.org/= doc/minutes-97-curdle/

 

Please review the minutes by the end of the month.&n= bsp; Speak up on the list if anything’s wrong.  Thanks to Ben Ka= duk for taking them.

 

Has anyone (besides Kyle Rose) reviewed curdle-rsa-s= ha2 ?  Are we ready for WGLC?  Please respond within a week.=

 

The text in draft-ietf-curdle-pkix says CA’s M= UST NOT use pre-hash version of signatures.  Does anyone object to thi= s?  There is a mention of the trade-offs in doing that at the end of s= ection 5.  Please respond within a week.

 

curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh= -modp-dh-sha2

Has anyone read these?  Will one or more people= commit to doing so within a week?  (Commit, not actually read)

 

Contexts – has anyone got a use for signature = contexts? See the minutes.  If you’re opposed to the (slight) co= nsensus, speak up.

 

Thanks.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_ada1784daf4349afae3ec29414bb4444usma1exdag1mb1msgcorpak_-- From nobody Thu Dec 8 18:18:46 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64256129616 for ; Thu, 8 Dec 2016 18:18:45 -0800 (PST) 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 G_RPPCVPHUPh for ; Thu, 8 Dec 2016 18:18:41 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF69129619 for ; Thu, 8 Dec 2016 18:18:41 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id a197so6089093wmd.0 for ; Thu, 08 Dec 2016 18:18:41 -0800 (PST) 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=jJTw7JLq8fd2NhckupHazh1rc0DmGpgaN2eerdPjENE=; b=E+XESrbahJJmpKh+7zyRCrvzwK3EQ5dYDXOkSLMiXG4qZzBI4YHZLv9iZN6PLCkpcV mltHch9qsTyH/7LttV/KBvu/QsNXAJt9QzUOk3Ou+W6kBEfkQJkMCgWdrzhn4jgKnBz2 sCLH9zgegHyuKlKwrYXzlmc6bWiM/kvfMBV8pKDU1heUxROruUkNE7vFKTibMtJdXFFi CpamzVmDkuEr0i7D8WRkryFLgq3TeiOpXwX/iKboNqGreA0R4JHqft5VNAg+avoh/UMo v4ghnAukdTgeUKGXooG0nuHAcH5u/pEVmU61lihEP+ZTdIvNydFyhFLS/zKc4FbG25uR f2oA== 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=jJTw7JLq8fd2NhckupHazh1rc0DmGpgaN2eerdPjENE=; b=AdS0XlrJ88jgrFXqYWpZC8IpmVlFwE6YxI3uyc4F0f7SmKB1EF5LBCSbqRiFnpn+SU QKqWQMufcAjMtskljO0iXgEAgYMLUJfOMSqIWDl3KOGD9Ar6OMf5xZy+IDZKhzQE/cDD hgwAIWmtfasQlDuDNaVz88HAuRGnnspQrlgxMGoxWHEzYC4IECF6tcN0mKYAHx5B5FAH EWvnEuuc29TM/eN/zd0leZiF4cNuDnE3EP2uX9gDvoRNg5hs03KnTUrkb56H0HXUIvxF vae6H1qMRokYct3uAnaRdHME70Kah0QymTmceAwyGgh8TyyxoFgUWChinn6oXmto6Lgg QlgQ== X-Gm-Message-State: AKaTC03hn4JvINpQpZ1o5wAORwd5VKT6EOJYA90LtIOXP+YfxwQQ5TO7A2v8urA77vXTJcwnvKsyEtvj2oeyVA== X-Received: by 10.28.218.129 with SMTP id r123mr4291919wmg.137.1481249919606; Thu, 08 Dec 2016 18:18:39 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Thu, 8 Dec 2016 18:18:38 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 8 Dec 2016 21:18:38 -0500 X-Google-Sender-Auth: D34i0oFv7DWE5T7KAFZiXc5WNXs Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114697bc4829fc0543305f6e Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 02:18:45 -0000 --001a114697bc4829fc0543305f6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't much care from a CA point of view unless there is going to be difficult getting the hardware we need to implement the signatures. Since that hardware does not currently exist and since we would assume that any suppliers would make sure they support the required mode, I doubt that will be an issue. There is a modest efficiency hit. As far as making the system more robust goes, we are going to have to drop SHA-2 if there is any significant compromise regardless of whether this detail makes an exploit infeasible. It is far more expensive to explain why faulty algorithms are safe than to switch to a safe one. We are not shutting down use of SHA-1 because there is a real risk of a bogus cert being generated by a competent CA. The security justification such as it is is that the system should be fail safe and require at least two failures before a catastrophe. What the collision resistance property does provide is a cushion that makes a compromise during the transition highly unlikely. And given the refusal to consider issue of code points for SHA-3, we will probably need quite a cushion. On Thu, Dec 8, 2016 at 7:23 PM, Salz, Rich wrote: > Hi there! > > > > We are looking for feedback on the following items, my memory spurred by > the draft minutes found here: https://datatracker.ietf.org/ > doc/minutes-97-curdle/ > > > > Please review the minutes by the end of the month. Speak up on the list > if anything=E2=80=99s wrong. Thanks to Ben Kaduk for taking them. > > > > Has anyone (besides Kyle Rose) reviewed curdle-rsa-sha2 ? Are we ready > for WGLC? Please respond within a week. > > > > The text in draft-ietf-curdle-pkix says CA=E2=80=99s MUST NOT use pre-has= h version > of signatures. Does anyone object to this? There is a mention of the > trade-offs in doing that at the end of section 5. Please respond within = a > week. > > > > curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh-modp-dh-sha2 > > Has anyone read these? Will one or more people commit to doing so within > a week? (Commit, not actually read) > > > > Contexts =E2=80=93 has anyone got a use for signature contexts? See the m= inutes. > If you=E2=80=99re opposed to the (slight) consensus, speak up. > > > > Thanks. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114697bc4829fc0543305f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I d= on't much care from a CA point of view unless there is going to be diff= icult getting the hardware we need to implement the signatures. Since that = hardware does not currently exist and since we would assume that any suppli= ers would make sure they support the required mode, I doubt that will be an= issue.

There is a modest= efficiency hit.

As far a= s making the system more robust goes, we are going to have to drop SHA-2 if= there is any significant compromise regardless of whether this detail make= s an exploit infeasible. It is far more expensive to explain why faulty alg= orithms are safe than to switch to a safe one.=C2=A0

We are not shutting down use of SHA-1 because t= here is a real risk of a bogus cert being generated by a competent CA. The = security justification such as it is is that the system should be fail safe= and require at least two failures before a catastrophe.

What the collision resistance property does= provide is a cushion that makes a compromise during the transition highly = unlikely. And given the refusal to consider issue of code points for SHA-3,= we will probably need quite a cushion.



On Thu, Dec 8, 2016 at 7:23 PM, Salz, Rich = <rsalz@akamai.com<= /a>> wrote:

Hi there!

=C2=A0

We are looking for feedback on the following items, = my memory spurred by the draft minutes found here: =C2=A0https://dat= atracker.ietf.org/doc/minutes-97-curdle/

=C2=A0

Please review the minutes by the end of the month.= =C2=A0 Speak up on the list if anything=E2=80=99s wrong.=C2=A0 Thanks to Be= n Kaduk for taking them.

=C2=A0

Has anyone (besides Kyle Rose) reviewed curdle-rsa-s= ha2 ?=C2=A0 Are we ready for WGLC?=C2=A0 Please respond within a week.

=C2=A0

The text in draft-ietf-curdle-pkix says CA=E2=80=99s= MUST NOT use pre-hash version of signatures.=C2=A0 Does anyone object to t= his?=C2=A0 There is a mention of the trade-offs in doing that at the end of= section 5.=C2=A0 Please respond within a week.

=C2=A0

curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh= -modp-dh-sha2

Has anyone read these?=C2=A0 Will one or more people= commit to doing so within a week?=C2=A0 (Commit, not actually read)=

=C2=A0

Contexts =E2=80=93 has anyone got a use for signatur= e contexts? See the minutes.=C2=A0 If you=E2=80=99re opposed to the (slight= ) consensus, speak up.

=C2=A0

Thanks.

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


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

--001a114697bc4829fc0543305f6e-- From nobody Fri Dec 9 05:46:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E87129428 for ; Fri, 9 Dec 2016 05:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 lT6mBhFB0mZk for ; Fri, 9 Dec 2016 05:46:44 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F65212940B for ; Fri, 9 Dec 2016 05:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qqfTCeNH5chcAwX9ouWtYnXEtwNpOszzYSk7zqbTIdg=; b=veDvUosFlxAeUL88bSIBEN++Ux3mmOLi7aalb3xbzQUzFJ3w+FDvKtIVVQqBB+MDMq4D7bt5hrBKIF0u4p9dtv4alApojYvIkgdtT2BoKmS4l907dYnaLQFVD/o+R2lrhuWnuhVKnW74BRahKzYsyuLTna9nJrF3XewHNJMHwG0= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 9 Dec 2016 13:46:42 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0761.018; Fri, 9 Dec 2016 13:46:42 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmA== Date: Fri, 9 Dec 2016 13:46:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 2c12448a-5a3c-4cc5-d70e-08d42039cf29 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1464; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:YiSO0KUG5JfWQhcQHkSxitAwECWH55uuVpJsRZ4zY7gk/S6o0+RaTIuAMwK33JDJXk79CLvgtThjSn747+BNF2VvfcWjvJozMW/F5yZHQJ7G2a/eNCyUutDK3NBp9/YAEutl87AtfaM7sG1BUzSHY+2ElLvY+IDUa1SVsYR6lj9WpXMXLIO27+7zEJuc0tNQdI+FOs1LNx/TG2jv87j95pHW35qjlHdGdDkV+B2VAoqjDiMMnOoITR9v5RG3zRsKx9rKlVw+7hi4yUAWCCv886vtPwtQPZhtjD3SHqouV+mOl38m+wtCEqPK0uDqFZiPUmkmRcb5buARYj72vPSUxz6iZfuepDalSTWJVLt41PHp4z1DNiDpjUOk/y8AyJET7RsXDSPxmK/jXtjyGWyAV26xIpPWNmSiMTiLd7UUo5ynByRyYofcV+WcPJpWy/xpYmwN2/9ni7VmQ0+oqTyG3g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682)(120809045254105)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 015114592F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(199003)(189002)(377454003)(77096006)(36756003)(101416001)(105586002)(54356999)(66066001)(106356001)(790700001)(99286002)(106116001)(50986999)(189998001)(2906002)(7906003)(2900100001)(6116002)(7736002)(122556002)(5001770100001)(3846002)(6436002)(8676002)(92566002)(2501003)(107886002)(6506006)(97736004)(4001350100001)(8936002)(606004)(86362001)(6486002)(83506001)(6512006)(68736007)(38730400001)(3660700001)(229853002)(3280700002)(5660300001)(81166006)(102836003)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D47019652CFABqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2016 13:46:42.4711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 13:46:47 -0000 --_000_D47019652CFABqdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rich and all, From: Curdle > on b= ehalf of "Salz, Rich" > Date: Thursday, December 8, 2016 at 7:23 PM To: "curdle@ietf.org" > Subject: [Curdle] Some work for the group Hi there! We are looking for feedback on the following items, my memory spurred by th= e draft minutes found here: https://datatracker.ietf.org/doc/minutes-97-cu= rdle/ Please review the minutes by the end of the month. Speak up on the list if= anything's wrong. Thanks to Ben Kaduk for taking them. Has anyone (besides Kyle Rose) reviewed curdle-rsa-sha2 ? Are we ready for= WGLC? Please respond within a week. The text in draft-ietf-curdle-pkix says CA's MUST NOT use pre-hash version = of signatures. Does anyone object to this? There is a mention of the trad= e-offs in doing that at the end of section 5. Please respond within a week= . There are no security issues with the pre-hash option. One more hash does n= ot create any performance issues for the current protocols. In addition, t= he pre-hash option provides the need for long messages as we know: one exam= ple is the long CRLs on small devices as pointed out on Jim's slides. If I had to choose one algorithm which works well for all situations, I wou= ld choose the pre-hash option. We already know that there are situations people are going to use the pre-h= ash option and there are no security issues with it, but we say that "MUST = NOT use it" which is odd to me. Therefore, the "MUST NOT" requirement for the pre-hash option is not approp= riate in my opinion. curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh-modp-dh-sha2 Has anyone read these? Will one or more people commit to doing so within a= week? (Commit, not actually read) Contexts - has anyone got a use for signature contexts? See the minutes. I= f you're opposed to the (slight) consensus, speak up. Thanks. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_D47019652CFABqdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <575DE55366E68048AB41693097EE614C@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Rich and all, 

From: Curdle <curdle-bounces@ietf.org> on behalf of "= ;Salz, Rich" <rsalz@akamai.com<= /a>>
Date: Thursday, December 8, 2016 at= 7:23 PM
To: "curdle@ietf.org" <= curdle@ietf.org>
Subject: [Curdle] Some work for the= group

Hi there!

 

We are looking for feedback on the following items, = my memory spurred by the draft minutes found here:  https://datatracker.ietf.org/= doc/minutes-97-curdle/

 

Please review the minutes by the end of the month.&n= bsp; Speak up on the list if anything’s wrong.  Thanks to Ben Ka= duk for taking them.

 

Has anyone (besides Kyle Rose) reviewed curdle-rsa-s= ha2 ?  Are we ready for WGLC?  Please respond within a week.=

 

The text in draft-ietf-curdle-pkix says CA’s M= UST NOT use pre-hash version of signatures.  Does anyone object to thi= s?  There is a mention of the trade-offs in doing that at the end of s= ection 5.  Please respond within a week.

There are no security issues with the pre-hash option. One more hash d= oes not create any performance issues for the current protocols.  In a= ddition, the pre-hash option provides the need for long messages as we know= : one example is the long CRLs on small devices as pointed out on Jim’s slides. 

If I had to choose one algorithm which works well for all situations, = I would choose the pre-hash option. 

We already know that there are situations people are going to use the = pre-hash option and there are no security issues with it, but we say that &= #8220;MUST NOT use it”  which is odd to me. 

Therefore, the “MUST NOT” requirement for the pre-hash opt= ion is not appropriate in my opinion.  


 

curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh= -modp-dh-sha2

Has anyone read these?  Will one or more people= commit to doing so within a week?  (Commit, not actually read)

 

Contexts – has anyone got a use for signature = contexts? See the minutes.  If you’re opposed to the (slight) co= nsensus, speak up.

 

Thanks.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@j= abber.at Twitter: RichSalz

 

 --_000_D47019652CFABqdangnistgov_-- From nobody Fri Dec 9 07:04:59 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AA4129546 for ; Fri, 9 Dec 2016 07:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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 dViFF5lQw8AB for ; Fri, 9 Dec 2016 07:04:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AC1129460 for ; Fri, 9 Dec 2016 07:04:55 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D127C057FA4; Fri, 9 Dec 2016 15:04:55 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.253]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB9F4rg5022553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Dec 2016 10:04:54 -0500 Message-ID: <1481295892.20432.16.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Dang, Quynh (Fed)" , "rsalz@akamai.com" , "curdle@ietf.org" Date: Fri, 09 Dec 2016 16:04:52 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 09 Dec 2016 15:04:55 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:04:58 -0000 On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote: > There are no security issues with the pre-hash option. One more hash > does not create any performance issues for the current protocols.  In > addition, the pre-hash option provides the need for long messages as > we know: one example is the long CRLs on small devices as pointed out > on Jim’s slides.  > > If I had to choose one algorithm which works well for all situations, > I would choose the pre-hash option.  I agree. Moreover, I don't quite follow the rationale for having it a must not on some scenarios. Of the options: 1. CA uses SECP256R1 (no prehash) 2. CA uses Ed25519R1 (prehash) 3. CA uses Ed25519R1 (no prehash) the 3rd is banned. I kind of understand what the authors try to achieve, but adding local policies into RFCs does not make much sense (especially if the policy is dubious as in this case; one option with this particular curve is banned, with the other curves it is fine). The option (2) is apparently better than 3, but I do not see why the existence of better option should prevent a CA from using option (3). Similar argumentation could be made for banning Ed25519R1 since Ed441 is better. I instead propose 2 alternatives, (a) remove the prehash option, or (b) create an RFC mandating policies for CAs, which algorithms they MUST use and which not. A CA can chose to follow them. regards, Nikos From nobody Fri Dec 9 08:42:11 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F408D1297BC for ; Fri, 9 Dec 2016 08:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 xacqD6oqImSi for ; Fri, 9 Dec 2016 08:42:06 -0800 (PST) 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 25D7C129480 for ; Fri, 9 Dec 2016 08:42:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E9940300278 for ; Fri, 9 Dec 2016 11:31:48 -0500 (EST) 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 m4l1XWKQPqRY for ; Fri, 9 Dec 2016 11:31:46 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1F4D23000E6; Fri, 9 Dec 2016 11:31:46 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BA5675E-7A07-4A65-B23C-0472FF09D943" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 9 Dec 2016 11:42:01 -0500 Message-Id: <7F982A95-C7D3-408F-8B1D-D2F5F21CD166@vigilsec.com> References: To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:42:09 -0000 --Apple-Mail=_5BA5675E-7A07-4A65-B23C-0472FF09D943 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > The text in draft-ietf-curdle-pkix says CA=92s MUST NOT use pre-hash = version of signatures. Does anyone object to this? There is a mention = of the trade-offs in doing that at the end of section 5. Please respond = within a week. =09 draft-ietf-curdle-cms-eddsa-signatures is aligned with this decision. = If it changes in one of the documents, it needs to change in both. Russ --Apple-Mail=_5BA5675E-7A07-4A65-B23C-0472FF09D943 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

The text in draft-ietf-curdle-pkix says = CA=92s MUST NOT use pre-hash version of signatures.  Does anyone = object to this?  There is a mention of the trade-offs in doing that = at the end of section 5.  Please respond within a = week.

  =
draft-ietf-curdle-cms-eddsa-signatures is aligned with = this decision.  If it changes in one of the documents, it needs to = change in = both.

Russ

= --Apple-Mail=_5BA5675E-7A07-4A65-B23C-0472FF09D943-- From nobody Fri Dec 9 09:33:32 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA321295AC for ; Fri, 9 Dec 2016 09:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_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 6ljUDOVbW-VQ for ; Fri, 9 Dec 2016 09:33:19 -0800 (PST) Received: from mail-wj0-x233.google.com (mail-wj0-x233.google.com [IPv6:2a00:1450:400c:c01::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 E61D91299A0 for ; Fri, 9 Dec 2016 09:33:15 -0800 (PST) Received: by mail-wj0-x233.google.com with SMTP id v7so20296130wjy.2 for ; Fri, 09 Dec 2016 09:33:15 -0800 (PST) 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=pLCSuhvxXUhtHWvs+Wu/X5PS5c/6YIfoWAWpNMCRpyg=; b=UPdoWcqSYTgE9XtpG+t/2lRdUX2o4aA5U88CGQUjj6jcwDzRdkual0EbUuIg0gXG6U /At7dfBHhLNZUIjP+mBOT4Espp+t54//3cmQB2h+DILrg+sWs1E4k+JCV7TC3PPa+pn2 yXEXOM2FfoeyvFljL5oHdIJVwEF6eZVYzJ3FripvwW0YhRoq2lx0s50h09rGN3kmxJ7D giREgKt7awLLcVygtsL+u6YL2He57Fi2X3KyAEJNJugy/nlvvg43Onf0FS57cJ3BzIzR alxkWAMoeEhH8kENnnT4dl73PgjEd03M6b86fzlftu0gAKyhauq82xuiDTub0o9BkYSo bgqg== 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=pLCSuhvxXUhtHWvs+Wu/X5PS5c/6YIfoWAWpNMCRpyg=; b=m1RY84CBSnkappxDP2KPxaRuTWgwoNn+CKSZLInYvi9DMRHrtDEsxQlKDZaLzfdqbr EnZeKE7CEpcx/43N6VwXqrdsY6S1VOu0BBWQ7zm0WIlpcls7iogzhPa3a3B9iYXrxGWB 95J9SO556RdOsIDoPNhY/XpfMf/oOBJOy+ZfDUF8DsnhfBfyWBFxxav46p0w3oKqPd9N eZDwBzJkIy/KqiW+kZe1YvaCo00BorNdhOjVT4T6skOuIEP4QksJFemi76Hkn1UqIe/w g6H0/9HXCwIv8YyBqEn1XzX2nmzzlRUi1UPItfI27NdmtiHAFrlNEIoggasVpOw6Vof4 zbpg== X-Gm-Message-State: AKaTC01Yod8pCTGf+Ti1GdZFOj18VsmzmUiMsrNTB2cJMdzk5lX+HTkHl8arvoNe3zT4DHhEUftLXNmqh19gOQ== X-Received: by 10.194.187.103 with SMTP id fr7mr67113551wjc.99.1481304794296; Fri, 09 Dec 2016 09:33:14 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Fri, 9 Dec 2016 09:33:13 -0800 (PST) In-Reply-To: <7F982A95-C7D3-408F-8B1D-D2F5F21CD166@vigilsec.com> References: <7F982A95-C7D3-408F-8B1D-D2F5F21CD166@vigilsec.com> From: Phillip Hallam-Baker Date: Fri, 9 Dec 2016 12:33:13 -0500 X-Google-Sender-Auth: 9OU4PrmoEI4BTQ3IpRU5wFHwidg Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=047d7bd6bc9c118da705433d26b9 Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:33:31 -0000 --047d7bd6bc9c118da705433d26b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2016 at 11:42 AM, Russ Housley wrote: > > The text in draft-ietf-curdle-pkix says CA=E2=80=99s MUST NOT use pre-has= h version > of signatures. Does anyone object to this? There is a mention of the > trade-offs in doing that at the end of section 5. Please respond within = a > week. > > > > draft-ietf-curdle-cms-eddsa-signatures is aligned with this decision. If > it changes in one of the documents, it needs to change in both. > =E2=80=8BI don't think it is sustainable in CMS so if it has to be the same= in both places then we have to reject it. In order for a crypto mode to be viable, it has to be possible to implement it in a streaming encoder. Memory is cheap but storage is cheaper. If I have a digital camera that is signing pictures as they are taken, that module has to be something that can be implemented in a hardware blob somewhere close to the point the image is captured. Another think I have great difficulty with here is actually working out what the pure vs free hash implementation is from the specification. trying to describe crypto in RFC plaintext isn't a good match at the best of times. =E2=80=8BThis is particularly hard to follow. --047d7bd6bc9c118da705433d26b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, De= c 9, 2016 at 11:42 AM, Russ Housley <housley@vigilsec.com> wrote:

The text in draft-ietf-curdle-pkix= says CA=E2=80=99s MUST NOT use pre-hash version of signatures.=C2=A0 Does = anyone object to this?=C2=A0 There is a mention of the trade-offs in doing = that at the end of section 5.=C2=A0 Please respond within a week.

=C2=A0
draf= t-ietf-curdle-cms-eddsa-signatures is aligned with this decision.=C2= =A0 If it changes in one of the documents, it needs to change in both.

=E2=80=8BI don't think it is sustainable in C= MS so if it has to be the same in both places then we have to reject it.

In order for a crypto mode = to be viable, it has to be possible to implement it in a streaming encoder.= Memory is cheap but storage is cheaper. If I have a digital camera that is= signing pictures as they are taken, that module has to be something that c= an be implemented in a hardware blob somewhere close to the point the image= is captured.
<= br>
Another thi= nk I have great difficulty with here is actually working out what the pure = vs free hash implementation is from the specification. trying to describe c= rypto in RFC plaintext isn't a good match at the best of times. =E2=80= =8BThis is particularly hard to follow.


= =C2=A0
--047d7bd6bc9c118da705433d26b9-- From nobody Fri Dec 9 09:42:49 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F02129994 for ; Fri, 9 Dec 2016 09:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 TYXOn1dNYLjj for ; Fri, 9 Dec 2016 09:42:44 -0800 (PST) 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 0BF421299AA for ; Fri, 9 Dec 2016 09:42:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C61A0300272 for ; Fri, 9 Dec 2016 12:32:08 -0500 (EST) 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 xedWRW5IJVBh for ; Fri, 9 Dec 2016 12:32:07 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E71DD30025D; Fri, 9 Dec 2016 12:32:06 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9A707B2E-3361-48DE-9123-2390DF2B0D24" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 9 Dec 2016 12:42:23 -0500 Message-Id: <3C801145-E04A-493A-BD10-7B8A0F683AA0@vigilsec.com> References: <7F982A95-C7D3-408F-8B1D-D2F5F21CD166@vigilsec.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:42:46 -0000 --Apple-Mail=_9A707B2E-3361-48DE-9123-2390DF2B0D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2016, at 12:33 PM, Phillip Hallam-Baker = wrote: >=20 >=20 > On Fri, Dec 9, 2016 at 11:42 AM, Russ Housley = wrote: >=20 >> The text in draft-ietf-curdle-pkix says CA=E2=80=99s MUST NOT use = pre-hash version of signatures. Does anyone object to this? There is a = mention of the trade-offs in doing that at the end of section 5. Please = respond within a week. >=20 > =09 > draft-ietf-curdle-cms-eddsa-signatures is aligned with this decision. = If it changes in one of the documents, it needs to change in both. >=20 > =E2=80=8BI don't think it is sustainable in CMS so if it has to be the = same in both places then we have to reject it. >=20 > In order for a crypto mode to be viable, it has to be possible to = implement it in a streaming encoder. Memory is cheap but storage is = cheaper. If I have a digital camera that is signing pictures as they are = taken, that module has to be something that can be implemented in a = hardware blob somewhere close to the point the image is captured. >=20 > Another think I have great difficulty with here is actually working = out what the pure vs free hash implementation is from the specification. = trying to describe crypto in RFC plaintext isn't a good match at the = best of times. =E2=80=8BThis is particularly hard to follow. Please take a look at the document. The content is hashed, and that = hash is placed in the message digest attribute, then the set of = attributes is signed with pure EdDSA. Russ= --Apple-Mail=_9A707B2E-3361-48DE-9123-2390DF2B0D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 9, 2016, at 12:33 PM, Phillip = Hallam-Baker <phill@hallambaker.com> = wrote:



On Fri, Dec 9, 2016 at 11:42 AM, Russ Housley = <housley@vigilsec.com> = wrote:

The text in = draft-ietf-curdle-pkix says CA=E2=80=99s MUST NOT use pre-hash version = of signatures.  Does anyone object to this?  There is a = mention of the trade-offs in doing that at the end of section 5.  = Please respond within a = week.

  =
draft-ietf-curdle-cms-eddsa-signatures is aligned = with this decision.  If it changes in one of the documents, it = needs to change in = both.

=E2=80=8BI don't think = it is sustainable in CMS so if it has to be the same in both places then = we have to reject it.

In order for a crypto mode to be viable, it = has to be possible to implement it in a streaming encoder. Memory is = cheap but storage is cheaper. If I have a digital camera that is signing = pictures as they are taken, that module has to be something that can be = implemented in a hardware blob somewhere close to the point the image is = captured.

Another think I have great difficulty with = here is actually working out what the pure vs free hash implementation = is from the specification. trying to describe crypto in RFC plaintext = isn't a good match at the best of times. =E2=80=8BThis is particularly = hard to = follow.

Please = take a look at the document.  The content is hashed, and that hash = is placed in the message digest attribute, then the set of attributes is = signed with pure = EdDSA.

Russ
= --Apple-Mail=_9A707B2E-3361-48DE-9123-2390DF2B0D24-- From nobody Sun Dec 11 03:21:29 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0952D1296F6; Sun, 11 Dec 2016 03:21:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148145528503.29942.6087808105717521379.idtracker@ietfa.amsl.com> Date: Sun, 11 Dec 2016 03:21:25 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa.all@ietf.org, curdle@ietf.org, ietf@ietf.org Subject: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 11:21:25 -0000 Reviewer: Dan Romascanu Review result: Ready with Nits Summary: Ready, with nits I am not an expert in this field, but the document seems to meet its goals, it's clear and precise Major issues: Minor issues: Nits/editorial comments: 1. Section 4: s/Section5.1.7/Sections 5.1.7/ 2. Section 8: 'The following entry has been added to the registry' - I may be wrong, but the section seems to define two new entries in the registry rather than one From nobody Sun Dec 11 05:14:27 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DB12968E; Sun, 11 Dec 2016 05:14:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Sun, 11 Dec 2016 05:14:19 -0800 Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 13:14:19 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits. Introduction ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key and a 96-bit nonce. ChaCha20 is described in [FORIETF]. ChaCha20 is described in DJB's paper. RFC 7539 just repeats the definition with more detail, examples and test vectors. Same for Poly1305 in the next paragraph. Section 3 describes how to use AEAD_CHACHA20_POLY1305 with AuthEnvelopedData. The algorithm, as stated in section 1.1 has four inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, and an arbitrary length additional authenticated data (AAD). The key is generated by one of the methods in section 2 (Key Management); the nonce is generated by the sender. The text requires that it be unique, but does not mandate of suggest a way of doing this. This is fine. The plaintext according to section 3 is "the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field". and the tag is stored in the AuthEnvelopedData mac field. What's missing is the AAD. I could not find what goes into the AAD. This is described in section 2.2 of RFC 5083, but it should be either repeated here or referenced. It's jarring that the other inputs are described while this one is omitted. The Security Considerations section seems fine. Yoav From nobody Sun Dec 11 23:36:55 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC14F12956C; Sun, 11 Dec 2016 23:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 1rCkF2MLbZzY; Sun, 11 Dec 2016 23:36:47 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 7FFFC12957F; Sun, 11 Dec 2016 23:36:44 -0800 (PST) X-AuditID: c618062d-ab7ff70000007359-21-584e58d4720e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id 8A.D7.29529.4D85E485; Mon, 12 Dec 2016 08:59:19 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0319.002; Mon, 12 Dec 2016 02:36:40 -0500 From: Daniel Migault To: Dan Romascanu , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-curdle-dnskey-eddsa-02 Thread-Index: AQHSU6C4i+rMO9ocBUWkxf9EcksFjKED7ZgQ Date: Mon, 12 Dec 2016 07:36:39 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117FF1023@eusaamb107.ericsson.se> References: <148145528503.29942.6087808105717521379.idtracker@ietfa.amsl.com> In-Reply-To: <148145528503.29942.6087808105717521379.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt+71CL8Ig/2HTCy2LpzFbLFo91pm i8bHWhZXX31msXi2cT6LA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxbu9VxoJzHBVf H+9lbmDcwNHFyMkhIWAiMffIFzYQW0hgPaPEi76kLkYuIHs5o8SsDW/BEmwCRhJth/rZQWwR AV+J66cnsYMUMQusZJT49e03WJGwgIXEr/l3oYosJf6emQ0U5wCyjSTWtUqBhFkEVCWOHl7A CmLzAs15v30zM8RiX4nPb16wgNicAn4SS3ZvBqthFBCT+H5qDROIzSwgLnHryXwmiKMFJJbs Oc8MYYtKvHz8jxXCVpL4+Hs+O8haZgFNifW79CFaFSWmdD9kh1grKHFy5hOWCYyis5BMnYXQ MQtJxywkHQsYWVYxcpQWF+TkphsZbGIERskxCTbdHYz3p3seYhTgYFTi4f2Q6RshxJpYVlyZ e4hRgoNZSYR3T5BfhBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeuNX3w4UE0hNLUrNTUwtSi2Cy TBycUg2MzGq3unu+ZrxKuZeg+sRH8WRW1eXXey5eUjELnlYy6WFuQ5b9ga0WQvE6WnP+qVl8 ZDhyeUVow7v2/dzxryymTH2z4drEL/KV84OLTkacOuL20/fLlg3nGEJ3M30uYukNsyjQqrnz cePL1+92Z3/Xv7njYsxclb/swldYTB8sVxPzXiRc/udeqBJLcUaioRZzUXEiAGa74wWOAgAA Archived-At: Cc: "draft-ietf-curdle-dnskey-eddsa.all@ietf.org" , "curdle@ietf.org" , "ietf@ietf.org" Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 07:36:50 -0000 VGhhbmtzIERhbiBmb3IgdGhlIHJldmlldy4gDQoNCllvdXJzLCANCkRhbmllbA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuIFJvbWFzY2FudSBbbWFpbHRvOmRyb21hc2Nh QGdtYWlsLmNvbV0gDQpTZW50OiBTdW5kYXksIERlY2VtYmVyIDExLCAyMDE2IDEyOjIxIFBNDQpU bzogZ2VuLWFydEBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtY3VyZGxlLWRuc2tleS1lZGRzYS5h bGxAaWV0Zi5vcmc7IGN1cmRsZUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogUmV2 aWV3IG9mIGRyYWZ0LWlldGYtY3VyZGxlLWRuc2tleS1lZGRzYS0wMg0KDQpSZXZpZXdlcjogRGFu IFJvbWFzY2FudQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNClN1bW1hcnk6IFJl YWR5LCB3aXRoIG5pdHMNCg0KSSBhbSBub3QgYW4gZXhwZXJ0IGluIHRoaXMgZmllbGQsIGJ1dCB0 aGUgZG9jdW1lbnQgc2VlbXMgdG8gbWVldCBpdHMgZ29hbHMsIGl0J3MgY2xlYXIgYW5kIHByZWNp c2UNCg0KTWFqb3IgaXNzdWVzOg0KDQpNaW5vciBpc3N1ZXM6DQoNCk5pdHMvZWRpdG9yaWFsIGNv bW1lbnRzOg0KDQoxLiBTZWN0aW9uIDQ6IHMvU2VjdGlvbjUuMS43L1NlY3Rpb25zIDUuMS43Lw0K DQoyLiBTZWN0aW9uIDg6ICdUaGUgZm9sbG93aW5nIGVudHJ5IGhhcyBiZWVuIGFkZGVkIHRvDQog ICB0aGUgcmVnaXN0cnknIC0gSSBtYXkgYmUgd3JvbmcsIGJ1dCB0aGUgc2VjdGlvbiBzZWVtcyB0 byBkZWZpbmUgdHdvIG5ldyBlbnRyaWVzIGluIHRoZSByZWdpc3RyeSByYXRoZXIgdGhhbiBvbmUN Cg0KDQo= From nobody Mon Dec 12 01:38:53 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F61294DA; Mon, 12 Dec 2016 01:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq9mXwdxcYkr; Mon, 12 Dec 2016 01:38:42 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1541295A3; Mon, 12 Dec 2016 01:38:37 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 23F1F6127A; Mon, 12 Dec 2016 10:38:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481535516; bh=jNR6LblXm7uu3HC68mpBMXkzX/1jNjqaQ19OG3h2Gqg=; h=Date:From:To; b=o6mtY4yNkWZUGFgPgF4ZHhalIhT3badJi/qoxJwJGDw07jV+6yNU9QgkiDfgcCEfy GtSCQPQYrJfuR7Oo5tQMcKF+uQbgxvVBbbk3Dd420hRKukxSjHw90ZFIjXuJheKhUP qIagOogkL48nUP/kXGGGW6KgmiNvQfiq9g7KeQ8M= Date: Mon, 12 Dec 2016 10:38:35 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Magnus =?utf-8?Q?Nystr=C3=B6m?= , Dan Romascanu Message-ID: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF50 (Linux)/8.7.0_GA_1659) Thread-Topic: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) Thread-Index: LzflipimV17IlkcBn4a2Ul/QhkSYmA== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 09:38:45 -0000 Magnus and Dan, thanks for the review. Magnus, you are right, I have removed the first full paragraph about "security properties" from Security Considerations from my git version as the security properties of EdDSA are better described in Normative references anyway. https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270f= dd103d9a2 Dan, good catches, I fixed the nits in the git: https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d90= 7d035aadf I would be happy to upload next revision after Last Call is finished or just let the RFC editors to fix it. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Magnus Nystr=C3=B6m" > To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" > Sent: Monday, 12 December, 2016 02:44:18 > Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document describes how to use two two specific Edwards Curves > (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > ed448. >=20 > The only comment I have on this document is that the Security > Considerations section plainly states, without any reference or proof: >=20 > "Ed25519 and Ed448 offers improved security properties and > implementation characteristics compared to RSA and ECDSA algorithms" >=20 > I suggest either adding references to proofs of these statements or > alternatively just remove the sentence (since it doesn't really add > anything to the memo); the remaining paragraphs in the Security > Considerations section is what really covers what someone implementing > the memo should know or be aware of. >=20 > -- Magnus ~~~~ ----- Original Message ----- > From: "Dan Romascanu" > To: gen-art@ietf.org > Cc: "draft-ietf-curdle-dnskey-eddsa all" , "curdle" , > ietf@ietf.org > Sent: Sunday, 11 December, 2016 12:21:25 > Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > Reviewer: Dan Romascanu > Review result: Ready with Nits >=20 > Summary: Ready, with nits >=20 > I am not an expert in this field, but the document seems to meet its > goals, it's clear and precise >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 > 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >=20 > 2. Section 8: 'The following entry has been added to > the registry' - I may be wrong, but the section seems to define two > new entries in the registry rather than one From nobody Mon Dec 12 03:24:37 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744C11295FF; Mon, 12 Dec 2016 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 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=-2.896, 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 YK3bSZ3Ctutf; Mon, 12 Dec 2016 03:24:22 -0800 (PST) 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 EFD38129602; Mon, 12 Dec 2016 03:24:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D795BE2F; Mon, 12 Dec 2016 11:24:19 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZGtARDRuDPP; Mon, 12 Dec 2016 11:24:19 +0000 (GMT) Received: from [134.226.63.183] (cswireless63-183.scss.tcd.ie [134.226.63.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68DE2BE2E; Mon, 12 Dec 2016 11:24:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1481541858; bh=XvdeJNpPToY+29lAuA4x8cJZk6w+nHJJKxaJzkiMnO4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xuZfQnzb1DMkT7Qiolz6/IUwJ9JT8jbYpHT1VdI5I8XU7ZTI+LGIAg1vcEhg4Nuzu 8aiM0vR7HETxCDOYKAKnx8/ms6pQq56utbrR1bfCeMZifTKaTjtQDbRmA0cqqRwki9 gMRbKoxY/dkxwlV9IjoiFsKds40eiYdnvBSmpLOk= To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , =?UTF-8?Q?Magnus_Nystr=c3=b6m?= , Dan Romascanu References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 12 Dec 2016 11:24:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070201090804090507050903" Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:24:24 -0000 This is a cryptographically signed message in MIME format. --------------ms070201090804090507050903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ond=C5=99ej, On 12/12/16 09:38, Ond=C5=99ej Sur=C3=BD wrote: > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. Please do upload a new version at the end of last call with these and any other non-controversial changes. Thabks, S. --------------ms070201090804090507050903 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMTIx MTI0MThaMC8GCSqGSIb3DQEJBDEiBCBGXewgzTXP4DFS2BwG04y9PM5VZPlGbXxcIMDbzy61 MDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAK+e6ptJMDATxmeqvSe2WbC+LHJvaZum2KBcf9+/a7q3dAypnIifWm 5RMv7cBLy6264BsBRUZKvDWgOpSyhU08z32nbRCo4J6EwNBxA22I+khK/CxUc+QXNQca4nAt mHRMwVlN3pNMawgvd34r2bluKKrJg5oqvVATjwJvoOIyUvsC4hJAVe1NEe4WyIRTrVvM4gpG E503MhshUusmsCm6H7wmshNFIGCOrOYBkCZKvYBEPgyprHuO28fWPDbf4PYC3VK6Feke9rwd Moe2leYJ+H+Yez5SXcVzPskRHnvCUFl3NHC3j5Q3/wqqcGritt1vem65xLgoIlhXoHaqATel AAAAAAAA --------------ms070201090804090507050903-- From nobody Mon Dec 12 03:34:40 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7894E129628; Mon, 12 Dec 2016 03:34:38 -0800 (PST) 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 q-kGziC1ZhaE; Mon, 12 Dec 2016 03:34:36 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 15F85129605; Mon, 12 Dec 2016 03:34:36 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id c47so72757759qtc.2; Mon, 12 Dec 2016 03:34:36 -0800 (PST) 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=uzxsrosCRe73vJ0ngxRkzoBpj5gmH+0x4aSVHay3sAQ=; b=yWh33Wqg2bmZAKPsXv8d+zHuLbfnN+RRDF1oKAroiV44fJsgICJDr0eCorUj4eA4mH rnDcKqovMz/1myTuDQjt9YWPTmExsR2YRdZVUetq8bwilXO391pRFOZFvemWBaRZ9kjL 6Dj31zFRmNkHpqh79Ko3X54odnw4vD+WfxvohPjaunxVoGgS4nwTr10Q7oEwv3XsIXyq xPJXbagULWSOxjp5582kZqwoUYHxhWqx4JC8WeDBMscGZm0UbcRQ3P1CT7v7G0XlO/Fr CvUaGBqm2rQDTRjJrxThguIaHt8m+IGmBJxNDN53VL6KRImF/wbjAVcarIOYsCj74qAF fDIg== 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=uzxsrosCRe73vJ0ngxRkzoBpj5gmH+0x4aSVHay3sAQ=; b=cFyFJ//NWxqlOtVdrlV7cYAPcd0oFScZFVjwRGchpq8F3wfpE50YTW+exvx2YVVMyR D3vHhbasJ/WOEN46+Ir8Yd2sDhikpKLijPJscTpX3YhDNBN3fLY56ohhy81l10ioiymY MELmpvh5F7j5S85B7X7n679ImjTWVjmKQHkPkxiihRKxQxVeULNa9ED7/YL5xgN1zV1v qqZ4y1kvRlXuCjrDp9nkdvjF1Di331IgZTa91QhDD1qpbhdTqiu956RL+eliMBwRlktB NIXYu1hqUb4jli9C72p2BNLPyQ8H0kDJ1bY/PlahdHl55WHInNvActUWO5tnh3BWNsZp lBpw== X-Gm-Message-State: AKaTC005YhrGplzr+BbnZ8+UKa3w6HcE8H3pcQWyUqMEasQU5L31iDWIzTunI2u4EG+5ZH7+WkVpMGGgXpc0Vw== X-Received: by 10.200.48.44 with SMTP id f41mr79590033qte.94.1481542475151; Mon, 12 Dec 2016 03:34:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.114 with HTTP; Mon, 12 Dec 2016 03:34:34 -0800 (PST) In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> From: Dan Romascanu Date: Mon, 12 Dec 2016 13:34:34 +0200 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a1137aa56f37e510543747c6a Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa , =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:34:38 -0000 --001a1137aa56f37e510543747c6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ondrej, Thanks for addressing my comments. The nits can be fixed at any time you find more convenient before publication. Regards, Dan On Mon, Dec 12, 2016 at 11:38 AM, Ond=C5=99ej Sur=C3=BD wrote: > Magnus and Dan, > > thanks for the review. > > Magnus, you are right, I have removed the first full paragraph > about "security properties" from Security Considerations > from my git version as the security properties of EdDSA > are better described in Normative references anyway. > > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96027= 0 > fdd103d9a2 > > Dan, > > good catches, I fixed the nits in the git: > > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d= 9 > 07d035aadf > > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. > > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Magnus Nystr=C3=B6m" > > To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" < > draft-ietf-curdle-dnskey-eddsa@ietf.org> > > Sent: Monday, 12 December, 2016 02:44:18 > > Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This document describes how to use two two specific Edwards Curves > > (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > > ed448. > > > > The only comment I have on this document is that the Security > > Considerations section plainly states, without any reference or proof: > > > > "Ed25519 and Ed448 offers improved security properties and > > implementation characteristics compared to RSA and ECDSA algorithms" > > > > I suggest either adding references to proofs of these statements or > > alternatively just remove the sentence (since it doesn't really add > > anything to the memo); the remaining paragraphs in the Security > > Considerations section is what really covers what someone implementing > > the memo should know or be aware of. > > > > -- Magnus > > ~~~~ > > ----- Original Message ----- > > From: "Dan Romascanu" > > To: gen-art@ietf.org > > Cc: "draft-ietf-curdle-dnskey-eddsa all" eddsa.all@ietf.org>, "curdle" , > > ietf@ietf.org > > Sent: Sunday, 11 December, 2016 12:21:25 > > Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > > > Reviewer: Dan Romascanu > > Review result: Ready with Nits > > > > Summary: Ready, with nits > > > > I am not an expert in this field, but the document seems to meet its > > goals, it's clear and precise > > > > Major issues: > > > > Minor issues: > > > > Nits/editorial comments: > > > > 1. Section 4: s/Section5.1.7/Sections 5.1.7/ > > > > 2. Section 8: 'The following entry has been added to > > the registry' - I may be wrong, but the section seems to define two > > new entries in the registry rather than one > > --001a1137aa56f37e510543747c6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ondrej,

Thanks for address= ing my comments. The nits can be fixed at any time you find more convenient= before publication.

Regards,

Dan



On Mon, Dec 12= , 2016 at 11:38 AM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
Magnus and Dan,

thanks for the review.

Magnus, you are right, I have removed the first full paragraph
about "security properties" from Security Considerations
from my git version as the security properties of EdDSA
are better described in Normative references anyway.

https://gitlab.l= abs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270fd= d103d9a2

Dan,

good catches, I fixed the nits in the git:

https://gitlab.l= abs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d907= d035aadf

I would be happy to upload next revision after Last Call
is finished or just let the RFC editors to fix it.

Cheers,
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>
> To: secdir@ietf.org, "draf= t-ietf-curdle-dnskey-eddsa" <draft-ietf-curdle-dnskey-eddsa@ietf.org&= gt;
> Sent: Monday, 12 December, 2016 02:44:18
> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02

> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments.
>
> This document describes how to use two two specific Edwards Curves
> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and
> ed448.
>
> The only comment I have on this document is that the Security
> Considerations section plainly states, without any reference or proof:=
>
> "Ed25519 and Ed448 offers improved security properties and
> implementation characteristics compared to RSA and ECDSA algorithms&qu= ot;
>
> I suggest either adding references to proofs of these statements or > alternatively just remove the sentence (since it doesn't really ad= d
> anything to the memo); the remaining paragraphs in the Security
> Considerations section is what really covers what someone implementing=
> the memo should know or be aware of.
>
> -- Magnus

~~~~

----- Original Message -----
> From: "Dan Romascanu" <dromasca@gmail.com>
> To: gen-art@ietf.org
> Cc: "draft-ietf-curdle-dnskey-eddsa all" <draft-ietf-curdle-dnsk= ey-eddsa.all@ietf.org>, "curdle" <curdle@ietf.org>,
> ietf@ietf.org
> Sent: Sunday, 11 December, 2016 12:21:25
> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02

> Reviewer: Dan Romascanu
> Review result: Ready with Nits
>
> Summary: Ready, with nits
>
> I am not an expert in this field, but the document seems to meet its > goals, it's clear and precise
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
> 1. Section 4: s/Section5.1.7/Sections 5.1.7/
>
> 2. Section 8: 'The following entry has been added to
>=C2=A0 =C2=A0the registry' - I may be wrong, but the section seems = to define two
> new entries in the registry rather than one


--001a1137aa56f37e510543747c6a-- From nobody Mon Dec 12 05:28:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35267129B55 for ; Mon, 12 Dec 2016 05:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 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=-2.896, 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 v3fi7UmKZvVz for ; Mon, 12 Dec 2016 05:28:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC9129B85 for ; Mon, 12 Dec 2016 05:26:58 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1959943344E; Mon, 12 Dec 2016 13:26:58 +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 02E1E43344A; Mon, 12 Dec 2016 13:26:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481549218; bh=cC4MgjetqCkH4WiNoq1bRqzuPE2vRCe3+Yw64viR/fk=; l=185; h=From:To:Date:References:In-Reply-To:From; b=g0ws3F9YSz7vUB5N1Mf9vMV7AjtGIyIlKcyYANBrqaN+w9FpT4Y6guDWfIOTAz7cA FVfo4mIhFJGHAQqXkG1sJhAOWPdbZ8v/A2u+37+RsQnsKg4ih7Jum/PFfEutKt75FZ gUzR88QI9FKC0IThmp1adDhu8Ut0YhXGHVvG+Cmc= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F37DF1FC9B; Mon, 12 Dec 2016 13:26:57 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 12 Dec 2016 08:26:57 -0500 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; Mon, 12 Dec 2016 08:26:57 -0500 From: "Salz, Rich" To: "Dang, Quynh (Fed)" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKEEUlMA Date: Mon, 12 Dec 2016 13:26:57 +0000 Message-ID: References: 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.32.252] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 13:28:23 -0000 > There are no security issues with the pre-hash option. There are concerns about software being "tricked" into becoming a signing o= racle, not just the data format being secure. From nobody Mon Dec 12 05:30:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB7129B8B for ; Mon, 12 Dec 2016 05:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 uQaLFJklMuX3 for ; Mon, 12 Dec 2016 05:30:23 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0130.outbound.protection.outlook.com [23.103.200.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A96129B4F for ; Mon, 12 Dec 2016 05:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NVa8RZ8ktevAg8CILgiWr/LF8yW8sTGrLD/gzldvQNk=; b=u/f0UU5h9hnT4iDPBV9TDE3I46njRrr0za1hoSebSEoYa6bTPLvvZ/oJtVifTJgWSqzp7V/pdQZ/kyJL9rkjZPO2RTRcnJ1EYH4JWloYZ+EMaRrdMhtw1LqKOlKRziue07issOvzgpiuNYXDV5l1yAAyUmvhlWaPL7o31nWp6Xk= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1465.namprd09.prod.outlook.com (10.173.171.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Mon, 12 Dec 2016 13:29:15 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0771.014; Mon, 12 Dec 2016 13:29:14 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKEEUlMA//+tCQA= Date: Mon, 12 Dec 2016 13:29:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: ecd6a35e-af9e-4216-ce18-08d42292dde1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1465; x-microsoft-exchange-diagnostics: 1; DM5PR09MB1465; 7:DI9gr0qRdmi4x9u0CBgk5YGCyhfd3+vkhZzNwyoB/nde0zW2ISCWG9bDpBQvly4BLNhwhd/lzxybJMK+mxfEqJF36y6FezzuumXEp2xLgAhljdXIupSpKgjHD9kuwz9c2DFAIcQQxH+NK5r+h+bUnILPsBH4TLq/rhLwCwIyZgDBKCJSI1t20r/cmv6hJTkUYiHgdWrPQAlvg/Cg1k3w40VPJAkVQjEXDBfKtzaSZGdpiYJCp99vLS3ggmjkVFslpXaLekp390zIoaTthBr3DWsDBUN4IoMAjmYahbSkhjmVq24gWOqu10F8mqF3gk0npR1dyOmgb8sMT4vAokhRyyLr/YEQa2ToDYcBLMPBCZ76UKfWq2x1Y/qRVMtuKq2MtNVMGyUboMO6NETh7tK1hqBcd3hDVD4iiXLpN0jjVPXGqrs3bdgKLkwM5aKgKoK5QKPDFzZXQo1lauyu5Sp+Ag== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM5PR09MB1465; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1465; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39840400002)(39850400002)(189002)(199003)(377454003)(81156014)(3846002)(101416001)(102836003)(8936002)(6116002)(76176999)(54356999)(50986999)(6512006)(5660300001)(189998001)(2950100002)(6506006)(36756003)(99286002)(7736002)(106356001)(106116001)(105586002)(38730400001)(229853002)(6486002)(81166006)(92566002)(66066001)(2900100001)(8676002)(77096006)(3280700002)(107886002)(86362001)(2501003)(2906002)(122556002)(97736004)(4001350100001)(5001770100001)(83506001)(6436002)(68736007)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1465; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D47410202D044qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 13:29:14.7533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1465 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 13:30:26 -0000 --_000_D47410202D044qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: "Salz, Rich" > Date: Monday, December 12, 2016 at 8:26 AM To: 'Quynh' >, "curdle@ietf= .org" > Subject: RE: [Curdle] Some work for the group There are no security issues with the pre-hash option. There are concerns about software being "tricked" into becoming a signing o= racle, not just the data format being secure. Can you explain that: I don't understand ? Quynh. --_000_D47410202D044qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: "Salz, Rich" <rsalz@akamai.com>
Date: Monday, December 12, 2016 at = 8:26 AM
To: 'Quynh' <Quynh.Dang@nist.gov>, "curdle@ietf.org" <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group

There are no security issues with the pre-hash option.

There are concerns about software being "tricked" into becom= ing a signing oracle, not just the data format being secure.

Can you explain that: I don’t understand ?

Quynh. 





 --_000_D47410202D044qdangnistgov_-- From nobody Mon Dec 12 06:13:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65594129BB3 for ; Mon, 12 Dec 2016 06:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 URy9SBpRcBoA for ; Mon, 12 Dec 2016 06:13:05 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0110.outbound.protection.outlook.com [23.103.200.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5750D129BAA for ; Mon, 12 Dec 2016 06:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X19o1ivqWSGSnP5owVOriKbUk8I72bgXJ0iUAzhZtSM=; b=hJ2O83eY6NdzmKgcc1T4TX25+1mKF2pnXIKNZyAEYoBdis2B6Sgyf9h6FTdzmng27MHHwdmnDY4bUj9dpwwNA5m/Rmc0TLyzk8t7guXH6jCLkB97rPfs7MWRJysGfYaxN4dDsMdtCGiZKQ4qTendNU/mRpxcDo4c+BHJ6yREy6c= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1468.namprd09.prod.outlook.com (10.173.171.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Mon, 12 Dec 2016 14:13:03 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0771.014; Mon, 12 Dec 2016 14:13:03 +0000 From: "Dang, Quynh (Fed)" To: "rsalz@akamai.com" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKEEUlMA//+tCQCAAFWF0P//trmA Date: Mon, 12 Dec 2016 14:13:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 3c1fa3b3-eed3-4703-b7ac-08d42298fcd8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1468; x-microsoft-exchange-diagnostics: 1; DM5PR09MB1468; 7:cSUCUFJYrHxvwmkzRVslqg/lAaiQ0Z1M5C3qDhinTwPVqnnoYap2OJ7qkTtuUkVJcgKImWT9Hpcnkf/S8k8VV4QnPqpXTaSIOSdC9pbvtU2SS3BywGtwSqBWEDvKr+xwSd6fZ4acNqPVpvyNootumy6sm2CO5TNEbO4h1mV8dpnGSVop3nmaDqLCykoDH4+awEYlpaWZLZD90N0czr0c9fL9xdqFFCYSaonPPkbAyzpNjxcJO2yxNZFETHsMx7A2NSN8GKRYKP5bBk/3N/9S6vGnHytwLq6qbqxKw1+GQbsK0IWZf9EFlvsIx2Lnvgwqbg9L+G9++WD00XPHGB7bId90j/TYx+Sm1qep2XQi7Mmy9WTiL8kaFr0bpcKqiwrMpqXsMQG6RiL/diQbvKAmt5lwiK9tT1nis2ZBi0Ovt2x5VH2E8kXej0ixNl7UUZUmLIZLsXL/vjMTfllhbtOrhQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR09MB1468; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1468; x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39840400002)(39450400003)(199003)(189002)(377454003)(92566002)(81156014)(54356999)(81166006)(50986999)(6512006)(76176999)(229853002)(38730400001)(6486002)(77096006)(6506006)(7736002)(122556002)(2900100001)(3660700001)(102836003)(2906002)(93886004)(66066001)(345774005)(2950100002)(36756003)(3846002)(6116002)(5660300001)(3280700002)(790700001)(101416001)(86362001)(8936002)(68736007)(4001350100001)(99286002)(6436002)(107886002)(5001770100001)(106356001)(105586002)(97736004)(83506001)(2501003)(8676002)(106116001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1468; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D47418B62D04Eqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2016 14:13:03.6425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1468 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 14:13:07 -0000 --_000_D47418B62D04Eqdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the explanation. If an implementation could have that serious error, then we can say anythin= g could happen I guess. If that happened, the signature won't get verified. Quynh. From: "Salz, Rich" > Date: Monday, December 12, 2016 at 8:35 AM To: 'Quynh' > Subject: RE: [Curdle] Some work for the group Software could have an API that wasn't fed the original document, but inste= ad the pre-hashed document. --_000_D47418B62D04Eqdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Thank you for the explanation. 

If an implementation could have that serious error, then we can say an= ything could happen I guess. If that happened, the signature won’t ge= t verified. 

Quynh. 

From: "Salz, Rich" <rsalz@akamai.com>
Date: Monday, December 12, 2016 at = 8:35 AM
To: 'Quynh' <Quynh.Dang@nist.gov>
Subject: RE: [Curdle] Some work for= the group

Software could have an API that was= n’t fed the original document, but instead the pre-hashed document.

 --_000_D47418B62D04Eqdangnistgov_-- From nobody Mon Dec 12 13:52:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F62B129D15 for ; Mon, 12 Dec 2016 13:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=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 m6hYD-qbqdH5 for ; Mon, 12 Dec 2016 13:51:48 -0800 (PST) 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 A0565129DA9 for ; Mon, 12 Dec 2016 13:51:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 581EE300293 for ; Mon, 12 Dec 2016 16:41:31 -0500 (EST) 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 Y7opA-pcsshY for ; Mon, 12 Dec 2016 16:41:29 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1395B300093; Mon, 12 Dec 2016 16:41:29 -0500 (EST) 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: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 16:51:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <112F7397-2F82-4573-B552-B7BE69E2F24C@vigilsec.com> References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, IETF SecDir Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:51:53 -0000 Yoav: Thanks for the review. The document will be more clear about the = handling of AAD because you reviewed it. > Reviewer: Yoav Nir > Review result: Has Nits >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: Ready with nits. >=20 > Introduction > ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit = key > and a 96-bit nonce. ChaCha20 is described in [FORIETF]. >=20 > ChaCha20 is described in DJB's paper. RFC 7539 just repeats the > definition with more detail, examples and test vectors. Same for > Poly1305 in the next paragraph. The point of RFC 7539, I believe, is a reference that is readily = available to the Internet community. Does this rewording resolve your = concern? [FORIETF] provides a detailed algorithm description, examples, and test = vectors of ChaCha20. [FORIETF] also provides a detailed algorithm description, examples, and = test vectors of Poly1305. > Section 3 describes how to use AEAD_CHACHA20_POLY1305 with > AuthEnvelopedData. The algorithm, as stated in section 1.1 has four > inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, > and an arbitrary length additional authenticated data (AAD). The key > is generated by one of the methods in section 2 (Key Management); the > nonce is generated by the sender. The text requires that it be unique, > but does not mandate of suggest a way of doing this. This is fine. The > plaintext according to section 3 is "the content located in the > AuthEnvelopedData EncryptedContentInfo encryptedContent field". and > the tag is stored in the AuthEnvelopedData mac field. >=20 > What's missing is the AAD. I could not find what goes into the AAD. > This is described in section 2.2 of RFC 5083, but it should be either > repeated here or referenced. It's jarring that the other inputs are > described while this one is omitted. I suggest the following replacement for the third paragraph in Section = 3. The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the attributes located in the AuthEnvelopedData authAttrs field, if any are present, encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and to provide the message authentication code (MAC) located in the AuthEnvelopedData mac field. The authenticated attributes are DER encoded to produce the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called the authentication tag in [FORIETF], provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent. Thanks, Russ From nobody Mon Dec 12 14:11:56 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B12943B; Mon, 12 Dec 2016 14:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Mlk2zrq5eIFd; Mon, 12 Dec 2016 14:11:47 -0800 (PST) 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 CBBC9129793; Mon, 12 Dec 2016 14:11:43 -0800 (PST) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 14:31:18 -0800 From: Jim Schaad To: 'Yoav Nir' , References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> In-Reply-To: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 14:11:34 -0800 Message-ID: <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNAj1+knqelScWc7hRTFF3lbOB1zp4oahLg Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 22:11:51 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Sunday, December 11, 2016 5:14 AM > To: secdir@ietf.org > Cc: curdle@ietf.org; draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org; > ietf@ietf.org > Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 > > Reviewer: Yoav Nir > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > Summary: Ready with nits. > > Introduction > ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key > and a 96-bit nonce. ChaCha20 is described in [FORIETF]. > > ChaCha20 is described in DJB's paper. RFC 7539 just repeats the definition with > more detail, examples and test vectors. Same for > Poly1305 in the next paragraph. ChaCha20 was originally described in DJB's paper. There is still a complete description of the algorithm in [FORIETF]. Once could argue that it is a more complete description since it includes examples and test vectors. > > Section 3 describes how to use AEAD_CHACHA20_POLY1305 with > AuthEnvelopedData. The algorithm, as stated in section 1.1 has four > inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, and an > arbitrary length additional authenticated data (AAD). The key is generated by > one of the methods in section 2 (Key Management); the nonce is generated by > the sender. The text requires that it be unique, but does not mandate of suggest > a way of doing this. This is fine. The plaintext according to section 3 is "the > content located in the AuthEnvelopedData EncryptedContentInfo > encryptedContent field". and the tag is stored in the AuthEnvelopedData mac > field. > > What's missing is the AAD. I could not find what goes into the AAD. > This is described in section 2.2 of RFC 5083, but it should be either repeated here > or referenced. It's jarring that the other inputs are described while this one is > omitted. That seems reasonable to add. Jim > > The Security Considerations section seems fine. > > Yoav > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Dec 12 14:22:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CAA129C7F for ; Mon, 12 Dec 2016 14:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 zk7Ql3DTs5IQ for ; Mon, 12 Dec 2016 14:22:55 -0800 (PST) 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 EAAE51294BB for ; Mon, 12 Dec 2016 14:22:54 -0800 (PST) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 14:42:31 -0800 From: Jim Schaad To: 'Nikos Mavrogiannopoulos' , "'Dang, Quynh (Fed)'" , , References: <1481295892.20432.16.camel@redhat.com> In-Reply-To: <1481295892.20432.16.camel@redhat.com> Date: Mon, 12 Dec 2016 14:22:47 -0800 Message-ID: <0e1701d254c6$46509670$d2f1c350$@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: AQGOVN2GtPOV1KiNXXPE24AdYcNsXgL/ocZFoXTkMvA= Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 22:22:57 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Friday, December 09, 2016 7:05 AM > To: Dang, Quynh (Fed) ; rsalz@akamai.com; > curdle@ietf.org > Subject: Re: [Curdle] Some work for the group >=20 > On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote: >=20 > > There are no security issues with the pre-hash option. One more hash > > does not create any performance issues for the current protocols. = In > > addition, the pre-hash option provides the need for long messages as > > we know: one example is the long CRLs on small devices as pointed = out > > on Jim=E2=80=99s slides. > > > > If I had to choose one algorithm which works well for all = situations, > > I would choose the pre-hash option. >=20 > I agree. >=20 > Moreover, I don't quite follow the rationale for having it a must not = on some > scenarios. Of the options: > 1. CA uses SECP256R1 (no prehash) > 2. CA uses Ed25519R1 (prehash) > 3. CA uses Ed25519R1 (no prehash) I am going to assume that this is just a typo as the prehash and no = prehash are reversed on the above list. =20 There is one low level argument that I have found for forbidding the = pre-hash version for Ed25519. There is a possibility that if the = pre-hash version is allowed somebody is going to implement it = incorrectly and do the pre-hash as the item to be signed for pure mode = as that is what is currently available. The current restrictions would = avoid this possibility for certificates but not for other uses. >=20 > the 3rd is banned. I kind of understand what the authors try to = achieve, but > adding local policies into RFCs does not make much sense (especially = if the > policy is dubious as in this case; one option with this particular = curve is banned, > with the other curves it is fine). The option (2) is apparently better = than 3, but I > do not see why the existence of better option should prevent a CA from = using > option (3). >=20 > Similar argumentation could be made for banning Ed25519R1 since Ed441 = is > better. >=20 > I instead propose 2 alternatives, (a) remove the prehash option, or = (b) create an > RFC mandating policies for CAs, which algorithms they MUST use and = which not. > A CA can chose to follow them. I think that option B would be more for the CA Consortium that for the = IETF to do.=20 Jim >=20 > regards, > Nikos >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Dec 13 04:09:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ACF12A066 for ; Tue, 13 Dec 2016 04:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 B8cHiTcvTqkp for ; Tue, 13 Dec 2016 04:09:24 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0122.outbound.protection.outlook.com [23.103.200.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C781129617 for ; Tue, 13 Dec 2016 04:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HSscTk71fY2eg1ITyYmp3RXF3gi9PGb97jSICUhkJPE=; b=rB2DCNIi8oSdhNzXHWoxjUDCZ+UCHbECkENDWAM0vPFZL3w81PMewdBqZ+PeG4hadOL3AiT2tWKb22/ojHcHKCXpygjXcYCUmQknCRL7W9irLP5dh0aVHDyVEZLKaQz/JhZRn4F6scL3jK4CP6kEP6V/PiPHSQ9pwozhxP1lc84= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Tue, 13 Dec 2016 12:09:22 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0771.014; Tue, 13 Dec 2016 12:09:21 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , 'Nikos Mavrogiannopoulos' , "Dang, Quynh (Fed)" , "rsalz@akamai.com" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAAJMdgA== Date: Tue, 13 Dec 2016 12:09:21 +0000 Message-ID: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> In-Reply-To: <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:zwPraZ2IUhejglU/Rm//EgP06AQLeMp8KF563G+1DlfVSKbep5uiPU/y8rAXScGw/D/SArxhxF9qVjTKLqbBkaeTNHmtJ0rGApnjO5DVhFm25z/Kz1UXDs23bvYCRiJvTNMSobRU0fbEzW94SVcnQ5c+7cr+j9cUVu3NYO+16yTrIZd2Q6jJvatZjE7IyAUNS+Rk/ABMVGOMaNxmVAGz+vl4UVnMfQjNZ1VDX7Ir2TBBMei4x/SaJ5dicMrBdeJ9OI//fjoM9vP/9kbiY65R6i/JSaOEy0XTN/+SOWRA1TcAJhoIhGQIaCPOromdMI0gdQX/nr2MnUoNovy8ZjeZyuOF5zSu5+7JkwFowQpE+y99itPeWV/e2nslv8GnPNxrCKQOVuU0vftM4FHV6Ce9Y/5RU5NwlzpFa3XhjbRST5LbC2xxZPocwfucrAMM4bC+D7h1G8SpeDk9Y6VQC/97BA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(377424004)(199003)(189002)(13464003)(24454002)(377454003)(51444003)(5660300001)(83506001)(97736004)(5001770100001)(101416001)(2201001)(189998001)(86362001)(2900100001)(3660700001)(106116001)(77096006)(2950100002)(2906002)(99286002)(6512006)(122556002)(4001350100001)(105586002)(107886002)(106356001)(8936002)(36756003)(8676002)(6486002)(6506006)(81166006)(81156014)(92566002)(54356999)(7736002)(50986999)(68736007)(7906003)(606005)(229853002)(3280700002)(3846002)(76176999)(6436002)(2501003)(6116002)(102836003)(38730400001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 5f6c25dc-ce02-42e2-8255-08d42350df6c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 01559F388D received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4754C1E2D0B1qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2016 12:09:21.7137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 12:09:27 -0000 --_000_D4754C1E2D0B1qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Jim Schaad > Date: Monday, December 12, 2016 at 5:22 PM To: 'Nikos Mavrogiannopoulos' >, 'Q= uynh' >, "rsalz@akamai.com<= mailto:rsalz@akamai.com>" >, "cur= dle@ietf.org" > Subject: RE: [Curdle] Some work for the group -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, December 09, 2016 7:05 AM To: Dang, Quynh (Fed) >; rs= alz@akamai.com; curdle@ietf.org Subject: Re: [Curdle] Some work for the group On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote: > There are no security issues with the pre-hash option. One more hash > does not create any performance issues for the current protocols. In > addition, the pre-hash option provides the need for long messages as > we know: one example is the long CRLs on small devices as pointed out > on Jim's slides. > > If I had to choose one algorithm which works well for all situations, > I would choose the pre-hash option. I agree. Moreover, I don't quite follow the rationale for having it a must not on so= me scenarios. Of the options: 1. CA uses SECP256R1 (no prehash) 2. CA uses Ed25519R1 (prehash) 3. CA uses Ed25519R1 (no prehash) I am going to assume that this is just a typo as the prehash and no prehash= are reversed on the above list. There is one low level argument that I have found for forbidding the pre-ha= sh version for Ed25519. There is a possibility that if the pre-hash versi= on is allowed somebody is going to implement it incorrectly and do the pre-= hash as the item to be signed for pure mode as that is what is currently av= ailable. The current restrictions would avoid this possibility for certifi= cates but not for other uses. Hi Jim, Don't people check or test their implementations. It is hard for me to ima= gine why when someone does not want to use the pre-hash, decides to impleme= nt the non pre-hash version, but ended implementing the pre-hash version, t= hen don't check or test his or her implementation at all. I appreciate your work and contributions! Quynh. the 3rd is banned. I kind of understand what the authors try to achieve, bu= t adding local policies into RFCs does not make much sense (especially if the policy is dubious as in this case; one option with this particular curve is= banned, with the other curves it is fine). The option (2) is apparently better than= 3, but I do not see why the existence of better option should prevent a CA from usin= g option (3). Similar argumentation could be made for banning Ed25519R1 since Ed441 is better. I instead propose 2 alternatives, (a) remove the prehash option, or (b) cre= ate an RFC mandating policies for CAs, which algorithms they MUST use and which no= t. A CA can chose to follow them. I think that option B would be more for the CA Consortium that for the IETF= to do. Jim regards, Nikos _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_D4754C1E2D0B1qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Jim Schaad <ietf@augustcellars.com>
Date: Monday, December 12, 2016 at = 5:22 PM
To: 'Nikos Mavrogiannopoulos' <<= a href=3D"mailto:nmav@redhat.com">nmav@redhat.com>, 'Quynh' <Quynh.Dang@nist.gov>, "rsalz@akamai.com" <rsalz@akamai.com>, "curdle@ietf.org" <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group



-----Original Message-----
From: Curdle [mailto:curdle= -bounces@ietf.org] On Behalf Of Nikos
Mavrogiannopoulos
Sent: Friday, December 09, 2016 7:05 AM
To: Dang, Quynh (Fed) <quynh= .dang@nist.gov>; rsalz@akamai.com;
Subject: Re: [Curdle] Some work for the group
On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote:
> There are no security issues with the pre-hash option. One more h= ash
> does not create any performance issues for the current protocols.=   In
> addition, the pre-hash option provides the need for long messages= as
> we know: one example is the long CRLs on small devices as pointed= out
> on Jim’s slides.
>
> If I had to choose one algorithm which works well for all situati= ons,
> I would choose the pre-hash option.
I agree.
Moreover, I don't quite follow the rationale for having it a must not = on some
scenarios. Of the options:
1. CA uses SECP256R1 (no prehash)
2. CA uses Ed25519R1 (prehash)
3. CA uses Ed25519R1 (no prehash)

I am going to assume that this is just a typo as the prehash and no pr= ehash are reversed on the above list.  

There is one low level argument that I have found for forbidding the p= re-hash version for Ed25519.   There is a possibility that if the= pre-hash version is allowed somebody is going to implement it incorrectly = and do the pre-hash as the item to be signed for pure mode as that is what is currently available.  The curre= nt restrictions would avoid this possibility for certificates but not for o= ther uses.

Hi = Jim, 
D= on’t people check or test their implementations.  It is hard for= me to imagine why when someone does not want to use the pre-hash, decides to implement the non pre-hash version, but ended= implementing the pre-hash version, then don’t check or test his or h= er implementation at all. 
<= br>
I appreciate your work and con= tributions!
<= br>
Quynh. 


the 3rd is banned. I kind of understand what the authors try to achiev= e, but
adding local policies into RFCs does not make much sense (especially i= f the
policy is dubious as in this case; one option with this particular cur= ve is banned,
with the other curves it is fine). The option (2) is apparently better= than 3, but I
do not see why the existence of better option should prevent a CA from= using
option (3).
Similar argumentation could be made for banning Ed25519R1 since Ed441 = is
better.
I instead propose 2 alternatives, (a) remove the prehash option, or (b= ) create an
RFC mandating policies for CAs, which algorithms they MUST use and whi= ch not.
A CA can chose to follow them.

I think that option B would be more for the CA Consortium that for the= IETF to do.

Jim

regards,
Nikos
_______________________________________________
Curdle mailing list


 --_000_D4754C1E2D0B1qdangnistgov_-- From nobody Tue Dec 13 12:30:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B6812970F for ; Tue, 13 Dec 2016 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, 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 mVDWBWypqW5r for ; Tue, 13 Dec 2016 12:30:44 -0800 (PST) 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 B72F3129706 for ; Tue, 13 Dec 2016 12:30:42 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 12:50:17 -0800 From: Jim Schaad To: "'Dang, Quynh (Fed)'" , References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> In-Reply-To: Date: Tue, 13 Dec 2016 12:30:33 -0800 Message-ID: <00f001d2557f$c298b140$47ca13c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01D2553C.B4774600" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGOVN2GtPOV1KiNXXPE24AdYcNsXgL/ocZFAelhcFYAhZA4jaFi36FA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 20:30:48 -0000 ------=_NextPart_000_00F1_01D2553C.B4774600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Dang, Quynh (Fed) [mailto:quynh.dang@nist.gov] Sent: Tuesday, December 13, 2016 4:09 AM To: Jim Schaad ; 'Nikos Mavrogiannopoulos' ; Dang, Quynh (Fed) ; rsalz@akamai.com; curdle@ietf.org Subject: Re: [Curdle] Some work for the group From: Jim Schaad > Date: Monday, December 12, 2016 at 5:22 PM To: 'Nikos Mavrogiannopoulos' , 'Quynh' >, "rsalz@akamai.com " >, "curdle@ietf.org " > Subject: RE: [Curdle] Some work for the group -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, December 09, 2016 7:05 AM To: Dang, Quynh (Fed) >; rsalz@akamai.com ; curdle@ietf.org Subject: Re: [Curdle] Some work for the group On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote: > There are no security issues with the pre-hash option. One more hash > does not create any performance issues for the current protocols. In > addition, the pre-hash option provides the need for long messages as > we know: one example is the long CRLs on small devices as pointed out > on Jim's slides. > > If I had to choose one algorithm which works well for all situations, > I would choose the pre-hash option. I agree. Moreover, I don't quite follow the rationale for having it a must not on some scenarios. Of the options: 1. CA uses SECP256R1 (no prehash) 2. CA uses Ed25519R1 (prehash) 3. CA uses Ed25519R1 (no prehash) I am going to assume that this is just a typo as the prehash and no prehash are reversed on the above list. There is one low level argument that I have found for forbidding the pre-hash version for Ed25519. There is a possibility that if the pre-hash version is allowed somebody is going to implement it incorrectly and do the pre-hash as the item to be signed for pure mode as that is what is currently available. The current restrictions would avoid this possibility for certificates but not for other uses. Hi Jim, Don't people check or test their implementations. It is hard for me to imagine why when someone does not want to use the pre-hash, decides to implement the non pre-hash version, but ended implementing the pre-hash version, then don't check or test his or her implementation at all. Quynh, No, this is I implement the pure version and somebody else abuses it and uses it as a pre-hash version. That is they do what comes naturally today. Jim I appreciate your work and contributions! Quynh. the 3rd is banned. I kind of understand what the authors try to achieve, but adding local policies into RFCs does not make much sense (especially if the policy is dubious as in this case; one option with this particular curve is banned, with the other curves it is fine). The option (2) is apparently better than 3, but I do not see why the existence of better option should prevent a CA from using option (3). Similar argumentation could be made for banning Ed25519R1 since Ed441 is better. I instead propose 2 alternatives, (a) remove the prehash option, or (b) create an RFC mandating policies for CAs, which algorithms they MUST use and which not. A CA can chose to follow them. I think that option B would be more for the CA Consortium that for the IETF to do. Jim regards, Nikos _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_00F1_01D2553C.B4774600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Dang, Quynh (Fed) [mailto:quynh.dang@nist.gov]
Sent: Tuesday, = December 13, 2016 4:09 AM
To: Jim Schaad = <ietf@augustcellars.com>; 'Nikos Mavrogiannopoulos' = <nmav@redhat.com>; Dang, Quynh (Fed) <quynh.dang@nist.gov>; = rsalz@akamai.com; curdle@ietf.org
Subject: Re: [Curdle] Some = work for the group

 

<= o:p> 

<= o:p> 

F= rom: J= im Schaad <ietf@augustcellars.com>
= Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos = Mavrogiannopoulos' <nmav@redhat.com>, 'Quynh' <Quynh.Dang@nist.gov>, = "rsalz@akamai.com" = <rsalz@akamai.com>, = "curdle@ietf.org" = <curdle@ietf.org>
Subject: = RE: [Curdle] Some work for the = group

<= o:p> 

<= o:p> 

<= o:p> 

-= ----Original Message-----

<= a = href=3D"mailto:curdle@ietf.org">curdle@ietf.org

=

S= ubject: Re: [Curdle] Some work for the = group

O= n Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) = wrote:

&= gt; There are no security issues with the pre-hash option. One more = hash

&= gt; does not create any performance issues for the current = protocols.  In

&= gt; addition, the pre-hash option provides the need for long messages = as

&= gt; we know: one example is the long CRLs on small devices as pointed = out

&= gt; on Jim’s slides.

&= gt; 

&= gt; If I had to choose one algorithm which works well for all = situations,

&= gt; I would choose the pre-hash = option.

I= agree.

M= oreover, I don't quite follow the rationale for having it a must not on = some

s= cenarios. Of the options:

1= . CA uses SECP256R1 (no prehash)

2= . CA uses Ed25519R1 (prehash)

3= . CA uses Ed25519R1 (no = prehash)

<= o:p> 

I= am going to assume that this is just a typo as the prehash and no = prehash are reversed on the above = list.  

<= o:p> 

T= here is one low level argument that I have found for forbidding the = pre-hash version for Ed25519.   There is a possibility that if = the pre-hash version is allowed somebody is going to implement it = incorrectly and do the pre-hash as the item to be signed for pure mode = as that is what is currently available.  The current = restrictions would avoid this possibility for certificates but not for = other uses.

<= o:p> 

Hi = Jim, 

 

Don’t = people check or test their implementations.  It is hard for me to = imagine why when someone does not want to use the pre-hash, decides to = implement the non pre-hash version, but ended implementing the pre-hash = version, then don’t check or test his or her implementation at = all. 

 

Quynh,

 

No, this is = I implement the pure version and somebody else abuses it and uses it as = a pre-hash version.  That is they do what comes naturally = today.

 

Jim

 



I appreciate your work and = contributions!



Quynh. 

<= o:p> 

<= o:p> 

t= he 3rd is banned. I kind of understand what the authors try to achieve, = but

a= dding local policies into RFCs does not make much sense (especially if = the

p= olicy is dubious as in this case; one option with this particular curve = is banned,

w= ith the other curves it is fine). The option (2) is apparently better = than 3, but I

d= o not see why the existence of better option should prevent a CA from = using

o= ption (3).

S= imilar argumentation could be made for banning Ed25519R1 since Ed441 = is

b= etter.

I= instead propose 2 alternatives, (a) remove the prehash option, or (b) = create an

R= FC mandating policies for CAs, which algorithms they MUST use and which = not.

A= CA can chose to follow = them.

<= o:p> 

I= think that option B would be more for the CA Consortium that for the = IETF to do.

<= o:p> 

J= im

<= o:p> 

r= egards,

N= ikos

_= ______________________________________________

C= urdle mailing list

<= a = href=3D"mailto:Curdle@ietf.org">Curdle@ietf.org

=

<= a = href=3D"https://www.ietf.org/mailman/listinfo/curdle">https://www.ietf.or= g/mailman/listinfo/curdle

<= o:p> 

<= o:p> 

------=_NextPart_000_00F1_01D2553C.B4774600-- From nobody Tue Dec 13 13:16:35 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992E51299C5 for ; Tue, 13 Dec 2016 13:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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 olfhQB5yrCOa for ; Tue, 13 Dec 2016 13:16:33 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612901299DF for ; Tue, 13 Dec 2016 13:15:19 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 285E880F9E for ; Tue, 13 Dec 2016 21:15:12 +0000 (UTC) Received: from ovpn-116-74.phx2.redhat.com (ovpn-116-74.phx2.redhat.com [10.3.116.74]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBDLF9e4025998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 13 Dec 2016 16:15:11 -0500 Message-ID: <1481663708.3127.63.camel@redhat.com> From: Simo Sorce To: curdle@ietf.org Date: Tue, 13 Dec 2016 16:15:08 -0500 Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 13 Dec 2016 21:15:12 +0000 (UTC) Archived-At: Subject: [Curdle] Introducing draft-ssorce-gss-keyex-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:16:34 -0000 Hello Curdle list, For quite a while I and Hubert (co-author) have been thinking of updating the GSSAPI Key Exchange algorithms for SSH which are still using SHA-1 Hashes, so I just uploaded a first revision here[1]. As it happens by the time we got to write a proposal and looked at the references section we found out that Mark Baushke had started expanding a related draft[2] to cover gss- methods. However Mark's draft just allocated new names to extend only the existing FFDH methods. Our intent was not only to allocate names, but to describe the new FFDH's according to previous drafts as well as introduce new ECDH based methods to keep this key exchange in line with the standard public key based key exchange. We discussed this with Mark and he proposed we go ahead and propose a separate draft, so with Chair's permission we'd like to ask for adoption of this draft to complement the work started by Mark in[2]. We already plan to add more text in some of the vague parts that reference ECDH keys verification, we would also like to discuss a possible additional extension to the GSS exchange method that would use Gss_Wrap()/Unwrap() instead of GSS_get/verify_mic(). Any comment and feedback is welcome. Simo. [1] https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt [2] https://www.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-05.txt -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Dec 14 03:17:24 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80390129D79 for ; Wed, 14 Dec 2016 03:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-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 3I91TURv3P0L for ; Wed, 14 Dec 2016 03:17:17 -0800 (PST) Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7A0129D8C for ; Wed, 14 Dec 2016 03:16:54 -0800 (PST) Received: from smtp.postman.i2p (unknown [193.150.121.26]) by postman.meeh.i2p (Postfix) with ESMTP id 52A932E50BB for ; Wed, 14 Dec 2016 12:16:50 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: curdle@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H6HckJJ2D0ENfFu3FmN14BpBtjHxWIpLR" Message-Id: <20161214105434.418FAADD1C@smtp.postman.i2p> Date: Wed, 14 Dec 2016 10:54:34 +0000 (UTC) Archived-At: Subject: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:17:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H6HckJJ2D0ENfFu3FmN14BpBtjHxWIpLR Content-Type: multipart/mixed; boundary="bwk6m3hJ1QVCKNFc8rCsHx5Tujl23L2to"; protected-headers="v1" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: curdle@ietf.org Subject: Key examples in draft-ietf-curdle-pkix-03 --bwk6m3hJ1QVCKNFc8rCsHx5Tujl23L2to Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I am currently updating my EdDSA Java library to implement the current spec for key encoding [0] (previously I used draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in PKCS#8 format for private keys). The example public key given in draft-ietf-curdle-pkix-03 [1] passes my tests, however the example private key [2] does not. It appears that the private key material within the example is 34 bytes, but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which AFAICT the present draft defers to for encoding), the private key is the b-bit seed k, which is 32 bytes. Am I missing something? If the example keys in the present draft are correct, it would be helpful to add a reference that clarifies their exact encoding. Thanks, Jack Grigg [0] https://github.com/str4d/ed25519-java/pull/22 [1] https://tools.ietf.org/html/draft-ietf-curdle-pkix-03#section-10.1 [2] https://tools.ietf.org/html/draft-ietf-curdle-pkix-03#section-10.3 [3] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08#section-3.2 --bwk6m3hJ1QVCKNFc8rCsHx5Tujl23L2to-- --H6HckJJ2D0ENfFu3FmN14BpBtjHxWIpLR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYUSTdAAoJEGppFNr76gDap/UQAIaB7gGI8fGPXS3N4bYeRgZ+ rJz7IZwxP+f+8n9oTDzszE0bIk3BJ1JgMBym4kd+JPb4kZ6nJ+bKCCx3rdbrpxF/ DLNzJvFrjJlhLU4BtBBUQL2BGqxJ7fBebIQE7fwImYGMGAursoQAy8v8BACkxhyq E1KTHf0QDirM1UFsIq/lwStJsvuRCRS7xGcJ55DVDcBd3KjOAGhxzOZ9pPpn/ro6 wWInFhBemOc2aeGuq4FsxeLTFOIHVjRSpFi/6BeivKXEVaxHUIse/tyDRXO4dXHt ZopkZgZZYPdnIOns2hPKnRPP8JuXr3WjmoBtZqxrXbCwSgP9zKUFlIEk19mWVGjR ApnSr2YBeyhVnVUKTPUqp+TkhYNohNF9mV+rZm9D7mg2av94FnPT4cWrg3s5nUfb Qt3SDImyvHRKZmiLshgLqWp/KLHcbFQ2AM2srowKTjiLWk0um1KbmOqyoQKQH8+G 709Nb8xePSenMphE9CC1IZ+hKIVCEsQ3Uq60QFsQiREkt1TyDFtLF9As+3OcxKp+ Z5+0sdaFD50Y4v1LnKQcyOaOzAXfsQ1awXz+s5dq55LFTnHE316+ukJGoOeyxJ51 cO7QengF8Euqo0pqDVGy9Nsk/zZ0vmcD3zwB4rLyUmYE0lzr/Qcd844f7LK9KfYo FJFWGDu2Lz6vWhtK+DTy =Wgmf -----END PGP SIGNATURE----- --H6HckJJ2D0ENfFu3FmN14BpBtjHxWIpLR-- From nobody Wed Dec 14 04:15:30 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA5129A5E for ; Wed, 14 Dec 2016 04:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896] 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 s3Nq0z424eVv for ; Wed, 14 Dec 2016 04:15:25 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4E1295FC for ; Wed, 14 Dec 2016 04:15:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id E2D0A16A9B; Wed, 14 Dec 2016 14:15:23 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id dn4blUfYA6Tp; Wed, 14 Dec 2016 14:15:23 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A408A21C; Wed, 14 Dec 2016 14:15:23 +0200 (EET) Date: Wed, 14 Dec 2016 14:15:15 +0200 From: Ilari Liusvaara To: str4d Message-ID: <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161214105434.418FAADD1C@smtp.postman.i2p> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161214105434.418FAADD1C@smtp.postman.i2p> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 12:15:28 -0000 On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > Hello, > > I am currently updating my EdDSA Java library to implement the current > spec for key encoding [0] (previously I used > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > private key [2] does not. > > It appears that the private key material within the example is 34 bytes, > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is the > b-bit seed k, which is 32 bytes. > > Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding. Apparently the key is wrapped in OCTET STRING twice for some reason, so the length is actually 32 bytes (the first 2 are second OCTET STRING header). -Ilari From nobody Wed Dec 14 05:23:20 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD3129658 for ; Wed, 14 Dec 2016 05:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVnq8d-danCj for ; Wed, 14 Dec 2016 05:23:17 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 50CD0129637 for ; Wed, 14 Dec 2016 05:23:17 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id p16so20930993qta.0 for ; Wed, 14 Dec 2016 05:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=he0JVCu5ecdXAsMOcuMlHnhiXJiXVx+ATEwm5n8SmVw=; b=PMjGVvrAhGlpdMOrf4X7S9oETV9CQz9+ujfjkH7VDQHBx/eDXG/VDplmpRRZlR+gIH zRY7+SqnvlAad9LgqNa4vahC4zogRC1EZlKEk424RqT5m3JOMvIbSo+Owgnj8DRKTIZQ DSDc4gtPfZTYheBYvG65A9mbCx/UCCOTxJ75s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=he0JVCu5ecdXAsMOcuMlHnhiXJiXVx+ATEwm5n8SmVw=; b=G88n7c+ugarJ5JnBhMYFlI4jtip/DHL7Kdn82QZ6rt4Sfp+ZqdnYIo+zE+gDYHmOrr ROBAqZpmTJecV4MNGzNBObG/4auCYAtGupAiAkxyrIbm9Ud6oOHTTgbiR2CpBbVoL3eN MlzRGdqi5pP6WFTd1d/nDFV1wQnLToIuQRoTujATiHJsCp0vZxrBQWSvCG2o8TH9Vc/j zqgWoIz7ZkaFgdtSarsw+wkGzy+uSz3U6fJnv1uqve0X2gWSJtWB88o5eAaphpJqRG3W Evlhcpli1hvjWTY/hJ72XsLFzGvJV2y9HFoHXSegdhvZtUJ31Ym/WTwkE8cMLJO8dkxZ qi2w== X-Gm-Message-State: AKaTC03Q4FeQyfrW0Jd3n3aRYmHitPb8dB4184avVdZBg+qmFx5Fi9fK8s1aa8665sGA65HQEfM5tlEPn5OEt0Ij X-Received: by 10.200.58.65 with SMTP id w59mr85058088qte.54.1481721795335; Wed, 14 Dec 2016 05:23:15 -0800 (PST) MIME-Version: 1.0 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Wed, 14 Dec 2016 13:23:05 +0000 Message-ID: To: Ilari Liusvaara , str4d Content-Type: multipart/alternative; boundary=001a114db99044d34905439e3d66 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 13:23:19 -0000 --001a114db99044d34905439e3d66 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara wrote: > On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > > Hello, > > > > I am currently updating my EdDSA Java library to implement the current > > spec for key encoding [0] (previously I used > > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > > PKCS#8 format for private keys). The example public key given in > > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > > private key [2] does not. > > > > It appears that the private key material within the example is 34 bytes, > > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > > AFAICT the present draft defers to for encoding), the private key is the > > b-bit seed k, which is 32 bytes. > > > > Am I missing something? If the example keys in the present draft are > > correct, it would be helpful to add a reference that clarifies their > > exact encoding. > > Apparently the key is wrapped in OCTET STRING twice for some reason, > so the length is actually 32 bytes (the first 2 are second OCTET STRING > header). > Is it too late to change that / was there any particular reason for this? Not that saving or using two bytes really matters, but it seems unnecessary when we already have an OCTET-STRING-shaped hole to put our octet string in. David --001a114db99044d34905439e3d66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 14= , 2016 at 7:15 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
> Hello,
>
> I am currently updating my EdDSA Java library to implement the current=
> spec for key encoding [0] (previously I used
> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example
> private key [2] does not.
>
> It appears that the private key material within the example is 34 byte= s,
> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is t= he
> b-bit seed k, which is 32 bytes.
>
> Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding.

Apparently the key is wrapped in OCTET STRING twice for some reason,
so the length is actually 32 bytes (the first 2 are second OCTET STRING
header).

Is it too = late to change that / was there any particular reason for this? Not that sa= ving or using two bytes really matters, but it seems unnecessary when we al= ready have an OCTET-STRING-shaped hole to put our octet string in.

David
--001a114db99044d34905439e3d66-- From nobody Wed Dec 14 07:02:30 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E31296CD for ; Wed, 14 Dec 2016 07:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 bUKnc0R1L9fd for ; Wed, 14 Dec 2016 07:02:25 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0099.outbound.protection.outlook.com [23.103.200.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F44E129532 for ; Wed, 14 Dec 2016 07:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=82dpiWFV25ndHDbVA3+O+YMgY/NQWeL8JK4Cqnawbt0=; b=difFpnChMFr5nwim3nnc+kELIwm0avYHQC1s4o5GOMImhv/FfVACDvIpyXUvFveOyKrUXqHQ9KSGNaIv4v/r1yBbUZpJMjyS1N7ihHwhd0qk1KqlwKwxmP2qJfElwvkF1uaZ120nE3Zh0r0K01YOz8ir+N0hreLj/p4qIyyjgxY= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 14 Dec 2016 15:02:23 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 15:02:22 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , "Dang, Quynh (Fed)" , "curdle@ietf.org" Thread-Topic: [Curdle] Some work for the group Thread-Index: AQHSUiKs3PWVL7wFScuPYdGzcgHHmKD/tuoAgAUxWICAAJMdgIAA392AgADiy4A= Date: Wed, 14 Dec 2016 15:02:22 +0000 Message-ID: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <00f001d2557f$c298b140$47ca13c0$@augustcellars.com> In-Reply-To: <00f001d2557f$c298b140$47ca13c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.223.235] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:KWIC4OeILt1iKqfQi5Ffk+JbaYCx+DqvjbZUbu4pLyShll6lz9yQkALohliXy7DpjyaftN8EzZe7K/OxQBFE39kSbEifGxMlOgawWuuo+M2CJ0puC7ct/vKObO/HZiR84iJZ30I4F3fEW76Qg7HYvuSoaIwdsfu3czTFaUgfZCyfvHmiapZQ1hOTlJ7cyU7JEjPqQQzAf4a+BDtFA8RWASEazi3GUxsXNsdOUyAQBK7Yw1UO4hbgJNTuXSEePQSYP71e8unlQsb5wb9J2fTbHjtJOS5jPEPFwBoFQ9ai0E3NcrjKmo8rKrEpH13fZyoMrtFJ4cF7M8rvMImLl/yl3+taMbcPp03QTNDgdehaNgcmB4lyIbI0d8QPlb3HJekDiTsBn2X3WhfphVXfyRuiWfIZeYKTKUfdohqt+RH0WvW1a90ZRPdGd/zm3Up2u7Fj5gXTl8IZC4tl4zkKvC0r1w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(377424004)(199003)(51444003)(76104003)(377454003)(24454002)(189002)(13464003)(81166006)(76176999)(38730400001)(50986999)(7906003)(5660300001)(99286002)(5001770100001)(2900100001)(4001350100001)(97736004)(36756003)(3846002)(7736002)(790700001)(102836003)(6116002)(105586002)(68736007)(106356001)(8676002)(106116001)(2950100002)(122556002)(2906002)(77096006)(606005)(3660700001)(3280700002)(93886004)(189998001)(83506001)(81156014)(6506006)(6512006)(2501003)(54356999)(229853002)(66066001)(6486002)(86362001)(101416001)(92566002)(6436002)(107886002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: f9e4524b-e825-4631-6cff-08d424323553 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 01565FED4C received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D476C8AE2D138qdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 15:02:22.6295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 15:02:28 -0000 --_000_D476C8AE2D138qdangnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Jim Schaad > Date: Tuesday, December 13, 2016 at 3:30 PM To: 'Quynh' >, "curdle@ietf= .org" > Subject: RE: [Curdle] Some work for the group From: Dang, Quynh (Fed) [mailto:quynh.dang@nist.gov] Sent: Tuesday, December 13, 2016 4:09 AM To: Jim Schaad >; 'Ni= kos Mavrogiannopoulos' >; Dang, Quy= nh (Fed) >; rsalz@akamai.co= m; curdle@ietf.org Subject: Re: [Curdle] Some work for the group From: Jim Schaad > Date: Monday, December 12, 2016 at 5:22 PM To: 'Nikos Mavrogiannopoulos' >, 'Q= uynh' >, "rsalz@akamai.com<= mailto:rsalz@akamai.com>" >, "cur= dle@ietf.org" > Subject: RE: [Curdle] Some work for the group -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, December 09, 2016 7:05 AM To: Dang, Quynh (Fed) >; rs= alz@akamai.com; curdle@ietf.org Subject: Re: [Curdle] Some work for the group On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote: > There are no security issues with the pre-hash option. One more hash > does not create any performance issues for the current protocols. In > addition, the pre-hash option provides the need for long messages as > we know: one example is the long CRLs on small devices as pointed out > on Jim's slides. > > If I had to choose one algorithm which works well for all situations, > I would choose the pre-hash option. I agree. Moreover, I don't quite follow the rationale for having it a must not on so= me scenarios. Of the options: 1. CA uses SECP256R1 (no prehash) 2. CA uses Ed25519R1 (prehash) 3. CA uses Ed25519R1 (no prehash) I am going to assume that this is just a typo as the prehash and no prehash= are reversed on the above list. There is one low level argument that I have found for forbidding the pre-ha= sh version for Ed25519. There is a possibility that if the pre-hash versi= on is allowed somebody is going to implement it incorrectly and do the pre-= hash as the item to be signed for pure mode as that is what is currently av= ailable. The current restrictions would avoid this possibility for certifi= cates but not for other uses. Hi Jim, Don't people check or test their implementations. It is hard for me to ima= gine why when someone does not want to use the pre-hash, decides to impleme= nt the non pre-hash version, but ended implementing the pre-hash version, t= hen don't check or test his or her implementation at all. Quynh, No, this is I implement the pure version and somebody else abuses it and us= es it as a pre-hash version. That is they do what comes naturally today. Hi Jim, I am not sure I understand what you think is a security issue here? Could y= ou please explain? Thank you, Quynh. Jim I appreciate your work and contributions! Quynh. the 3rd is banned. I kind of understand what the authors try to achieve, bu= t adding local policies into RFCs does not make much sense (especially if the policy is dubious as in this case; one option with this particular curve is= banned, with the other curves it is fine). The option (2) is apparently better than= 3, but I do not see why the existence of better option should prevent a CA from usin= g option (3). Similar argumentation could be made for banning Ed25519R1 since Ed441 is better. I instead propose 2 alternatives, (a) remove the prehash option, or (b) cre= ate an RFC mandating policies for CAs, which algorithms they MUST use and which no= t. A CA can chose to follow them. I think that option B would be more for the CA Consortium that for the IETF= to do. Jim regards, Nikos _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_D476C8AE2D138qdangnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Jim Schaad <ietf@augustcellars.com>
Date: Tuesday, December 13, 2016 at= 3:30 PM
To: 'Quynh' <Quynh.Dang@nist.gov>, "curdle@ietf.org" <curdle@ietf.org>
Subject: RE: [Curdle] Some work for= the group

 

 

From: Dang, Quynh (Fed) [mailto:quynh.dang@nist.gov]
Sent: Tuesday, December 13, 2016 4:09 AM
To: Jim Schaad <ietf@au= gustcellars.com>; 'Nikos Mavrogiannopoulos' <nmav@redhat.com>; Dang, Quynh (Fed) <quynh.dang@nist.gov>; rsalz@akamai.com; curdle@ietf.org
Subject: Re: [Curdle] Some work for the group

 

 

 

From: Jim Schaad <ietf@augustcellars.com>
Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos Mavrogiannopoulos' <nmav@redhat.com>, 'Quynh' <Quynh.Dang@nist.gov>, "rs= alz@akamai.com" <rsalz@akam= ai.com>, "curdle@ietf.org" <curdle@ietf.org>
Subject: RE: [Curdle] Some work for the group

 

 

 

-----Original Message-----

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos

Mavrogiannopoulos

Sent: Friday, December 09, 2016 7:05 AM=

To: Dang, Quynh (Fed) <quynh.dang@nist.gov>; rsalz@akamai.com;=

Subject: Re: [Curdle] Some work for the= group

On Fri, 2016-12-09 at 13:46 +0000, = Dang, Quynh (Fed) wrote:

> There are no security issues with = the pre-hash option. One more hash

> does not create any performance is= sues for the current protocols.  In

> addition, the pre-hash option prov= ides the need for long messages as

> we know: one example is the long C= RLs on small devices as pointed out

> on Jim’s slides.<= /span>

> 

> If I had to choose one algorithm w= hich works well for all situations,

> I would choose the pre-hash option= .

I agree.

Moreover, I don't quite follow the rati= onale for having it a must not on some

scenarios. Of the options:

1. CA uses SECP256R1 (no prehash)<= /o:p>

2. CA uses Ed25519R1 (prehash)

3. CA uses Ed25519R1 (no prehash)<= /o:p>

 

I am going to assume that this is just = a typo as the prehash and no prehash are reversed on the above list. &= nbsp;

 

There is one low level argument that I = have found for forbidding the pre-hash version for Ed25519.   The= re is a possibility that if the pre-hash version is allowed somebody is going to implement it incorrectly and do the pre-hash as the i= tem to be signed for pure mode as that is what is currently available. = ; The current restrictions would avoid this possibility for certificat= es but not for other uses.

 

Hi Jim, 

 

Don’t people check or test their implementati= ons.  It is hard for me to imagine why when someone does not want to u= se the pre-hash, decides to implement the non pre-hash version, but ended implementing the pre-hash version, then don’t check or tes= t his or her implementation at all. 

 

Quynh,

 

No, this is I implement the pure version and somebo= dy else abuses it and uses it as a pre-hash version.  That is they do = what comes naturally today.

Hi Jim,

I am not sure I understand what you think is a security issue here? Co= uld you please explain?

Thank you,
Quynh. 



 

Jim

 



I appreciate your work and c= ontributions!



Quynh. 

 

 

the 3rd is banned. I kind of understand= what the authors try to achieve, but

adding local policies into RFCs does no= t make much sense (especially if the

policy is dubious as in this case; one = option with this particular curve is banned,

with the other curves it is fine). The = option (2) is apparently better than 3, but I

do not see why the existence of better = option should prevent a CA from using

option (3).

Similar argumentation could be made for= banning Ed25519R1 since Ed441 is

better.

I instead propose 2 alternatives, (a) r= emove the prehash option, or (b) create an

RFC mandating policies for CAs, which a= lgorithms they MUST use and which not.

A CA can chose to follow them.

 

I think that option B would be more for= the CA Consortium that for the IETF to do.

 

Jim

 

regards,

Nikos

_______________________________________= ________

Curdle mailing list

 

 

 --_000_D476C8AE2D138qdangnistgov_-- From nobody Thu Dec 15 00:03:18 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCE2129979 for ; Thu, 15 Dec 2016 00:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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 iVFHyChrRAHy for ; Thu, 15 Dec 2016 00:03:16 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10885129712 for ; Thu, 15 Dec 2016 00:03:15 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5B0112F90EC; Thu, 15 Dec 2016 08:03:15 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.66]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBF83CkH001170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Dec 2016 03:03:14 -0500 Message-ID: <1481788992.2779.15.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Jim Schaad , "'Dang, Quynh (Fed)'" , rsalz@akamai.com, curdle@ietf.org Date: Thu, 15 Dec 2016 09:03:12 +0100 In-Reply-To: <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 15 Dec 2016 08:03:15 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 08:03:17 -0000 On Mon, 2016-12-12 at 14:22 -0800, Jim Schaad wrote: > > the 3rd is banned. I kind of understand what the authors try to > > achieve, but > > adding local policies into RFCs does not make much sense > > (especially if the > > policy is dubious as in this case; one option with this particular > > curve is banned, > > with the other curves it is fine). The option (2) is apparently > > better than 3, but I > > do not see why the existence of better option should prevent a CA > > from using > > option (3). > > > > Similar argumentation could be made for banning Ed25519R1 since > > Ed441 is > > better. > > > > I instead propose 2 alternatives, (a) remove the prehash option, or > > (b) create an > > RFC mandating policies for CAs, which algorithms they MUST use and > > which not. > > A CA can chose to follow them. > I think that option B would be more for the CA Consortium that for > the IETF to do.  That is exactly my point with the MUST NOT requirement. regards, Nikos From nobody Thu Dec 15 05:27:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D928A1293DA for ; Thu, 15 Dec 2016 05:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSQp17rdHRSS for ; Thu, 15 Dec 2016 05:26:59 -0800 (PST) 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 7BD6C1295BB for ; Thu, 15 Dec 2016 05:26:57 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n21so55877109qka.3 for ; Thu, 15 Dec 2016 05:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3GAyGZn00vCrLtuk1tOA8XC8VBp/nKWgiqivp8nwySE=; b=jluhLlrId3iaQznBfrLDZl835/TSlhrLq8GDHzmnX4OF9GiJobWWYPTVSWnNY4eero 34MFh8ZmbnIJVDaW9g8MO8QlmSxOSeh4T7wvwV6sueTRQGu8/tvS5GYh2rO089DuRhDr sYounR2VDktzTaRx/TXcgUmDsbcK7AqOErYXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3GAyGZn00vCrLtuk1tOA8XC8VBp/nKWgiqivp8nwySE=; b=qmFfw2RmUIyPbxqsxnOvpJpef3dtY5NnMI6Y49p90dC44v45TmhreH6D5w0tSstc8b EU64KTP1QdrtS68RnaNRAJnZDfCnHZzUaru5F+D2++oflHqBMbydiSFB/OQ3ZiuYkVLH Y1CVW4eidKgrg/TJOn9QZUeNoSy6WwmcydjwvauaagJofiRA80mIb7dH4DQSlffp+5TP NzcM/Fca38L1qDJpGhm01oOENLbQundYNAEqEbQN+7+jGTLeOJF8EbXXiL+ZG9wuBxLf PNzC0dw6BM2CMx51ueYQouagghCmJJecQU+QHnivIHJVuAWxmGlJQ82WjtQVlYG9vPlM hmqQ== X-Gm-Message-State: AIkVDXJ3T29W3B+4RTeCXxmJ+I7VZ5Xz4rN27AfUw22DRhWqPF+nIMbYjUF7ygrfeequrxstA8le/CfZFEIdvR8x X-Received: by 10.55.156.81 with SMTP id f78mr1345350qke.123.1481808416478; Thu, 15 Dec 2016 05:26:56 -0800 (PST) MIME-Version: 1.0 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <20161214132326.29D3BADD12@smtp.postman.i2p> <20161215043852.11033ADD1E@smtp.postman.i2p> In-Reply-To: <20161215043852.11033ADD1E@smtp.postman.i2p> From: David Benjamin Date: Thu, 15 Dec 2016 13:26:44 +0000 Message-ID: To: str4d , Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c075ab44a82d20543b2681d Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 13:27:02 -0000 --94eb2c075ab44a82d20543b2681d Content-Type: text/plain; charset=UTF-8 On Thu, Dec 15, 2016 at 1:42 AM str4d wrote: > On 12/15/2016 02:23 AM, David Benjamin wrote: > > On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > >> On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > >>> Hello, > >>> > >>> I am currently updating my EdDSA Java library to implement the current > >>> spec for key encoding [0] (previously I used > >>> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > >>> PKCS#8 format for private keys). The example public key given in > >>> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > >>> private key [2] does not. > >>> > >>> It appears that the private key material within the example is 34 > bytes, > >>> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > >>> AFAICT the present draft defers to for encoding), the private key is > the > >>> b-bit seed k, which is 32 bytes. > >>> > >>> Am I missing something? If the example keys in the present draft are > >>> correct, it would be helpful to add a reference that clarifies their > >>> exact encoding. > >> > >> Apparently the key is wrapped in OCTET STRING twice for some reason, > >> so the length is actually 32 bytes (the first 2 are second OCTET STRING > >> header). > >> > > > > Is it too late to change that / was there any particular reason for this? > > Not that saving or using two bytes really matters, but it seems > unnecessary > > when we already have an OCTET-STRING-shaped hole to put our octet string > in. > > > > Additionally, it is somewhat strange that the same document > (draft-irtf-cfrg-eddsa-08) would define that the public key requires no > additional OCTET STRING wrapping, while the private key does. I > personally don't have a problem implementing it this way if that is what > the WG decides, but one of the two documents needs to be updated > regardless of whether or not this is changed (either to change it or to > clarify the encoding). > Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should be changed to mention the OCTET STRING wrapping. EdDSA public and private keys are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just need to store one of those, you use it. Neither use ASN.1 at that layer since there's no need. Serialization asks for a byte string, and we already have a way to return a byte string. If you need to store them in an SPKI or PKCS#8 blob, you then follow draft-ietf-curdle-pkix which calls into that serialization and adds a bunch of ASN.1. The PKCS#8 wrapping, for some reason, prescribes two layers of OCTET STRING wrapping right now. This, though odd, is still self-consistent. David --94eb2c075ab44a82d20543b2681d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 15= , 2016 at 1:42 AM str4d <str4d@i2pm= ail.org> wrote:
On 12/15/201= 6 02:23 AM, David Benjamin wrote:
> On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <ilariliusva= ara@welho.com>
> wrote:
>
>> On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
>>> Hello,
>>>
>>> I am currently updating my EdDSA Java library to implement the= current
>>> spec for key encoding [0] (previously I used
>>> draft-josefsson-pkix-eddsa-04 for public keys, and the equival= ent in
>>> PKCS#8 format for private keys). The example public key given = in
>>> draft-ietf-curdle-pkix-03 [1] passes my tests, however the exa= mple
>>> private key [2] does not.
>>>
>>> It appears that the private key material within the example is= 34 bytes,
>>> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (= which
>>> AFAICT the present draft defers to for encoding), the private = key is the
>>> b-bit seed k, which is 32 bytes.
>>>
>>> Am I missing something? If the example keys in the present dra= ft are
>>> correct, it would be helpful to add a reference that clarifies= their
>>> exact encoding.
>>
>> Apparently the key is wrapped in OCTET STRING twice for some reaso= n,
>> so the length is actually 32 bytes (the first 2 are second OCTET S= TRING
>> header).
>>
>
> Is it too late to change that / was there any particular reason for th= is?
> Not that saving or using two bytes really matters, but it seems unnece= ssary
> when we already have an OCTET-STRING-shaped hole to put our octet stri= ng in.
>

Additionally, it is somewhat strange that the same document
(draft-irtf-cfrg-eddsa-08) would define that the public key requires no
additional OCTET STRING wrapping, while the private key does. I
personally don't have a problem implementing it this way if that is wha= t
the WG decides, but one of the two documents needs to be updated
regardless of whether or not this is changed (either to change it or to
clarify the encoding).
=C2=A0
Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should b= e changed to mention the OCTET STRING wrapping. EdDSA public and private ke= ys are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just need t= o store one of those, you use it. Neither use ASN.1 at that layer since the= re's no need. Serialization asks for a byte string, and we already have= a way to return a byte string.

If you need to sto= re them in an SPKI or PKCS#8 blob, you then follow draft-ietf-curdle-pkix w= hich calls into that serialization and adds a bunch of ASN.1. The PKCS#8 wr= apping, for some reason, prescribes two layers of OCTET STRING wrapping rig= ht now. This, though odd, is still self-consistent.

David
--94eb2c075ab44a82d20543b2681d-- From nobody Thu Dec 15 07:53:43 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D3B12986F for ; Thu, 15 Dec 2016 07:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 baHULo6LN4tW for ; Thu, 15 Dec 2016 07:53:41 -0800 (PST) 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 D45281296D5 for ; Thu, 15 Dec 2016 07:53:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9770F30029E for ; Thu, 15 Dec 2016 10:43:23 -0500 (EST) 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 19_nuswyGHPS for ; Thu, 15 Dec 2016 10:43:22 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7B40E300125 for ; Thu, 15 Dec 2016 10:43:22 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_B916D0D2-8635-42EB-A3B5-F3527E5D14C4" Message-Id: <620823B0-BC8E-4A27-B606-39D8939DCA1E@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 15 Dec 2016 10:53:42 -0500 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <20161214132326.29D3BADD12@smtp.postman.i2p> <20161215043852.11033ADD1E@smtp.postman.i2p> To: curdle@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:53:43 -0000 --Apple-Mail=_B916D0D2-8635-42EB-A3B5-F3527E5D14C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Additionally, it is somewhat strange that the same document > (draft-irtf-cfrg-eddsa-08) would define that the public key requires = no > additional OCTET STRING wrapping, while the private key does. I > personally don't have a problem implementing it this way if that is = what > the WG decides, but one of the two documents needs to be updated > regardless of whether or not this is changed (either to change it or = to > clarify the encoding). > =20 > Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should be = changed to mention the OCTET STRING wrapping. EdDSA public and private = keys are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just = need to store one of those, you use it. Neither use ASN.1 at that layer = since there's no need. Serialization asks for a byte string, and we = already have a way to return a byte string. I do not see any OCTET STRING wrapping in the test vectors in section 7 = of draft-irtf-cfrg-eddsa-08. Russ --Apple-Mail=_B916D0D2-8635-42EB-A3B5-F3527E5D14C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Additionally, it is somewhat strange that the same = document
(draft-irtf-cfrg-eddsa-08) would define that the public key = requires no
additional OCTET STRING wrapping, = while the private key does. I
personally don't = have a problem implementing it this way if that is what
the WG decides, but one of the two documents needs = to be updated
regardless of whether or not this = is changed (either to change it or to
clarify the = encoding).
 
Even if it stays as-is, I do not think = draft-irtf-cfrg-eddsa should be changed to mention the OCTET STRING = wrapping. EdDSA public and private keys are encoded as specified by = draft-irtf-cfrg-eddsa-08. If you just need to store one of those, you = use it. Neither use ASN.1 at that layer since there's no need. = Serialization asks for a byte string, and we already have a way to = return a byte string.

I do not see any = OCTET STRING wrapping in the test vectors in section 7 = of draft-irtf-cfrg-eddsa-08.

Russ

<= /body>= --Apple-Mail=_B916D0D2-8635-42EB-A3B5-F3527E5D14C4-- From nobody Thu Dec 15 07:53:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E6129981 for ; Thu, 15 Dec 2016 07:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 KEM7Vb5XJxao for ; Thu, 15 Dec 2016 07:53:41 -0800 (PST) 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 66B5A120727 for ; Thu, 15 Dec 2016 07:53:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3AFB9300288 for ; Thu, 15 Dec 2016 10:43:24 -0500 (EST) 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 ZF0qbD3aEqlY for ; Thu, 15 Dec 2016 10:43:23 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2F7A1300260 for ; Thu, 15 Dec 2016 10:43:23 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_F7293D66-163D-4C83-ACCE-4715455BD09D" Message-Id: <0357C7C6-8E15-4767-9C55-11F2318FB3E4@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 15 Dec 2016 10:53:42 -0500 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <20161214132326.29D3BADD12@smtp.postman.i2p> <20161215043852.11033ADD1E@smtp.postman.i2p> To: curdle@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:53:44 -0000 --Apple-Mail=_F7293D66-163D-4C83-ACCE-4715455BD09D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Additionally, it is somewhat strange that the same document > (draft-irtf-cfrg-eddsa-08) would define that the public key requires = no > additional OCTET STRING wrapping, while the private key does. I > personally don't have a problem implementing it this way if that is = what > the WG decides, but one of the two documents needs to be updated > regardless of whether or not this is changed (either to change it or = to > clarify the encoding). > =20 > Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should be = changed to mention the OCTET STRING wrapping. EdDSA public and private = keys are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just = need to store one of those, you use it. Neither use ASN.1 at that layer = since there's no need. Serialization asks for a byte string, and we = already have a way to return a byte string. I do not see any OCTET STRING wrapping in the test vectors in section 7 = of draft-irtf-cfrg-eddsa-08. Russ --Apple-Mail=_F7293D66-163D-4C83-ACCE-4715455BD09D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Additionally, it is somewhat strange that the same = document
(draft-irtf-cfrg-eddsa-08) would define that the public key = requires no
additional OCTET STRING wrapping, = while the private key does. I
personally don't = have a problem implementing it this way if that is what
the WG decides, but one of the two documents needs = to be updated
regardless of whether or not this = is changed (either to change it or to
clarify the = encoding).
 
Even if it stays as-is, I do not think = draft-irtf-cfrg-eddsa should be changed to mention the OCTET STRING = wrapping. EdDSA public and private keys are encoded as specified by = draft-irtf-cfrg-eddsa-08. If you just need to store one of those, you = use it. Neither use ASN.1 at that layer since there's no need. = Serialization asks for a byte string, and we already have a way to = return a byte string.

I do not see any = OCTET STRING wrapping in the test vectors in section 7 = of draft-irtf-cfrg-eddsa-08.

Russ

<= /body>= --Apple-Mail=_F7293D66-163D-4C83-ACCE-4715455BD09D-- From nobody Thu Dec 15 08:33:40 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7019D129A5D for ; Thu, 15 Dec 2016 08:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, 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 U4aFmZipXqvu for ; Thu, 15 Dec 2016 08:33:38 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 CBE81129A56 for ; Thu, 15 Dec 2016 08:33:37 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id g23so7563943wme.1 for ; Thu, 15 Dec 2016 08:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ORJx3kiRFn2iYadytnbHS9q12TJeMMvX5RIPGrIPJBo=; b=N4YzYsE20i6mdee4a2t602cx92lgcp3ngTk2wH044MC9XSS3xla2ZORW8S6BTsXV0k dXZOXo4bGt7SbMjF8YkwjmTyId9gX2jkh5iGcl7lfi7Jf3PuXkFNFFU9gUEoO9ROgmHp NQ3GBchPWZ7S7e+hZhErCJSL/5XPprYweuxkzGU4vyleqKI6OgOlZb0VbvBfY0JHAXWt BWp/FxmeG3fomHE+qfNtFaQNptIxtf3sBJlos33wmXyOfHKR34l++WR7WC8HwnNM/oOB boK2pbsK24WU0k5YiCBfV2OE18kmL0H7yp2Q+8ZEBtExCShfS3NvVVGlBQq/lFIfOzgK LpxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ORJx3kiRFn2iYadytnbHS9q12TJeMMvX5RIPGrIPJBo=; b=ke2uJH48bzE25CB1eXadVGxSE4JvIhRUK2kXWZyNMi0NERU8g9lV09rdC9rqqQpWOZ 61U0CPjP3NK9B1CONlr+u3UeYgB5PptQHm8zfGdM/f1vBmbXuViGkXBCls91RsBenY23 I1bMr8ieXb8yN3pEtmacOawbrNaLDrCU7dUz11P5SqFIet7psACkYk/ppnR1ruE3hpLF adRAA9pZZ59qneQRT34AqDmrcTjpIXNO3zBLoHtD4ErqpjoZUz4hfs3SbfOR1F/IYBmm CEfsort2B25VvJ4qeyTD5oHGDwYYVrJTBQ1iVKG38g4m+PqWPyH8jGlVxfzUSfKxRLmt aM7A== X-Gm-Message-State: AIkVDXInGRCSgUW3XyODpOimElgS5KrJXyWlHeKzZW8tH9bFQJiOBCGrOqZlFG31KNdpzqnUqxAebWj2diu26w== X-Received: by 10.28.211.72 with SMTP id k69mr2177773wmg.137.1481819616277; Thu, 15 Dec 2016 08:33:36 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Thu, 15 Dec 2016 08:33:35 -0800 (PST) In-Reply-To: <1481788992.2779.15.camel@redhat.com> References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> From: Phillip Hallam-Baker Date: Thu, 15 Dec 2016 11:33:35 -0500 X-Google-Sender-Auth: 3erEaZ2LS1gxWrERAlzM9GvHkb4 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a11470106d97cd80543b5032f Archived-At: Cc: "Dang, Quynh \(Fed\)" , "Salz, Rich" , Jim Schaad , Curdle Subject: Re: [Curdle] Some work for the group X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:33:39 -0000 --001a11470106d97cd80543b5032f Content-Type: text/plain; charset=UTF-8 It looks to me as if in effect the prehash vs pure issue is going to settle out into a situation where all signatures are pure signatures at the specification level with an additional hash being introduced in the packaging layer where bulk data is involved. I have implemented most of the popular packaging formats and most of my API calls internally turn out to be for a 'sign and digest' operation rather than Sign-this-digest. Most cases the bulk data is being put through a digest that is then put into some other structure for signature. There is almost always some sort of metadata you want in there in addition to the content. Another way to look at this is that Ed255x is a drop in replacement for RSA Signature that removes the restriction on the size of the input data to be signed but not the requirement for it to be buffered. Most packaging formats end up being a signature over a small chunk of static data which in the case of streamed content are virtually always reference to external data. --001a11470106d97cd80543b5032f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It = looks to me as if in effect the prehash vs pure issue is going to settle ou= t into a situation where all signatures are pure signatures at the specific= ation level with an additional hash being introduced in the packaging layer= where bulk data is involved.

I have implemented most of the popular packaging formats and most of m= y API calls internally turn out to be for a 'sign and digest' opera= tion rather than Sign-this-digest. Most cases the bulk data is being put th= rough a digest that is then put into some other structure for signature. Th= ere is almost always some sort of metadata you want in there in addition to= the content.
<= br>
Another way= to look at this is that Ed255x is a drop in replacement for RSA Signature = that removes the restriction on the size of the input data to be signed but= not the requirement for it to be buffered. Most packaging formats end up b= eing a signature over a small chunk of static data which in the case of str= eamed content are virtually always reference to external data.

--001a11470106d97cd80543b5032f-- From nobody Thu Dec 15 21:53:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFDE12948E for ; Thu, 15 Dec 2016 21:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 qt1k4YXkJ4XH for ; Thu, 15 Dec 2016 21:53:03 -0800 (PST) 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 30AA7129412 for ; Thu, 15 Dec 2016 21:53:03 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Dec 2016 22:12:38 -0800 From: Jim Schaad To: 'David Benjamin' References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Date: Thu, 15 Dec 2016 21:52:54 -0800 Message-ID: <002501d25760$a75c0bb0$f6142310$@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: AQGOM3TmntUFFR0Xvs/2NeMkxBysCwMWGXNJAq52cnChZDU1gA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 05:53:05 -0000 I believe that the OpenSSL people would be sad if we changed this at = this time. I did some interop testing with their developers before the = last version was released and the OCTET STRING wrapper on the private = key is what we were doing at the time. Jim From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin Sent: Wednesday, December 14, 2016 5:23 AM To: Ilari Liusvaara ; str4d = Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara = wrote: On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > Hello, > > I am currently updating my EdDSA Java library to implement the current > spec for key encoding [0] (previously I used > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > private key [2] does not. > > It appears that the private key material within the example is 34 = bytes, > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is = the > b-bit seed k, which is 32 bytes. > > Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding. Apparently the key is wrapped in OCTET STRING twice for some reason, so the length is actually 32 bytes (the first 2 are second OCTET STRING header). Is it too late to change that / was there any particular reason for = this? Not that saving or using two bytes really matters, but it seems = unnecessary when we already have an OCTET-STRING-shaped hole to put our = octet string in. David From nobody Thu Dec 15 22:56:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD63129434 for ; Thu, 15 Dec 2016 22:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04cI-GfGyJvf for ; Thu, 15 Dec 2016 22:56:39 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 CBBC51294ED for ; Thu, 15 Dec 2016 22:56:39 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id t184so28082455qkd.0 for ; Thu, 15 Dec 2016 22:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5xutFWgmVIJJjjSLuZUkDf9thYrBog1PsGYCv3hY+g=; b=XDAlOFePOk+d5k5E24zb52jcnKotMzxj6eWRsHEXuJ3T/KbP5ZE24r6XohsIq7uuCX riauDuHrkiCPZiDz1CvbrdBxgDBrAWQjbhcITFCxXwA9fQQMirHWHjonn7ZJBiV9E16P 69YxNTAhtzvBoTIKW10pZLrealmf3KPILI8HU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5xutFWgmVIJJjjSLuZUkDf9thYrBog1PsGYCv3hY+g=; b=X9LZDlkfZw4U3ohbC+XMxS6LiaQFRrxElDz/sJx4zCQAixCatcSOlTNglf5R2ecNM8 p7mGzbBSNGogKn6Dsdjc3PgcMZNjMNnpxUR+IRdAtFgodTwGReUSe7594DV4vSktWM5Z HLYSDG9EdQgb6GFZz5HMmxeHqtNostKJsydnnq6rKqWQwG2DEKT1RxT4yJKe/0wBBWnB DXQ0TFAhRYDWdlCP6uhO3hrZA90F7rGbaC+8NvSFukGtZnEzy1b5qQFbiZArrkfDgX4E 5aQq7wp9L3OKRyQpRXPHTKYOC/ACoWXA+J8AfeGeXXiSNzobJQ3G7656I8urhRpjLldK 8yJQ== X-Gm-Message-State: AIkVDXL+Qo3HcPpfZEochw0iQ8Af6YzTl0rKozr6HPfO8DjEs8Tq5GY/B9slELJdbKiLCq8THNNwNQehpRQ3Es/x X-Received: by 10.55.23.213 with SMTP id 82mr1280927qkx.40.1481871398728; Thu, 15 Dec 2016 22:56:38 -0800 (PST) MIME-Version: 1.0 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> In-Reply-To: <002501d25760$a75c0bb0$f6142310$@augustcellars.com> From: David Benjamin Date: Fri, 16 Dec 2016 06:56:27 +0000 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1147a2f05366db0543c11206 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 06:56:42 -0000 --001a1147a2f05366db0543c11206 Content-Type: text/plain; charset=UTF-8 Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It would have been preferable to avoid this confusing double wrapper, but so it goes I guess. David On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad wrote: > I believe that the OpenSSL people would be sad if we changed this at this > time. I did some interop testing with their developers before the last > version was released and the OCTET STRING wrapper on the private key is > what we were doing at the time. > > Jim > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin > Sent: Wednesday, December 14, 2016 5:23 AM > To: Ilari Liusvaara ; str4d > Cc: curdle@ietf.org > Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 > > On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara ilariliusvaara@welho.com> wrote: > On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > > Hello, > > > > I am currently updating my EdDSA Java library to implement the current > > spec for key encoding [0] (previously I used > > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > > PKCS#8 format for private keys). The example public key given in > > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > > private key [2] does not. > > > > It appears that the private key material within the example is 34 bytes, > > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > > AFAICT the present draft defers to for encoding), the private key is the > > b-bit seed k, which is 32 bytes. > > > > Am I missing something? If the example keys in the present draft are > > correct, it would be helpful to add a reference that clarifies their > > exact encoding. > > Apparently the key is wrapped in OCTET STRING twice for some reason, > so the length is actually 32 bytes (the first 2 are second OCTET STRING > header). > > Is it too late to change that / was there any particular reason for this? > Not that saving or using two bytes really matters, but it seems unnecessary > when we already have an OCTET-STRING-shaped hole to put our octet string in. > > > > David > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1147a2f05366db0543c11206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, yes, I see OpenSSL has already shipped code which= serializes X25519 in this way, as early as OpenSSL 1.1.0 in September. Tha= t's unfortunate. It would have been preferable to avoid this confusing = double wrapper, but so it goes I guess.

David

On Fri, Dec 16, 2016 = at 12:53 AM Jim Schaad <ietf@a= ugustcellars.com> wrote:
I b= elieve that the OpenSSL people would be sad if we changed this at this time= .=C2=A0 I did some interop testing with their developers before the last ve= rsion was released and the OCTET STRING wrapper on the private key is what = we were doing at the time.

Jim

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin
Sent: Wednesday, December 14, 2016 5:23 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; str4d &l= t;str4d@i2pmail.org>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <mailto:ilarilius= vaara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
> Hello,
>
> I am currently updating my EdDSA Java library to implement the current=
> spec for key encoding [0] (previously I used
> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example
> private key [2] does not.
>
> It appears that the private key material within the example is 34 byte= s,
> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is t= he
> b-bit seed k, which is 32 bytes.
>
> Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding.

Apparently the key is wrapped in OCTET STRING twice for some reason,
so the length is actually 32 bytes (the first 2 are second OCTET STRING
header).

Is it too late to change that / was there any particular reason for this? N= ot that saving or using two bytes really matters, but it seems unnecessary = when we already have an OCTET-STRING-shaped hole to put our octet string in= .



David

_______________________________________________
Curdle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinf= o/curdle
--001a1147a2f05366db0543c11206-- From nobody Thu Dec 15 23:18:49 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDA129849 for ; Thu, 15 Dec 2016 23:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrJ-y8xkRMTI for ; Thu, 15 Dec 2016 23:18:46 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 3133D12986C for ; Thu, 15 Dec 2016 23:18:23 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id p16so77566163qta.0 for ; Thu, 15 Dec 2016 23:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IImgLd0mWE20aW6s9kNy6daXi0WXK3Pmts6wu2tIM1w=; b=IDiyFKnFZInt8L4P3JKrUvLZmwcMSlHKND8ZPaUJwHZUeS5qk5fB+dfTSmpXek+0BR O9V0DYUNFcLxza43CRP9Pu4vZBDuj9bSkGxARVXzT9u1fw59NEpV5Og8b8Mo121egeJP 3K0VQrIi91/GIsbKZRQDDpeZGxCSupQx/EQh8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IImgLd0mWE20aW6s9kNy6daXi0WXK3Pmts6wu2tIM1w=; b=UBko+8qry4YdK7HJRbpGTuwNyTV8UyAR+6l/puwWeWE/y/mnUH3dK+PMwrMRvXkLe+ Cx1bVSZLGqKfmdZuguLWohTs6VSHWM16hbg+CkInwwod6xLaPqraGs/cVs39WvuIMxxx ef8S3+n4xfWYS3jvxojiw3aDveRXydfBjHTp+t86laaZIvxcYaLqW0wdTdZo4vj/2HIr l0tmrtJti3YRYub+l64pLhyVdHUltuztutmobY6l6bKnT7CdkWlf7kPIeeBpvsROlV7h dVMi7MFUBY0amKLRz0hgwBoN94AsixH0O8ZMe4F5eNRrriBYj/KoXlorljr0mxYuPXZs Pkpw== X-Gm-Message-State: AIkVDXKrP2tB+tc7WXjcz252T8mwvK8HjixH1tMH/wqfrDZQuK5uOzxDILoj5pzRiFUq2Wxvy+dOSo6W/sE5FhaR X-Received: by 10.237.62.38 with SMTP id l35mr1224414qtf.175.1481872702028; Thu, 15 Dec 2016 23:18:22 -0800 (PST) MIME-Version: 1.0 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> In-Reply-To: From: David Benjamin Date: Fri, 16 Dec 2016 07:18:11 +0000 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11408cb602119c0543c160b6 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 07:18:48 -0000 --001a11408cb602119c0543c160b6 Content-Type: text/plain; charset=UTF-8 So we don't end up with two variants of this floating around (this thread gives one data point of the current text being misinterpreted), What do you think about these editorial changes? 1. In the paragraph beginning "For the keys defined in this document [...]", add a sentence like "Note the opaque byte sequence is wrapped in OCTET STRINGs twice in total." 2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed* and X*. It should probably be renamed. But the best name I can come up with right now is PrivateKeyWrapper, which is terrible. Another option is to avoid defining a type and just say: For the keys defined in this document, the private key is always an opaque byte sequence. This is encoded in a OneAsymmetricKey object by wrapping the sequence in an ASN.1 OCTET STRING and placing its DER encoding in the 'privateKey' field. Note that 'privateKey' is itself an OCTET STRING, so the original byte sequence is wrapped in OCTET STRINGs twice in total. David On Fri, Dec 16, 2016 at 1:56 AM David Benjamin wrote: Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It would have been preferable to avoid this confusing double wrapper, but so it goes I guess. David On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad wrote: I believe that the OpenSSL people would be sad if we changed this at this time. I did some interop testing with their developers before the last version was released and the OCTET STRING wrapper on the private key is what we were doing at the time. Jim From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin Sent: Wednesday, December 14, 2016 5:23 AM To: Ilari Liusvaara ; str4d Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara wrote: On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > Hello, > > I am currently updating my EdDSA Java library to implement the current > spec for key encoding [0] (previously I used > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > private key [2] does not. > > It appears that the private key material within the example is 34 bytes, > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is the > b-bit seed k, which is 32 bytes. > > Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding. Apparently the key is wrapped in OCTET STRING twice for some reason, so the length is actually 32 bytes (the first 2 are second OCTET STRING header). Is it too late to change that / was there any particular reason for this? Not that saving or using two bytes really matters, but it seems unnecessary when we already have an OCTET-STRING-shaped hole to put our octet string in. David _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --001a11408cb602119c0543c160b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So we don't end u= p with two variants of this floating around (this thread gives one data poi= nt of the current text being misinterpreted), What do you think about these= editorial changes?

<= div class=3D"gmail_msg">1. In the paragraph beginning "For the keys de= fined in this document [...]", add a sentence like "Note the opaq= ue byte sequence is wrapped in OCTET STRINGs twice in total."

2. EdPrivateKey sounds like this only applies to = Ed* rather than both Ed* and X*. It should probably be renamed. But the bes= t name I can come up with right now is PrivateKeyWrapper, which is terrible= . Another option is to avoid defining a type and just say:

=C2=A0 =C2=A0For the keys defined in this document, the= private key is always an
=C2=A0 =C2=A0opaque= byte sequence.=C2=A0 This is encoded in a OneAsymmetricKey
=C2=A0 =C2=A0object by wrapping the sequence in an ASN.1 OCT= ET STRING
=C2=A0 =C2=A0and placing its DER en= coding in the 'privateKey' field. Note that
=C2=A0 =C2=A0'privateKey' is itself an OCTET STRING, so the = original byte
=C2=A0 =C2=A0sequence is wrappe= d in OCTET STRINGs twice in total.

David


On Fri, Dec 16, 2016 at 1:56 AM David Benjamin &l= t;davidben@chromium.org> wrote:
=
Ah, yes, I see OpenSSL has already shipped code wh= ich serializes X25519 in this way, as early as OpenSSL 1.1.0 in September. = That's unfortunate. It would have been preferable to avoid this confusi= ng double wrapper, but so it goes I guess.

David
=

On Fri, Dec 16, 2016 at 12:= 53 AM Jim Schaad <ietf@augustcellars.com> wrote:
I believe that t= he OpenSSL people would be sad if we changed this at this time.=C2=A0 I did= some interop testing with their developers before the last version was rel= eased and the OCTET STRING wrapper on the private key is what we were doing= at the time.

Jim

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin
Sent: Wednesday, December 14, 2016 5:23 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; str4d &l= t;str4d@i2pmail.org>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <mailto:ilarilius= vaara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
> Hello,
>
> I am currently updating my EdDSA Java library to implement the current=
> spec for key encoding [0] (previously I used
> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example
> private key [2] does not.
>
> It appears that the private key material within the example is 34 byte= s,
> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is t= he
> b-bit seed k, which is 32 bytes.
>
> Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding.

Apparently the key is wrapped in OCTET STRING twice for some reason,
so the length is actually 32 bytes (the first 2 are second OCTET STRING
header).

Is it too late to change that / was there any particular reason for this? N= ot that saving or using two bytes really matters, but it seems unnecessary = when we already have an OCTET-STRING-shaped hole to put our octet string in= .



David

_______________________________________________
Curdle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinf= o/curdle
--001a11408cb602119c0543c160b6-- From nobody Fri Dec 16 05:06:11 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9277E129C7A for ; Fri, 16 Dec 2016 05:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 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=-2.896, 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 n4sK-aXk1wre for ; Fri, 16 Dec 2016 05:06:09 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A0129A35 for ; Fri, 16 Dec 2016 05:06:04 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A041743345A; Fri, 16 Dec 2016 13:06:02 +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 8A249433409; Fri, 16 Dec 2016 13:06:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481893562; bh=IOuVlZItGiqlwivuqBU2k5uFyA6YmBTC8zesxQKA+3M=; l=327; h=From:To:CC:Date:References:In-Reply-To:From; b=v5xOkLchayeF6A2XSODJhvKopBJrxAc/2OalFlsJk5VXmQrH6MBGEb3q5iQjxaixs t6ZD+yL9w50twrUBLX8EKcmknv4B6Os9xe8j0h1+zwtjRZqdsXlIFV/PUmC2g2/+uG soysOXeI/gu0Nzw2ySeozfBnFY/iK+C+l1F77L4Q= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 83C311FCA1; Fri, 16 Dec 2016 13:06:02 +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; Fri, 16 Dec 2016 08:06:02 -0500 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; Fri, 16 Dec 2016 08:06:02 -0500 From: "Salz, Rich" To: Jim Schaad , 'David Benjamin' Thread-Topic: [Curdle] Key examples in draft-ietf-curdle-pkix-03 Thread-Index: AQHSVfumvLn0sQswokSnJ1mTlGDo0aEHr06AgAAS84CAAqbiAIAAJRjw Date: Fri, 16 Dec 2016 13:06:01 +0000 Message-ID: <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> In-Reply-To: <002501d25760$a75c0bb0$f6142310$@augustcellars.com> 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.32.62] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 13:06:10 -0000 > I believe that the OpenSSL people would be sad if we changed this at this > time. I did some interop testing with their developers before the last v= ersion > was released and the OCTET STRING wrapper on the private key is what we > were doing at the time. Speaking as an individual, yes. Please don=92t change this. From nobody Fri Dec 16 18:44:04 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE511294DB for ; Fri, 16 Dec 2016 18:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, 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 AiUapAe-tE0n for ; Fri, 16 Dec 2016 18:44:02 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 E580F127058 for ; Fri, 16 Dec 2016 18:44:01 -0800 (PST) X-AuditID: 1209190c-b5fff700000004b7-b1-5854a66fc3fb Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 05.46.01207.F66A4585; Fri, 16 Dec 2016 21:44:00 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uBH2hx0U016942; Fri, 16 Dec 2016 21:43:59 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uBH2htDW007816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Dec 2016 21:43:58 -0500 Date: Fri, 16 Dec 2016 20:43:55 -0600 From: Benjamin Kaduk To: David Benjamin Message-ID: <20161217024355.GT8460@kduck.kaduk.org> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixG6nrluwLCTCoOe6msXWhbOYLXZ/NbVY Pf07mwOzx8Y509k8ZjdcZPFYsuQnUwBzFJdNSmpOZllqkb5dAlfG1iXTWAqOc1asXjGbvYFx D3sXIyeHhICJxLeji9i6GLk4hATamCT2Helmh3A2MkocOnOJBcK5yiTxb98y1i5GDg4WAVWJ Pbf4QbrZBFQkGrovM4PYIgJaEg3fHrOB2MwCFhKn2m6BxYUF7CVe7zvGCGLzChhL3Gj/CrWt kVliR99ZFoiEoMTJmU9YIJq1JG78e8kEsotZQFpi+T8OkDCnQKDEun+zwOaICihLNMx4wDyB UWAWku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZopeaUrqJERS4nJI8 OxjPvPE6xCjAwajEw3vgT3CEEGtiWXFl7iFGSQ4mJVHeh64hEUJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeJctBMrxpiRWVqUW5cOkpDlYlMR5L2W6RwgJpCeWpGanphakFsFkZTg4lCR4C5cC NQoWpaanVqRl5pQgpJk4OEGG8wANdwep4S0uSMwtzkyHyJ9iVJQS501bApQQAElklObB9YIS i0T2/ppXjOJArwjz7gNp5wEmJbjuV0CDmYAGW8wLBhlckoiQkmpgZKnjCz+40uSU9uKCOyfV 3S117Bm0Jux4EGzjc64lInuRqgV34kW7l0e/fV7d0aB1aIPqCfVJm5/O2Zb94kbF15NGTYlT 02cs7F0ZyXRHOu2I0KuU6dJBLyo2SM5P3pHbd2jOBtNP+zS5Ii22P5FL4frJriIm7Vam3P3L 5VfoNxGvhGmL6k49UGIpzkg01GIuKk4EAOq50qIHAwAA Archived-At: Cc: Jim Schaad , curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 02:44:03 -0000 On Fri, Dec 16, 2016 at 07:18:11AM +0000, David Benjamin wrote: > So we don't end up with two variants of this floating around (this thread > gives one data point of the current text being misinterpreted), What do you > think about these editorial changes? > > 1. In the paragraph beginning "For the keys defined in this document > [...]", add a sentence like "Note the opaque byte sequence is wrapped in > OCTET STRINGs twice in total." > > 2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed* > and X*. It should probably be renamed. But the best name I can come up with > right now is PrivateKeyWrapper, which is terrible. Another option is to > avoid defining a type and just say: > > For the keys defined in this document, the private key is always an > opaque byte sequence. This is encoded in a OneAsymmetricKey > object by wrapping the sequence in an ASN.1 OCTET STRING > and placing its DER encoding in the 'privateKey' field. Note that > 'privateKey' is itself an OCTET STRING, so the original byte > sequence is wrapped in OCTET STRINGs twice in total. And/or have an appendix with an example of the full encoding for a given dummy key? -Ben From nobody Fri Dec 16 19:27:07 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953AF1294E8 for ; Fri, 16 Dec 2016 19:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, 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 82k8Uh3F7JnZ for ; Fri, 16 Dec 2016 19:27:04 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 1951E129489 for ; Fri, 16 Dec 2016 19:27:03 -0800 (PST) X-AuditID: 1209190c-b5fff700000004b7-8a-5854b0854781 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E2.87.01207.580B4585; Fri, 16 Dec 2016 22:27:02 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uBH3R15A021293; Fri, 16 Dec 2016 22:27:01 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uBH3QwIS017198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Dec 2016 22:27:00 -0500 Date: Fri, 16 Dec 2016 21:26:58 -0600 From: Benjamin Kaduk To: "curdle@ietf.org" Message-ID: <20161217032657.GU8460@kduck.kaduk.org> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT123bEBJhsHI3h8XWhbOYLXZ/NXVg 8pjdcJHFY8mSn0wBTFFcNimpOZllqUX6dglcGe9+vmYrWMVT8flbE0sD4wfOLkZODgkBE4lV D34wdTFycQgJtDFJLFp9hhUkISSwkVHiyMJ0iMRVJonve/vZQRIsAqoS965OYAOx2QRUJBq6 LzOD2CIC6hInDu0AaubgYBbQk3j1RRMkLCxgL/F63zFGEJtXwFii5VkXO8TMPUwS/6d8YYNI CEqcnPmEBcRmBprzZ94lZog50hLL/3FAhOUlmrfOBlvFKRAscf/EbyYQW1RAWaJhxgPmCYyC s5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjKKQ5 JXl2MJ5543WIUYCDUYmH98Cf4Agh1sSy4srcQ4ySHExKorxT1oZECPEl5adUZiQWZ8QXleak Fh9ilOBgVhLhDVwNlONNSaysSi3Kh0lJc7AoifNeynSPEBJITyxJzU5NLUgtgsnKcHAoSfC+ XgfUKFiUmp5akZaZU4KQZuLgBBnOAzS8DmQxb3FBYm5xZjpE/hSjopQ47x2QZgGQREZpHlwv KOVIZO+vecUoDvSKMO/u9UBVPMB0Bdf9CmgwE9Bgi3nBIINLEhFSUg2Mc+YL+5+6G/si4NiS ZVeP9u+UM6l6lcBwSENL6v3RS78blH/vd0nfn/8k+4aUxMy40Nr7rF5O2ldStuYFLo1OWy0y wVtwxz+l6+lbpF1+TNL7pLaHSeies97pOdIFD4O6767UXvvl6qSQWRfq+9MzFeTOGyhfO1Z/ sbbcN0Lxa7N0eN+t6iWCSizFGYmGWsxFxYkAqp5JTBQDAAA= Archived-At: Cc: 'David Benjamin' Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 03:27:05 -0000 On Fri, Dec 16, 2016 at 01:06:01PM +0000, Salz, Rich wrote: > > I believe that the OpenSSL people would be sad if we changed this at this > > time. I did some interop testing with their developers before the last version > > was released and the OCTET STRING wrapper on the private key is what we > > were doing at the time. > > Speaking as an individual, yes. Please don’t change this. It's a fairly frustrating feeling for a protocol designer to be hedged in to a particular behavior because an implementation of a draft version escaped into the wild and the change is not worth the pain of breaking interoperability. This happens all over the place, not just here, of course, which leads to the question of what can we do to avoid getting locked into the draft interfaces. It's easy to point fingers and say that the software authors should know to have a transition strategy if they ship a protocol that is explicitly a work in progress, but that doesn't really seem very productive. The TLS 1.3 story seems fairly reasonable, with a scheme to indicate support for a specific draft version as opposed to having to squat on the version number for the final protcol, but that seems to have evolved semi-organically as I understand it, with informal contact among the early implementors. Should all drafts burn a set of codepoints and map them to the given draft versions? Probably not. Should they think about it? Maybe. Are there other techniques that we can use to help software authors avoid shooting the ecosystem in the foot? -Ben From nobody Fri Dec 16 22:50:18 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF191295EF; Fri, 16 Dec 2016 22:50:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148195741605.14676.8505283972661893109.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2016 22:50:16 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 06:50:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : EdDSA for DNSSEC Authors : Ondrej Sury Robert Edmonds Filename : draft-ietf-curdle-dnskey-eddsa-03.txt Pages : 8 Date : 2016-12-16 Abstract: This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 16 23:02:00 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D562129452; Fri, 16 Dec 2016 23:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFSFsqNzrchj; Fri, 16 Dec 2016 23:01:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A885129555; Fri, 16 Dec 2016 23:01:49 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id A53886094A; Sat, 17 Dec 2016 08:01:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481958107; bh=UVGXi5RusZjFr3BlmDxFTN++IWScuuxHFt84KpFaLKg=; h=Date:From:To; b=QYntcLkvsEAfoqBxYpznLFZ8W3fHxk+VDLhCZR8GrGjSkefAjTX7cPA08EOZaSkm9 TLFNw0hHVZ95NOnQYSpfRAUoG3Kx8j0W05FRrUYXlpTFQknwimFVQ7DNWYEPwt2xdc 2dXuGl3y3gTQ5OQjz80YMFW63q1CWhlpYrcF8CxM= Date: Sat, 17 Dec 2016 08:01:47 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Magnus =?utf-8?Q?Nystr=C3=B6m?= , Dan Romascanu , Tim Chown Message-ID: <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - SAF10 (Linux)/8.7.0_GA_1659) Thread-Topic: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) Thread-Index: LzflipimV17IlkcBn4a2Ul/QhkSYmDP6HbRZ X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: curdle , ietf , secdir , gen-art , ops-dir@ietf.org, draft-ietf-curdle-dnskey-eddsa.all@ietf.org Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 07:01:51 -0000 Hi all, the IETF review has ended, so I have uploaded -03 version. Magnus, Dan, the -03 version addresses all your comments. Tim, I left the irtf documents in Normative as per Stephan's comments. I believe that Section 8 correctly references IANA registry: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xht= ml by its name. The paragraph with nit has been removed altogether per Magnus's request. Thank you all very much for the reviews. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Ond=C5=99ej Sur=C3=BD" > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" , "gen-art" > , "ietf" , "curdle-chairs" , "curdle" > Sent: Monday, 12 December, 2016 10:38:35 > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir= review of draft-ietf-curdle-dnskey-eddsa-02) > Magnus and Dan, >=20 > thanks for the review. >=20 > Magnus, you are right, I have removed the first full paragraph > about "security properties" from Security Considerations > from my git version as the security properties of EdDSA > are better described in Normative references anyway. >=20 > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96027= 0fdd103d9a2 >=20 > Dan, >=20 > good catches, I fixed the nits in the git: >=20 > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d= 907d035aadf >=20 > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. >=20 > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- >=20 > ----- Original Message ----- >> From: "Magnus Nystr=C3=B6m" >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" >> >> Sent: Monday, 12 December, 2016 02:44:18 >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> This document describes how to use two two specific Edwards Curves >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> ed448. >>=20 >> The only comment I have on this document is that the Security >> Considerations section plainly states, without any reference or proof: >>=20 >> "Ed25519 and Ed448 offers improved security properties and >> implementation characteristics compared to RSA and ECDSA algorithms" >>=20 >> I suggest either adding references to proofs of these statements or >> alternatively just remove the sentence (since it doesn't really add >> anything to the memo); the remaining paragraphs in the Security >> Considerations section is what really covers what someone implementing >> the memo should know or be aware of. >>=20 >> -- Magnus >=20 > ~~~~ >=20 > ----- Original Message ----- >> From: "Dan Romascanu" >> To: gen-art@ietf.org >> Cc: "draft-ietf-curdle-dnskey-eddsa all" >> , "curdle" , >> ietf@ietf.org >> Sent: Sunday, 11 December, 2016 12:21:25 >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 >=20 >> Reviewer: Dan Romascanu >> Review result: Ready with Nits >>=20 >> Summary: Ready, with nits >>=20 >> I am not an expert in this field, but the document seems to meet its >> goals, it's clear and precise >>=20 >> Major issues: >>=20 >> Minor issues: >>=20 >> Nits/editorial comments: >>=20 >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >>=20 >> 2. Section 8: 'The following entry has been added to >> the registry' - I may be wrong, but the section seems to define two > > new entries in the registry rather than one From nobody Fri Dec 16 23:11:13 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA95E1294E9; Fri, 16 Dec 2016 23:11:07 -0800 (PST) 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 joCzmFY3C1EL; Fri, 16 Dec 2016 23:11:05 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 56094129452; Fri, 16 Dec 2016 23:11:05 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w33so106326376qtc.3; Fri, 16 Dec 2016 23:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4oo0PYw5wXkM+at8CMads1k/KxW6cuUBrhaJI5/frrw=; b=YdjkC43E0ZyG8q334vTRMEe+egHHTqqUodT7AXKzJCGG3mGxqenzNFPE+aEM08zyo5 Hl+9ElUO2a+skC2zZCQS3063UlU286dsqlqy9EZ1mFuuYvlnevflHk3nfX2XfAoXsk0w noSoqWxiOd8il+MA5mhSqYao7fsaOKa0xk/aIRG1xlY7t3P+eyDt5wKG9pyjqZ5Vixn5 GvT4YZJoqagq9xaKDwirY4t5bW4qzSo3UotNrJAKUuznSpEUdyKVrEyH0iraoLpXuXI9 /igTu4sXFND4+swEnIYUJhH1KVI7X3uBGNdo7+ePt3tJ4VUaCku5UaCPtnbrkNz8ePz4 kAXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4oo0PYw5wXkM+at8CMads1k/KxW6cuUBrhaJI5/frrw=; b=rfi+tKN08Q7pUDC1Oh0+AxH+sS6uIm3EDaJJWMIpHUSme22wM6ryScfYJYPUEVZ7cT Ka94FoCxDLf/Zovsw1hsJt60+3S7ChoC1KiVAiCBuBa5hOGhZNBkQprM9LvkZMB6nCi1 4YIClOaV9p3T9TWx1/4MJj+4LP3VEiRy7hJ5X50X45n1kLhNSaFJ12+kgUuKQGRYvCYd 0Do6iGTZPtwdcmMi3dDm14Ojmsd+yCVo732juPSj5u24bsBksqud/vORf4hCosxWpCvP /t0P4dfYnF0e7yLJR6urfZC4gjTnloRXOro8zXDnh6z4p0iC5q6/2hzi8dHdT6LA1IXN PqNA== X-Gm-Message-State: AIkVDXIGouwLPbeCEZ9T78LjignZY/kDRK5JHvsdv3PuLHQ/b6Sd6DigfCSXb8Z+t/jgluuaYmN0yhCy5/WpdQ== X-Received: by 10.200.48.44 with SMTP id f41mr6234013qte.94.1481958664421; Fri, 16 Dec 2016 23:11:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.114 with HTTP; Fri, 16 Dec 2016 23:11:03 -0800 (PST) In-Reply-To: <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> From: Dan Romascanu Date: Sat, 17 Dec 2016 09:11:03 +0200 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a1137aa56c3c6d40543d563e3 Archived-At: Cc: ops-dir@ietf.org, ietf , secdir , gen-art , curdle , Tim Chown , draft-ietf-curdle-dnskey-eddsa.all@ietf.org, =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 07:11:08 -0000 --001a1137aa56c3c6d40543d563e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for addressing my comments. Regards, Dan On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Hi all, > > the IETF review has ended, so I have uploaded -03 version. > > Magnus, Dan, > > the -03 version addresses all your comments. > > Tim, > > I left the irtf documents in Normative as per Stephan's comments. > > I believe that Section 8 correctly references IANA registry: > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers. > xhtml > by its name. > > The paragraph with nit has been removed altogether per Magnus's request. > > Thank you all very much for the reviews. > > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Ond=C5=99ej Sur=C3=BD" > > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" < > dromasca@gmail.com> > > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" < > draft-ietf-curdle-dnskey-eddsa@ietf.org>, "gen-art" > > , "ietf" , "curdle-chairs" < > curdle-chairs@ietf.org>, "curdle" > > Sent: Monday, 12 December, 2016 10:38:35 > > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: > Secdir review of draft-ietf-curdle-dnskey-eddsa-02) > > > Magnus and Dan, > > > > thanks for the review. > > > > Magnus, you are right, I have removed the first full paragraph > > about "security properties" from Security Considerations > > from my git version as the security properties of EdDSA > > are better described in Normative references anyway. > > > > https://gitlab.labs.nic.cz/labs/ietf/commit/ > 7b52c8e2bbe44042a279a81b960270fdd103d9a2 > > > > Dan, > > > > good catches, I fixed the nits in the git: > > > > https://gitlab.labs.nic.cz/labs/ietf/commit/ > bbfc7ce43fb1f46c91fb7f5de564d907d035aadf > > > > I would be happy to upload next revision after Last Call > > is finished or just let the RFC editors to fix it. > > > > Cheers, > > -- > > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > > -------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > > Milesovska 5, 130 00 Praha 3, Czech Republic > > mailto:ondrej.sury@nic.cz https://nic.cz/ > > -------------------------------------------- > > > > ----- Original Message ----- > >> From: "Magnus Nystr=C3=B6m" > >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" > >> > >> Sent: Monday, 12 December, 2016 02:44:18 > >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > > > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments. > >> > >> This document describes how to use two two specific Edwards Curves > >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > >> ed448. > >> > >> The only comment I have on this document is that the Security > >> Considerations section plainly states, without any reference or proof: > >> > >> "Ed25519 and Ed448 offers improved security properties and > >> implementation characteristics compared to RSA and ECDSA algorithms" > >> > >> I suggest either adding references to proofs of these statements or > >> alternatively just remove the sentence (since it doesn't really add > >> anything to the memo); the remaining paragraphs in the Security > >> Considerations section is what really covers what someone implementing > >> the memo should know or be aware of. > >> > >> -- Magnus > > > > ~~~~ > > > > ----- Original Message ----- > >> From: "Dan Romascanu" > >> To: gen-art@ietf.org > >> Cc: "draft-ietf-curdle-dnskey-eddsa all" > >> , "curdle" < > curdle@ietf.org>, > >> ietf@ietf.org > >> Sent: Sunday, 11 December, 2016 12:21:25 > >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > > > >> Reviewer: Dan Romascanu > >> Review result: Ready with Nits > >> > >> Summary: Ready, with nits > >> > >> I am not an expert in this field, but the document seems to meet its > >> goals, it's clear and precise > >> > >> Major issues: > >> > >> Minor issues: > >> > >> Nits/editorial comments: > >> > >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ > >> > >> 2. Section 8: 'The following entry has been added to > >> the registry' - I may be wrong, but the section seems to define two > > > new entries in the registry rather than one > --001a1137aa56c3c6d40543d563e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for addressing my comments.

Regards,

Dan


<= div class=3D"gmail_quote">On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur= =C3=BD <ondrej.sury@nic.cz> wrote:
Hi all,

the IETF review has ended, so I have uploaded -03 version.

Magnus, Dan,

the -03 version addresses all your comments.

Tim,

I left the irtf documents in Normative as per Stephan's comments.

I believe that Section 8 correctly references IANA registry:
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml by its name.

The paragraph with nit has been removed altogether per Magnus's request= .

Thank you all very much for the reviews.

Cheers,
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Ond=C5=99ej= Sur=C3=BD" <ondrej.sury@nic.= cz>
> To: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>, "Dan Romascanu" <dromasca@gmail.com>
> Cc: "secdir" <secdir@i= etf.org>, "draft-ietf-curdle-dnskey-eddsa" <draft-ietf-curdle-dnsk= ey-eddsa@ietf.org>, "gen-art"
> <gen-art@ietf.org>, &quo= t;ietf" <ietf@ietf.org>, &q= uot;curdle-chairs" <curdl= e-chairs@ietf.org>, "curdle" <curdle@ietf.org>
> Sent: Monday, 12 December, 2016 10:38:35
> Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was= : Secdir review of draft-ietf-curdle-dnskey-eddsa-02)

> Magnus and Dan,
>
> thanks for the review.
>
> Magnus, you are right, I have removed the first full paragraph
> about "security properties" from Security Considerations
> from my git version as the security properties of EdDSA
> are better described in Normative references anyway.
>
> https://git= lab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270fdd103d9a2
>
> Dan,
>
> good catches, I fixed the nits in the git:
>
> https://git= lab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d907d035aadf
>
> I would be happy to upload next revision after Last Call
> is finished or just let the RFC editors to fix it.
>
> Cheers,
> --
> Ond=C5=99ej Sur=C3=BD -- Technical Fellow
> --------------------------------------------
> CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e CZ= .NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz=C2= =A0 =C2=A0 https://nic.cz/
> --------------------------------------------
>
> ----- Original Message -----
>> From: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>
>> To: secdir@ietf.org, "= draft-ietf-curdle-dnskey-eddsa"
>> <dra= ft-ietf-curdle-dnskey-eddsa@ietf.org>
>> Sent: Monday, 12 December, 2016 02:44:18
>> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG. These comments were written primarily for the benefit of the=
>> security area directors. Document editors and WG chairs should tre= at
>> these comments just like any other last call comments.
>>
>> This document describes how to use two two specific Edwards Curves=
>> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> ed448.
>>
>> The only comment I have on this document is that the Security
>> Considerations section plainly states, without any reference or pr= oof:
>>
>> "Ed25519 and Ed448 offers improved security properties and >> implementation characteristics compared to RSA and ECDSA algorithm= s"
>>
>> I suggest either adding references to proofs of these statements o= r
>> alternatively just remove the sentence (since it doesn't reall= y add
>> anything to the memo); the remaining paragraphs in the Security >> Considerations section is what really covers what someone implemen= ting
>> the memo should know or be aware of.
>>
>> -- Magnus
>
> ~~~~
>
> ----- Original Message -----
>> From: "Dan Romascanu" <dromasca@gmail.com>
>> To: gen-art@ietf.org
>> Cc: "draft-ietf-curdle-dnskey-eddsa all"
>> <draft-ietf-curdle-dnskey-eddsa.all@ietf.org>, "curdle&quo= t; <curdle@ietf.org>,
>> ietf@ietf.org
>> Sent: Sunday, 11 December, 2016 12:21:25
>> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02
>
>> Reviewer: Dan Romascanu
>> Review result: Ready with Nits
>>
>> Summary: Ready, with nits
>>
>> I am not an expert in this field, but the document seems to meet i= ts
>> goals, it's clear and precise
>>
>> Major issues:
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> 1. Section 4: s/Section5.1.7/Sections 5.1.7/
>>
>> 2. Section 8: 'The following entry has been added to
>>=C2=A0 =C2=A0the registry' - I may be wrong, but the section se= ems to define two
> > new entries in the registry rather than one

--001a1137aa56c3c6d40543d563e3-- From nobody Fri Dec 16 23:14:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBCF1294E9 for ; Fri, 16 Dec 2016 23:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-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 JqUSztwkHnLe for ; Fri, 16 Dec 2016 23:14:00 -0800 (PST) Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24AD129452 for ; Fri, 16 Dec 2016 23:13:59 -0800 (PST) Received: from smtp.postman.i2p (unknown [193.150.121.26]) by postman.meeh.i2p (Postfix) with ESMTP id CA0FF2E52A6 for ; Sat, 17 Dec 2016 08:13:49 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p To: David Benjamin , Ilari Liusvaara References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <20161214132326.29D3BADD12@smtp.postman.i2p> <20161215043852.11033ADD1E@smtp.postman.i2p> <20161215132709.4AB57ADD11@smtp.postman.i2p> X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d MIME-Version: 1.0 In-Reply-To: <20161215132709.4AB57ADD11@smtp.postman.i2p> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9xneOBRkcDIHw7G3noto2qVvh476G7R3c" Message-Id: <20161216212834.B138DADD20@smtp.postman.i2p> Date: Fri, 16 Dec 2016 21:28:34 +0000 (UTC) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 07:14:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9xneOBRkcDIHw7G3noto2qVvh476G7R3c Content-Type: multipart/mixed; boundary="9hjbgGqkIivHTE5PGKfi34DMNiHPwrML8"; protected-headers="v1" X-Mailer: smtp.postman.i2p - Official I2P Mailer From: str4d To: David Benjamin , Ilari Liusvaara Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <20161214132326.29D3BADD12@smtp.postman.i2p> <20161215043852.11033ADD1E@smtp.postman.i2p> <20161215132709.4AB57ADD11@smtp.postman.i2p> In-Reply-To: <20161215132709.4AB57ADD11@smtp.postman.i2p> --9hjbgGqkIivHTE5PGKfi34DMNiHPwrML8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/16/2016 02:27 AM, David Benjamin wrote: > On Thu, Dec 15, 2016 at 1:42 AM str4d wrote: >=20 >> On 12/15/2016 02:23 AM, David Benjamin wrote: >>> On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara < >> ilariliusvaara@welho.com> >>> wrote: >>> >>>> On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: >>>>> Hello, >>>>> >>>>> I am currently updating my EdDSA Java library to implement the curr= ent >>>>> spec for key encoding [0] (previously I used >>>>> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent i= n >>>>> PKCS#8 format for private keys). The example public key given in >>>>> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example >>>>> private key [2] does not. >>>>> >>>>> It appears that the private key material within the example is 34 >> bytes, >>>>> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which= >>>>> AFAICT the present draft defers to for encoding), the private key i= s >> the >>>>> b-bit seed k, which is 32 bytes. >>>>> >>>>> Am I missing something? If the example keys in the present draft ar= e >>>>> correct, it would be helpful to add a reference that clarifies thei= r >>>>> exact encoding. >>>> >>>> Apparently the key is wrapped in OCTET STRING twice for some reason,= >>>> so the length is actually 32 bytes (the first 2 are second OCTET STR= ING >>>> header). >>>> >>> >>> Is it too late to change that / was there any particular reason for t= his? >>> Not that saving or using two bytes really matters, but it seems >> unnecessary >>> when we already have an OCTET-STRING-shaped hole to put our octet str= ing >> in. >>> >> >> Additionally, it is somewhat strange that the same document >> (draft-irtf-cfrg-eddsa-08) would define that the public key requires n= o >> additional OCTET STRING wrapping, while the private key does. I >> personally don't have a problem implementing it this way if that is wh= at >> the WG decides, but one of the two documents needs to be updated >> regardless of whether or not this is changed (either to change it or t= o >> clarify the encoding). >> >=20 > Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should be > changed to mention the OCTET STRING wrapping. EdDSA public and private = keys > are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just need = to > store one of those, you use it. Neither use ASN.1 at that layer since > there's no need. Serialization asks for a byte string, and we already h= ave > a way to return a byte string. >=20 > If you need to store them in an SPKI or PKCS#8 blob, you then follow > draft-ietf-curdle-pkix which calls into that serialization and adds a b= unch > of ASN.1. The PKCS#8 wrapping, for some reason, prescribes two layers o= f > OCTET STRING wrapping right now. This, though odd, is still self-consis= tent. I've figured out the source of my confusion (and you're right, it wasn't related to draft-irtf-cfrg-eddsa, that was my mis-remembering): section 7 of draft-ietf-curdle-pkix is somewhat obtuse (to someone not well-versed in IETF lingo) as to how the various ASN.1 types are stacked. Specifically, on my first read of that section it seemed that the EdPrivateKey type took the place of the PrivateKey type in OneAsymmetricKey. But reading it again now, I can see that the intent of the section is: OneAsymmetricKey ::=3D SEQUENCE { ..., privateKey PrivateKey(EdPrivateKey(byte sequence)) ... } I think the confusing language is the use of "wrapped in" followed by "placed in", which implied to me that these were different actions, when in fact they both refer to the same action of wrapping in OCTET STRING (resulting in the aforementioned two layers). Perhaps a clarification in this section might be pertinent? Or maybe I'm an outlier, and everyone who normally reads these specs will be completely familiar with the intended usage constraints of ASN.1 types *shrug* In any case, thanks for clearing up my confusion! Should I wait around for consensus on whether the layering is likely to change, or go ahead with implementing as-is? I don't really want to implement a second backwards-compatibility handler later ^_^; Cheers, str4d --9hjbgGqkIivHTE5PGKfi34DMNiHPwrML8-- --9xneOBRkcDIHw7G3noto2qVvh476G7R3c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYVFxOAAoJEGppFNr76gDaOXYP/A12P3+BBD6pn9RTlIivRPEq VOYj665b90GqJiygUgjJvsBpFqNgrXp73KjWgT9FM8ikDeeNW6pIy2YaAXgKTIoT ItHozM8Gb/7QnjG/fwSC9O8FhXk8JclN33zM/BmZIHT4nywD6/a/75oBqvw93+u9 Bnn3rQNURjkW1x1+j9BubUQy+257kcSUEw3Xws9unP087iUBTzYs2rNNTGwB1zmp 7kInKjmRRJNkGDa39jNjz+ikax5J9L1yKhc1Fk5oBOaio+JOQId7NtvFmHEaNrW7 4n8mvOt84QOQPRXIujB6yld4eeo5d0d2pirXWejVo7LjnSFy2J9pzCLGonzm6TqF 2sVSkFf3TNOI0cg707JZnTf9jx80PGy+mZa54xgczz5uGOuCkdukhTxJLb2E9u1d X0jgFvcuRRpeUfb1uvyV0z8eT7yEV1Akv0X4Xz6+MqcjBbraOLHhlSvmArIi4GVO F71FJV1wfoM3UsIxnfh6wxp+Ua1Jnw+hBsp5yt4Eo0oyvOTNjstApdHG6ZQAzqlU WP7eGOdVJfampv+OqhBRqkJjlysYg8+j4op2Gh0yFX9mdYN+X4ImXp84F5UPTEnm J5vxWE3jZcZP+Xo7c8WXLPjgSXnOGA0JopC/Brlehi3mqYMJ7ZVvBYdKe+wy71NU VTkKUE+J7KcXLiEXlj9Q =+yOr -----END PGP SIGNATURE----- --9xneOBRkcDIHw7G3noto2qVvh476G7R3c-- From nobody Sat Dec 17 09:14:59 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2E129866; Sat, 17 Dec 2016 09:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 xHqSxy3qylc7; Sat, 17 Dec 2016 09:14:54 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.161.196]) (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 42A981296D6; Sat, 17 Dec 2016 09:14:54 -0800 (PST) Received: by mail-yw0-f196.google.com with SMTP id a10so6052839ywa.1; Sat, 17 Dec 2016 09:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LbAV1cxEwPPyTUwS9uuFVdb9XbKSn4yB9LbDqrvBaiM=; b=D5XZW4RCKNwNeQKomO0Fn3vq8B6ThYMPSaJqQDs0nZaRQMystwZfeOpDrwtm50tVry kaRxolf4FJvsOKz+qoj1l1EAYnAkIWjWliKUx5JkzQX8sh3YX1C9n0yyPDq0yMbVJKIw crCm4zUlzIgYtWrp++RfrTs+tXgw5qyCGjumUgz0WndCqQ6qGSOqv/ElQ1hY8zbEhBlH 5c0WZBopfZxc7lEMMjSnNs5L3jPKPFi/bHfyNuwnVOaCNzscmwZEykI1HGfBYS6f1M8N 6UalcB7qw9SPm+nOqZpvMC9u1IKjurvoOxgq7NcQzWFu0BvnMejBrDHN0uAt1hZARuvg SjrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LbAV1cxEwPPyTUwS9uuFVdb9XbKSn4yB9LbDqrvBaiM=; b=SEUM5IGQM02x4uFWWZn738es1epr6Zvupjkr5im4e4Z3vlApP585qplvKx2+QUN2Ya bmhs8fRMjv6HGzfYa2ivoZUjTYaonc1NNjHFg5+3Q6EY7ems5k1EtODYWL8ghWY16nqA YHtqkJhMjFWUchHJRAFdSFIZFDOXb9+9Q8eB2ZI8/JVDvQzux+q//kfoRtsvclsPxPPp Hu981HXPkDXG5ED7Bjc5497Iy2PtgPF2cx3SGxbp/866o1//6lbk8kMlVc9bqo7ZgHBp kD2IF4XCGp3/74QQsTpmcG5sUYslAv/SkuWb9PBByFWZAOTQqkdMZeIEwQgMTziYCCow F7Sg== X-Gm-Message-State: AKaTC030woaZfflgUF2m2K+w/Jn8w9kDH1sIEDSxTCwAhS+ChYmaaetGbnf6EY1aOYn25UQM6Oxp6Yra9PyO+w== X-Received: by 10.129.90.67 with SMTP id o64mr6518158ywb.188.1481994833385; Sat, 17 Dec 2016 09:13:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.195.195 with HTTP; Sat, 17 Dec 2016 09:13:52 -0800 (PST) In-Reply-To: References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sat, 17 Dec 2016 09:13:52 -0800 Message-ID: To: Dan Romascanu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ops-dir@ietf.org, ietf , secdir , gen-art , curdle , Tim Chown , draft-ietf-curdle-dnskey-eddsa.all@ietf.org, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 17:14:55 -0000 Same here. Thank you! /M On Fri, Dec 16, 2016 at 11:11 PM, Dan Romascanu wrote: > Thank you for addressing my comments. > > Regards, > > Dan > > > On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur=C3=BD wrote: >> >> Hi all, >> >> the IETF review has ended, so I have uploaded -03 version. >> >> Magnus, Dan, >> >> the -03 version addresses all your comments. >> >> Tim, >> >> I left the irtf documents in Normative as per Stephan's comments. >> >> I believe that Section 8 correctly references IANA registry: >> >> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.= xhtml >> by its name. >> >> The paragraph with nit has been removed altogether per Magnus's request. >> >> Thank you all very much for the reviews. >> >> Cheers, >> -- >> Ond=C5=99ej Sur=C3=BD -- Technical Fellow >> -------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> Milesovska 5, 130 00 Praha 3, Czech Republic >> mailto:ondrej.sury@nic.cz https://nic.cz/ >> -------------------------------------------- >> >> ----- Original Message ----- >> > From: "Ond=C5=99ej Sur=C3=BD" >> > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" >> > >> > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" >> > , "gen-art" >> > , "ietf" , "curdle-chairs" >> > , "curdle" >> > Sent: Monday, 12 December, 2016 10:38:35 >> > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: >> > Secdir review of draft-ietf-curdle-dnskey-eddsa-02) >> >> > Magnus and Dan, >> > >> > thanks for the review. >> > >> > Magnus, you are right, I have removed the first full paragraph >> > about "security properties" from Security Considerations >> > from my git version as the security properties of EdDSA >> > are better described in Normative references anyway. >> > >> > >> > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96= 0270fdd103d9a2 >> > >> > Dan, >> > >> > good catches, I fixed the nits in the git: >> > >> > >> > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de5= 64d907d035aadf >> > >> > I would be happy to upload next revision after Last Call >> > is finished or just let the RFC editors to fix it. >> > >> > Cheers, >> > -- >> > Ond=C5=99ej Sur=C3=BD -- Technical Fellow >> > -------------------------------------------- >> > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> > Milesovska 5, 130 00 Praha 3, Czech Republic >> > mailto:ondrej.sury@nic.cz https://nic.cz/ >> > -------------------------------------------- >> > >> > ----- Original Message ----- >> >> From: "Magnus Nystr=C3=B6m" >> >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" >> >> >> >> Sent: Monday, 12 December, 2016 02:44:18 >> >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >> > >> >> I have reviewed this document as part of the security directorate's >> >> ongoing effort to review all IETF documents being processed by the >> >> IESG. These comments were written primarily for the benefit of the >> >> security area directors. Document editors and WG chairs should treat >> >> these comments just like any other last call comments. >> >> >> >> This document describes how to use two two specific Edwards Curves >> >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> >> ed448. >> >> >> >> The only comment I have on this document is that the Security >> >> Considerations section plainly states, without any reference or proof= : >> >> >> >> "Ed25519 and Ed448 offers improved security properties and >> >> implementation characteristics compared to RSA and ECDSA algorithms" >> >> >> >> I suggest either adding references to proofs of these statements or >> >> alternatively just remove the sentence (since it doesn't really add >> >> anything to the memo); the remaining paragraphs in the Security >> >> Considerations section is what really covers what someone implementin= g >> >> the memo should know or be aware of. >> >> >> >> -- Magnus >> > >> > ~~~~ >> > >> > ----- Original Message ----- >> >> From: "Dan Romascanu" >> >> To: gen-art@ietf.org >> >> Cc: "draft-ietf-curdle-dnskey-eddsa all" >> >> , "curdle" >> >> , >> >> ietf@ietf.org >> >> Sent: Sunday, 11 December, 2016 12:21:25 >> >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 >> > >> >> Reviewer: Dan Romascanu >> >> Review result: Ready with Nits >> >> >> >> Summary: Ready, with nits >> >> >> >> I am not an expert in this field, but the document seems to meet its >> >> goals, it's clear and precise >> >> >> >> Major issues: >> >> >> >> Minor issues: >> >> >> >> Nits/editorial comments: >> >> >> >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >> >> >> >> 2. Section 8: 'The following entry has been added to >> >> the registry' - I may be wrong, but the section seems to define two >> > > new entries in the registry rather than one > > --=20 -- Magnus From nobody Mon Dec 19 03:37:23 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7C12940A for ; Mon, 19 Dec 2016 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 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=-3.1, SPF_HELO_PASS=-0.001, 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 axA1JzEhnpmR for ; Mon, 19 Dec 2016 03:37:18 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDE7129713 for ; Mon, 19 Dec 2016 03:37:18 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 36DE67F359 for ; Mon, 19 Dec 2016 11:37:18 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.66]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBJBbG2K022434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 19 Dec 2016 06:37:17 -0500 Message-ID: <1482147435.21135.14.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "curdle@ietf.org" Date: Mon, 19 Dec 2016 12:37:15 +0100 In-Reply-To: <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 19 Dec 2016 11:37:18 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:37:20 -0000 On Fri, 2016-12-16 at 13:06 +0000, Salz, Rich wrote: > > I believe that the OpenSSL people would be sad if we changed this > > at this > > time.  I did some interop testing with their developers before the > > last version > > was released and the OCTET STRING wrapper on the private key is > > what we > > were doing at the time. > > Speaking as an individual, yes.  Please don’t change this. While indeed openssl has quite some user base, version 1.1.0 is still not being integrated to major distributions to have significant impact. Do we really need to carry technical debt for that? Can't we change the OIDs on the final version to avoid confusion with released versions? regards, Nikos From nobody Mon Dec 19 03:39:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA68129713 for ; Mon, 19 Dec 2016 03:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 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=-3.1, SPF_HELO_PASS=-0.001, 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 iPDuCFSeBS4N for ; Mon, 19 Dec 2016 03:39:25 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A8812940A for ; Mon, 19 Dec 2016 03:39:25 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C52CD7F368; Mon, 19 Dec 2016 11:39:24 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.66]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBJBdM2m020533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Dec 2016 06:39:24 -0500 Message-ID: <1482147562.21135.16.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Benjamin Kaduk , "curdle@ietf.org" Date: Mon, 19 Dec 2016 12:39:22 +0100 In-Reply-To: <20161217032657.GU8460@kduck.kaduk.org> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> <20161217032657.GU8460@kduck.kaduk.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 19 Dec 2016 11:39:24 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:39:25 -0000 On Fri, 2016-12-16 at 21:26 -0600, Benjamin Kaduk wrote: > On Fri, Dec 16, 2016 at 01:06:01PM +0000, Salz, Rich wrote: > > > I believe that the OpenSSL people would be sad if we changed this > > > at this > > > time.  I did some interop testing with their developers before > > > the last version > > > was released and the OCTET STRING wrapper on the private key is > > > what we > > > were doing at the time. > > > > Speaking as an individual, yes.  Please don’t change this. > > It's a fairly frustrating feeling for a protocol designer to be > hedged in to a particular behavior because an implementation of a > draft version escaped into the wild and the change is not worth the > pain of breaking interoperability.  In this particular draft (the earlier versions which had been demo'ed -though not included- in gnutls), we were switching the OIDs once the definitions were modified in an incompatible way. regards, Nikos From nobody Mon Dec 19 08:42:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E036129BC7 for ; Mon, 19 Dec 2016 08:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 GZaMVHZ6Q2Dn for ; Mon, 19 Dec 2016 08:42:02 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 93312129BB8 for ; Mon, 19 Dec 2016 08:41:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 664521A688 for ; Mon, 19 Dec 2016 18:41:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id XF7pBkzMoFCE for ; Mon, 19 Dec 2016 18:41:54 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 0BD4927F for ; Mon, 19 Dec 2016 18:41:54 +0200 (EET) Date: Mon, 19 Dec 2016 18:41:45 +0200 From: Ilari Liusvaara To: "curdle@ietf.org" Message-ID: <20161219164145.GB4593@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> <1482147435.21135.14.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1482147435.21135.14.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 16:42:04 -0000 On Mon, Dec 19, 2016 at 12:37:15PM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-12-16 at 13:06 +0000, Salz, Rich wrote: > > > I believe that the OpenSSL people would be sad if we changed this > > > at this > > > time.  I did some interop testing with their developers before the > > > last version > > > was released and the OCTET STRING wrapper on the private key is > > > what we > > > were doing at the time. > > > > Speaking as an individual, yes.  Please don’t change this. > > While indeed openssl has quite some user base, version 1.1.0 is still > not being integrated to major distributions to have significant impact. > Do we really need to carry technical debt for that? Can't we change the > OIDs on the final version to avoid confusion with released versions? Actually, looking at the ECC keys out there, aren't most V2 keys, since those contain also the public key, as public key is not subset of private key for ECC (unlike RSA)? Looking at the private key example in document, those look like (at least the Ed25519 key does) v1 keys. And I am aware of at least one Ed25519 implementation (that I didn't write) that requires both private and public key to load a keypair. -Ilari From nobody Mon Dec 19 13:41:10 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39263129418 for ; Mon, 19 Dec 2016 13:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, 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 KFbBbSDs9b7f for ; Mon, 19 Dec 2016 13:41:08 -0800 (PST) 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 966D912943D for ; Mon, 19 Dec 2016 13:34:19 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 13:53:53 -0800 From: Jim Schaad To: 'David Benjamin' References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> In-Reply-To: Date: Mon, 19 Dec 2016 13:34:10 -0800 Message-ID: <035701d25a3f$a46ca9f0$ed45fdd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0358_01D259FC.964C5020" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGOM3TmntUFFR0Xvs/2NeMkxBysCwMWGXNJAq52cnABKGzVxgEXXxKfAYY6/V2hSOvWEA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 21:41:09 -0000 ------=_NextPart_000_0358_01D259FC.964C5020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In my local version, I have done the following: =20 1. Changed EdPrivateKey to CurvePrivateKey. I hope that this will = not cause any confusion with the ECPrivateKey type defined in RFC5915. 2. I have changed the last sentence in the paragraph mentioned = below to Thus when encoding a OneAsymmetricKey object, the private key is = wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of = the 'privateKey' field. 3. I have also expanded the appendix with the private key example = to have 1) the current PEM format, 2) an ASN.1 dump and 3) the value of = the private key.=20 =20 I debated using the OKP (Octet Key Pair) which was used in JOSE and COSE = but decided not to. =20 Jim =20 =20 From: David Benjamin [mailto:davidben@chromium.org]=20 Sent: Thursday, December 15, 2016 11:18 PM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 =20 So we don't end up with two variants of this floating around (this = thread gives one data point of the current text being misinterpreted), = What do you think about these editorial changes? =20 1. In the paragraph beginning "For the keys defined in this document = [...]", add a sentence like "Note the opaque byte sequence is wrapped in = OCTET STRINGs twice in total." =20 2. EdPrivateKey sounds like this only applies to Ed* rather than both = Ed* and X*. It should probably be renamed. But the best name I can come = up with right now is PrivateKeyWrapper, which is terrible. Another = option is to avoid defining a type and just say: =20 For the keys defined in this document, the private key is always an opaque byte sequence. This is encoded in a OneAsymmetricKey object by wrapping the sequence in an ASN.1 OCTET STRING and placing its DER encoding in the 'privateKey' field. Note that 'privateKey' is itself an OCTET STRING, so the original byte sequence is wrapped in OCTET STRINGs twice in total. =20 David =20 On Fri, Dec 16, 2016 at 1:56 AM David Benjamin > wrote: Ah, yes, I see OpenSSL has already shipped code which serializes X25519 = in this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. = It would have been preferable to avoid this confusing double wrapper, = but so it goes I guess. =20 David =20 On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad > wrote: I believe that the OpenSSL people would be sad if we changed this at = this time. I did some interop testing with their developers before the = last version was released and the OCTET STRING wrapper on the private = key is what we were doing at the time. Jim From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of David Benjamin Sent: Wednesday, December 14, 2016 5:23 AM To: Ilari Liusvaara >; str4d > Cc: curdle@ietf.org =20 Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara = > = wrote: On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > Hello, > > I am currently updating my EdDSA Java library to implement the current > spec for key encoding [0] (previously I used > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > PKCS#8 format for private keys). The example public key given in > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > private key [2] does not. > > It appears that the private key material within the example is 34 = bytes, > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > AFAICT the present draft defers to for encoding), the private key is = the > b-bit seed k, which is 32 bytes. > > Am I missing something? If the example keys in the present draft are > correct, it would be helpful to add a reference that clarifies their > exact encoding. Apparently the key is wrapped in OCTET STRING twice for some reason, so the length is actually 32 bytes (the first 2 are second OCTET STRING header). Is it too late to change that / was there any particular reason for = this? Not that saving or using two bytes really matters, but it seems = unnecessary when we already have an OCTET-STRING-shaped hole to put our = octet string in. David _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0358_01D259FC.964C5020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

In my local = version, I have done the following:

 

1.      = =C2=A0Changed= EdPrivateKey to CurvePrivateKey.=C2=A0 I hope that this will not cause = any confusion with the ECPrivateKey type defined in = RFC5915.

2.      = I have = changed the last sentence in the paragraph mentioned below = to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thus when encoding a = OneAsymmetricKey object, the private key is wrapped in an = CurvePrivateKey object and wrapped by the OCTET STRING of the = 'privateKey' field.

3.      = I have also = expanded the appendix with the private key example to have 1) the = current PEM format, 2) an ASN.1 dump and 3) the value of the private = key.

 

I debated = using the OKP (Octet Key Pair) which was used in JOSE and COSE but = decided not to.

 

Jim

 

 

From:<= /b> = David Benjamin [mailto:davidben@chromium.org]
Sent: Thursday, = December 15, 2016 11:18 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = curdle@ietf.org
Subject: Re: [Curdle] Key examples in = draft-ietf-curdle-pkix-03

 

So = we don't end up with two variants of this floating around (this thread = gives one data point of the current text being misinterpreted), What do = you think about these editorial changes?

 

1. In the paragraph beginning "For the keys = defined in this document [...]", add a sentence like "Note the = opaque byte sequence is wrapped in OCTET STRINGs twice in = total."

 

2. EdPrivateKey sounds like this only applies to Ed* = rather than both Ed* and X*. It should probably be renamed. But the best = name I can come up with right now is PrivateKeyWrapper, which is = terrible. Another option is to avoid defining a type and just = say:

 

   For the keys defined in this document, = the private key is always an

   opaque byte sequence.  This is = encoded in a OneAsymmetricKey

   object by wrapping the sequence in an = ASN.1 OCTET STRING

  =  and placing its DER encoding in the 'privateKey' field. Note = that

  =  'privateKey' is itself an OCTET STRING, so the original = byte

   sequence = is wrapped in OCTET STRINGs twice in = total.

 

David

 

On Fri, Dec 16, 2016 at 1:56 AM David Benjamin <davidben@chromium.org> = wrote:

Ah, yes, I see OpenSSL has already shipped code which = serializes X25519 in this way, as early as OpenSSL 1.1.0 in September. = That's unfortunate. It would have been preferable to avoid this = confusing double wrapper, but so it goes I = guess.

 

David

 

On = Fri, Dec 16, 2016 at 12:53 AM Jim Schaad <ietf@augustcellars.com> = wrote:

I believe = that the OpenSSL people would be sad if we changed this at this = time.  I did some interop testing with their developers before the = last version was released and the OCTET STRING wrapper on the private = key is what we were doing at the time.

Jim

From: Curdle = [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin
Sent: Wednesday, December 14, 2016 5:23 AM
To: Ilari = Liusvaara <ilariliusvaara@welho.com>; str4d <str4d@i2pmail.org>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Key = examples in draft-ietf-curdle-pkix-03

On Wed, Dec 14, 2016 at = 7:15 AM Ilari Liusvaara <mailto:ilariliusvaara@welho.com> wrote:
On Wed, Dec = 14, 2016 at 10:54:34AM +0000, str4d wrote:
> = Hello,
>
> I am currently updating my EdDSA Java library to = implement the current
> spec for key encoding [0] (previously I = used
> draft-josefsson-pkix-eddsa-04 for public keys, and the = equivalent in
> PKCS#8 format for private keys). The example = public key given in
> draft-ietf-curdle-pkix-03 [1] passes my = tests, however the example
> private key [2] does = not.
>
> It appears that the private key material within the = example is 34 bytes,
> but according to Section 3.2 of = draft-irtf-cfrg-eddsa-08 [3] (which
> AFAICT the present draft = defers to for encoding), the private key is the
> b-bit seed k, = which is 32 bytes.
>
> Am I missing something? If the = example keys in the present draft are
> correct, it would be = helpful to add a reference that clarifies their
> exact = encoding.

Apparently the key is wrapped in OCTET STRING twice for = some reason,
so the length is actually 32 bytes (the first 2 are = second OCTET STRING
header).

Is it too late to change that / = was there any particular reason for this? Not that saving or using two = bytes really matters, but it seems unnecessary when we already have an = OCTET-STRING-shaped hole to put our octet string = in.



David

_________________________________________= ______
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

------=_NextPart_000_0358_01D259FC.964C5020-- From nobody Mon Dec 19 23:10:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972531294F3 for ; Mon, 19 Dec 2016 23:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 L2cov-wbxOHP for ; Mon, 19 Dec 2016 23:10:22 -0800 (PST) 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 04DD1129CDE for ; Mon, 19 Dec 2016 23:09:58 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 23:29:32 -0800 From: Jim Schaad To: 'Ilari Liusvaara' , References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <808d6563f5f54acfb1a795769dc84402@usma1ex-dag1mb1.msg.corp.akamai.com> <1482147435.21135.14.camel@redhat.com> <20161219164145.GB4593@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161219164145.GB4593@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 19 Dec 2016 23:09:50 -0800 Message-ID: <03ed01d25a90$0faecc70$2f0c6550$@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: AQGOM3TmntUFFR0Xvs/2NeMkxBysCwMWGXNJAq52cnABKGzVxgJqfBZAAZzY6ecBtlwc3qEzYpGA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 07:10:23 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari = Liusvaara > Sent: Monday, December 19, 2016 8:42 AM > To: curdle@ietf.org > Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 >=20 > On Mon, Dec 19, 2016 at 12:37:15PM +0100, Nikos Mavrogiannopoulos = wrote: > > On Fri, 2016-12-16 at 13:06 +0000, Salz, Rich wrote: > > > > I believe that the OpenSSL people would be sad if we changed = this > > > > at this time. I did some interop testing with their developers > > > > before the last version was released and the OCTET STRING = wrapper > > > > on the private key is what we were doing at the time. > > > > > > Speaking as an individual, yes. Please don=E2=80=99t change this. > > > > While indeed openssl has quite some user base, version 1.1.0 is = still > > not being integrated to major distributions to have significant = impact. > > Do we really need to carry technical debt for that? Can't we change > > the OIDs on the final version to avoid confusion with released = versions? >=20 > Actually, looking at the ECC keys out there, aren't most V2 keys, = since those > contain also the public key, as public key is not subset of private = key for ECC > (unlike RSA)? Not sure if that is a true statement. There are two opportunities to = have the public key in for ECC. It can be as part of the PKCS#8 wrapper = (or OneAsymmetricKey if you talk RFC 5915) or in the ECPrivateKey = structure (RFC 5915). If part of the OneAsymmetricKey then the version = number for that is v2. If part of the ECPrivateKey then both are v1 = structures. I made the decision that having the public key in two places did not = make sense so it is only in the OneAsymmetricKey structure as outlined = in this document. Thus, if the public key is present, yes it would be a = v2. >=20 > Looking at the private key example in document, those look like (at = least the > Ed25519 key does) v1 keys. And I am aware of at least one Ed25519 > implementation (that I didn't write) that requires both private and = public key to > load a keypair. I hope the code verifies that the public and private match. Jim >=20 >=20 > -Ilari >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Dec 25 09:23:50 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B012944F; Sun, 25 Dec 2016 09:23:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148268662863.28246.9120060465328322636.idtracker@ietfa.amsl.com> Date: Sun, 25 Dec 2016 09:23:48 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa.all@ietf.org, curdle@ietf.org, ietf@ietf.org Subject: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2016 17:23:48 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-curdle-dnskey-eddsa-?? Reviewer: Dan Romascanu Review Date: 2016-12-25 IETF LC End Date: 2016-12-16 IESG Telechat date: 2017-01-05 Summary: Ready. The minor issues noticed in the LC review were addressed and the appropriate edits incorporated. Major issues: Minor issues: Nits/editorial comments: