From nobody Wed Feb 1 18:24:53 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5F1295C9 for ; Wed, 1 Feb 2017 18:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 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=-3.199, 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 InRJPAyXklVN for ; Wed, 1 Feb 2017 18:24:50 -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 C6B5D129613 for ; Wed, 1 Feb 2017 18:24:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3BF41BE58 for ; Thu, 2 Feb 2017 02:24:48 +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 drMb-rPXEAOd for ; Thu, 2 Feb 2017 02:24:45 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB39ABE3E for ; Thu, 2 Feb 2017 02:24:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486002285; bh=eD8Y9xjnbjUTstIvIsRlr9XWFH0KyE1TmgzXRM0WdfE=; h=To:From:Subject:Date:From; b=FIwkSHJJQkhBftQoqJP/J8OUhesk1CvUWIBrUkTBZJGZ2cYPZmrwjOOWUOOEZNbcL F+0oVSJqheFsrVPkQ9oXsayvHvlslBsb6tyxL1YxeKfeppQFo2z+1apeXsO5Tk90lX 0hVM9wCHTgfXeS2daf36l8GVqyAOK/SdMvltu7S4= To: "cfrg@irtf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> Date: Thu, 2 Feb 2017 02:24:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060606010303070404050103" Archived-At: Subject: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:24:53 -0000 This is a cryptographically signed message in MIME format. --------------ms060606010303070404050103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, There's an erratum posted for hmac [1] where I'd be interested in what folks here think. I'm unsure if this is a real problem, esp given that there are I guess a lot of implementations. And even if it were a real problem, I'm not sure we'd want that fix. Opinions welcome... Thanks, S. [1] https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&rec_st= atus=3D15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=3D&= stream_name=3D&submit_date=3D&presentation=3Drecords --------------ms060606010303070404050103 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIw MjI0NDRaMC8GCSqGSIb3DQEJBDEiBCD5KNKH9dSzuiWxonfld4TiLsKW6Xy1RJw1A8grctSf zDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCcXZ9AJWHhy48FB3cKp+7vDfm7XNpTkqK5k/mZUiMclJ/mnfqhZs1+ XrYR5YjO//exEIu8wdoeZEtnC14JqbTdrdY7dZF4/ClWyHSrlbRuziivgAcVoqYbSgb+Yij4 ZyGR3snd7rUM2ilZ/jeiODLIVdA19BtAe1wnd807Gr7w4oMrk8/sYYZKocE2aMkZhaH4KydC Eljycui0gkGEPivyk1/+jZtTBqz21Y6XiAYC9OVgVSQZ0TMeK5r7LkAh5WFI4qpJWtwwCcOE HA237qfMJvMWGBMI7mg6sCiu813Yo41p6leDpmBnwQ++uX+CFxfk8SLSj6nTw0x1a3Q752E2 AAAAAAAA --------------ms060606010303070404050103-- From nobody Thu Feb 2 05:21:48 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF44129444 for ; Thu, 2 Feb 2017 05:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, 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 vwPLwGElg5Vj for ; Thu, 2 Feb 2017 05:21:45 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BD3129438 for ; Thu, 2 Feb 2017 05:21:45 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id z134so8368673lff.3 for ; Thu, 02 Feb 2017 05:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Iosnjglxd0xmwBzairWarnNY9u5MMWWWp3/7AKY7fwc=; b=bVyCW/pS8VgYu2dELcD+0xyYerQzoAiPxYPsSCeA3ZDHs3SUVMz3fvb7M44N5MADNI JQOkPqPBe4vGMyoaix1lfidkKyGCgZjlgCh9NehnG4AcsMQqxBKxaSjeccsFJtmdu1iQ 2Z7mYu5dteY8cx+3jtoVm1n1hCba9QyduufqV+qJfmtX2soKUJI1kyBCsdlfzBhM7goZ dVuOC/IKd/kG6jA1hqQHqtqsGtZQAv42bHvoYJRrIIFcJIF7FkSZsBRF1U9ekS9TFjSJ Y4aomMdMRgeajuyzcljuP7453RHZHliKmJO2GXwk7NErl9qeMb9WmI47GTNXti35vof8 Hjkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Iosnjglxd0xmwBzairWarnNY9u5MMWWWp3/7AKY7fwc=; b=KzTNt+5xDCFgDWcEHTHRofkjFP3dsErq90MgC4w/iMMwNqTmeFIANkeMMHSJD2lQyG Y8i+SqM2dCXuEzmqk5Yflo/i/Jxi5vt3yq6k9hVGWee5eTkt5jFQhTAc1UsERycQL8vh 4szK79s3hulUVHcRsAchLzttiUuul3P0zTG/jDh/CnnzOvQCDFunOYjU2o4ugKlgQfWT M67iNdkNVFGYxnSXB1XkiIUsR4hTsUnYlyLNlHe8xgyqV3OEfeBX7qJyodLPOVyvBOSW TT9roVL1YnQJzSTwZkzmNNS5dL/vlRrVdJTKQdaDo2CPes3u9hpU36NFel6MzhuJh4m/ 0uKQ== X-Gm-Message-State: AIkVDXIO9ABiid74tuIuqH0ABNtwbpd9EiYlqLpczK72jfVYOYGqx42QMidRNufxF5547Q== X-Received: by 10.25.208.20 with SMTP id h20mr3153721lfg.150.1486041703348; Thu, 02 Feb 2017 05:21:43 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s63sm6639965lja.49.2017.02.02.05.21.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 05:21:42 -0800 (PST) From: "Valery Smyslov" To: "'Stephen Farrell'" , "'cfrg@irtf.org'" References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> In-Reply-To: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> Date: Thu, 2 Feb 2017 16:21:43 +0300 Message-ID: <0f8701d27d57$4c802920$e5807b60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISJ/kYuhxy1GvJcY7laVpklrAigqDWS8TQ Content-Language: ru Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:21:47 -0000 Hi Stephen, I would let cryptographers decide whether it is a real problem (I'm not a cryptographer), but the proposed resolution will break existing standards and implementations. For example, in IKEv2 there is a requirement that PRFs MUST accept keys of any length and HMAC is widely used as PRF (e.g. PRF_HMAC_SHA1 is currently MTI). And since nonces are used as a PRF key for SKEYSEED computation in IKEv2, the key may be quite long. So, regardless whether this is a real problem, the proposed resolution looks bad. Regards, Valery Smyslov. > Hiya, > > There's an erratum posted for hmac [1] where I'd be > interested in what folks here think. > > I'm unsure if this is a real problem, esp given that > there are I guess a lot of implementations. > > And even if it were a real problem, I'm not sure we'd > want that fix. > > Opinions welcome... > > Thanks, > S. > > [1] > https://www.rfc- > editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_ac > ronym=&submitter_name=&stream_name=&submit_date=&presentation=records From nobody Thu Feb 2 06:07:56 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F0C129435 for ; Thu, 2 Feb 2017 06:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 GLDy_wUWZEgZ for ; Thu, 2 Feb 2017 06:07:53 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50048.outbound.protection.outlook.com [40.107.5.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EFA1293D9 for ; Thu, 2 Feb 2017 06:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gm3wbhXH9nwzDba/pIIUAh07S98e6UEqlJSu74350D8=; b=c76w3Dms+8tn3PV+n+4bMaXZpWUUMcInHeGBXykBfz4RbuboW2gq16FV7jIVIR6VU+bANGomunCzCNBqVksKaNfcdeyjDnWDFUrNVvD3209EDgCwgmw+coHlH10//bC97c5rfGjWUV1IDiyLxxHSuRuyrS930YYwwG0UM0rmGbo= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 14:07:50 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0860.027; Thu, 2 Feb 2017 14:07:50 +0000 From: "Paterson, Kenny" To: Stephen Farrell , "cfrg@irtf.org" Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfPuUfS5Ckg60qEyDX+TNu0OdxKFVwe6A Date: Thu, 2 Feb 2017 14:07:49 +0000 Message-ID: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> In-Reply-To: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.227.30] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:SfRy5I0YMMEe/N0rHFmmPive6UzTo75uZXFAueKzmpGqxQlRw1iJ0EbWcWC1V4byOedA+OdwtVA4eXJtmlxrJuJ8w5lUrCAVP/lQDZrAJlzAKLC3V47YnRXbz97ChP14sc9yf/Jc4KZL3aHhOUY6wQ1rEnBxddhW4x+7aA9tLVdXakSKfzAMBETcIU9TTMV7eajLcb/U92C8IBg2+bRpLx9IYU8raswvep0Wx2aKK5xjOtIpQrRzs+aYTj2wxWIXJzEYlL65BZfy7BhDJUMuWkSP1rQbd2LlhnYiriBnD+x3IyDPqfWgRQJW1qDCRv84jDsnynmgeTbk2iwpsjsTSSIBQpZ/P9VftaJt5Z9ltAM+ruigek2bmu8sF3YLOsyWYsZHuTfzFhxGuG97FY25MibC68wM64QxLVTEEqALEQDk94GmVt9xNuKy+nGVmE39gqBG1l1+6CGzFoNgBPcurApPbkRfpY12TqBpYuqbvKRx316tkdN6KPx2wsPo5hvwSlIAoNFRJi8Nb8gCznBZn2CAnmN/UDJ9PYfuPaCAoXSXZNcueD7zJ9YJgx70IMyj x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(38730400001)(77096006)(6486002)(36756003)(6436002)(5660300001)(6506006)(8936002)(81156014)(81166006)(16799955002)(8676002)(3660700001)(74482002)(99286003)(6116002)(3846002)(83506001)(2950100002)(3280700002)(25786008)(2906002)(42882006)(2501003)(6306002)(6512007)(102836003)(229853002)(4001350100001)(101416001)(305945005)(5001770100001)(97736004)(53936002)(189998001)(107886002)(122556002)(92566002)(86362001)(7736002)(2900100001)(50986999)(76176999)(68736007)(105586002)(106116001)(106356001)(66066001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: e5a9a6a4-22fb-4d94-fe28-08d44b74df41 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; x-forefront-prvs: 02065A9E77 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <746E5EC2B5C3A2428068C43B8E3CCFC7@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 14:07:49.7753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:07:55 -0000 RGVhciBDRlJHLA0KDQpJdCdkIGJlIGdyZWF0IGlmIHNvbWUgSE1BQyBleHBlcnRzIGNvdWxkIHRh a2UgYSBsb29rIGF0IHRoaXMgcHJvcG9zZWQNCmVycmF0dW0gYW5kIGdpdmUgYSB2aWV3IG9uIGl0 Lg0KDQpJIGxvb2tlZCBxdWlja2x5IG15c2VsZi4gSXQncyBhbiB1bmRlc2lyYWJsZSBwcm9wZXJ0 eSwgYnV0IEkgZG9uJ3QgdGhpbmsNCml0J3MgZGlzYXN0cm91cyAoeWVzLCBJIGNvdWxkIGludmVu dCBzY2VuYXJpb3Mgd2hlcmUgb25lIGNvdWxkIGNvbWUNCnVuc3R1Y2sgYmVjYXVzZSBvZiBpdCku IEl0IHJlbWluZHMgbWUgc29tZXdoYXQgb2YgdGhlIHdlbGwta25vd24sIGFuZA0KYWdhaW4gc29t ZXdoYXQgdW5mb3J0dW5hdGUsIGZhY3QgdGhhdCBITUFDIGtleXMgb2YgZGlmZmVyZW50IGxlbmd0 aHMgY2FuDQplbmQgdXAgYmVpbmcgcGFkZGVkIHRvIGZvcm0gY29sbGlkaW5nIGtleXMuDQoNCkNo ZWVycywNCg0KS2VubnkgDQoNCk9uIDAyLzAyLzIwMTcgMDI6MjQsICJDZnJnIG9uIGJlaGFsZiBv ZiBTdGVwaGVuIEZhcnJlbGwiDQo8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBz dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCg0KPg0KPkhpeWEsDQo+DQo+VGhlcmUn cyBhbiBlcnJhdHVtIHBvc3RlZCBmb3IgaG1hYyBbMV0gd2hlcmUgSSdkIGJlDQo+aW50ZXJlc3Rl ZCBpbiB3aGF0IGZvbGtzIGhlcmUgdGhpbmsuDQo+DQo+SSdtIHVuc3VyZSBpZiB0aGlzIGlzIGEg cmVhbCBwcm9ibGVtLCBlc3AgZ2l2ZW4gdGhhdA0KPnRoZXJlIGFyZSBJIGd1ZXNzIGEgbG90IG9m IGltcGxlbWVudGF0aW9ucy4NCj4NCj5BbmQgZXZlbiBpZiBpdCB3ZXJlIGEgcmVhbCBwcm9ibGVt LCBJJ20gbm90IHN1cmUgd2UnZA0KPndhbnQgdGhhdCBmaXguDQo+DQo+T3BpbmlvbnMgd2VsY29t ZS4uLg0KPg0KPlRoYW5rcywNCj5TLg0KPg0KPlsxXQ0KPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz0yMTA0JmVpZD00ODA5JnJlY19zdGF0dXM9DQo+MTUm YXJlYV9hY3JvbnltPSZlcnJhdGFfdHlwZT0md2dfYWNyb255bT0mc3VibWl0dGVyX25hbWU9JnN0 cmVhbV9uYW1lPSZzdWINCj5taXRfZGF0ZT0mcHJlc2VudGF0aW9uPXJlY29yZHMNCj4NCg0K From nobody Thu Feb 2 06:20:10 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443E7129648 for ; Thu, 2 Feb 2017 06:20:08 -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 fyOjo9aJGoIg for ; Thu, 2 Feb 2017 06:20:05 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0100.outbound.protection.outlook.com [23.103.200.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6C01293E9 for ; Thu, 2 Feb 2017 06:20: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=FxRrp+JX8YqpX/42+KVFBNfAXWN7B3deEQFp3dLS8zw=; b=kfy4YIAK1JLbPJTO2fHYy3h+jQM16DdAAUPaguvwK7NwwsLvWKKXlfwV4zudrUhXavSVx1wAGg0noYVlWxTsxdmDsAfEmCfgEqwvbYICLK/iv7oQpGGze/tdZqslg9Y3mi5k7z0YmGDzSRjUyhxrcRKMEg8usBE0jihod5EtcyM= 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.888.16; Thu, 2 Feb 2017 14:20:03 +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.0888.020; Thu, 2 Feb 2017 14:20:03 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , Stephen Farrell , "cfrg@irtf.org" Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfPuTQmuL3UqM9EiFUsuWG7TDaaFVwYGAgAACtTw= Date: Thu, 2 Feb 2017 14:20:03 +0000 Message-ID: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.218.222] x-ms-office365-filtering-correlation-id: 016cf595-9c65-416a-cbf0-08d44b769488 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:IhxBxh3rKldV8RXig4jPa1HGNgJSnPTDZ2k0DdT1oJRDvF1dW/KH6NDREiSK4JCB6mtUnBbl69ZRK5+VlNBHurmLCoiEQM6A2dAQuzOEJ9CNsv38/+ltwXaOtrDCBWzkXgyatO7dkItjIRnDErhqQXhrwU8YXpKXa73wErivUmqJjpuhGkTXb7jxA4PE1UKuV6+WA8Ntea5Ladn0eUfuU03Y1itOcVQXzu7YBxq4QyVvexMjr76JUo939Zpmi+HMFDJbaeEujjpoJTC0LocWjmCGEIBNjEvGRF6g7HT9JkKnmg1Et3zBrhlBPmtraJ2C6nh0Xp7s6FiB00YFcOtUCNIObvSDlrky6hzVtVqZcL0NfDnfUlN9hpuUkOdgYBjVBoKT8PsxPNk47+Z8YH6ZwrhOHP0o69RNJwBOJEr8FrUt/Ym2Nr0rxy075j64uLSW8Fb4YZAdYJJqlQPN2JdmspPHyrHQgnIw6tGOeOBL97yqPgpMl8x7WDHFYRRBCxWRimXjdCMyUkzQSiN6qwOTqA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(24454002)(199003)(377454003)(189002)(33656002)(3280700002)(122556002)(101416001)(2950100002)(6606003)(7906003)(3660700001)(50986999)(3900700001)(7696004)(2906002)(53936002)(5660300001)(7736002)(74316002)(76176999)(54356999)(16799955002)(189998001)(81166006)(6306002)(54896002)(55016002)(81156014)(99286003)(2900100001)(8936002)(105586002)(102836003)(6116002)(3846002)(106356001)(9686003)(236005)(106116001)(92566002)(25786008)(19627405001)(6506006)(6436002)(107886002)(606005)(68736007)(2501003)(8676002)(8656002)(77096006)(66066001)(86362001)(38730400001)(229853002)(5001770100001)(97736004); 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_CY4PR09MB14645E105002D056B27D9DA4F34C0CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 14:20:03.4448 (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: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:20:08 -0000 --_000_CY4PR09MB14645E105002D056B27D9DA4F34C0CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kenny just made a great point that HMAC is not a PRF: it is trivial to find= 2 keys which produce the same HMAC output. Quynh. ________________________________ From: Cfrg on behalf of Paterson, Kenny Sent: Thursday, February 2, 2017 9:07 AM To: Stephen Farrell; cfrg@irtf.org Subject: Re: [Cfrg] erratum for hmac what do we think... Dear CFRG, It'd be great if some HMAC experts could take a look at this proposed erratum and give a view on it. I looked quickly myself. It's an undesirable property, but I don't think it's disastrous (yes, I could invent scenarios where one could come unstuck because of it). It reminds me somewhat of the well-known, and again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys. Cheers, Kenny On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell" wrote: > >Hiya, > >There's an erratum posted for hmac [1] where I'd be >interested in what folks here think. > >I'm unsure if this is a real problem, esp given that >there are I guess a lot of implementations. > >And even if it were a real problem, I'm not sure we'd >want that fix. > >Opinions welcome... > >Thanks, >S. > >[1] >https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&rec_sta= tus=3D >15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=3D&stream_n= ame=3D&sub >mit_date=3D&presentation=3Drecords > _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --_000_CY4PR09MB14645E105002D056B27D9DA4F34C0CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Kenny just made a great point that HMAC is not a PRF: it is trivial to f= ind 2 keys which produce the same HMAC output.


Quynh. 



From: Cfrg <cfrg-bounc= es@irtf.org> on behalf of Paterson, Kenny <Kenny.Paterson@rhul.ac.uk&= gt;
Sent: Thursday, February 2, 2017 9:07 AM
To: Stephen Farrell; cfrg@irtf.org
Subject: Re: [Cfrg] erratum for hmac what do we think...
 
Dear CFRG,

It'd be great if some HMAC experts could take a look at this proposed
erratum and give a view on it.

I looked quickly myself. It's an undesirable property, but I don't think it's disastrous (yes, I could invent scenarios where one could come
unstuck because of it). It reminds me somewhat of the well-known, and
again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys.

Cheers,

Kenny

On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell"
<cfrg-bounces@irtf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:=

>
>Hiya,
>
>There's an erratum posted for hmac [1] where I'd be
>interested in what folks here think.
>
>I'm unsure if this is a real problem, esp given that
>there are I guess a lot of implementations.
>
>And even if it were a real problem, I'm not sure we'd
>want that fix.
>
>Opinions welcome...
>
>Thanks,
>S.
>
>[1]
>ht= tps://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&re= c_status=3D
>15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitt= er_name=3D&stream_name=3D&sub
>mit_date=3D&presentation=3Drecords
>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--_000_CY4PR09MB14645E105002D056B27D9DA4F34C0CY4PR09MB1464namp_-- From nobody Thu Feb 2 06:22:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41D12940E for ; Thu, 2 Feb 2017 06:22:36 -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 gegjD7uHTFG5 for ; Thu, 2 Feb 2017 06:22:34 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0135.outbound.protection.outlook.com [23.103.200.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAD1129408 for ; Thu, 2 Feb 2017 06:22:34 -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=pSnCRIHprVsMljU7YTwYI5+V4rvODUWgdLIqeoIwRHU=; b=D0z3vmC0CL/e9qnBZjL/pewDW9xV6oDzW3DZ9YAfWSvFPDBes4F5gGrEt5el73dCE5naKlRfx0aX4/P4l2Z+SN0X9hRfdj2VPsY560PHp7ckd02qJi7C0XpxoCcyUEWx69uuz1TD6AGjUEKR0Vg7wJJ5TwT7S6m5MNGAXM+s0es= 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.888.16; Thu, 2 Feb 2017 14:22:32 +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.0888.020; Thu, 2 Feb 2017 14:22:32 +0000 From: "Dang, Quynh (Fed)" To: "Paterson, Kenny" , Stephen Farrell , "cfrg@irtf.org" Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfPuTQmuL3UqM9EiFUsuWG7TDaaFVwYGAgAACtTyAAAEWOg== Date: Thu, 2 Feb 2017 14:22:32 +0000 Message-ID: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.218.222] x-ms-office365-filtering-correlation-id: e145b334-1b4d-44da-ae01-08d44b76ed76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:ZrlYxSEbMCqEbg99u56Wtc54F/VX4UL+7JIkMmBBsacQji+pDQk37X7HatI+9qNjtkVVdwSG7ITzoy+FVljdemj/WLseTX4uyO5xEcWikCets8A0/K8tqgqSca7jYunsepOn/VaQnR+qCThuPTryFhhVRWbmKdUUO6dL9QdoIYxQUq+zJu/UCttfpNT9NCHj4+DN/qSF4n9MfFB1FOxnMTM5dl1EMRxKXc1RMyVAPJCa29Sy0zUyS2IHZBTOmXnDug/kS49kfKhdGnhiFfN7YBw2FOAi3kIpO5a5rWfDXkckidiZLYm812tByJunntDioo0QxLfrTVevVW+MLRIwuJYkgbYh951eEstthW2laonUYECeFbz6V9C/YcNjZe/i7XgRnCCzT5VDNETUrwccuGAQmhq46XM6jqmYYLZ9HE/7OkjJgF+MnItTb+yjuDoPNnyYQ6HyVwsgnROIQOflQ8/aoYOonOBsYNzzCSlHYmkOTPNvfmETn0wo9eceBukB7T86TiROSd27Z1QbY6CnnA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(377454003)(189002)(24454002)(199003)(606005)(6506006)(19627405001)(107886002)(6436002)(8676002)(8656002)(77096006)(2501003)(68736007)(6116002)(102836003)(105586002)(8936002)(81156014)(99286003)(2900100001)(106116001)(25786008)(92566002)(3846002)(236005)(106356001)(9686003)(5001770100001)(97736004)(86362001)(66066001)(229853002)(38730400001)(2950100002)(50986999)(3660700001)(7906003)(3280700002)(33656002)(122556002)(101416001)(54356999)(16799955002)(76176999)(74316002)(55016002)(6306002)(54896002)(81166006)(189998001)(2906002)(7696004)(53936002)(3900700001)(5660300001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.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_CY4PR09MB1464453C2AE6265E43011C6BF34C0CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 14:22:32.6523 (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: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:22:36 -0000 --_000_CY4PR09MB1464453C2AE6265E43011C6BF34C0CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One way to fix that is always hash the key. Quynh. ________________________________ From: Cfrg on behalf of Dang, Quynh (Fed) Sent: Thursday, February 2, 2017 9:20:03 AM To: Paterson, Kenny; Stephen Farrell; cfrg@irtf.org Subject: Re: [Cfrg] erratum for hmac what do we think... Kenny just made a great point that HMAC is not a PRF: it is trivial to find= 2 keys which produce the same HMAC output. Quynh. ________________________________ From: Cfrg on behalf of Paterson, Kenny Sent: Thursday, February 2, 2017 9:07 AM To: Stephen Farrell; cfrg@irtf.org Subject: Re: [Cfrg] erratum for hmac what do we think... Dear CFRG, It'd be great if some HMAC experts could take a look at this proposed erratum and give a view on it. I looked quickly myself. It's an undesirable property, but I don't think it's disastrous (yes, I could invent scenarios where one could come unstuck because of it). It reminds me somewhat of the well-known, and again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys. Cheers, Kenny On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell" wrote: > >Hiya, > >There's an erratum posted for hmac [1] where I'd be >interested in what folks here think. > >I'm unsure if this is a real problem, esp given that >there are I guess a lot of implementations. > >And even if it were a real problem, I'm not sure we'd >want that fix. > >Opinions welcome... > >Thanks, >S. > >[1] >https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&rec_sta= tus=3D >15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=3D&stream_n= ame=3D&sub >mit_date=3D&presentation=3Drecords > _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --_000_CY4PR09MB1464453C2AE6265E43011C6BF34C0CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

One way to fix that is always hash the key.


Quynh. 

From: Cfrg <cfrg-bounces= @irtf.org> on behalf of Dang, Quynh (Fed) <quynh.dang@nist.gov> Sent: Thursday, February 2, 2017 9:20:03 AM
To: Paterson, Kenny; Stephen Farrell; cfrg@irtf.org
Subject: Re: [Cfrg] erratum for hmac what do we think...
 

Kenny just made a great point that HMAC is not a PRF: it is trivial to f= ind 2 keys which produce the same HMAC output.


Quynh. 



From: Cfrg <cfrg-bounc= es@irtf.org> on behalf of Paterson, Kenny <Kenny.Paterson@rhul.ac.uk&= gt;
Sent: Thursday, February 2, 2017 9:07 AM
To: Stephen Farrell; cfrg@irtf.org
Subject: Re: [Cfrg] erratum for hmac what do we think...
 
Dear CFRG,

It'd be great if some HMAC experts could take a look at this proposed
erratum and give a view on it.

I looked quickly myself. It's an undesirable property, but I don't think it's disastrous (yes, I could invent scenarios where one could come
unstuck because of it). It reminds me somewhat of the well-known, and
again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys.

Cheers,

Kenny

On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell"
<cfrg-bounces@irtf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:=

>
>Hiya,
>
>There's an erratum posted for hmac [1] where I'd be
>interested in what folks here think.
>
>I'm unsure if this is a real problem, esp given that
>there are I guess a lot of implementations.
>
>And even if it were a real problem, I'm not sure we'd
>want that fix.
>
>Opinions welcome...
>
>Thanks,
>S.
>
>[1]
>ht= tps://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&re= c_status=3D
>15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitt= er_name=3D&stream_name=3D&sub
>mit_date=3D&presentation=3Drecords
>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--_000_CY4PR09MB1464453C2AE6265E43011C6BF34C0CY4PR09MB1464namp_-- From nobody Thu Feb 2 07:21:44 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF0129663 for ; Thu, 2 Feb 2017 07:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 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=-3.199, 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 iDiAljldIHPY for ; Thu, 2 Feb 2017 07:21:37 -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 A18AE129662 for ; Thu, 2 Feb 2017 07:21:37 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A74CF4334AC; Thu, 2 Feb 2017 15:21:36 +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 90E9B43341C; Thu, 2 Feb 2017 15:21:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486048896; bh=G+fRMHMA7umeYVS6NnuEB7nxDuZeHKoeVH4gxYlOgXk=; l=324; h=From:To:Date:References:In-Reply-To:From; b=wj8A0Wv8xrDLQcOlBHkZunUWnu169mgr+ZMgFyZO9zGs2DymrPCmVYD0OlR50fM7V 76JwLlYjsTxghgHc2bNcVvZpFWGOs2TLaZLYWQNPyMD7pVx3WuflaL2NEGRegsClY8 og+ZAi86eME0ik3+eDhdiiGoV4QaR/K4i1HDkvDs= 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 8D75D1FC88; Thu, 2 Feb 2017 15:21:36 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Feb 2017 10:21:36 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Thu, 2 Feb 2017 10:21:36 -0500 From: "Salz, Rich" To: "Paterson, Kenny" , Stephen Farrell , "cfrg@irtf.org" Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfQSjLR5A9wxQCUyU4vgAZUrraqFWFUCA///AcnA= Date: Thu, 2 Feb 2017 15:21:35 +0000 Message-ID: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.204] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:21:39 -0000 > I looked quickly myself. It's an undesirable property, but I don't think = it's > disastrous If this is accurate (paging Hugo... :) then I think the best reply to this = is a couple of sentences in the security considerations advising applicatio= ns that are concerned to limit keys to B bytes instead of hashing. From nobody Thu Feb 2 07:26:47 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1512965D for ; Thu, 2 Feb 2017 07:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 yV89BkPBHUis for ; Thu, 2 Feb 2017 07:26:43 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B8712946B for ; Thu, 2 Feb 2017 07:26:43 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 10:26:41 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 2 Feb 2017 10:26:40 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Thu, 2 Feb 2017 10:26:40 -0500 From: Dan Brown To: "Paterson, Kenny" , Stephen Farrell , "cfrg@irtf.org" Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfPuN6HvCHp+9s0S4RLJsKwPOB6FWFVKA///CNeA= Date: Thu, 2 Feb 2017 15:26:39 +0000 Message-ID: <20170202152629.98033754.871.9639@blackberry.com> References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:26:45 -0000 http://ia.cr/2013/382 might be relevant, theoretically, but I'm no expert... Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Paterson, Kenny Sent: Thursday, February 2, 2017 9:08 AM To: Stephen Farrell; cfrg@irtf.org Subject: Re: [Cfrg] erratum for hmac what do we think... Dear CFRG, It'd be great if some HMAC experts could take a look at this proposed erratum and give a view on it. I looked quickly myself. It's an undesirable property, but I don't think it's disastrous (yes, I could invent scenarios where one could come unstuck because of it). It reminds me somewhat of the well-known, and again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys. Cheers, Kenny On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell" wrote: > >Hiya, > >There's an erratum posted for hmac [1] where I'd be >interested in what folks here think. > >I'm unsure if this is a real problem, esp given that >there are I guess a lot of implementations. > >And even if it were a real problem, I'm not sure we'd >want that fix. > >Opinions welcome... > >Thanks, >S. > >[1] >https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&rec_sta= tus=3D >15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=3D&stream_n= ame=3D&sub >mit_date=3D&presentation=3Drecords > _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Feb 2 07:52:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A89129686 for ; Thu, 2 Feb 2017 07:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 tEBvt6buCVIp for ; Thu, 2 Feb 2017 07:52:49 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 AB4EF12968D for ; Thu, 2 Feb 2017 07:52:49 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id f9so14821795otd.1 for ; Thu, 02 Feb 2017 07:52:49 -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=BHgHzyoWuRrhb1R2BNVxgY4YRg1lMd4HJwjql0tFsqs=; b=Xlm1enJX6WPIuANOHnQb8KhMS8ZpWa2hLmz3n0v7elbI9TIMPfMm2al/N8QoL6ILvY D2bQFCTQMLgWoCTCTeFx16F6zXRGQ/HWR+AqcAt16jcLMv1iOBvJyhERq4Opod2jkTO/ oI+UQosahXS86uJZl2bDMA7UeKyw9pNBQXcfPKS7Bu6GaNdLCB6U6GcnSrIDb622AWXE Rs4cNyuw/4Ljnx3oBM23pA7/3uFkV1a3Ofr16OeIHoV65gjfMNHphI4voOUmfz40rEZ6 FALMz5Iu0BCsSpB1/CoKVvSkK4XBTguARJR3BOp63RpbSe15igP6zZt43rFWxXjXJhlb b7yw== 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=BHgHzyoWuRrhb1R2BNVxgY4YRg1lMd4HJwjql0tFsqs=; b=DWYhJxO0lZxoSbRB9czTpkbTmv1HvuhCuHX3SnlLGC6Oa4bq3QRuxh+V20kj2wHYC/ kbAcxd0PuYP4aM/WXl8EFJlkn0o6ytL2ekykGbbkdk7nFLuoZRKNCBtmJBrC+nHKHxLW zWJiijEdHtgfrl4xRzKB6xqalkVT0h1aMuY4UYEolwmVj68IsqhDUjI01pKJ2DiSO/KY 0+6m3wvumg86fCuL6500Wdi+lmw6qes66zE7v3jlfAX9Azb8iCtB8Z3Vdx1xCDe49pUH x+EsWWMbdG/q3774TbEI1kfPRqZ7Q/Pdn2ciC9i7N8RB8in4fRHJsGzkX675NhDWIhbx of+Q== X-Gm-Message-State: AIkVDXLHj7dmvM9Yv9I+DcecKW5NI8nCAt/24pFERmvsMtXPMpRaaKa9C2Fip7lJsCJ31ed0bAClC81WoPybxQ== X-Received: by 10.157.47.141 with SMTP id r13mr3984394otb.203.1486050768879; Thu, 02 Feb 2017 07:52:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.15 with HTTP; Thu, 2 Feb 2017 07:52:48 -0800 (PST) In-Reply-To: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> From: Xander Sherry Date: Thu, 2 Feb 2017 10:52:48 -0500 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=001a113d15dc329e7105478e28e3 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:52:53 -0000 --001a113d15dc329e7105478e28e3 Content-Type: text/plain; charset=UTF-8 Speaking not as an HMAC expert but as an application security guy, while I agree that the ares where the design of HMAC could be improved, the vulnerability described in the proposed errata is, in my opinion, less a security issue with HMAC, and more a security issue with a badly designed system. I can immediately think of several ways to mitigate the threat, not the least of which is simply not to build a system that stores plaintext hashes of bare keys. As we all well know, virtually any cryptographic design can (and will!) be implemented badly in ways that introduce vulnerability, when the implementer doesn't understand the system he or she is implementing, which is exactly what the scenario in question seems to be. Generally speaking, I think HMAC is easier than most to implement reasonably securely, and even where it is not, this particular case is not where it is likeliest to fail. Short colliding keys as Kenny mentioned are certainly a bigger issue, and weak keys and non-constant-time comparison are other issues I see regularly in real systems. On a tangent, purely as personal opinion, errata is a great tool for fixing mistakes and adding clarification. It's a lousy way to propose a fundamental breaking change to an RFC that's been published for 19 years and is already baked into who-knows-how-many systems in its current specification. Best regards, -Xander Sherry On Thu, Feb 2, 2017 at 9:07 AM, Paterson, Kenny wrote: > Dear CFRG, > > It'd be great if some HMAC experts could take a look at this proposed > erratum and give a view on it. > > I looked quickly myself. It's an undesirable property, but I don't think > it's disastrous (yes, I could invent scenarios where one could come > unstuck because of it). It reminds me somewhat of the well-known, and > again somewhat unfortunate, fact that HMAC keys of different lengths can > end up being padded to form colliding keys. > > Cheers, > > Kenny > > On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell" > wrote: > > > > >Hiya, > > > >There's an erratum posted for hmac [1] where I'd be > >interested in what folks here think. > > > >I'm unsure if this is a real problem, esp given that > >there are I guess a lot of implementations. > > > >And even if it were a real problem, I'm not sure we'd > >want that fix. > > > >Opinions welcome... > > > >Thanks, > >S. > > > >[1] > >https://www.rfc-editor.org/errata_search.php?rfc=2104& > eid=4809&rec_status= > >15&area_acronym=&errata_type=&wg_acronym=&submitter_name=& > stream_name=&sub > >mit_date=&presentation=records > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a113d15dc329e7105478e28e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking not as an HMAC expert but as an application secur= ity guy, while I agree that the ares where the design of HMAC could be impr= oved, the vulnerability described in the proposed errata is, in my opinion,= less a security issue with HMAC, and more a security issue with a badly de= signed system.=C2=A0 I can immediately think of several ways to mitigate th= e threat, not the least of which is simply not to build a system that store= s plaintext hashes of bare keys.

As we all well know, virtuall= y any cryptographic design can (and will!) be implemented badly in ways tha= t introduce vulnerability, when the implementer doesn't understand the = system he or she is implementing, which is exactly what the scenario in que= stion seems to be. =C2=A0 Generally speaking, I think HMAC is easier than m= ost to implement reasonably securely, and even where it is not, this partic= ular case is not where it is likeliest to fail. =C2=A0 Short colliding keys= as Kenny mentioned are certainly a bigger issue, and weak keys and non-con= stant-time comparison are other issues I see regularly in real systems. =C2= =A0

On a tangent, purely as personal opinion, erra= ta is a great tool for fixing mistakes and adding clarification.=C2=A0 It&#= 39;s a lousy way to propose a fundamental breaking change to an RFC that= 9;s been published for 19 years and is already baked into who-knows-how-man= y systems in its current specification.

Best regards,

-Xander Sherry
=C2=A0

On Thu, Feb 2, 2017 a= t 9:07 AM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
Dear CFRG,

It'd be great if some HMAC experts could take a look at this proposed erratum and give a view on it.

I looked quickly myself. It's an undesirable property, but I don't = think
it's disastrous (yes, I could invent scenarios where one could come
unstuck because of it). It reminds me somewhat of the well-known, and
again somewhat unfortunate, fact that HMAC keys of different lengths can end up being padded to form colliding keys.

Cheers,

Kenny

On 02/02/2017 02:24, "Cfrg on behalf of Stephen Farrell"
<cfrg-bounces@irtf.org on b= ehalf of stephen.farrell@cs.tc= d.ie> wrote:

>
>Hiya,
>
>There's an erratum posted for hmac [1] where I'd be
>interested in what folks here think.
>
>I'm unsure if this is a real problem, esp given that
>there are I guess a lot of implementations.
>
>And even if it were a real problem, I'm not sure we'd
>want that fix.
>
>Opinions welcome...
>
>Thanks,
>S.
>
>[1]
>https://= www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&am= p;rec_status=3D
>15&area_acronym=3D&errata_type=3D&wg_acronym=3D&su= bmitter_name=3D&stream_name=3D&sub
>mit_date=3D&presentation=3Drecords
>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a113d15dc329e7105478e28e3-- From nobody Thu Feb 2 08:10:59 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32965129696 for ; Thu, 2 Feb 2017 08:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-i5SYIVi8Tl for ; Thu, 2 Feb 2017 08:10:57 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9386B129490 for ; Thu, 2 Feb 2017 08:10:57 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so38080066qtg.3 for ; Thu, 02 Feb 2017 08:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=AoqA0CrDOXPwqVg+Qbg1fTkx3n0Frk+HUHjH9dMDoV4=; b=kESWMpOxfWuQDs+865WLhnHOCk04/RccWNuh3esn8XPur8ksZSJTipQTJ+2q3PfUMO ro04Ya3dMLITk9mhUAGMybsi5KW62DUCuUZhLDbYUx59WvnpGebqnJ8ugYroGxFx55YO FTiVZYQm/yC5w8p0KYUoAWonhdFGRv9+KCBt1j4m4Hwvz2NkxvnGwQaRmJYV+2DAhMON P7W8Hfu2bb/ZRCn/TdaxAsVKxXmA5ltN54XKm8N8Uf4y+NeU39kcscj3iff3l/9DO1kt Xa3G9UpYfgIZCa0ri82EIJyw+huRXkvCl0of3XnqsNCVlmZXeiT7ohNpb9ZWJUIqGg+q /g1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=AoqA0CrDOXPwqVg+Qbg1fTkx3n0Frk+HUHjH9dMDoV4=; b=elOTZZtHQ5ukSvfdJoVNdJAlSYxV3rrOcX1pbj5YpHqY83NJsAkRz+4NVIdfZqeJvR DNkBFmU8jM42+64dvgwcZWVKnNWXibLvIV+1yiQOV6zgjTFiU5dfrT9/MlqXT7ny4aE6 PrQJrIpRvNj/u/uBwkpAMTZKgGJAvLvWcx+9KZX4/Rz1+SWnY09mvOFAWmfPIAJ4uwPR s1Tdj3TFZeusvrW+/Z+i6ba/zCRK0U8Kv2rRNbA1jP6h/OmDUYfULo8M3jOHSQAlCPhc +xs8G9tXPDZpH0sRzUBh2Gjle27glNbQAvDe/inYVpWR1lfGGOi+NsqqnUeraXcff8zE UQCg== X-Gm-Message-State: AIkVDXK/IMQKBG614KKDitFbhYkKrGQSInnSRALRj6NSJ9udR3i7trYXJh9xjv4vhtzYxQ== X-Received: by 10.237.62.44 with SMTP id l41mr9570789qtf.16.1486051855994; Thu, 02 Feb 2017 08:10:55 -0800 (PST) Received: from ?IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975? ([2601:152:4400:9b5f:c8f0:67e5:88b1:2975]) by smtp.gmail.com with ESMTPSA id q145sm21823318qke.37.2017.02.02.08.10.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 08:10:55 -0800 (PST) To: cfrg@irtf.org References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> From: Michael StJohns Message-ID: Date: Thu, 2 Feb 2017 11:10:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------BF1D8B98402EF4780EF84109" Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:10:59 -0000 This is a multi-part message in MIME format. --------------BF1D8B98402EF4780EF84109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Inline. On 2/1/2017 9:24 PM, Stephen Farrell wrote: > Hiya, > > There's an erratum posted for hmac [1] where I'd be > interested in what folks here think. > > I'm unsure if this is a real problem, esp given that > there are I guess a lot of implementations. > > And even if it were a real problem, I'm not sure we'd > want that fix. I think it's probably a bogus erratum. Basically, there are a lot of ways to calculate check values for secret keys - hashing the key as suggested in this report - is not the one I would suggest for HMAC keys. Instead, doing an HMAC over a known value - HMAC (K, '0000000000000000'b) to get a check value might be a better choice. I think this report boils down to a "I came up with a way to use this mechanism in a way that may have security weaknesses". If he'd said that IPSEC uses this and its bad, then I'd say the report was actionable - with respect to IPSEC. As it stands, I'd reject the report. Alternately, I might say "Applications MUST not use keys longer than 8 bytes, where the hash of the key (with the same hash as used in the HMAC) is also used as a public value (a key identifier or check value)". And given that AFAICT RFC 2104 was really a feeder document for the NIST FIPS 198-1 submission (compare if you will the abstract of the RFC with the NIST document Introduction), I would suggest that any changes to HMAC be fed in to NIST rather than being accepted as updates to this informational document. Mike > > Opinions welcome... > > Thanks, > S. > > [1] > https://www.rfc-editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&stream_name=&submit_date=&presentation=records > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --------------BF1D8B98402EF4780EF84109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Inline.

On 2/1/2017 9:24 PM, Stephen Farrell wrote:
Hiya,

There's an erratum posted for hmac [1] where I'd be
interested in what folks here think.

I'm unsure if this is a real problem, esp given that
there are I guess a lot of implementations.

And even if it were a real problem, I'm not sure we'd
want that fix.

I think it's probably a bogus erratum.   Basically, there are a lot of ways to calculate check values for secret keys - hashing the key as suggested in this report - is not the one I would suggest for HMAC keys.  Instead, doing an HMAC over a known value - HMAC (K, '0000000000000000'b) to get a check value might be a better choice.

I think this report boils down to a "I came up with a way to use this mechanism in a way that may have security weaknesses".  If he'd said that IPSEC uses this and its bad, then I'd say the report was actionable - with respect to IPSEC.  As it stands, I'd reject the report.  Alternately, I might say "Applications MUST not use keys longer than 8 bytes, where the hash of the key (with the same hash as used in the HMAC) is also used as a public value (a key identifier or check value)".

And given that AFAICT RFC 2104 was really a feeder document for the NIST  FIPS 198-1 submission  (compare if you will the abstract of the RFC with the NIST document Introduction), I would suggest that any changes to HMAC be fed in to NIST rather than being accepted as updates to this informational document.

Mike










Opinions welcome...

Thanks,
S.

[1]
https://www.rfc-editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&stream_name=&submit_date=&presentation=records




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--------------BF1D8B98402EF4780EF84109-- From nobody Thu Feb 2 08:22:59 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F59129458 for ; Thu, 2 Feb 2017 08:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, 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 M6Tvi4t8Qedm for ; Thu, 2 Feb 2017 08:22:56 -0800 (PST) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (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 9F75C12943F for ; Thu, 2 Feb 2017 08:22:56 -0800 (PST) Received: by mail-yb0-x241.google.com with SMTP id j82so862810ybg.2 for ; Thu, 02 Feb 2017 08:22:56 -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:cc; bh=8oZ4MFmYkDd4CfMBO/X16BvlPn7kPyfEZUH7EmhmuUE=; b=AVed+ilnXTBZ+mu4p1GAOK4CnOc3Rz4Uqks5LP7+/+2nc8sekkCk10Q0IeBiTozFIB W3fC5EOYDL0MR86mX2qksLCsGoxB9xpgddo94ZjKNdlzEyaLBQuBpLLNnX7wyGPqaUkr o4A/jr6C8GNybErEtXo5ujEXsW8sUk2Jj6pPTQFmIOC4hB1orTcB2XFBgE66GMJ8V5uD bjSIb8xUD4s7z0OZw/JtdkCp9eRgILKJG4sMbTk9HidJAtghQSS/axjI547k06+ETRhH 3id17aoA/hTZGg24+haEm843oTzaN5eAkFY8bP0aU83ctDnd0d78s4CMNeHgT9Y9fydq JE7A== 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:cc; bh=8oZ4MFmYkDd4CfMBO/X16BvlPn7kPyfEZUH7EmhmuUE=; b=QhJJLbQ1H/IEy102OaNH87/wa+T+oAiJQKla/M6jYNme3mg0+B8EJ3PdsVFY9QJwJN kPtuZxmTMIJ7579Kv9drsLPTuPWI1yeqCYPqnj6ImmF6gJoWNJGb06nWNnWrkBnQFuew M1JDx6PIeuOVwN5Bm8QQEP3K/EZcONr0hYreVbW52f2z9WaEWuPyhbReQG4phEnxOtS+ zNNhBaA1yNXwITav2MWkYeCwieBMfZ/PhzUXAnHJtHsCjnWajz883IG64q3WRitiAbiV DNjNkqOC+2GQAJHeSBjn0FehEv4GSDEUjh0VoHU2gZt6XR+p16QiINRbYqRyltVgWvue azWw== X-Gm-Message-State: AIkVDXIcjHb7wl+h48S2CZs+nAgFKJlXFSvUb6pI31VC+mAeR3zF2NzQtVSgGJns7J6qVI79Mmb/C206JtcyiA== X-Received: by 10.37.61.199 with SMTP id k190mt3262295yba.147.1486052575751; Thu, 02 Feb 2017 08:22:55 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.44.82 with HTTP; Thu, 2 Feb 2017 08:22:25 -0800 (PST) In-Reply-To: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> From: Hugo Krawczyk Date: Thu, 2 Feb 2017 11:22:25 -0500 X-Google-Sender-Auth: d2j_dIGK1rKiCJrhLXlPxC061vA Message-ID: Content-Type: multipart/alternative; boundary=001a114bd0c6e59f0305478e9310 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:22:58 -0000 --001a114bd0c6e59f0305478e9310 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BThese cases of related key setting=E2=80=8Bs are well known and c= an indeed be seen as a weakness of HMAC. They are part of the engineering trade-offs you have to do for accommodating a design to the real world (and requirements from often chaotic IETF discussions). There were things we would have liked to do differently such as avoiding the longer-than-block keys or having different keys for the inner and outer hash applications, but that would have made the design problematic in different ways. The particular issue of not disallowing keys longer than a block came at least from an IKE requirement. For example, people wanted to use unlimited passphrases, and between having people truncate long keys or hash them first, the latter seemed the more robust solution. (BTW, the right way to deal with these issues using HMAC is to use HKDF.) Anyway, over the years I heard some rare instances where this led to a weakness (I have myself shown such cases) but either these were theoretical settings or some forms of bad practice (e.g. making the hash of a secret key public). The paper cited earlier by Dan Brown also notes that this property makes HMAC with long keys non-indifferentiable from a random oracle. Again, not the nicest property but hardly something to worry much about in practice. Also, contrary to what Quin said, this property does not contradict HMAC being a PRF (PRFs can have related key weaknesses). After 20 years of widespread use, it seems to me that (again) the engineering considerations (not breaking existing implementations) are more significant than the potential problems of such related key issues. Hugo --001a114bd0c6e59f0305478e9310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BThese cases= of =C2=A0related key setting=E2=80=8Bs are well known and can indeed be se= en as a weakness of HMAC. They are part of the engineering trade-offs you h= ave to do for accommodating a design to the real world (and requirements fr= om often chaotic IETF discussions). There were things we would have liked t= o do differently such as avoiding the longer-than-block keys or having diff= erent keys for the inner and outer hash applications, but that would have m= ade the design problematic in different ways. The particular issue of not d= isallowing keys longer than a block came at least from an IKE requirement. = For example, people wanted to use unlimited passphrases, and between having= people truncate long keys or hash them first, the latter seemed the more r= obust solution. (BTW, the right way to deal with these issues using HMAC is= to use HKDF.)

Anyway, over the years = I heard some rare instances where this led to a weakness (I have myself sho= wn such cases) but either these were theoretical settings or some forms of = bad practice (e.g. making the hash of a secret key public). The paper cited= earlier by Dan Brown also notes that this property makes HMAC with long ke= ys non-indifferentiable from a random oracle. Again, not the nicest propert= y but hardly something to worry much about in practice. Also, contrary to w= hat Quin said, this property does not contradict HMAC being a PRF (PRFs can= have related key weaknesses).

After 2= 0 years of widespread use, it seems to me that (again) the engineering cons= iderations (not breaking existing implementations) are more significant tha= n the potential problems of such related key issues.=C2=A0

Hugo


<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si= ze:small">



--001a114bd0c6e59f0305478e9310-- From nobody Thu Feb 2 10:05:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A201294D8 for ; Thu, 2 Feb 2017 10:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 C0Nir1zHs3XL for ; Thu, 2 Feb 2017 10:05:33 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40072.outbound.protection.outlook.com [40.107.4.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AFB1294EE for ; Thu, 2 Feb 2017 10:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jQL+q7XiOYxJsnbZAAbTuSrqcs1T1/he9PtmNmuExcc=; b=m+88lIjwmqLWJ0mxuPCtsKhIGjnnKWG7VD3NkfZRjDL3CSvmWfnDQXp5qnw8AwsdiPVAKo0RYHQaXdpM53qtahkOsL2GUE9gZj+/HXTYi8cQ2ADxO03/w/KxRxUIefLBkDdzEydF3tQskGjXm5yQ/OI4D6H5G/yb5lqIAZcYmgQ= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 18:05:28 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0860.027; Thu, 2 Feb 2017 18:05:28 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Rev RFC 7539? Thread-Index: AQHSfX7vEznckYOcA0y0r8Mn+cCAng== Date: Thu, 2 Feb 2017 18:05:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.76.254] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:lvw3ZDIq1ZOKJj2bQuWGrb/Mw8e43Njh6w+uswrq3PdmMDaEVG74z7o1rfzu8aAPVM1RsRZCVpIb0nZqm45YoSwhanAl7r7P6MZ70Ow9nRvuaQCqDncuG0T/gaB59y3h0lXOG9gYI9NSNbcJIdJE7K2MssHn2tsc6IBhfSygD6sWZ48XDtwKGMnH6Pw62cikhIZT+Vm1ej6fRzz/GlPI3lE9+KlNSzgTuiqwgZ/4/qPy9OoL88miIqGGXm1Cj8es5T2Qrd60HwMZrLogz4/FBkmxrG/kv+H1ZdZKAwETvtZAFJEco/3w6QQitd3OxhTFCIOFvSLbIb4EdZR8JaZeTkaLWQrZfb0sMaFSMHhm16lgtZvC1+Sibu/GyqLCIEqJs3MsMXuT8qgjpaf2EEMZR0OneMd4VcZWjAvuX2eQQf749f+CUKXz7d9RMAoau6bmDlvKL14uFhyLuQwQ1Ic8BGW2pI6HngXHQjOdgqbogQhpfDksnscdI/6R0c8pRUI2wZOqujYnWcWNYvT2AFy8E1XUmn4d+0KzY+7VS1efEi/rF9Pr4T5RXHIVeFDTqPag x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377424004)(24454002)(199003)(45984002)(77096006)(38730400001)(36756003)(6486002)(6436002)(6506006)(7116003)(8936002)(81156014)(81166006)(8676002)(1730700003)(3660700001)(74482002)(5660300001)(6116002)(99286003)(3846002)(68196006)(3280700002)(25786008)(5640700003)(83506001)(2906002)(42882006)(110136003)(2501003)(6916009)(6306002)(6512007)(102836003)(229853002)(4001350100001)(101416001)(305945005)(97736004)(53936002)(189998001)(107886002)(122556002)(92566002)(86362001)(7736002)(2900100001)(2351001)(68736007)(50986999)(105586002)(106116001)(106356001)(66066001)(54356999)(450100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 66883298-0c46-4a9d-0a27-08d44b961216 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; x-forefront-prvs: 02065A9E77 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 18:05:28.4572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] Rev RFC 7539? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:05:36 -0000 RGVhciBDRlJHLA0KDQpZb2F2IE5pciBoYXMgdXBkYXRlZCBoaXMgZHJhZnQgZm9yIHRoZSBwcm9w b3NlZCByZXZpc2lvbiBvZiBSRkM3NTM5IGluDQpyZXNwb25zZSB0byBmZWVkYmFjayByZWNlaXZl ZCBmcm9tIHRoZSBDRlJHIGNyeXB0byBwYW5lbC4NCg0KVGhlIG5ldyB2ZXJzaW9uLCAwMSwgaXMg YXZhaWxhYmxlIGhlcmU6DQoNCglodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbmly LWNmcmctcmZjNzUzOWJpcy0wMQ0KDQoNClRoaXMgdmVyc2lvbiBoYXMgbm93IGJlZW4gcmV2aWV3 ZWQgYnkgdGhlIHNhbWUgQ0ZSRyBjcnlwdG8gcGFuZWwgbWVtYmVycw0Kd2hvIGxvb2tlZCBhdCB2 ZXJzaW9uIDAwLCBhbmQgZGVjbGFyZWQgZ29vZCB0byBnby4gU2VlIGJlbG93IGZvciB0aGUNCmUt bWFpbCB0cmFpbC4NCg0KV2Ugd291bGQgbm93IHdlbGNvbWUgYW55IGFkZGl0aW9uYWwgcmVtYXJr cyBvbiB0aGlzIGRyYWZ0IGZyb20gdGhlIHdpZGVyDQpDRlJHIGNvbW11bml0eS4NCg0KQmVzdCB3 aXNoZXMsDQoNCktlbm55IChmb3IgdGhlIGNoYWlycykNCg0KDQoNCk9uIDAyLzAyLzIwMTcgMTc6 NTMsICJTdGFuaXNsYXYgVi4gU215c2hseWFldiIgPHNteXNoc3ZAZ21haWwuY29tPiB3cm90ZToN Cg0KPuKAjkRlYXIgS2VubnkgYW5kIFlvYXYsDQo+DQo+SW4gbXkgb3BpbmlvbiwgdGhlIGRvY3Vt ZW50IGlzIHJlYWR5IG5vdywgSSd2ZSBnb3Qgbm8gY29uY2VybnMg4oCObGVmdC4NCj4NCj5UaGFu ayB5b3UgdmVyeSBtdWNoLCBZb2F2LCBmb3IgYWRkcmVzc2luZyB0aGUgY29uY2VybnMuDQo+DQo+ S2luZGVzdCByZWdhcmRzLA0KPlN0YW5pc2xhdg0KPg0KPg0KPj4gT24gMiBGZWIgMjAxNywgYXQg MTY6MjcsIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPj4gDQo+ PiBEb2N1bWVudDogZHJhZnQtbmlyLWNmcmctcmZjNzUzOWJpcy0wMQ0KPj4gUmV2aWV3ZXI6IFJ1 c3MgSG91c2xleQ0KPj4gUmV2aWV3IERhdGU6IDIwMTctMDItMDINCj4+IA0KPj4gVGhhbmtzIGZv ciBhZGRyZXNzaW5nIG15IGNvbW1lbnRzIG9uIHRoZSAtMDAgdmVyc2lvbi4NCj4+IA0KPj4gU3Vt bWFyeTogUmVhZHkNCj4+IA0KPj4gTWFqb3IgQ29uY2VybnM6IE5vbmUNCj4+IA0KPj4gTWlub3Ig Q29uY2VybnM6IE5vbmUNCj4+IA0KPj4gTml0czogTm9uZQ0KDQoNCk9uIDMwLzAxLzIwMTcgMTU6 NDYsICJZb2F2IE5pciIgPHluaXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+SGkuDQo+DQo+ DQo+U28gSeKAmXZlIGp1c3QgcG9zdGVkIHZlcnNpb24gLTAxLiBDaGFuZ2VzIGluY2x1ZGU6DQo+ DQo+KiBSZXdvcmRlZCB0aGUgYWJzdHJhY3QgaW50cm9kdWN0aW9uIHRvIGF2b2lkIHNheWluZyB0 aGF0IHRoZSBkb2N1bWVudA0KPmRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IGNyeXB0byAodGhl IGNvbXBvc2l0aW9uIG9mIENoYUNoYTIwIGFuZA0KPlBvbHkxMzA1IHdhcyBpbiBmYWN0IG5vdmVs KQ0KPiogUmVwbGFjZWQg4oCccGFwZXJzIGJ5IEQuIEouIEJlcm5zdGVpbuKAnSB3aXRoIGFjdHVh bCByZWZlcmVuY2VzLg0KPiogUmVtb3ZlZCBudW1iZXJpbmcgYW5kIGJ1bGxldHMgZnJvbSBsaXN0 cyBvZiBmb3JtdWxhcy4NCj4qIENvbnZlcnRlZCBhbGwg4oCccm90YXRpb27igJ0gdG8g4oCccm9s bOKAnSBmb3IgY29uc2lzdGVuY3kuDQo+KiBDaGFuZ2VkIHRoZSB2YXJpYWJsZSBuYW1lIGluIGlu bmVyX2Jsb2NrKCkgZnJvbSDigJx3b3JraW5nX3N0YXRl4oCdIHRvDQo+4oCcaW5pdGlhbF9zdGF0 ZeKAnQ0KPiogRXhwbGFpbmVkIHRoZSBwaXBlICjigJx84oCdKSBjaGFyYWN0ZXIgYW5kIGJpdHdp c2UgQU5EIGFzc2lnbm1lbnQgKOKAnCY94oCcKSBpbg0KPmZvcm11bGFzLg0KPiogUmVtb3ZlZCBk aXNjdXNzaW9uIG9mIHBvdGVudGlhbCB1c2UgaW4gRVNQIGFuZCBUTFMuIEJvdGggYWxnb3JpdGht cw0KPmhhdmUgUkZDcyBieSBub3cuDQo+KiBSZW1vdmVkIGRpc2N1c3Npb24gb2YgdXNpbmcgSE1B QyBmb3IgUFJGLg0KPiogQ2xhcmlmaWVkIHRoYXQgYSA2NC0gKG9yIDEyOC0gb3IgMjU2LSkgYml0 IGNpcGhlciByZWZlcnMgdG8gYmxvY2sgc2l6ZSwNCj5ub3QgdG8ga2V5IHNpemUuDQo+KiBBZGRy ZXNzZWQgSmltIFNjaGFhZOKAmXMgY29tbWVudCB0aGF0IHRoZSB0YWcgTVVTVCBOT1QgYmUgdHJ1 bmNhdGVkICh0aGF0DQo+d2FzIHRoZSBsaXR0bGUgZXh0cmEgdGV4dCBpbiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMpDQo+KiBBIGZldyBtb3JlIGVkaXRvcmlhbCBmaXhlcw0KPg0KPg0KPg0K Pg0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXItY2ZyZy1yZmM3NTM5Ymlz LTAxDQo+DQo+DQo+WW9hdg0KPg0KDQoNCg0KDQo= From nobody Thu Feb 2 13:57:02 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBB71299FD for ; Thu, 2 Feb 2017 13:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 ZRLvQEuIvi9e for ; Thu, 2 Feb 2017 13:56:59 -0800 (PST) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 171A4129A18 for ; Thu, 2 Feb 2017 13:56:33 -0800 (PST) Received: by jupiter.mumble.net (Postfix, from userid 1014) id 7D72A60AA2; Thu, 2 Feb 2017 21:56:31 +0000 (UTC) From: Taylor R Campbell To: Stephen Farrell In-reply-to: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> (stephen.farrell@cs.tcd.ie) Date: Thu, 2 Feb 2017 21:56:31 +0000 Sender: Taylor R Campbell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20170202215631.7D72A60AA2@jupiter.mumble.net> Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:57:01 -0000 > Date: Thu, 2 Feb 2017 02:24:44 +0000 > From: Stephen Farrell > > There's an erratum posted for hmac [1] where I'd be > interested in what folks here think. Fix hash function H with block size b. The alleged problem is that for a key k, if |k| > b and h = H(k), then HMAC-H_h = HMAC-H_k. What protocol would ever use HMAC-H with related keys of different lengths like this for the same purpose? What protocol would ever use HMAC-H with keys of different lengths at all for the same purpose? Needless flexibility like that strikes me as more likely to indicate a deeper problem -- e.g., one reason that might happen is that the protocol foolishly uses a password verbatim as an HMAC key. From nobody Fri Feb 3 00:16:15 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6B12951F for ; Fri, 3 Feb 2017 00:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 GXokcmhvLyow for ; Fri, 3 Feb 2017 00:16:13 -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 D5767129BCC for ; Fri, 3 Feb 2017 00:16:12 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id w20so22700530qtb.1 for ; Fri, 03 Feb 2017 00:16:12 -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; bh=F1UpM6dP35eBJ9FLUDNlHwevEK5cgz++HBUdSFk7bEc=; b=rHwuNuZpvOYn3WiJflMDS9lTGL4otAnjUWAJoSvH1+sDN6mhesTVlkdzcDcvj4KWf7 6J00SErW+eKH+xLQsRxNp9VAbmT7UuEd3fgpDbO5Hu7jPlR0kMRrjplp4RkGo+go30Ro OWh0QhFEB3qp/im16rl+UveO9XYI+6AtFGMDzW5RG6OpBaJIaKTGtvC0wykR1BPslder q3yJfynt5qObHaNQHSCxIJxWUl9FBUdtLexM9P0zq25AkuB1nDrR/FMMhAJrmbGF8vxV bf3rg2i9+v1EbyeFLgBEc9SPtlQ1eEa0T60ltt+ssX9nkWJ749IXaQPtmb6tqH8hbzVe Yw2A== 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; bh=F1UpM6dP35eBJ9FLUDNlHwevEK5cgz++HBUdSFk7bEc=; b=neTop3U1/9ee9TCYamcC2y54H1qWWEoXuFEMQsLFN2cMpnaFnShvEtRl48dZyfyhf+ NRyFW+OOu8AvoZyRsWz/I30M3ZQvgCKsegFVqfNZfxKSNlnVZmlv4DDXWoggtRvLoubv wks2PaApAQHfdyWkTv/oWtaHVjdU8BfT/WnqZ+MyxpWxiDz06HCefh3Qn/dPEIpz4vRo oFn1z+ufYIavxSfALB1uTRKBHD/BzgH+joL9kkdZYxC/nBOm9FKdv2vphcQncsqVdGW2 AlYxJyozfNmbkakyEH7AChbN6EW77tFUwoul9q4Gc0TbzNO21N3fRr2KKTh0aZRML+37 iV8w== X-Gm-Message-State: AMke39kT5npDiERzOK48QKEg2LBKf/NEOSLt6yCmKi0vqy22s7wYWqsOYjjJro0bnRz/Z4bKiM0GkPtalOvrKA== X-Received: by 10.55.17.10 with SMTP id b10mr13255574qkh.64.1486109771879; Fri, 03 Feb 2017 00:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.31.75 with HTTP; Fri, 3 Feb 2017 00:16:11 -0800 (PST) In-Reply-To: References: <20170116200948.6535.qmail@cr.yp.to> <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie> <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com> <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie> From: Tibor Jager Date: Fri, 3 Feb 2017 09:16:11 +0100 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary=001a113ad4460cdcfb05479be582 Archived-At: Subject: Re: [Cfrg] Help with the use of contexts X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 08:16:14 -0000 --001a113ad4460cdcfb05479be582 Content-Type: text/plain; charset=UTF-8 On 30 January 2017 at 12:40, Paterson, Kenny wrote: > > So: does anyone else want to offer an opinion on the question of contexts? > > Contexts are a clean and relatively simple way to prevent cross-protocol attacks, in particular when implemented in an as simple way as proposed by Adam and Dan. The cross-protocol attacks we have seen so far were mostly rather academic and not too practical. However, with an increasing number of cryptographic protocols in use the occurrence of practical cross-protocol attacks becomes much more likely, as the number of possible combinations grows quadratically. At some point it will become infeasible to analyze all possible combinations thoroughly enough. I think at some point in the future we will have to deal with the prevention of cross-protocol attacks by using contexts, and doing this as early as possible is a good idea - following the "better safe than sorry" principle is always a good idea when designing security protocols. --001a113ad4460cdcfb05479be582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 30 January 2017 at 12:40, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:

So: does anyone else want to offer an opinion on the question of contexts?<= br>

Contexts are a clean and relatively simple way=
 to prevent cross-protocol
attacks, in particular when implemented in an as simple way as proposed
by Adam and Dan.

The cross-protocol attacks we have seen so far were mostly rather
academic and not too practical. However, with an increasing number of
cryptographic protocols in use the occurrence of practical
cross-protocol attacks becomes much more likely, as the number of
possible combinations grows quadratically. At some point it will become
infeasible to analyze all possible combinations thoroughly enough.

I think at some point in the future we will have to deal with the
prevention of cross-protocol attacks by using contexts, and doing this
as early as possible is a good idea - following the "better safe than
sorry" principle is always a good idea when designing security protoco=
ls.
--001a113ad4460cdcfb05479be582-- From nobody Fri Feb 3 02:23:49 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12800129BCB for ; Fri, 3 Feb 2017 02:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ9052GhIa6g for ; Fri, 3 Feb 2017 02:23:46 -0800 (PST) Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (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 56938129BDF for ; Fri, 3 Feb 2017 02:23:42 -0800 (PST) Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-25) with ESMTP id v13ANcOx011221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 3 Feb 2017 11:23:39 +0100 (MET) Received: from [192.168.178.106] (p5085BC75.dip0.t-ipconnect.de [80.133.188.117]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTP id v13ANaXn011205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2017 11:23:38 +0100 (MET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1486117418; bh=zmOODTSxwKiJQRhwD+dzZsAzdekFm0kosA6mdYC7Ebw=; h=Subject:To:References:From:Date:In-Reply-To; b=AZVoJ5kHPHZrdLgNnCA6EDGU7Argq6AoOkCQIqCS9jnYYkG1wgNylaEOtp4dDkIqb 0IL+cbpNkvISOoVuBXYjgnQIotu4F1Y8a06L0zD7KnIWSrRyMhqzTcU2LLAhnKYvlg l25nOiGcEY9cBLcdSFcswvRL0dE1BwvkHtvZkjK8= To: cfrg@irtf.org References: <20170202215631.7D72A60AA2@jupiter.mumble.net> From: Ann Message-ID: <58945A2E.7000606@informatik.hu-berlin.de> Date: Fri, 3 Feb 2017 11:23:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20170202215631.7D72A60AA2@jupiter.mumble.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at mailbox X-Virus-Status: Clean X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.5.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Fri, 03 Feb 2017 11:23:39 +0100 (MET) Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:23:48 -0000 Anyway, the actual text is prone to HMACcollisions: Given |k|> Date: Thu, 2 Feb 2017 02:24:44 +0000 >> From: Stephen Farrell >> >> There's an erratum posted for hmac [1] where I'd be >> interested in what folks here think. > Fix hash function H with block size b. The alleged problem is that > for a key k, if |k| > b and h = H(k), then HMAC-H_h = HMAC-H_k. > > What protocol would ever use HMAC-H with related keys of different > lengths like this for the same purpose? What protocol would ever use > HMAC-H with keys of different lengths at all for the same purpose? > > Needless flexibility like that strikes me as more likely to indicate a > deeper problem -- e.g., one reason that might happen is that the > protocol foolishly uses a password verbatim as an HMAC key. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Feb 3 02:24:13 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C726129BE8 for ; Fri, 3 Feb 2017 02:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvAe-b5UHlz5 for ; Fri, 3 Feb 2017 02:24:09 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CBB129BDA for ; Fri, 3 Feb 2017 02:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1486117449; x=1517653449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iVsQJ1mxI6FFhi/DlE/WkHPo+JOM0GgqS5+MkLtq4NU=; b=4lGsIrXaUovsUY5FdVxyIZUgKYsEVbX0UpbW4oGxMn3rBywUdeoYWxiz id0Mjf8uD/eOrqyxOcmjMywg7uLkj/0JPlXPbm8Balv9fO1Vf8BgWUnmM DfVsDl0SKgdKYn5b8rcG/7Yq7hkae1XqfF/LjGf2Lmb6gYylNpr/wuqb/ Rf4xY9OEY2PUhJWEfB9+Tbv21Rty6GGDDrPCj0OT6q3tpcGtKnpzOlORP El86mC/BeOKSLL5G2dWiGBYeH2zxkhfFQ2OTzmg5CjFsA3Xj/Dm7t8J/B +GyAdWgKY/FzyfyAql3TUWf5onVDdJ4wYuyi+ngTEZU1WBLiakawEOrfK g==; X-IronPort-AV: E=Sophos;i="5.33,328,1477911600"; d="scan'208";a="133196915" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Feb 2017 23:24:06 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 3 Feb 2017 23:24:06 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 3 Feb 2017 23:24:06 +1300 From: Peter Gutmann To: Hugo Krawczyk Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfP9DHMx13a6CPEKiiWX18/QaD6FU54uAgAAdVQCAAAhHgIACCACa Date: Fri, 3 Feb 2017 10:24:06 +0000 Message-ID: <1486117441931.10734@cs.auckland.ac.nz> References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:24:11 -0000 Hugo Krawczyk writes:=0A= =0A= >For example, people wanted to use unlimited passphrases, and between havin= g=0A= >people truncate long keys or hash them first, the latter seemed the more= =0A= >robust solution. (BTW, the right way to deal with these issues using HMAC = is=0A= >to use HKDF.)=0A= =0A= Another solution to the fact that there are two external-format keys that m= ap=0A= to a single internal-format key (i.e. the > blocksize key and its hash) wou= ld=0A= be to reserve the first bit of the internal-format key to denote hashed vs.= =0A= non-hashed.=A0 OTOH then people would complain about losing one bit of stre= ngth,=0A= or someone would propose an attack based on knowing that the first bit will= =0A= almost always be zero (for non-hashed), or something similar.=A0 You can't = win=0A= :-).=0A= =0A= Peter.=0A= =0A= = From nobody Fri Feb 3 04:55:40 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F111204D9 for ; Fri, 3 Feb 2017 04:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=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 rr7MZR1BXGoO for ; Fri, 3 Feb 2017 04:55:37 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DAA43129629 for ; Fri, 3 Feb 2017 04:55:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id E28E81EDAC; Fri, 3 Feb 2017 14:55:34 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id dtS5i5kRCc4w; Fri, 3 Feb 2017 14:55:34 +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-smtp3.welho.com (Postfix) with ESMTPSA id 81A8E2310; Fri, 3 Feb 2017 14:55:34 +0200 (EET) Date: Fri, 3 Feb 2017 14:55:33 +0200 From: Ilari Liusvaara To: Tibor Jager Message-ID: <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170116200948.6535.qmail@cr.yp.to> <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie> <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com> <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Help with the use of contexts X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 12:55:39 -0000 On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote: > On 30 January 2017 at 12:40, Paterson, Kenny > wrote: > > > > > So: does anyone else want to offer an opinion on the question of contexts? > > > > > Contexts are a clean and relatively simple way to prevent cross-protocol > attacks, in particular when implemented in an as simple way as proposed > by Adam and Dan. Unfortunately, in practice those are anything but clean and simple. Yes, the theoretical notion is pretty simple (where (context,message) tuple replaces the message in standard notion of signature security). The biggest practical problem: Backwards compatiblity, the ever-present nemsis of security. There are basically two major problems: - Non-contextualized schemes, which leave the system wide open for any possible attacks. Hopefully nothing major. - The standard signature API can't accomodiate contexts. When it comes to TLS, AFAIK the most significant target for possible cross-protocol attacks is PKIX CSR mechanism. What I think it would take to deploy contextualization to TLS and closely associated technologies (PKIX mainly): - New RSA-PSS (possibly original RSA-PSS), ECDSA and EdDSA signature schemes (X.509 algorithms) that are contextualized. - New RSA and ECDSA key types (X.509 key types; EdDSA can reuse keys) - New TLS SignatureScheme values to go with these. One advantage of having different RSA key type would be that the old standard one has been jinxed by the broken RSA-PKCS#1v1.5 encryption. However, there is already standard RSA-PSS key type, which does not have the same problem AFAIK. -Ilari From nobody Fri Feb 3 06:41:43 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ACB129D9D for ; Fri, 3 Feb 2017 06:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ygVaaGhp-gxY for ; Fri, 3 Feb 2017 06:41:39 -0800 (PST) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002: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 6B0B2129D9B for ; Fri, 3 Feb 2017 06:41:39 -0800 (PST) Received: by mail-yb0-x242.google.com with SMTP id w194so872767ybe.1 for ; Fri, 03 Feb 2017 06:41:39 -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=682bxI7RpYAiCNYu62huJLhJ6J8yyK80hWj0x5xQxNU=; b=BmPgByPQpHxv7HgL7/nr53ZlyDA3z828xbrXLCyHE79svnKht3ztMAJHoRYT+eN9lb 4kcmBP/0Y2Klx4N+pQq57b4Q9SNxoJNmbqXjb/HUO3VUj9u5kkROkztqFuYB4BsHG/h6 hxAALf9gQktLDjOJelrlr5PdTHPHwP9pnJ12fXvZ7zT2+zfI7eb1p3G5w7EDQpCou4q5 8h/Y29BfIbnpkqIFfYwO94Oe4fBykUCxIgL0kNOhm8wY28B5B0pBDFdPGtKA9XvBJdRf bnhLnT5u7O7zbDkyj17Af3lPyw5KXNaIUUQQHXpPUMVSvY/aoVYVYu0aE4keBIGg916W UIFw== 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=682bxI7RpYAiCNYu62huJLhJ6J8yyK80hWj0x5xQxNU=; b=DRG7G6KCHEXx84QLvu18n/f7pvPhyfRp1Lq4aGFhi2MVSgrd5bHz+8xrlVElrWj9rq h05uK4H3um7aC3EDuztKxfBQ3gsdb+qTxp9IYRWPlJWu7o9lsy76Cji6erT5k0FFJrf5 7SmrG2k0cT2LzP6+shDiCSuZPKVVIYWeyIGRkdSdVq9h075FK2+UzQXjWUfyj4w/m8BB 7UvemSbfrrHBq7xwukSb5/Q/xUcWn2cQY68+TZM7DfJ5izMsxTdcFg/o4WanE/cRCVCa J4bKLK2R3Br5LbLze91Sqdh9uHbmGPRJ1qwt6X+lYtwGkfXMmYTmhIDi64Da9sg8sidR CKsA== X-Gm-Message-State: AIkVDXLqZeGc/aYPguexHEu5V5gFSLSu+X7dTHCbxSBbJIW+SEfNeRLhByPj3Jn5iWyp0QVPrrXeNFNiAoscIg== X-Received: by 10.37.31.85 with SMTP id f82mr5802923ybf.188.1486132898548; Fri, 03 Feb 2017 06:41:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.75.67 with HTTP; Fri, 3 Feb 2017 06:41:37 -0800 (PST) Received: by 10.37.75.67 with HTTP; Fri, 3 Feb 2017 06:41:37 -0800 (PST) In-Reply-To: <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170116200948.6535.qmail@cr.yp.to> <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie> <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com> <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie> <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi> From: Natanael Date: Fri, 3 Feb 2017 15:41:37 +0100 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1143e93281d3bb0547a147e7 Archived-At: Cc: cfrg@irtf.org Subject: Re: [Cfrg] Help with the use of contexts X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:41:41 -0000 --001a1143e93281d3bb0547a147e7 Content-Type: text/plain; charset=UTF-8 Den 3 feb. 2017 13:55 skrev "Ilari Liusvaara" : On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote: > On 30 January 2017 at 12:40, Paterson, Kenny > wrote: > > So: does anyone else want to offer an opinion on the question of contexts? > > > Contexts are a clean and relatively simple way to prevent cross-protocol > attacks, in particular when implemented in an as simple way as proposed > by Adam and Dan. Unfortunately, in practice those are anything but clean and simple. Yes, the theoretical notion is pretty simple (where (context,message) tuple replaces the message in standard notion of signature security). The biggest practical problem: Backwards compatiblity, the ever-present nemsis of security. There are basically two major problems: - Non-contextualized schemes, which leave the system wide open for any possible attacks. Hopefully nothing major. - The standard signature API can't accomodiate contexts. Couldn't we go the other way and suggest that people don't simply use the raw signature primitive, and instead only use a message format that includes room for contexts? Because in general, only cryptographers should deal with the raw primitives. Can anybody find a flaw with the following? Sign(; SHAKE256(; <[hexadecimal encoded output length in bits], [Base64(Signature algorithm + format identifier], [Base64(Context identifier)], [hexadecimal encoded message hash]>)) = message signature, context You feed in the message, key and context, the rest is hardcoded in the context aware software. Question: should the public key be included among the above inputs? Depending on the signature scheme it may not always be formatted as expected by the verifier (malleability, etc), and must thus be forwarded along with every message. This could perhaps be algorithm specific, since those algorithms with a deterministic public key encoding can hash it without publishing it with the message, and still validate. The signature algorithm description could use predefined ciphersuite identifiers (much like TLS does), defining the exact choices in use. The above SHAKE256 inputs should also be encoded with prefixes like a null byte to guarantee there can be no manufactured collision spanning across them. This should in theory provide a context-equipped signature that will not collide accidentally with context-less messages, and will not collide across unique signature algorithms/formats, and in particular will not collide across contexts. It should also resist most imaginable attacks including length extension attacks and similar, while also naturally being able to generate arbitary length hashes (SHAKE256) for the signing primitives (which may use unusual input lengths). It even achieves this without truncation or padding! Another question, should we prefix the SHAKE256 output? Is there any attacks that would stop? This format should also stop context-unaware software (which can be presumed to be intended to NOT be able to parse these message) from being able to validate these signatures, preventing these signatures from enabling cross-protocol attacks elsewhere. While one could verify the signature of the raw SHAKE256 output, it would be meaningless to most unaware software. Software only expecting signatures with contexts also wouldn't accept context-less signatures, as they would be extremely unlikely to validate (assuming SHAKE256 is secure). The exception is if a context-less program would be insecure and behave as a signature oracle or even be malicious and thus could be manipulated to generate such a SHAKE256 output to be signed, to be used against context aware software. (Sorry if anything is incoherent, my phone keyboard app Swiftkey bugged out and started deleting text. Had to rewrite a lot.) --001a1143e93281d3bb0547a147e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
De= n 3 feb. 2017 13:55 skrev "Ilari Liusvaara" <ilariliusvaara@welho.com>:
On Fri, Feb 0= 3, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> On 30 January 2017 at 12:40, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
> wrote:
> > So: does anyone else want to offer an opinion on the question of = contexts?
> >
> Contexts are a clean and relatively simple way to prevent cross-protoc= ol
> attacks, in particular when implemented in an as simple way as propose= d
> by Adam and Dan.

Unfortunately, in practice those are anything but clean and simple.
Yes, the theoretical notion is pretty simple (where (context,message)
tuple replaces the message in standard notion of signature security).

The biggest practical problem: Backwards compatiblity, the ever-present
nemsis of security.

There are basically two major problems:

- Non-contextualized schemes, which leave the system wide open for
=C2=A0 any possible attacks. Hopefully nothing major.
- The standard signature API can't accomodiate contexts.

Couldn't we= go the other way and suggest that people don't simply use the raw sign= ature primitive, and instead only use a message format that includes room f= or contexts? Because in general, only cryptographers should deal with the r= aw primitives.

Can anybo= dy find a flaw with the following?=C2=A0

<= div dir=3D"auto">Sign(<private key>;
=C2=A0 = =C2=A0 SHAKE256(<output length parameter>;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 <[hexadecimal encoded output length in bits],= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Base64(Signature= algorithm + format identifier],=C2=A0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 [Base64(Context identifier)],=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 [hexadecimal encoded message hash]>))=C2=A0<= /div>

=3D message signature, c= ontext=C2=A0

You feed in= the message, key and context, the rest is hardcoded in the context aware s= oftware.

Question: shoul= d the public key be included among the above inputs?=C2=A0
Depending on the signature scheme it may not always be formatted as = expected by the verifier (malleability, etc), and must thus be forwarded al= ong with every message.=C2=A0
This could perhaps be = algorithm specific, since those algorithms with a deterministic public key = encoding can hash it without publishing it with the message, and still vali= date.

The signature algorithm description could use predefin= ed ciphersuite identifiers (much like TLS does), defining the exact choices= in use.=C2=A0

The above SHAKE256 inputs should also be encoded with prefixes like a nul= l byte to guarantee there can be no manufactured collision spanning across = them.=C2=A0



This should in theory provide a= context-equipped signature that will not collide accidentally with context= -less messages, and will not collide across unique signature algorithms/for= mats, and in particular will not collide across contexts.=C2=A0

It should also resist most imaginab= le attacks including length extension attacks and similar, while also natur= ally being able to generate arbitary length hashes (SHAKE256) for the signi= ng primitives (which may use unusual input lengths). It even achieves this = without truncation or padding!=C2=A0
Another questio= n, should we prefix the SHAKE256 output? Is there any attacks that would st= op?=C2=A0

This format sh= ould also stop context-unaware software (which can be presumed to be intend= ed to NOT be able to parse these message) from being able to validate these= signatures, preventing these signatures from enabling cross-protocol attac= ks elsewhere.=C2=A0
While one could verify the signa= ture of the raw SHAKE256 output, it would be meaningless to most unaware so= ftware.

Software only ex= pecting signatures with contexts also wouldn't accept context-less sign= atures, as they would be extremely unlikely to validate (assuming SHAKE256 = is secure).=C2=A0
The exception is if a context-less= program would be insecure and behave as a signature oracle or even be mali= cious and thus could be manipulated to generate such a SHAKE256 output to b= e signed, to be used against context aware software.

(Sorry if anything is incoherent, my phone key= board app Swiftkey bugged out and started deleting text. Had to rewrite a l= ot.)
--001a1143e93281d3bb0547a147e7-- From nobody Fri Feb 3 08:15:17 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1038129C19 for ; Fri, 3 Feb 2017 08:15:15 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU6UkCp8mG5T for ; Fri, 3 Feb 2017 08:15:15 -0800 (PST) Received: from nm24-vm2.access.bullet.mail.bf1.yahoo.com (nm24-vm2.access.bullet.mail.bf1.yahoo.com [216.109.115.177]) (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 3192712946F for ; Fri, 3 Feb 2017 08:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1486137980; bh=58vP7/T4Z/Rrh37svUerLRiXjZ+R2GjtKYEyUSHyKDM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=Z/t50zIpC2TKrrA8gn1csGd1EuSCoHtRz/8svMQAJ3dv7YKjihnPOCDVUcCwJjFFl6Z8k8mLdfnylvs+RrmIMxTSzArc1Xx94xX5uhbnx5tkmrjbRKakfzg2lnnAhZBe9SrIvN2DCNLj407RWfYUnQNbZ0mJ5xxJULV7FV4uNOwHpRTLZJQRMlqP+iJc21ZZlORLuFSDd8LUFuK506NhBbMRb5Uw3Le9SZsfY3Rt5CTbnXDC0MIbtY4rfxeAIsrk7DP3xBhJrGJqUtH+AkAonxPcL2PUqJYmrH/I8lTCN6X2Jfdy0YH70G6cVxj5CB2/Y1zTvJP1iNdoWVJsHm8d1w== Received: from [66.196.81.158] by nm24.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000 Received: from [98.138.104.98] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000 X-Yahoo-Newman-Id: 222935.53514.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hSEZXvQVM1mfQ6de5Sc6YO4A3l6gYt1D2T3tXnmnwf6vc0o .PHUK4gX8xXaFHz6yg8oT3YG8TRwI0149vApSY4YQIOUkcbNTDNgZudtI.v8 csT0gziw25F_eKf85t7XKMpXl7dDXVibqPMDGs_avuIhtkudk5YcDxOcXKq_ LjNEjwvLo35nvQk_EguRcEF8eQESre6BMwXfX8ySZnAkAhAfnpXRVfW1AJ6B RTP5yeZWu27M6NE1Bjx944XLBgQfGrvv8k9PpyGFERcdyEtNIoDXVJRdsT47 5yZJyn5gWFoOWJYvwUQfDAO4Z67e3.8PD33m88Djd8O6xNmkcDJNK2Dzk_tp WlbavO8xMY_iljZn8Jz1xRzIUJ6jAwcnTV9omC.adxFzzpiyNXQIMFXxMJcn drK7n796OUl2mZ1grcnVvC0rMbJerQPSZfeh5RJ5tEILeJ34qae1LBCRAAVw Xq54XCK1nCn4x..PgRd3Cr7z.7MV.CfinCvjX3lKH7tGxozXsampi3N3FHUg 529ZNxN7vyByMD6p7PSPMD7NMEEwPNPAKhmfBHxWx2mYF.jIYgK38d6QYUCz mCoGYRZuqLQ-- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- To: Peter Gutmann , Hugo Krawczyk References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> <1486117441931.10734@cs.auckland.ac.nz> From: David Jacobson Message-ID: <3af52483-3793-91cc-54e4-dc383748e713@sbcglobal.net> Date: Fri, 3 Feb 2017 08:06:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1486117441931.10734@cs.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:15:16 -0000 On 2/3/17 2:24 AM, Peter Gutmann wrote: > Hugo Krawczyk writes: > >> For example, people wanted to use unlimited passphrases, and between having >> people truncate long keys or hash them first, the latter seemed the more >> robust solution. (BTW, the right way to deal with these issues using HMAC is >> to use HKDF.) > Another solution to the fact that there are two external-format keys that map > to a single internal-format key (i.e. the > blocksize key and its hash) would > be to reserve the first bit of the internal-format key to denote hashed vs. > non-hashed. OTOH then people would complain about losing one bit of strength, > or someone would propose an attack based on knowing that the first bit will > almost always be zero (for non-hashed), or something similar. You can't win > :-). > > Peter. Okay, we're off on a tangent and into hypotheticals about what could be done, so I'll make two suggestions. They could be used separately or together. 1. The present scheme uses an OPAD of 3636... . Instead use 3636... when no hashing is done and, say, a9a9... when hashing is done. 2. In addition to XORing the key with the OPAD, also XOR (at the right of the first block) with the length of the key in in bits (or bytes). --David Jacobson From nobody Fri Feb 3 10:28:21 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E773C1294B5 for ; Fri, 3 Feb 2017 10:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=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 JBgl9_pJJaMt for ; Fri, 3 Feb 2017 10:28:18 -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 ACAD21293FB for ; Fri, 3 Feb 2017 10:28:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5F33BE56 for ; Fri, 3 Feb 2017 18:28:16 +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 8N9AEU86mESd for ; Fri, 3 Feb 2017 18:28:15 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02AA4BE55 for ; Fri, 3 Feb 2017 18:28:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486146495; bh=m2X0oYwKqe/YcBsZFs6iln2vbqujMUb5RjMVB7XsTeE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ReasdSS4WerrCySQqwBg1av/ubGk1BifhG80grRdwzZN0QEOnObUcaXsLa0Y5tBRZ 8J9k6CWfPvMiZjHDJHcYa5E9kv89iYij+VsON0GjUdMIucih1vvPHpX1Ma9PE8Avh2 hn/e0zjDOinv7PeYGEBcy1jf3cNFjwNEYZEZHddc= To: "cfrg@irtf.org" References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <52b3065b-bb20-9b2b-30da-78b09aace9cb@cs.tcd.ie> Date: Fri, 3 Feb 2017 18:28:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020108080300050803000304" Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:28:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020108080300050803000304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks all, My reading of that thread leads me to conclude there there's consensus to not verify the erratum on the basis that the threat isn't that significant and a backwards incompatible change as would be required is not justified. However, if HMAC were to be updated in a manner that didn't require backwards compatibility then one would likely consider this. Hence I've marked this as "hold for document update" Cheers, S. On 02/02/17 02:24, Stephen Farrell wrote: >=20 > Hiya, >=20 > There's an erratum posted for hmac [1] where I'd be > interested in what folks here think. >=20 > I'm unsure if this is a real problem, esp given that > there are I guess a lot of implementations. >=20 > And even if it were a real problem, I'm not sure we'd > want that fix. >=20 > Opinions welcome... >=20 > Thanks, > S. >=20 > [1] > https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&rec_= status=3D15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=3D= &stream_name=3D&submit_date=3D&presentation=3Drecords >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 --------------ms020108080300050803000304 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDMx ODI4MTRaMC8GCSqGSIb3DQEJBDEiBCA2sbiI8j+zYtK5Eq7n2lczBk5JpO/cXzmMil0TirBr oTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCbe6jZEbScFsFefwtZ50McwoQe7DRc5U1a+u6lJ1AspXK0LtxmccBI vUhKhEGxObocEYtFBXzby25eHGqra1pSbH8pdZ1qcuNT0MkvDsLo6sK0FZPrVJxoUOzJN9f3 Os4XxHG5CkMkwekfiWMJEL3uQ6vDRHscORandzlILAa8NcZt933ZXZZZ/5yrz0IXe81R5Ouq mCjWI7J5G/16xkHmeDCEwOVtaEU3e5b4VVC+zW3XiJe0oSs9J/TAom4IuomgWRI+kgF8wHXw OuMsKKzX+0KO56f5g6DPEA5BnAmgB2oGuqLA2l1os+9l8zpl2WPHyfDnJj20fIvnlnHW+KCv AAAAAAAA --------------ms020108080300050803000304-- From nobody Fri Feb 3 11:47:41 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC012952B for ; Fri, 3 Feb 2017 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 71Y-p0gDZ_eb for ; Fri, 3 Feb 2017 11:47:37 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0123.outbound.protection.outlook.com [23.103.201.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB3212950C for ; Fri, 3 Feb 2017 11:47:37 -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=XFjIAmUcO7ovIU4SrMtHq7Fty5EuJ2Lt2t6Qs1d2wQc=; b=lCFRWEq8vlcLWRuNZ76+KuIunoNNcpb6sLX/1ObHoj2dfW02OQeME1tPkNlxy2okxCnuADdZT8XSbDluNh7ZLNturA+sWwTEkbgiX3LG6uiNUEwCFoyGOYGmOcYftYGvxmFu014NZHX83Zj4vh4g88ufQYU/Ph1dzQNhu5CGbo0= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 3 Feb 2017 19:47:36 +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.0888.020; Fri, 3 Feb 2017 19:47:36 +0000 From: "Dang, Quynh (Fed)" To: Hugo Krawczyk Thread-Topic: [Cfrg] erratum for hmac what do we think... Thread-Index: AQHSfPuTQmuL3UqM9EiFUsuWG7TDaaFVwYGAgAAdVQCAAAhGgIABxWDP Date: Fri, 3 Feb 2017 19:47:35 +0000 Message-ID: References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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-ms-office365-filtering-correlation-id: 54035ea6-6bbe-4822-bb93-08d44c6d80af x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:6iAc78m866ngcXcBTd1XRaVPkyKmm0G1PVbsaHAMC6DV8v7na86Rvpx1Vfdn37+jJdzQltfLXstCRJ7u4Wi9UhlCCTrmDozYd3+9/mPSB9Bjg1jgXM3XLJOKdmVnq0tL9BebVkYxf7C4GmbeuxvHh6nYvQD73NwTKUVsa9vYRNCQ+weickQ7ma6G1zeqEz59KzOiLAmb8IAr2Qvu7A5Gum+Tzh+Jhyk98jqN3mCdDl5daI3GDLtM6RT78fSRobmq3mQySxc9ueg9YUgIQ/WpmWoH/rZ5y4357WVTZ0J3BFip6iPU8zHS7J0nug+w4KV2eLr3qphfSXc6+w+iXBsxo3gzplxpakBHauEMjzVfyQ/t80SNKAq4Nbcceed/XrlBCujMWr6uyPDy0OLphGfr+bM0oNFNvLtLitPRVNGUrKHFEj9oPOlids0gvlXH9ZsDbRwPKBaek7lUZv/mtOrAtc+wk3iRtkEgqmSMeVEOQnjCC8jvfKhdbi9Kc/op95xbkv6C7Vc1KvNAsA3gG5bERA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(52314003)(377454003)(189002)(199003)(6116002)(102836003)(4326007)(3846002)(3660700001)(25786008)(77096006)(6436002)(189998001)(54896002)(9686003)(3280700002)(93886004)(99286003)(53936002)(55016002)(2900100001)(6506006)(66066001)(2906002)(2950100002)(68736007)(38730400001)(33656002)(345774005)(229853002)(8936002)(5660300001)(19627405001)(76176999)(122556002)(7696004)(110136003)(92566002)(101416001)(54356999)(8676002)(50986999)(6246003)(7736002)(97736004)(74316002)(86362001)(106356001)(106116001)(6916009)(81156014)(81166006)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.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_CY4PR09MB1464ED9008BCF397A0228C00F34F0CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 19:47:35.8567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 19:47:39 -0000 --_000_CY4PR09MB1464ED9008BCF397A0228C00F34F0CY4PR09MB1464namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSHVnbywNCg0KDQpUaGFuayB5b3UgZm9yIGNhbGxpbmcgbWUgYSBuaWNlIG5hbWUgIlF1aW4i IQ0KDQoNCkluIHRoZSBITUFDIHBhcGVyLCB0aGUga2V5IGxlbmd0aCBpcyB0aGUgSVYgbGVuZ3Ro ICh0aGUgbGVuZ3RoIG9mIHRoZSBoYXNoIGZ1bmN0aW9uIG91dHB1dCkuIEJ1dCBpbiB0aGUgUkZD IHNwZWNpZmljYXRpb24gb2YgdGhlIEhNQUMsIHRoZSBrZXkgaXMgImFueSIgbGVuZ3RoLg0KDQoN CkkgYW0gc3VyZSB5b3Ugc2F3IHRoYXQgYiBiaXRzIG9mICAoa2V5fHwwMDAwMC4uLi4pIGNyZWF0 ZWQgdGhlIHNpdHVhdGlvbiB0aGF0IG1hbnkga2V5cyBwcm9kdWNlZCB0aGUgc2FtZSBvdXRwdXQg ZnJvbSB0aGUgZnVuY3Rpb24gSE1BQyBmb3IgdGhlIHNhbWUgbWVzc2FnZSBpbnB1dCB3aGVuIHRo ZSBrZXkncyBsZW5ndGggd2FzIG5vdCBhIGZpeGVkIHZhbHVlLiBJZiB5b3Ugd2FudGVkIGEgdmFy aWFibGUga2V5IGxlbmd0aCwgeW91IHdvdWxkIGhhdmUgaGFkIGF0IGxlYXN0IDIgb3B0aW9uczog KDEpIGFkZGluZyBlbmNvZGluZyBmb3Iga2V5IGxlbmd0aCBhbmQgcHV0IHNvbWUgcmVzdHJpY3Rp b24gb24ga2V5IGxlbmd0aCBzbyB0aGF0IHRoZSBrZXkgYW5kIGl0cyBsZW5ndGggZW5jb2Rpbmcg ZGlkIG5vdCBnZXQgbG9uZ2VyIHRoYW4gdGhlIGhhc2ggZnVuY3Rpb24gaW5wdXQgYmxvY2sgKGF2 b2lkaW5nIG9uZSBoYXNoIGZ1bmN0aW9uIGNhbGwgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZSkgb3Ig KDIpIGFsd2F5cyBoYXNoaW5nIHRoZSBrZXkgdG8gcHJvZHVjZSB0aGUgZXhhY3QgbGVuZ3RoIEwg Zm9yIHRoZSBrZXkuDQoNCg0KUXV5bmguDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBDZnJnIDxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmc+IG9uIGJlaGFsZiBvZiBIdWdv IEtyYXdjenlrIDxodWdvQGVlLnRlY2huaW9uLmFjLmlsPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDIsIDIwMTcgMTE6MjI6MjUgQU0NCkNjOiBjZnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTog W0NmcmddIGVycmF0dW0gZm9yIGhtYWMgd2hhdCBkbyB3ZSB0aGluay4uLg0KDQrigItUaGVzZSBj YXNlcyBvZiAgcmVsYXRlZCBrZXkgc2V0dGluZ+KAi3MgYXJlIHdlbGwga25vd24gYW5kIGNhbiBp bmRlZWQgYmUgc2VlbiBhcyBhIHdlYWtuZXNzIG9mIEhNQUMuIFRoZXkgYXJlIHBhcnQgb2YgdGhl IGVuZ2luZWVyaW5nIHRyYWRlLW9mZnMgeW91IGhhdmUgdG8gZG8gZm9yIGFjY29tbW9kYXRpbmcg YSBkZXNpZ24gdG8gdGhlIHJlYWwgd29ybGQgKGFuZCByZXF1aXJlbWVudHMgZnJvbSBvZnRlbiBj aGFvdGljIElFVEYgZGlzY3Vzc2lvbnMpLiBUaGVyZSB3ZXJlIHRoaW5ncyB3ZSB3b3VsZCBoYXZl IGxpa2VkIHRvIGRvIGRpZmZlcmVudGx5IHN1Y2ggYXMgYXZvaWRpbmcgdGhlIGxvbmdlci10aGFu LWJsb2NrIGtleXMgb3IgaGF2aW5nIGRpZmZlcmVudCBrZXlzIGZvciB0aGUgaW5uZXIgYW5kIG91 dGVyIGhhc2ggYXBwbGljYXRpb25zLCBidXQgdGhhdCB3b3VsZCBoYXZlIG1hZGUgdGhlIGRlc2ln biBwcm9ibGVtYXRpYyBpbiBkaWZmZXJlbnQgd2F5cy4gVGhlIHBhcnRpY3VsYXIgaXNzdWUgb2Yg bm90IGRpc2FsbG93aW5nIGtleXMgbG9uZ2VyIHRoYW4gYSBibG9jayBjYW1lIGF0IGxlYXN0IGZy b20gYW4gSUtFIHJlcXVpcmVtZW50LiBGb3IgZXhhbXBsZSwgcGVvcGxlIHdhbnRlZCB0byB1c2Ug dW5saW1pdGVkIHBhc3NwaHJhc2VzLCBhbmQgYmV0d2VlbiBoYXZpbmcgcGVvcGxlIHRydW5jYXRl IGxvbmcga2V5cyBvciBoYXNoIHRoZW0gZmlyc3QsIHRoZSBsYXR0ZXIgc2VlbWVkIHRoZSBtb3Jl IHJvYnVzdCBzb2x1dGlvbi4gKEJUVywgdGhlIHJpZ2h0IHdheSB0byBkZWFsIHdpdGggdGhlc2Ug aXNzdWVzIHVzaW5nIEhNQUMgaXMgdG8gdXNlIEhLREYuKQ0KDQpBbnl3YXksIG92ZXIgdGhlIHll YXJzIEkgaGVhcmQgc29tZSByYXJlIGluc3RhbmNlcyB3aGVyZSB0aGlzIGxlZCB0byBhIHdlYWtu ZXNzIChJIGhhdmUgbXlzZWxmIHNob3duIHN1Y2ggY2FzZXMpIGJ1dCBlaXRoZXIgdGhlc2Ugd2Vy ZSB0aGVvcmV0aWNhbCBzZXR0aW5ncyBvciBzb21lIGZvcm1zIG9mIGJhZCBwcmFjdGljZSAoZS5n LiBtYWtpbmcgdGhlIGhhc2ggb2YgYSBzZWNyZXQga2V5IHB1YmxpYykuIFRoZSBwYXBlciBjaXRl ZCBlYXJsaWVyIGJ5IERhbiBCcm93biBhbHNvIG5vdGVzIHRoYXQgdGhpcyBwcm9wZXJ0eSBtYWtl cyBITUFDIHdpdGggbG9uZyBrZXlzIG5vbi1pbmRpZmZlcmVudGlhYmxlIGZyb20gYSByYW5kb20g b3JhY2xlLiBBZ2Fpbiwgbm90IHRoZSBuaWNlc3QgcHJvcGVydHkgYnV0IGhhcmRseSBzb21ldGhp bmcgdG8gd29ycnkgbXVjaCBhYm91dCBpbiBwcmFjdGljZS4gQWxzbywgY29udHJhcnkgdG8gd2hh dCBRdWluIHNhaWQsIHRoaXMgcHJvcGVydHkgZG9lcyBub3QgY29udHJhZGljdCBITUFDIGJlaW5n IGEgUFJGIChQUkZzIGNhbiBoYXZlIHJlbGF0ZWQga2V5IHdlYWtuZXNzZXMpLg0KDQpBZnRlciAy MCB5ZWFycyBvZiB3aWRlc3ByZWFkIHVzZSwgaXQgc2VlbXMgdG8gbWUgdGhhdCAoYWdhaW4pIHRo ZSBlbmdpbmVlcmluZyBjb25zaWRlcmF0aW9ucyAobm90IGJyZWFraW5nIGV4aXN0aW5nIGltcGxl bWVudGF0aW9ucykgYXJlIG1vcmUgc2lnbmlmaWNhbnQgdGhhbiB0aGUgcG90ZW50aWFsIHByb2Js ZW1zIG9mIHN1Y2ggcmVsYXRlZCBrZXkgaXNzdWVzLg0KDQpIdWdvDQoNCg0KDQoNCg0KDQo= --_000_CY4PR09MB1464ED9008BCF397A0228C00F34F0CY4PR09MB1464namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHN0eWxlIHR5cGU9 InRleHQvY3NzIiBzdHlsZT0iZGlzcGxheTpub25lOyI+PCEtLSBQIHttYXJnaW4tdG9wOjA7bWFy Z2luLWJvdHRvbTowO30gLS0+PC9zdHlsZT4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVy IiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpDYWxpYnJp LEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyIgZGlyPSJsdHIiPg0KPHA+SGkgSHVnbyw8L3A+ DQo8cD48YnI+DQo8L3A+DQo8cD5UaGFuayB5b3UgZm9yIGNhbGxpbmcgbWUgYSBuaWNlIG5hbWUg JnF1b3Q7UXVpbiZxdW90OyE8L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5JbiB0aGUgSE1BQyBwYXBl ciwgdGhlIGtleSBsZW5ndGggaXMgdGhlIElWIGxlbmd0aCAodGhlIGxlbmd0aCBvZiB0aGUgaGFz aCBmdW5jdGlvbiBvdXRwdXQpLiBCdXQgaW4gdGhlIFJGQyBzcGVjaWZpY2F0aW9uIG9mIHRoZSBI TUFDLCB0aGUga2V5IGlzICZxdW90O2FueSZxdW90OyBsZW5ndGguPC9wPg0KPHA+PGJyPg0KPC9w Pg0KPHA+SSBhbSBzdXJlIHlvdSBzYXcgdGhhdCBiIGJpdHMgb2YgJm5ic3A7KGtleXx8MDAwMDAu Li4uKSBjcmVhdGVkIHRoZSBzaXR1YXRpb24gdGhhdCBtYW55IGtleXMgcHJvZHVjZWQgdGhlIHNh bWUgb3V0cHV0IGZyb20gdGhlIGZ1bmN0aW9uIEhNQUMgZm9yIHRoZSBzYW1lIG1lc3NhZ2UgaW5w dXQgd2hlbiB0aGUmbmJzcDtrZXkncyBsZW5ndGggd2FzIG5vdCBhIGZpeGVkIHZhbHVlLiBJZiB5 b3Ugd2FudGVkIGEgdmFyaWFibGUga2V5IGxlbmd0aCwgeW91IHdvdWxkDQogaGF2ZSBoYWQgYXQg bGVhc3QgMiBvcHRpb25zOiAoMSkmbmJzcDthZGRpbmcgZW5jb2RpbmcgZm9yIGtleSBsZW5ndGgg YW5kIHB1dCBzb21lIHJlc3RyaWN0aW9uIG9uIGtleSBsZW5ndGggc28gdGhhdCB0aGUga2V5IGFu ZCBpdHMgbGVuZ3RoIGVuY29kaW5nIGRpZCBub3QgZ2V0IGxvbmdlciB0aGFuIHRoZSBoYXNoIGZ1 bmN0aW9uIGlucHV0IGJsb2NrIChhdm9pZGluZyBvbmUgaGFzaCBmdW5jdGlvbiBjYWxsIHRvIGlt cHJvdmUgcGVyZm9ybWFuY2UpIG9yDQogKDIpIGFsd2F5cyBoYXNoaW5nIHRoZSBrZXkgdG8gcHJv ZHVjZSB0aGUgZXhhY3QgbGVuZ3RoIEwgZm9yIHRoZSBrZXkuJm5ic3A7PC9wPg0KPHA+PGJyPg0K PC9wPg0KPHA+UXV5bmguICZuYnNwOzwvcD4NCjwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5Omlu bGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5Rndk TXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZv bnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IENmcmcgJmx0O2Nmcmct Ym91bmNlc0BpcnRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEh1Z28gS3Jhd2N6eWsgJmx0O2h1Z29A ZWUudGVjaG5pb24uYWMuaWwmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFy eSAyLCAyMDE3IDExOjIyOjI1IEFNPGJyPg0KPGI+Q2M6PC9iPiBjZnJnQGlydGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbQ2ZyZ10gZXJyYXR1bSBmb3IgaG1hYyB3aGF0IGRvIHdlIHRo aW5rLi4uPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGwiPg0K4oCLVGhlc2UgY2FzZXMgb2YgJm5ic3A7cmVsYXRlZCBrZXkgc2V0dGluZ+KAi3MgYXJl IHdlbGwga25vd24gYW5kIGNhbiBpbmRlZWQgYmUgc2VlbiBhcyBhIHdlYWtuZXNzIG9mIEhNQUMu IFRoZXkgYXJlIHBhcnQgb2YgdGhlIGVuZ2luZWVyaW5nIHRyYWRlLW9mZnMgeW91IGhhdmUgdG8g ZG8gZm9yIGFjY29tbW9kYXRpbmcgYSBkZXNpZ24gdG8gdGhlIHJlYWwgd29ybGQgKGFuZCByZXF1 aXJlbWVudHMgZnJvbSBvZnRlbiBjaGFvdGljIElFVEYgZGlzY3Vzc2lvbnMpLg0KIFRoZXJlIHdl cmUgdGhpbmdzIHdlIHdvdWxkIGhhdmUgbGlrZWQgdG8gZG8gZGlmZmVyZW50bHkgc3VjaCBhcyBh dm9pZGluZyB0aGUgbG9uZ2VyLXRoYW4tYmxvY2sga2V5cyBvciBoYXZpbmcgZGlmZmVyZW50IGtl eXMgZm9yIHRoZSBpbm5lciBhbmQgb3V0ZXIgaGFzaCBhcHBsaWNhdGlvbnMsIGJ1dCB0aGF0IHdv dWxkIGhhdmUgbWFkZSB0aGUgZGVzaWduIHByb2JsZW1hdGljIGluIGRpZmZlcmVudCB3YXlzLiBU aGUgcGFydGljdWxhciBpc3N1ZQ0KIG9mIG5vdCBkaXNhbGxvd2luZyBrZXlzIGxvbmdlciB0aGFu IGEgYmxvY2sgY2FtZSBhdCBsZWFzdCBmcm9tIGFuIElLRSByZXF1aXJlbWVudC4gRm9yIGV4YW1w bGUsIHBlb3BsZSB3YW50ZWQgdG8gdXNlIHVubGltaXRlZCBwYXNzcGhyYXNlcywgYW5kIGJldHdl ZW4gaGF2aW5nIHBlb3BsZSB0cnVuY2F0ZSBsb25nIGtleXMgb3IgaGFzaCB0aGVtIGZpcnN0LCB0 aGUgbGF0dGVyIHNlZW1lZCB0aGUgbW9yZSByb2J1c3Qgc29sdXRpb24uIChCVFcsIHRoZQ0KIHJp Z2h0IHdheSB0byBkZWFsIHdpdGggdGhlc2UgaXNzdWVzIHVzaW5nIEhNQUMgaXMgdG8gdXNlIEhL REYuKTwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dmVyZGFuYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpBbnl3YXksIG92ZXIgdGhlIHllYXJzIEkgaGVhcmQgc29t ZSByYXJlIGluc3RhbmNlcyB3aGVyZSB0aGlzIGxlZCB0byBhIHdlYWtuZXNzIChJIGhhdmUgbXlz ZWxmIHNob3duIHN1Y2ggY2FzZXMpIGJ1dCBlaXRoZXIgdGhlc2Ugd2VyZSB0aGVvcmV0aWNhbCBz ZXR0aW5ncyBvciBzb21lIGZvcm1zIG9mIGJhZCBwcmFjdGljZSAoZS5nLiBtYWtpbmcgdGhlIGhh c2ggb2YgYSBzZWNyZXQga2V5IHB1YmxpYykuIFRoZSBwYXBlciBjaXRlZCBlYXJsaWVyDQogYnkg RGFuIEJyb3duIGFsc28gbm90ZXMgdGhhdCB0aGlzIHByb3BlcnR5IG1ha2VzIEhNQUMgd2l0aCBs b25nIGtleXMgbm9uLWluZGlmZmVyZW50aWFibGUgZnJvbSBhIHJhbmRvbSBvcmFjbGUuIEFnYWlu LCBub3QgdGhlIG5pY2VzdCBwcm9wZXJ0eSBidXQgaGFyZGx5IHNvbWV0aGluZyB0byB3b3JyeSBt dWNoIGFib3V0IGluIHByYWN0aWNlLiBBbHNvLCBjb250cmFyeSB0byB3aGF0IFF1aW4gc2FpZCwg dGhpcyBwcm9wZXJ0eSBkb2VzIG5vdCBjb250cmFkaWN0DQogSE1BQyBiZWluZyBhIFBSRiAoUFJG cyBjYW4gaGF2ZSByZWxhdGVkIGtleSB3ZWFrbmVzc2VzKS48L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQWZ0 ZXIgMjAgeWVhcnMgb2Ygd2lkZXNwcmVhZCB1c2UsIGl0IHNlZW1zIHRvIG1lIHRoYXQgKGFnYWlu KSB0aGUgZW5naW5lZXJpbmcgY29uc2lkZXJhdGlvbnMgKG5vdCBicmVha2luZyBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMpIGFyZSBtb3JlIHNpZ25pZmljYW50IHRoYW4gdGhlIHBvdGVudGlhbCBw cm9ibGVtcyBvZiBzdWNoIHJlbGF0ZWQga2V5IGlzc3Vlcy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KSHVnbzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFt aWx5OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dmVyZGFuYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0K PC9kaXY+DQo8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY4PR09MB1464ED9008BCF397A0228C00F34F0CY4PR09MB1464namp_-- From nobody Fri Feb 3 11:49:15 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B79812950C for ; Fri, 3 Feb 2017 11:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goVIli6yAiBk for ; Fri, 3 Feb 2017 11:49:11 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0BD129535 for ; Fri, 3 Feb 2017 11:49:11 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so50611004qtb.0 for ; Fri, 03 Feb 2017 11:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=7gvkxxf5MiEY745LuKu9Z16e7E172r5Mv/6I1R6cl80=; b=Y1jdJB7GG3uSnmHKs+Hxso763We0oladliPpHcWg3D8gSMYbnOZdELQHo9xhrUtTJG egOe6/cdOEOn/hoCN5KOB/iB9PPaR9XKaZjy5Jo+oL20jxjydvJ/zwGM20holku/oiL+ kkxyGQwdhOSbIeiGZ0jqa4DPbYwpFltmh1MdHUzE2NYIiTWakKfH5iUzAg2iyhjOQcJ8 Apw+OT3aGJxWPj/YKf3A/RwqArT35izoLkyeSJ9tkn0gvuiFPzNqPhTmqKM2F9xYzEy2 ErRiE2G/xvor0wGlVgoHukRNVnbAs34rA25B6gNR+ph87dMgzFWlboWBRcUlunMaS/mb /SpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=7gvkxxf5MiEY745LuKu9Z16e7E172r5Mv/6I1R6cl80=; b=X6Vrvx7Tv+S6IS93txZA938c2iZ9kW4p1sfCdVsedUOteyyTIBFsQUxIoMqdRDIG6S Gqfol/hlDGg9qddeOf+hp0W26civhAXZ/EFh6atazteu1x6KRT5M4fuKQd519bdVtLzw 5bJkvR+trcwRMcsb1ogCdURGrlmJMZEUP1a8d2XxZYQan0P7w8/at0HfbrcF1xV8cMFq 3P4RDGOm7vuycVu+WEZxzgbie8RoD88YYHOqAdSIg9ieJmtV4DXWt8HZ+qjM86gQ53Oo k3ItN8ItxZgDNZgF5524947hT6wL5T8PlUYM/WQhRc5ux76msnUF7MjoGa7vHvYVmKdM dIhQ== X-Gm-Message-State: AMke39kuso6aDWZPjwwcOpscyvXbQnuF0DpyORlJCzWGwzyy9xMvQC1EcBMDPwhgHdAANg== X-Received: by 10.55.80.136 with SMTP id e130mr16286043qkb.52.1486151349691; Fri, 03 Feb 2017 11:49:09 -0800 (PST) Received: from ?IPv6:2601:152:4400:9b5f:1139:d049:134:71bb? ([2601:152:4400:9b5f:1139:d049:134:71bb]) by smtp.gmail.com with ESMTPSA id i132sm25299903qke.44.2017.02.03.11.49.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 11:49:08 -0800 (PST) To: cfrg@irtf.org References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> <52b3065b-bb20-9b2b-30da-78b09aace9cb@cs.tcd.ie> From: Michael StJohns Message-ID: Date: Fri, 3 Feb 2017 14:49:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <52b3065b-bb20-9b2b-30da-78b09aace9cb@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------EBE595310E1F8F2DED6A1B08" Archived-At: Subject: Re: [Cfrg] erratum for hmac what do we think... X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 19:49:13 -0000 This is a multi-part message in MIME format. --------------EBE595310E1F8F2DED6A1B08 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2/3/2017 1:28 PM, Stephen Farrell wrote: > Thanks all, > > My reading of that thread leads me to conclude there there's consensus > to not verify the erratum on the basis that the threat isn't that > significant and a backwards incompatible change as would be required is > not justified. However, if HMAC were to be updated in a manner that > didn't require backwards compatibility then one would likely consider > this. Hence I've marked this as "hold for document update" I'd like to reiterate that RFC 2104 (or substantially similar text) was a feeder/submission for the FIPS 198-1 standard. Its also old enough that it doesn't have the boilerplate we've since added that would allow for any changes/errata. In that mode, its similar to the original publications of PKCS1, 7 and 12 as informational RFCs and we required a grant of rights to be able to gain change control over them. Instead of making changes here to a document that's been OBEd by first being published as a FIPS (FIPS 198) and second by an update in 2008 (FIPS 198-1), let me suggest that comments should be bundled up and addressed to that document instead. It looks like FIPS 198 is up for review in 2018 and changes might be applied then. Perhaps I'm wrong about this, but we - the IETF - do not own change control over every RFC. Mike > > Cheers, > S. > > On 02/02/17 02:24, Stephen Farrell wrote: >> Hiya, >> >> There's an erratum posted for hmac [1] where I'd be >> interested in what folks here think. >> >> I'm unsure if this is a real problem, esp given that >> there are I guess a lot of implementations. >> >> And even if it were a real problem, I'm not sure we'd >> want that fix. >> >> Opinions welcome... >> >> Thanks, >> S. >> >> [1] >> https://www.rfc-editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&stream_name=&submit_date=&presentation=records >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --------------EBE595310E1F8F2DED6A1B08 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 2/3/2017 1:28 PM, Stephen Farrell wrote:
Thanks all,

My reading of that thread leads me to conclude there there's consensus
to not verify the erratum on the basis that the threat isn't that
significant and a backwards incompatible change as would be required is
not justified. However, if HMAC were to be updated in a manner that
didn't require backwards compatibility then one would likely consider
this. Hence I've marked this as "hold for document update"

I'd like to reiterate that RFC 2104 (or substantially similar text) was a feeder/submission for the FIPS 198-1 standard.  Its also old enough that it doesn't have the boilerplate we've since added that would allow for any changes/errata.  In that mode, its similar to the original publications of PKCS1, 7 and 12 as informational RFCs and we required a grant of rights to be able to gain change control over them. 
 
Instead of making changes here to a document that's been OBEd by first being published as a FIPS  (FIPS 198) and second by an update in 2008 (FIPS 198-1), let me suggest that comments should be bundled up and addressed to that document instead.

It looks like FIPS 198 is up for review in 2018 and changes might be applied then.

Perhaps I'm wrong about this, but we - the IETF - do not own change control over every RFC. 

Mike



Cheers,
S.

On 02/02/17 02:24, Stephen Farrell wrote:

Hiya,

There's an erratum posted for hmac [1] where I'd be
interested in what folks here think.

I'm unsure if this is a real problem, esp given that
there are I guess a lot of implementations.

And even if it were a real problem, I'm not sure we'd
want that fix.

Opinions welcome...

Thanks,
S.

[1]
https://www.rfc-editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&stream_name=&submit_date=&presentation=records



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



      

      

      

      
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


    

    


    

  


--------------EBE595310E1F8F2DED6A1B08--


From nobody Fri Feb  3 12:33:06 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CB12996D for ; Fri,  3 Feb 2017 12:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 IOYta66PtUpv for ; Fri,  3 Feb 2017 12:33:03 -0800 (PST)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C5A129521 for ; Fri,  3 Feb 2017 12:33:02 -0800 (PST)
Received: by mail-yb0-x235.google.com with SMTP id o65so9554192ybo.2 for ; Fri, 03 Feb 2017 12:33:02 -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=UHxNliFWwYgFInpCZxcrGdnXdOJK/HhGCr7xu2y02UI=; b=vWXfvF9spP2hC0jwqexhjeOc9Z2xJ+5U7Uj7Tkpl3N0nPGI20iQMMCNd3dnrLMqnGr GJBzGP9H1SOixpo4kbhr5nrI1qqAIRlqNx9KEUgaAHT/sKY1jIYYsdjQxDBmszMvMOBi HJSTeoM978m+BrILJen0q7eEHs47WpFgk/oD8fnM27MsNqNJls2rI3sJXju/83ZGAcCc YhbytWIhrDyBPlxoVg1DILbKa53BWHHprZ9DUUpoBwvLIRr6BZja/omyPNKlbvahEZZr Z1meM6javBcZz9mi7y596zxmK7NVd1AtmfPUqBx+R+isPBhBFJLPzrvm0tSdbj5VRf8I uG6Q==
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=UHxNliFWwYgFInpCZxcrGdnXdOJK/HhGCr7xu2y02UI=; b=rUi96aqkIHIiE+qgA7v2yFD0Qf6dI3VnllrlDD9ZPtRPoOe/5hoT8Qj2GovNUjIC8M QHs1yMuUWzf3A+WZMJt+/baHFlGX3Yam6D0iLDJ2NxS7ovccLJnFBsCgbeNihWEhBMZT R5r2F24jnY4xatyzvaLhF6XUGAzGJ/I0qzMAM5j0qS3uwgeBJ+oRN4hAOlnhMGSLCA0y pjOmyrip+MMxA+aCcoDEScwLWWX6g/HcbvEtIYeB6aB6LurCQGZGVRBQvjiJSfUghpTF cAM+8qCaWV41yjISQ/DUcWDhpuseREe8BHmAe4IyJfphnrnAErufuthRnF4QNEFkRGFA gyHQ==
X-Gm-Message-State: AIkVDXJPlJTgH+IuzNezXhSDjZNq4tv9f647cQ2qQqqojs/f3DGbSwLxt8OcokTbhNBtPj/Jp7KF8jUPYDUCNA==
X-Received: by 10.37.45.19 with SMTP id t19mr7441754ybt.177.1486153981990; Fri, 03 Feb 2017 12:33:01 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.44.82 with HTTP; Fri, 3 Feb 2017 12:32:31 -0800 (PST)
In-Reply-To: 
References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie>    
From: Hugo Krawczyk 
Date: Fri, 3 Feb 2017 15:32:31 -0500
X-Google-Sender-Auth: p12PHl7nbXUu9VBzjD3dJhdfSx8
Message-ID: 
To: "Dang, Quynh (Fed)" 
Content-Type: multipart/alternative; boundary=94eb2c1b0ba02dae1e0547a630f0
Archived-At: 
Cc: "cfrg@irtf.org" 
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Feb 2017 20:33:05 -0000

--94eb2c1b0ba02dae1e0547a630f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry Quin ;-)

I knew I had to go look at the spelling but was rushing too much... Let's
see how you spell my last name from memory :-)

To the technical point: regardless of what could have been the best
resolution to variable length keys, neither of these considerations
invalidate HMAC as a PRF. Your statement "HMAC is not a PRF" is wrong (and
can add unjustified and unwanted confusion).

As I said, practice constraints us in different ways and produce
sub-optimal results. But in the case of HMAC, really, it is hard to argue
with 20 years of widespread and robust use. If this was a real issue, it
would have come in some significant practical situations but it hasn't. I
see no justification to change the standard after (exactly) 20 years.

Hugo


On Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) 
wrote:

> Hi Hugo,
>
>
> Thank you for calling me a nice name "Quin"!
>
>
> In the HMAC paper, the key length is the IV length (the length of the has=
h
> function output). But in the RFC specification of the HMAC, the key is
> "any" length.
>
>
> I am sure you saw that b bits of  (key||00000....) created the situation
> that many keys produced the same output from the function HMAC for the sa=
me
> message input when the key's length was not a fixed value. If you wanted =
a
> variable key length, you would have had at least 2 options: (1) adding
> encoding for key length and put some restriction on key length so that th=
e
> key and its length encoding did not get longer than the hash function inp=
ut
> block (avoiding one hash function call to improve performance) or (2)
> always hashing the key to produce the exact length L for the key.
>
>
> Quynh.
> ------------------------------
> *From:* Cfrg  on behalf of Hugo Krawczyk <
> hugo@ee.technion.ac.il>
> *Sent:* Thursday, February 2, 2017 11:22:25 AM
> *Cc:* cfrg@irtf.org
> *Subject:* Re: [Cfrg] erratum for hmac what do we think...
>
> =E2=80=8BThese cases of  related key setting=E2=80=8Bs are well known and=
 can indeed be
> seen as a weakness of HMAC. They are part of the engineering trade-offs y=
ou
> have to do for accommodating a design to the real world (and requirements
> from often chaotic IETF discussions). There were things we would have lik=
ed
> to do differently such as avoiding the longer-than-block keys or having
> different keys for the inner and outer hash applications, but that would
> have made the design problematic in different ways. The particular issue =
of
> not disallowing keys longer than a block came at least from an IKE
> requirement. For example, people wanted to use unlimited passphrases, and
> between having people truncate long keys or hash them first, the latter
> seemed the more robust solution. (BTW, the right way to deal with these
> issues using HMAC is to use HKDF.)
>
> Anyway, over the years I heard some rare instances where this led to a
> weakness (I have myself shown such cases) but either these were theoretic=
al
> settings or some forms of bad practice (e.g. making the hash of a secret
> key public). The paper cited earlier by Dan Brown also notes that this
> property makes HMAC with long keys non-indifferentiable from a random
> oracle. Again, not the nicest property but hardly something to worry much
> about in practice. Also, contrary to what Quin said, this property does n=
ot
> contradict HMAC being a PRF (PRFs can have related key weaknesses).
>
> After 20 years of widespread use, it seems to me that (again) the
> engineering considerations (not breaking existing implementations) are mo=
re
> significant than the potential problems of such related key issues.
>
> Hugo
>
>
>
>
>
>
>

--94eb2c1b0ba02dae1e0547a630f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sorry Quin ;-)

I knew I had to go look at the spelling but was rushing too much... Le=
t's see how you spell my last name from memory :-)

=

To the technical point: regardless of what could have been=
 the best resolution to variable length keys, neither of these consideratio=
ns invalidate HMAC as a PRF. Your statement "HMAC is not a PRF" i=
s wrong (and can add unjustified and unwanted confusion).

As I said, practice constraints us in different ways =
and produce sub-optimal results. But in the case of HMAC, really, it is har=
d to argue with 20 years of widespread and robust use. If this was a real i=
ssue, it would have come in some significant practical situations but it ha=
sn't. I see no justification to change the standard after (exactly) 20 =
years.=C2=A0

Hugo

On =
Fri, Feb 3, 2017 at 2:47 PM, Dang, Quynh (Fed) <quynh.dang@nist.gov&=
gt; wrote:










Hi Hugo,







Thank you for calling me a nice name "Quin"!







In the HMAC paper, the key length is the IV length (the length of the ha=
sh function output). But in the RFC specification of the HMAC, the key is &=
quot;any" length.







I am sure you saw that b bits of =C2=A0(key||00000....) created the situ=
ation that many keys produced the same output from the function HMAC for th=
e same message input when the=C2=A0key's length was not a fixed value. =
If you wanted a variable key length, you would
 have had at least 2 options: (1)=C2=A0adding encoding for key length and p=
ut some restriction on key length so that the key and its length encoding d=
id not get longer than the hash function input block (avoiding one hash fun=
ction call to improve performance) or
 (2) always hashing the key to produce the exact length L for the key.=C2=
=A0







Quynh. =C2=A0






From:=
 Cfrg <cfrg-b=
ounces@irtf.org> on behalf of Hugo Krawczyk <hugo@ee.technion.ac.il>

Sent: Thursday, February 2, 2017 11:22:25 AM

Cc: cfrg@irtf.org=


Subject: Re: [Cfrg] erratum for hmac what do we think...

=C2=A0











=E2=80=8BThese cases of =C2=A0related key setting=E2=80=8Bs are well known =
and can indeed be seen as a weakness of HMAC. They are part of the engineer=
ing trade-offs you have to do for accommodating a design to the real world =
(and requirements from often chaotic IETF discussions).
 There were things we would have liked to do differently such as avoiding t=
he longer-than-block keys or having different keys for the inner and outer =
hash applications, but that would have made the design problematic in diffe=
rent ways. The particular issue
 of not disallowing keys longer than a block came at least from an IKE requ=
irement. For example, people wanted to use unlimited passphrases, and betwe=
en having people truncate long keys or hash them first, the latter seemed t=
he more robust solution. (BTW, the
 right way to deal with these issues using HMAC is to use HKDF.)









Anyway, over the years I heard some rare instances where this led to a weak=
ness (I have myself shown such cases) but either these were theoretical set=
tings or some forms of bad practice (e.g. making the hash of a secret key p=
ublic). The paper cited earlier
 by Dan Brown also notes that this property makes HMAC with long keys non-i=
ndifferentiable from a random oracle. Again, not the nicest property but ha=
rdly something to worry much about in practice. Also, contrary to what Quin=
 said, this property does not contradict
 HMAC being a PRF (PRFs can have related key weaknesses).









After 20 years of widespread use, it seems to me that (again) the engineeri=
ng considerations (not breaking existing implementations) are more signific=
ant than the potential problems of such related key issues.=C2=A0









Hugo










































--94eb2c1b0ba02dae1e0547a630f0--


From nobody Fri Feb  3 12:41:28 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714C1294DD for ; Fri,  3 Feb 2017 12:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level: 
X-Spam-Status: No, score=-7.499 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=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 8YU9qNPi6s_9 for ; Fri,  3 Feb 2017 12:41:24 -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 D55CF129474 for ; Fri,  3 Feb 2017 12:41:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78D55BDCC; Fri,  3 Feb 2017 20:41:21 +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 FFOCnLRdYypR; Fri,  3 Feb 2017 20:41:19 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92669BE50; Fri,  3 Feb 2017 20:41:18 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486154479; bh=OneTi0f9mWL17yDwXcvBpDCAn2RIRNgPNFKMpRVfNNQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nsD0npTbk9iXh9ellGU834UXRb2g53Gjb24HmWwaYuTetHVxsmaoG6Y8gjUzRR+L2 +UD1IOTxWtVxYBZBffn9mIpCr7UKOAW40bYIIm9EX/MW98sLrbxHPPlK3QcK8HboF1 QFw3gUkBaCXiIE2wrjEnoH35DlWZs3Y2xUl9gY7U=
To: Michael StJohns , cfrg@irtf.org
References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> <52b3065b-bb20-9b2b-30da-78b09aace9cb@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <40ae1271-71ba-2fd2-c539-eadd993c3a7b@cs.tcd.ie>
Date: Fri, 3 Feb 2017 20:41:17 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208050802090702000203"
Archived-At: 
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Feb 2017 20:41:26 -0000

This is a cryptographically signed message in MIME format.

--------------ms020208050802090702000203
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 03/02/17 19:49, Michael StJohns wrote:
> On 2/3/2017 1:28 PM, Stephen Farrell wrote:
>> Thanks all,
>>
>> My reading of that thread leads me to conclude there there's consensus=

>> to not verify the erratum on the basis that the threat isn't that
>> significant and a backwards incompatible change as would be required i=
s
>> not justified. However, if HMAC were to be updated in a manner that
>> didn't require backwards compatibility then one would likely consider
>> this. Hence I've marked this as "hold for document update"
>=20
> I'd like to reiterate that RFC 2104 (or substantially similar text) was=

> a feeder/submission for the FIPS 198-1 standard.  Its also old enough
> that it doesn't have the boilerplate we've since added that would allow=

> for any changes/errata.  In that mode, its similar to the original
> publications of PKCS1, 7 and 12 as informational RFCs and we required a=

> grant of rights to be able to gain change control over them.
>=20
> Instead of making changes here to a document that's been OBEd by first
> being published as a FIPS  (FIPS 198) and second by an update in 2008
> (FIPS 198-1), let me suggest that comments should be bundled up and
> addressed to that document instead.
>=20
> It looks like FIPS 198 is up for review in 2018 and changes might be
> applied then.
>=20
> Perhaps I'm wrong about this, but we - the IETF - do not own change
> control over every RFC.

I don't think we need worry about process nits like that tbh. The
distinction between a rejected erratum, a hold-for-document-update
erratum and an erratum that's been posted but ignored for 6 months
isn't really of interest:-)

I would worry a bit about it if we approved an erratum that broke
interop, which we could have done, but didn't do, in this case.

And if/when someone wants to revise hmac then I hope they do talk
with the IETF about that. Most, but not all, RFCs that use that do
support alg agility so there could be done potential breakage to
consider.

S.


>=20
> Mike
>=20
>=20
>>
>> Cheers,
>> S.
>>
>> On 02/02/17 02:24, Stephen Farrell wrote:
>>> Hiya,
>>>
>>> There's an erratum posted for hmac [1] where I'd be
>>> interested in what folks here think.
>>>
>>> I'm unsure if this is a real problem, esp given that
>>> there are I guess a lot of implementations.
>>>
>>> And even if it were a real problem, I'm not sure we'd
>>> want that fix.
>>>
>>> Opinions welcome...
>>>
>>> Thanks,
>>> S.
>>>
>>> [1]
>>> https://www.rfc-editor.org/errata_search.php?rfc=3D2104&eid=3D4809&re=
c_status=3D15&area_acronym=3D&errata_type=3D&wg_acronym=3D&submitter_name=
=3D&stream_name=3D&submit_date=3D&presentation=3Drecords
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>=20


--------------ms020208050802090702000203
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
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDMy
MDQxMTdaMC8GCSqGSIb3DQEJBDEiBCBUAvbnpMSv+nYCWfp1fQr0jn5B43lRTaeFGIPY76kd
pzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQANcDxrkeYgYDkTY0CM7nfNY8bRdB6BS44rlJYsy6EDRK5pns+YQDFP
MpZuGe8yxlP8R86J3iY3+LAa4feYX/vX9M81vDogJ1/4+qMRaXvTynjdB4wnMgH1JZ0DLbfi
Rfue0CUrXsYjBIv1xOCh7Q4yUlUjrLLXOUWKBSvSP+RaNJwiZGvBA/1zGcqZCJCLtU8/re3X
gM2ed6CzhmsuUiYc+m5pnVhRj5lfAwigqyOO50LkuuNdkNQd/YTLoUl3TiY3jIpsgjgnczQz
bzde35021RBHoDGRIQhu/ICJmt2eeMck1WF1dTy9VXUQcSMZ+6ALehxch8F5arlFmM3gAsl0
AAAAAAAA
--------------ms020208050802090702000203--


From nobody Sat Feb  4 23:48:05 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC51294C9 for ; Sat,  4 Feb 2017 23:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 HgGf5QIb6mBR for ; Sat,  4 Feb 2017 23:48:03 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C3112945C for ; Sat,  4 Feb 2017 23:48:02 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id 11so29331929qkl.3 for ; Sat, 04 Feb 2017 23:48:02 -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;  bh=8DvZzCCgiZk0shW1SebR+twKG/r+RFkMcbgvEjElcNM=; b=JXdaIT3X2CFM8xtknTd1umVfhCTL+6gMw39Pw7nUsfWOiXLa6iK/OPqMggWJDBGZdm upeFaOOGhrQ7qt1RSBcTw+6Sd+ARDdTnHzXUe4cvVGTB9YTqrbJCejyLCpzC9vN1Dno/ Ij0xDZ0XSePNvgMAqFLNMvAMtp+XyCf13Xt08sauUPCIDkGvlUO8bSyc+rhugviPYUcw kU2WWM3IWBar5i/2WwfJprx2XnUYkpXV945W95SZ8bpBLjmTTklsDoQ+MdmQgjTYL/de 6zGFNUdxe6UVSTdXYt34bn77QzA2qC2K7NzaE3xEYpdjWZ0XEYFD+4vjkvodOj5FdBwO W0xw==
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; bh=8DvZzCCgiZk0shW1SebR+twKG/r+RFkMcbgvEjElcNM=; b=s6cVhAvAmuLE/sXWYztXNMrfNYl7Ms+x4OD3GNNru+vorgHvhZDdiQNMSgCt09G3hH UYRj6V9o2f84uhPbZ7BsMrJrju3sa6HkkhdQ31I+FsVZIMMOHufRnbMuC3VS7O95ZMCU VdiIN52i+vsH8Uw/9tcPV8tZJ57Chmht3h0xbgYkyfdredSaXygW0VtCQt6mswPx0OTL tQmhCJwQte5mmEJiulsHEX/KhFCgm/RXdEp+ZSi1ZUtqZtVKWgUgv980EmlOI9LoI62a SeOBGoeEQjYhfOhEVYlU8Hk+odPilWFzwKBoUl0PMdH93qLDLBH6T0e3q4RYpi18Cero 5shQ==
X-Gm-Message-State: AMke39mlfOCjonAq4LVnEyvW9RmdRZX4dloAEZ0ssVhdvQnx7PwF273tIXyfeV4gasitaSlETahJ7RVQkzxRbg==
X-Received: by 10.55.183.1 with SMTP id h1mr4370809qkf.88.1486280881714; Sat, 04 Feb 2017 23:48:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.31.75 with HTTP; Sat, 4 Feb 2017 23:48:01 -0800 (PST)
In-Reply-To: <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20170116200948.6535.qmail@cr.yp.to> <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie>  <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com>   <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie>   <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi>
From: Tibor Jager 
Date: Sun, 5 Feb 2017 08:48:01 +0100
Message-ID: 
To: cfrg@irtf.org
Content-Type: multipart/alternative; boundary=94eb2c06fa2cfdc4730547c3bb12
Archived-At: 
Subject: Re: [Cfrg] Help with the use of contexts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Feb 2017 07:48:04 -0000

--94eb2c06fa2cfdc4730547c3bb12
Content-Type: text/plain; charset=UTF-8

On 03/02/2017 13:55, Ilari Liusvaara wrote:
> On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
>> On 30 January 2017 at 12:40, Paterson, Kenny 
>> wrote:
>>
>>> So: does anyone else want to offer an opinion on the question of
contexts?
>>>
>>>
>> Contexts are a clean and relatively simple way to prevent cross-protocol
>> attacks, in particular when implemented in an as simple way as proposed
>> by Adam and Dan.
>
> Unfortunately, in practice those are anything but clean and simple.
>
> Yes, the theoretical notion is pretty simple (where (context,message)
> tuple replaces the message in standard notion of signature security).
>
> The biggest practical problem: Backwards compatiblity, the ever-present
> nemsis of security.


We do not have to change old protocols in order to enable domain separation
via contexts in new protocols:

- Old protocols: keep signing messages as before: sig = Sign(sk, m)
- New protocols: sign messages as sig = Sign(sk, ctx||m)

Here, ctx is a "unique" and sufficiently large context string, which even
in presence of an attacker is unlikely to occur in the message m of any
existing protocol. For example, one could use the ASCII string "TLS 1.3 TLS
1.3 TLS 1.3 ...", repeating "TLS 1.3" a suitable number of times. The
symbol || denotes concatenation of bytes, possibly with a NULL-byte as a
separator.

This is how I understand the solution pointed to by Adam and explained by
Dan, and it seems similar in spirit to (but simpler than) what Natanael
described. In particular, it seems not to break backwards compatibility
with existing protocols, but would allow a smooth transition to the use of
contexts to achieve domain separation, and thus help to prevent
cross-protocol attacks.

--94eb2c06fa2cfdc4730547c3bb12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 03/02/2017 13:55, Ilari Liusvaara wrote:
> On Fri=
, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
>> On 30 Ja=
nuary 2017 at 12:40, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
>> wrote:
>>=

>>> So: does anyone else want to offer an opinion on the quest=
ion of contexts?
>>>
>>>
>> Contexts are a=
 clean and relatively simple way to prevent cross-protocol
>> atta=
cks, in particular when implemented in an as simple way as proposed
>=
> by Adam and Dan.
> 
> Unfortunately, in practice those are=
 anything but clean and simple.
> 
> Yes, the theoretical notio=
n is pretty simple (where (context,message)
> tuple replaces the mess=
age in standard notion of signature security).
> 
> The biggest=
 practical problem: Backwards compatiblity, the ever-present
> nemsis=
 of security.


We do not have to change old protocols in order to=
 enable domain separation via contexts in new protocols:

- Old proto=
cols: keep signing messages as before: sig =3D Sign(sk, m)
- New protoco=
ls: sign messages as sig =3D Sign(sk, ctx||m)

Here, ctx is a "u=
nique" and sufficiently large context string, which even in presence o=
f an attacker is unlikely to occur in the message m of any existing protoco=
l. For example, one could use the ASCII string "TLS 1.3 TLS 1.3 TLS 1.=
3 ...", repeating "TLS 1.3" a suitable number of times. The =
symbol || denotes concatenation of bytes, possibly with a NULL-byte as a se=
parator.

This is how I understand the solution pointed to by Adam an=
d explained by Dan, and it seems similar in spirit to (but simpler than) wh=
at Natanael described. In particular, it seems not to break backwards compa=
tibility with existing protocols, but would allow a smooth transition to th=
e use of contexts to achieve domain separation, and thus help to prevent cr=
oss-protocol attacks.


--94eb2c06fa2cfdc4730547c3bb12--


From nobody Sun Feb  5 04:35:45 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DF012954E for ; Sun,  5 Feb 2017 04:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 NZKwrbWmhY5L for ; Sun,  5 Feb 2017 04:35:41 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 753B612706D for ; Sun,  5 Feb 2017 04:35:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A0A501DD61; Sun,  5 Feb 2017 14:35:39 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id xQ9DQ01xXHR5; Sun,  5 Feb 2017 14:35:39 +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 18C8821C; Sun,  5 Feb 2017 14:35:39 +0200 (EET)
Date: Sun, 5 Feb 2017 14:35:37 +0200
From: Ilari Liusvaara 
To: Tibor Jager 
Message-ID: <20170205123537.GA13710@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie>  <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com>   <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie>   <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Help with the use of contexts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Feb 2017 12:35:44 -0000

On Sun, Feb 05, 2017 at 08:48:01AM +0100, Tibor Jager wrote:
> On 03/02/2017 13:55, Ilari Liusvaara wrote:
> > On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> >> On 30 January 2017 at 12:40, Paterson, Kenny 
> >> wrote:
> >>
> >>> So: does anyone else want to offer an opinion on the question of
> contexts?
> >>>
> >>>
> >> Contexts are a clean and relatively simple way to prevent cross-protocol
> >> attacks, in particular when implemented in an as simple way as proposed
> >> by Adam and Dan.
> >
> > Unfortunately, in practice those are anything but clean and simple.
> >
> > Yes, the theoretical notion is pretty simple (where (context,message)
> > tuple replaces the message in standard notion of signature security).
> >
> > The biggest practical problem: Backwards compatiblity, the ever-present
> > nemsis of security.
> 
> We do not have to change old protocols in order to enable domain separation
> via contexts in new protocols:
> 
> - Old protocols: keep signing messages as before: sig = Sign(sk, m)
> - New protocols: sign messages as sig = Sign(sk, ctx||m)

The problem is, that keys need to be separated as well.

If it is just a protocol that stands alone, then one may just declare
its keys to be suitable.

However, if it uses external keys, you are faced with separating these
keys, which means changes to the key format. And if external keys are
critically used in some other way, you need to modify this use as well.

Implication of above for TLS:

- TLS critically relies in practice on X.509 SPKI key format and X.509
  CSRs.
- Reliance on SPKI impiles that new SPKI key type would be needed.
- Reliance on CSR would mean new X.509 signature type would be required.

Yes, the new key type and new signature type are not difficult to
define, but still need to be done for the scheme to give security.

> Here, ctx is a "unique" and sufficiently large context string, which even
> in presence of an attacker is unlikely to occur in the message m of any
> existing protocol. For example, one could use the ASCII string "TLS 1.3 TLS
> 1.3 TLS 1.3 ...", repeating "TLS 1.3" a suitable number of times. The
> symbol || denotes concatenation of bytes, possibly with a NULL-byte as a
> separator.

Fails the basic notion of security of contextualized signatures.

> This is how I understand the solution pointed to by Adam and explained by
> Dan, and it seems similar in spirit to (but simpler than) what Natanael
> described. In particular, it seems not to break backwards compatibility
> with existing protocols, but would allow a smooth transition to the use of
> contexts to achieve domain separation, and thus help to prevent
> cross-protocol attacks.

I don't think they described the catch with this type of construction...


-Ilari


From nobody Mon Feb  6 06:47:18 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EB4129E07 for ; Mon,  6 Feb 2017 06:47:16 -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, RP_MATCHES_RCVD=-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 MKjklSSeRPpV for ; Mon,  6 Feb 2017 06:47:15 -0800 (PST)
Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 A25E7129DFF for ; Mon,  6 Feb 2017 06:47:14 -0800 (PST)
Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v16El7J8082037 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 6 Feb 2017 14:47:07 GMT
Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v16Eks05034876 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 6 Feb 2017 14:46:54 GMT
Received: from host209-14-dynamic.233-95-r.retail.telecomitalia.it (host209-14-dynamic.233-95-r.retail.telecomitalia.it [95.233.14.209]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Mon, 06 Feb 2017 15:47:10 +0100
Date: Mon, 06 Feb 2017 15:47:10 +0100
Message-ID: <20170206154710.Horde.k69tGJlcpnVI1Hbd20_rXdn@webmail.math.unipd.it>
From: riccardo.lazzeretti@math.unipd.it
To: cfrg@irtf.org
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-DCC--Metrics: server5.math.unipd.it 1480; Body=1 Fuz1=1 Fuz2=1
X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker
X-Spam-Warning: SpamAssassin says this -probably- is not SPAM
X-Scanned-By: MIMEDefang 2.78
Archived-At: 
Subject: [Cfrg] [IEEE ATC 2017] Call for Workshop and Special Session Proposal
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Feb 2017 14:47:16 -0000

Dear colleague,

Apologies for multiple postings.

In conjunction with the 14th IEEE International Conference on Advanced  
and Trusted Computing (ATC 2017), we will organize some workshops.
The workshop proposals should be submitted to ieee-atc2017@googlegroups.com

Further information are provided in the ATC Call for Workshop page .
All accepted papers will be included in the ATC 2017 proceedings  
published by IEEE.

Workshop/Special Session proposals should contain following information:
·  The title of the workshop/special session, including both full name  
and abbreviation (for workshop)
·  The objectives, scope, and contributions to the main conference (up  
to 1 page)
·  The short bios of the key organizers and their related experience
·  The procedure for selecting papers, plans for dissemination (e.g.,  
how to advertise and special issues of journals), and the expected  
number of participants
·  A tentative list of program committee members
·  The (tentative) website/URL of the proposed workshop/special session

Important Schedule for ATC Workshops and Special Sessions:
·  Proposal Due: extended to Feb 15, 2017
·  Proposal Notification: extended to Feb 20, 2017
·  Paper Submission, Notification: TBD by individual workshops
·  Final Camera-ready Paper Due: June 10, 2017

Best regards,

Riccardo Lazzeretti
riccardo.lazzeretti@math.unipd.it
Workshop Chair
IEEE Advanced and Trusted Computing (ATC 2017)





From nobody Wed Feb  8 04:15:46 2017
Return-Path: 
X-Original-To: cfrg@ietf.org
Delivered-To: cfrg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5501299FD; Wed,  8 Feb 2017 04:15:45 -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.42.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148655614536.3784.13186379332569390971.idtracker@ietfa.amsl.com>
Date: Wed, 08 Feb 2017 04:15:45 -0800
Archived-At: 
Cc: cfrg@ietf.org
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-pake-reqs-08.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Feb 2017 12:15:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : Requirements for PAKE schemes
        Author          : Joern-Marc Schmidt
	Filename        : draft-irtf-cfrg-pake-reqs-08.txt
	Pages           : 10
	Date            : 2017-02-08

Abstract:
   Password-Authenticated Key Agreement (PAKE) schemes are interactive
   protocols that allow the participants to authenticate each other and
   derive shared cryptographic keys using a (weaker) shared password.
   This document reviews different types of PAKE schemes.  Furthermore,
   it presents requirements and gives recommendations to designers of
   new schemes.  It is a product of the Crypto Forum Research Group
   (CFRG).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-pake-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-pake-reqs-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-pake-reqs-08


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 Wed Feb  8 05:31:31 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4B129A49 for ; Wed,  8 Feb 2017 05:31:30 -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 XHS1n3XjVjJ8 for ; Wed,  8 Feb 2017 05:31:25 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0108.outbound.protection.outlook.com [23.103.201.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E88129A43 for ; Wed,  8 Feb 2017 05:31:25 -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=BjE/tVKaD94vNWUs7xxFUnh5fySguvQiARMXr/PGfVU=; b=hUi0itQKIn1WDPD/C2nfazoewvwHV+cbD7IkUxS+5JwojqqfgZLGSLH7Cm3qbx/5mfL1QRORdz+VfudxHxX2vazAcjbatse1rj9ffcJC0w7PRzzWVPTPheUh+QL0NYWyMK1CQWpGa9runpV7UfnpooknOvQ7dT4Z7vbf9jIODBc=
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.888.16; Wed, 8 Feb 2017 13:31: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.0888.026; Wed, 8 Feb 2017 13:31:22 +0000
From: "Dang, Quynh (Fed)" 
To: Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
Thread-Topic: Aside Re: [CFRG] erratum for hmac ...
Thread-Index: AQHSgWiX/QOHsp+cqk6PweDPw/SKDKFfEXKk
Date: Wed, 8 Feb 2017 13:31:22 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.219.23]
x-ms-office365-filtering-correlation-id: b3060307-9cc4-4572-1d3c-08d45026c61a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:0q/fTSzatPSU69UTVtIVmtJbVex0AxYYMLbq1gRGxl+e8OnbIK2TLZK6eh8pQeaIMtmsuyTFmYKOlgIUWnkc/eUGvXYoyspOegeBTyoAH8al2tiH+futRufqO4Pgt2c0hmkuIo31p9aSrzd7Q37otLjjpnHFQ3i3iAk4IaP+6Sjb5sH2qrGA60YD9UfO2bqKAYuyaH3rzJHZrrkA/x7eVyK2Aj02lustWwV40uGhaRoTZqkraAO7iiahr9llERHG8+oUagpETTnV1uivkE0lYb4artQsYMsYTAj8djtGmneAScEMMFgoNLNJCivke0C/B3bs8hfFdbPs356JL7gh3fef08UymwoBsMnZVmfN8doRPhFi+2zIfQaIfq3l0Z1h1euDK9mlvgi2fOqK/jxoNh/VSXUDLq7kxzfP3ST4xH6aDsbxTTWrmR+I6q0RwN285gWxeADgTuNHj2Xp8jE1wSUGXRqUwTODHZYq9F8CpJdUxAAMF04gKQs9CDGWSTboVoFmNKEeyTdU4LdcIXPsGA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(4659246709749);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(2017020702029)(20170203043)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; 
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(377454003)(189002)(199003)(9686003)(6246003)(2906002)(53546003)(74316002)(81166006)(38730400002)(6436002)(66066001)(229853002)(6506006)(6116002)(3846002)(102836003)(8656002)(101416001)(25786008)(54896002)(8936002)(7736002)(33656002)(8676002)(77096006)(81156014)(3660700001)(53936002)(55016002)(2900100001)(99286003)(7696004)(92566002)(189998001)(68736007)(76176999)(6606003)(54356999)(4326007)(3280700002)(5660300001)(122556002)(106116001)(19627405001)(105586002)(97736004)(106356001)(86362001)(2950100002)(50986999)(345774005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.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_CY4PR09MB1464F9936D5C07DF16D29403F3420CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 13:31:22.7120 (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: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Feb 2017 13:31:30 -0000

--_000_CY4PR09MB1464F9936D5C07DF16D29403F3420CY4PR09MB1464namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Randal, Michael and many others,


Thank you for your suggestions.


Kenny,


Thank you for your discussion email.


We are thinking about what would be the best option for HMAC.  Some technic=
al possibilities are below.


1) Don't change the HMAC spec.

Ask a HMAC key always to have a fixed length such as HMAC-SHA256 having 256=
-bit key. Which means that all protocols using HMAC-SHA256 use 256-bit keys=
.

If each protocol uses a different key length, then the issue would still ex=
ist across protocols. I don't know if this is a practical security problem,=
 but it seems like a problem that should be avoided.

Should ask HMAC keys to be processed/produced by a hash function or another=
 PRF always.

This option does not break interoperability of  the current HMAC implementa=
tions.

2) Change the HMAC Spec.

a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198.
b) Use a hash-based KDF (not HKDF) to produce B bits from the key, then go =
to step 4 in the FIPS. (bad for performance).
c) Require key < B, then do multi-rate padding 10* to make the key B bits, =
then go to step 4 in the FIPS. (good for performance).

We recommend the use of KMAC in SP 800-185. KMAC's security is solid and pr=
oven, and it has great performance. Code to implement KMAC can be reused to=
 implement many other Keccak-derived symmetric-key crypto functions.

Regards,
Quynh.
________________________________
From: Randal Atkinson 
Sent: Tuesday, February 7, 2017 12:34 PM
To: Dang, Quynh (Fed)
Cc: Randal Atkinson
Subject: Aside Re: [CFRG] erratum for hmac ...


One option available to NIST would be for NIST to open comments
on updating FIPS 198-1, even if opening comments on that now/soon
would be earlier than NIST ordinarily would do so.

Given how long it takes to move from an approved FIPS revision
to widespread US Government deployment, if data exists from
Kenny P and/or others that merits an update, then starting sooner
would not be a bad thing for the USG.

Cheers,

Ran Atkinson

--------------------------------
Randal Atkinson, PhD
Cheltenham Research for NRL 5520
randal.atkinson.ctr@nrl.navy.mil


--_000_CY4PR09MB1464F9936D5C07DF16D29403F3420CY4PR09MB1464namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Randal, Michael and many others,







Thank you for your suggestions.







Kenny,







Thank you for your discussion email.







We are thinking about what would be the best option for HMAC.  Some=
 technical possibilities are below. 







1) Don't change the HMAC spec.





Ask a HMAC key always to have a fixed length such as HMAC-SH=
A256 having 256-bit key. Which means that all protocols using HMAC-SHA256 u=
se 256-bit keys. 







If each protocol uses a different key length, then the issue would&nbs=
p;still exist across protocols. I don't know if this is a practical securit=
y problem, but it seems like a problem that should be avoided. 






Should ask HMAC keys to be processed/produced by a hash function or an=
other PRF always. 



This option does not break interoperability of  the current HMAC imple=
mentations.



2) Change the HMAC Spec. 



a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198. 

b) Use a hash-based KDF (not HKDF) to produce B bits from the key, the=
n go to step 4 in the FIPS. (bad for performance). 

c) Require key < B, then do multi-rate padding 10* to make the key B bit=
s, then go to step 4 in the FIPS. (good for performance).







We recommend the use of KMAC in SP 800-185. KMAC's security is solid a=
nd proven, and it has great performance. Code to implement KMAC can be reus=
ed to implement many other Keccak-derived symmetric-key crypto functio=
ns.







Regards,


Quynh. 








From: Randal Atkinson <=
;randal.atkinson.ctr@nrl.navy.mil>

Sent: Tuesday, February 7, 2017 12:34 PM

To: Dang, Quynh (Fed)

Cc: Randal Atkinson

Subject: Aside Re: [CFRG] erratum for hmac ...

 









One option available to NIST would be for NIST to open comments 

on updating FIPS 198-1, even if opening comments on that now/soon 

would be earlier than NIST ordinarily would do so.



Given how long it takes to move from an approved FIPS revision

to widespread US Government deployment, if data exists from 

Kenny P and/or others that merits an update, then starting sooner

would not be a bad thing for the USG.



Cheers,



Ran Atkinson



--------------------------------

Randal Atkinson, PhD

Cheltenham Research for NRL 5520

randal.atkinson.ctr@nrl.navy.mil        =













--_000_CY4PR09MB1464F9936D5C07DF16D29403F3420CY4PR09MB1464namp_--


From nobody Thu Feb  9 21:07:42 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0A0129EEF for ; Thu,  9 Feb 2017 21:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 cGkEiPzo0faB for ; Thu,  9 Feb 2017 21:07:39 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30DC129EEA for ; Thu,  9 Feb 2017 21:07:38 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id k15so25022259qtg.3 for ; Thu, 09 Feb 2017 21:07:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=sF3S+goNt9Bc/mv7lBJdR9RN0+hom/uJoQlvQeZaObU=; b=Yu944ksgP4BNAUzg5nZz4QG0MKpvHkSfZzhaIPdr5piLeK6sVTEHFPBTUDTBB4CVP8 B4qHoXskiWVR7t7qyZ1gchheCRdOVkPakteuWO1ekDoiJoZG2gyi5IqAZU7/Wb6gDfah bEODu0HySXN0xubhCKTjw5egw6uJcjcq+q+C8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=sF3S+goNt9Bc/mv7lBJdR9RN0+hom/uJoQlvQeZaObU=; b=tpzO9vFpOVeYVPKgssUXH0gG3q5pJxCxQrjM/KXl7FBtxIOseZuXbkKQyu5EnoTgFE bCqQXkKNlRmHoYH4tVjs4RObeyJBpDRMMqBblCcyHE0jo7m9nra97yBgT8b8oqBZ6QlY 7Kexq1VphcD46s7h9BXGCqJj7mPL92K9cPaoCXjcjpsoIgib/TXG3vF+FQcZdyYaM4oa DGkHeUF1/fh/U3LSVDpluxwCMrn6UGvALYFKPZ762BMrQLDphFpaGG4UcxCHYuGQJKQH dAQppYGAdt272gKThNqj3z8YKwpl5TMIqaquNLQC9D3hg7mLx0BTMF+zOVursvddfqbT 3SGA==
X-Gm-Message-State: AMke39kEKSWJov6UWuX3AnwaFcVnw24GaWFaX6I9cktGhYYYoY1E8kDOO9omCnShXSSDRg==
X-Received: by 10.200.47.46 with SMTP id j43mr6313569qta.178.1486703257918; Thu, 09 Feb 2017 21:07:37 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m143sm550421qke.18.2017.02.09.21.07.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Feb 2017 21:07:36 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Feb 2017 00:07:35 -0500
Message-Id: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
To: "" 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: IRTF CFRG 
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 05:07:40 -0000

All,

We=E2=80=99ve got two outstanding PRs that propose changes to =
draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D.  =
As it relates to rekeying, these limits have been discussed a couple of =
times and we need to resolve once and for all whether the TLS WG wants =
to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  =
Note that unless there=E2=80=99s clear consensus to change the text will =
remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769=


From nobody Thu Feb  9 21:19:15 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E431129FA5 for ; Thu,  9 Feb 2017 21:19:09 -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=unavailable 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 YPz2nVYmVVSQ for ; Thu,  9 Feb 2017 21:19:06 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82411129F07 for ; Thu,  9 Feb 2017 21:19:06 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id w20so25114868qtb.1 for ; Thu, 09 Feb 2017 21:19:06 -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=31zLHJdGvGGCK8k+YPPH34KWJ/Sz+jwocUlewf0+kBw=; b=TZa67SiCkYBBoV0c4tc4RRWy30M6Z0leN6kNFwWfPqzdQ6xbdtckbe5l9nY5vmbFn9 m112+h/QDgK6Ww/MRhrvgkeejE6kDTcLimpA0KHuWQQZhJGz769Vp5DVZn5NTAyEHkO3 f0LAiKuheF2HFbJAVDx+qMfNarm8kvi09O1bPyMArfanDnR8R2vYgIsiNEacOI5gfivz yWtkHKKjfYHqM4ZOT07I+K46Ou+JpaOtDbUoTRYJvgaRIT9k81HilHrxU0hTCbobXY8U HKdHY4SoD7m2+IYSg+2Ue+EkzcTLctw/sfwxKhKq3zLULyOWAyS0Lek0l/nwmEilPcok AopQ==
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=31zLHJdGvGGCK8k+YPPH34KWJ/Sz+jwocUlewf0+kBw=; b=YTvr00obibpy21SwdI7CwOd59JJOpNskLRxaAEncoHimW7jreE/wOQdQBI+Obuhlac G1kQ37BkZhpcDA1/E0vNpqM0mSi/ID+dpHaAXZ4MKq0lGwOLDM3ZU6MndAV19od0SGPv Hd/RMRWIdaqAzcIdzhdP7r4erliXPFrVH60ql2GUgYNj/wpKzzt4VM6BIkby+vuMIfta EEcGud801gYf0emE0lBzaZOmUzmXv16tZTGtwCwCdkRecEQyEAn+9ovJ+wm4OOMTsq56 3UtvNoXAb9C5g88rOcUpVtzb8zpnvbJ/FKFua+ljQW153BcbikwBh/dxBdaSy0l4muk1 9t8Q==
X-Gm-Message-State: AMke39miT0QqBd6PKg9tQz/tsVBRNM/Em+m/m5d9YGb6B/T/Aqc3TuSZ1TZ5M51TmPa75woNkyALO6XuH8vkGA==
X-Received: by 10.200.37.183 with SMTP id e52mr6848789qte.166.1486703945651; Thu, 09 Feb 2017 21:19:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.132.102 with HTTP; Thu, 9 Feb 2017 21:19:05 -0800 (PST)
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
From: "Stanislav V. Smyshlyaev" 
Date: Fri, 10 Feb 2017 08:19:05 +0300
Message-ID: 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=001a1141fcbc91383d0548263c60
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 05:19:09 -0000

--001a1141fcbc91383d0548263c60
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear Sean, dear all,

I find the existing limits quite reasonable and would prefer that we'll
stay conservative here, so I'd prefer option a) go with the existing text.


Best regards,
Stanislav Smyshlyaev


2017-02-10 8:07 GMT+03:00 Sean Turner :

> All,
>
> We=E2=80=99ve got two outstanding PRs that propose changes to draft-ietf-=
tls-tls13
> Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D.  As it relates to reke=
ying, these limits
> have been discussed a couple of times and we need to resolve once and for
> all whether the TLS WG wants to:
>
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]
>
> Please indicate you preference to the TLS mailing list before Feb 17.
> Note that unless there=E2=80=99s clear consensus to change the text will =
remain as
> is (i.e., option a).
>
> J&S
>
> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
> [1] https://github.com/tlswg/tls13-spec/pull/765
> [2] https://github.com/tlswg/tls13-spec/pull/769
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

--001a1141fcbc91383d0548263c60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Dear Sean, dear all,

=

I find the existing limits quite reasonable and would prefer that we&#=
39;ll stay conservative here, so I'd prefer option a) go with the exist=
ing text.


Best regards,
Stanislav Smyshlyaev
=




2017-02-10 8:07 GMT+03:00 Sean Turner <sean@sn=
3rd.com>:
https://tlswg.github.io/tls13-spec/#rfc.=
section.5.5

[1] https://github.com/tlswg/tls13-spec/pull/765

[2] https://github.com/tlswg/tls13-spec/pull/769

_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg





--001a1141fcbc91383d0548263c60--


From nobody Thu Feb  9 21:27:31 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1A129F16 for ; Thu,  9 Feb 2017 21:27:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCXXxNgCHe6b for ; Thu,  9 Feb 2017 21:27:28 -0800 (PST)
Received: from nm15-vm10.access.bullet.mail.bf1.yahoo.com (nm15-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.41]) (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 069AA129F0C for ; Thu,  9 Feb 2017 21:27:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1486704446; bh=ahiSviiTY3dYpbYeK/pWZvI1fex5uBzIS5nwVqZn7ls=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=DeVMUdncy40eCs9Twy5/5mcZHVIHjeHoexLHm3Lx3+amdK4UNeAwSR95Tq02o85uVVKZPv9vXaReELnki5NBKUFa9SBbCHqCOen7M13T2Ltn/luJVl1SJ/paT8aQgZ+0a/a/1lXUc0aSJlZJ+LXnv9xvHv6ASWdWN0DaZSQY8RdKVdulVYAsSQltHYXXi+/fb4y0UzpsFrhj1s8heCcqY5v6U8V5Ij5N7IjTirUobRpukhBz8xG8P8vMZE/51qX6hHNrj/fQ3rukRJyskLkFpat6BHZ0vXwugX3FZ7h7qSXIqlIt8kh9xDZMlv6esU8R3HMdMPZnukzGL+UPOgg6lQ==
Received: from [66.196.81.166] by nm15.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 05:27:26 -0000
Received: from [98.138.226.243] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 05:27:26 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 10 Feb 2017 05:27:26 -0000
X-Yahoo-Newman-Id: 99243.61195.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: YB6tGzkVM1n3wWhgdxB3K3t.cIUYsQqYJI.6BywoK01Bdkt hsyUcS3abrIoSGWs3jPXllRuzeJnkLSzimOp.PudHd.nz302VbFcs4k0XgBu ejSiKEitY63oxINdECKUMRYgooAo9Ai1K1Iz3LjDuY47r_RppMFy0LAoYz7l Z7gjcde1IHTFdcRSc.fmdvlrICtbi.VDyUYiHURBLGCkpKl.juOP3fXSQjEZ g8X_14sWBuGJczRM3vlpu6O6pjfW7XwWWQv0SOitq4G9dIPck6fnazi5Prsp cpykR.NypJizluTkRCrbRgc_nxoDVsVhlC4AF2NGc56TQIiOuKU2qIbpBqle mM_DkIxDpijRArtlupQkKfV5PpxDFzsZh81NROprSjpCnntbqyED1GRR71nT L5ILE_dK8A81XM71D9CDMGTUE1DsVqeU0jqR9O9nKvswX4o70T0RLkKjrsSd BSTe.lz4BzZRMinpJxgRqFBdxSD79qifdkiQgmt6utuZiOV_FOhoOJH7KcMd qBIepBXZnQXL1CyqYj8JKnmvCc5x01ZZroAvBodRld7DiAlTQPZ2KyPZaO8D .ZaI.hgThcw--
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: "Dang, Quynh (Fed)" , Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
References:  
From: David Jacobson 
Message-ID: <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>
Date: Thu, 9 Feb 2017 21:27:24 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C93E1F78F37C18C5D3440E02"
Archived-At: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 05:27:30 -0000

This is a multi-part message in MIME format.
--------------C93E1F78F37C18C5D3440E02
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

See interleaved comment.

On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:
>
> Randal, Michael and many others,
>
>
> Thank you for your suggestions.
>
>
> Kenny,
>
>
> Thank you for your discussion email.
>
>
> We are thinking about what would be the best option for HMAC.  Some 
> technical possibilities are below.
>
>
> 1) Don't change the HMAC spec.
>
>
> Ask a HMAC key always to have a fixed length such as HMAC-SHA256 
> having 256-bit key. Which means that all protocols using HMAC-SHA256 
> use 256-bit keys.
>
> If each protocol uses a different key length, then the issue 
> would still exist across protocols. I don't know if this is a 
> practical security problem, but it seems like a problem that should be 
> avoided.
>
> Should ask HMAC keys to be processed/produced by a hash function or 
> another PRF always.

I don't see the need or even desirability for this, assuming you ask 
each protocol to use a fixed (for that protocol) key length.  (That was 
the line above.)

For an attacker to find two messages with the same HMAC, not knowing the 
key, he would have to find a collision in the first stage, not knowing 
the first block.  And if you add an extra hash, you are only making it 
easier.  He has to get a collision in the pre-hash, where he knows 
everything.

    --David Jacobson
>
> This option does not break interoperability of  the current HMAC 
> implementations.
>
> 2) Change the HMAC Spec.
>
> a) Always hash the key regardless of its length, then perform step 3 
> in FIPS 198.
> b) Use a hash-based KDF (not HKDF) to produce B bits from the key, 
> then go to step 4 in the FIPS. (bad for performance).
> c) Require key < B, then do multi-rate padding 10* to make the key B 
> bits, then go to step 4 in the FIPS. (good for performance).
>
> We recommend the use of KMAC in SP 800-185. KMAC's security is solid 
> and proven, and it has great performance. Code to implement KMAC can 
> be reused to implement many other Keccak-derived symmetric-key crypto 
> functions.
>
> Regards,
> Quynh.
> ------------------------------------------------------------------------
> *From:* Randal Atkinson 
> *Sent:* Tuesday, February 7, 2017 12:34 PM
> *To:* Dang, Quynh (Fed)
> *Cc:* Randal Atkinson
> *Subject:* Aside Re: [CFRG] erratum for hmac ...
>
> One option available to NIST would be for NIST to open comments
> on updating FIPS 198-1, even if opening comments on that now/soon
> would be earlier than NIST ordinarily would do so.
>
> Given how long it takes to move from an approved FIPS revision
> to widespread US Government deployment, if data exists from
> Kenny P and/or others that merits an update, then starting sooner
> would not be a bad thing for the USG.
>
> Cheers,
>
> Ran Atkinson
>
> --------------------------------
> Randal Atkinson, PhD
> Cheltenham Research for NRL 5520
> randal.atkinson.ctr@nrl.navy.mil
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg



--------------C93E1F78F37C18C5D3440E02
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
See interleaved comment.

      

      On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:

    

    

      
      
      

        
Randal, Michael and many others,

        


        

        
Thank you for your suggestions.

        


        

        
Kenny,

        


        

        
Thank you for your discussion email.

        


        

        
We are thinking about what would be the best option for HMAC.
           Some technical possibilities are below. 

        


        

        
1) Don't change the HMAC spec.

        

        


          Ask a HMAC key always to have a fixed length such as
          HMAC-SHA256 having 256-bit key. Which means that all protocols
          using HMAC-SHA256 use 256-bit keys. 

        


        

        
If each protocol uses a different key length, then the
          issue would still exist across protocols. I don't know if this
          is a practical security problem, but it seems like a problem
          that should be avoided. 

          

        

        
Should ask HMAC keys to be processed/produced by a hash
          function or another PRF always. 

        

      

    

    

    I don't see the need or even desirability for this, assuming you ask
    each protocol to use a fixed (for that protocol) key length.  (That
    was the line above.)

    

    For an attacker to find two messages with the same HMAC, not knowing
    the key, he would have to find a collision in the first stage, not
    knowing the first block.  And if you add an extra hash, you are only
    making it easier.  He has to get a collision in the pre-hash, where
    he knows everything.

    

       --David Jacobson

    

      

        

          

          This option does not break interoperability of  the current
          HMAC implementations.

          

          2) Change the HMAC Spec. 

          

          a) Always hash the key regardless of its length, then perform
          step 3 in FIPS 198. 

          b) Use a hash-based KDF (not HKDF) to produce B bits from the
          key, then go to step 4 in the FIPS. (bad for performance). 

          c) Require key < B, then do multi-rate padding 10* to make
          the key B bits, then go to step 4 in the FIPS. (good for
          performance).

        


        

        
We recommend the use of KMAC in SP 800-185. KMAC's security
          is solid and proven, and it has great performance. Code to
          implement KMAC can be reused to implement many other
          Keccak-derived symmetric-key crypto functions.

        


        

        
Regards,

        
Quynh. 

        

          

            

            
From: Randal Atkinson
                <randal.atkinson.ctr@nrl.navy.mil>

                Sent: Tuesday, February 7, 2017 12:34 PM

                To: Dang, Quynh (Fed)

                Cc: Randal Atkinson

                Subject: Aside Re: [CFRG] erratum for hmac ...
              
 

            

          

          
              


                One option available to NIST would be for NIST to open
                comments 

                on updating FIPS 198-1, even if opening comments on that
                now/soon 

                would be earlier than NIST ordinarily would do so.

                

                Given how long it takes to move from an approved FIPS
                revision

                to widespread US Government deployment, if data exists
                from 

                Kenny P and/or others that merits an update, then
                starting sooner

                would not be a bad thing for the USG.

                

                Cheers,

                

                Ran Atkinson

                

                --------------------------------

                Randal Atkinson, PhD

                Cheltenham Research for NRL 5520

                randal.atkinson.ctr@nrl.navy.mil        

                

              

            

      

      

      

      

      
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


    

    


    

  


--------------C93E1F78F37C18C5D3440E02--


From nobody Thu Feb  9 21:38:38 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6230D129FB1 for ; Thu,  9 Feb 2017 21:38:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zSIlGAXeuF4 for ; Thu,  9 Feb 2017 21:38:35 -0800 (PST)
Received: from nm27-vm10.access.bullet.mail.bf1.yahoo.com (nm27-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.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 A6FB8129FB0 for ; Thu,  9 Feb 2017 21:38:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1486705113; bh=mmHjru3JM2KSSxOdCZUdeIsUNErdoDBlNbzIpUbBZQg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=e6BurRQ0uCXW1NO3DqvaCA5nCyqKGragp21gyOwD8pbakDj5TvA+0A/sRIFtCPcfdq/qZsypI859+Gm6obHI6Dpy6AKnUNAgIKU+HYVIMTa4Kq/lz9P4n45OY12oMe/xOw+orNfZW7pmRGIiKtXNVcvuPnmre2hzB63e2ju6/c8YLmm0ElNxErH12tEh7vOl9Dzc+n0IDuuGaM5OhbLLkVvB9wqJnDosLNW4Nb7186Kyu+hsmx88yqsmJC7SvOZWj5CcOZs369D8Ko2X2N+Tx5XicfCkk8d+gKKereioZYp4csRag7W1WZlwIFJ0e19SxbJyqv4LqKF9aAPi7gCcDQ==
Received: from [66.196.81.157] by nm27.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 05:38:33 -0000
Received: from [98.138.104.99] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 05:38:33 -0000
Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 10 Feb 2017 05:38:33 -0000
X-Yahoo-Newman-Id: 707821.72567.bm@smtp119.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: LYsX.aIVM1mR255esveyN4EphA5ddEgt5IPGcSvc.Df1VlE BuWKRtAma72MYBod4FDzpMKagMtgkIy3Gs3u_WgU7ahtdtJoceiZbobunRvX GjLqok8_DP7wj9wk5zR9OVbA4EHcrFZL_YE5aerhJgv8G6Ui5xvKoLdmHl_s A6JEZXAzmqWfyU3I540zoGlGw64vL4WM6MBeiqlz3ug5qLc8NXBpozwpyyfR JC8ibN77SKE0IZMVRsusL_fLyvzuEmAoNBocNjLh7qdwVPdG0hkF_zPVLpBz mXAsqZXaZeAO16C6Y11wLUd1e_Gr5lUivy_2ijFakj.uFHrho4g5A0a.oeyi 4_fMGQDOv059_yTEc9M.o.Yrl0V7Exv1jfIGLZ.u.uXlzrqldA15s9bgUFeI psrkUizEeYplFzjx1Y3B.4FwBr_o2WmGPhcu5fBqhSkeaBbngGH6toxeI5Qy axIJtAjbO12taNVyGN3A2EVMeCrPJxvFUVnGrvMxWlmlnpQZy06l8nJRPIYm 2XKDW09CPPJO1QvcHS5uiK0LkV4s6b.44d.x6GlWJel073P4nH8tJLs3i79g nn1FbpSKtxg--
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: "Dang, Quynh (Fed)" , Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
References:   <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>
From: David Jacobson 
Message-ID: <9a95bf47-9fea-6a38-5bdf-d88f10b36323@sbcglobal.net>
Date: Thu, 9 Feb 2017 21:38:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>
Content-Type: multipart/alternative; boundary="------------93BDA7C57AD9161DF4494782"
Archived-At: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 05:38:36 -0000

This is a multi-part message in MIME format.
--------------93BDA7C57AD9161DF4494782
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Oops.  I made a mistake.  It is the key that is being hashed not the 
message.

But I still don't see where it helps.  An attacker does not choose the key.

Now there was this discussion about related keys they could generate the 
same output.  But if we fix the key to some protocol-specific value, 
then there is no easy way to get related keys that give the same 
output.  You would need to find a sort of double-collision where the 
hash internal state after the first block is the same for keyA ^ IPAD 
and keyB ^ IPAD and the internal state after the first block is the same 
for keyA ^ OPAD and keyB ^ OPAD.  This seems much harder than just 
finding a collision.

    --David

On 2/9/17 9:27 PM, David Jacobson wrote:
> See interleaved comment.
>
> On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:
>>
>> Randal, Michael and many others,
>>
>>
>> Thank you for your suggestions.
>>
>>
>> Kenny,
>>
>>
>> Thank you for your discussion email.
>>
>>
>> We are thinking about what would be the best option for HMAC.  Some 
>> technical possibilities are below.
>>
>>
>> 1) Don't change the HMAC spec.
>>
>>
>> Ask a HMAC key always to have a fixed length such as HMAC-SHA256 
>> having 256-bit key. Which means that all protocols using HMAC-SHA256 
>> use 256-bit keys.
>>
>> If each protocol uses a different key length, then the issue 
>> would still exist across protocols. I don't know if this is a 
>> practical security problem, but it seems like a problem that should 
>> be avoided.
>>
>> Should ask HMAC keys to be processed/produced by a hash function or 
>> another PRF always.
>
> I don't see the need or even desirability for this, assuming you ask 
> each protocol to use a fixed (for that protocol) key length. (That was 
> the line above.)
>
> For an attacker to find two messages with the same HMAC, not knowing 
> the key, he would have to find a collision in the first stage, not 
> knowing the first block.  And if you add an extra hash, you are only 
> making it easier.  He has to get a collision in the pre-hash, where he 
> knows everything.
>
>    --David Jacobson
>>
>> This option does not break interoperability of  the current HMAC 
>> implementations.
>>
>> 2) Change the HMAC Spec.
>>
>> a) Always hash the key regardless of its length, then perform step 3 
>> in FIPS 198.
>> b) Use a hash-based KDF (not HKDF) to produce B bits from the key, 
>> then go to step 4 in the FIPS. (bad for performance).
>> c) Require key < B, then do multi-rate padding 10* to make the key B 
>> bits, then go to step 4 in the FIPS. (good for performance).
>>
>> We recommend the use of KMAC in SP 800-185. KMAC's security is solid 
>> and proven, and it has great performance. Code to implement KMAC can 
>> be reused to implement many other Keccak-derived symmetric-key crypto 
>> functions.
>>
>> Regards,
>> Quynh.
>> ------------------------------------------------------------------------
>> *From:* Randal Atkinson 
>> *Sent:* Tuesday, February 7, 2017 12:34 PM
>> *To:* Dang, Quynh (Fed)
>> *Cc:* Randal Atkinson
>> *Subject:* Aside Re: [CFRG] erratum for hmac ...
>>
>> One option available to NIST would be for NIST to open comments
>> on updating FIPS 198-1, even if opening comments on that now/soon
>> would be earlier than NIST ordinarily would do so.
>>
>> Given how long it takes to move from an approved FIPS revision
>> to widespread US Government deployment, if data exists from
>> Kenny P and/or others that merits an update, then starting sooner
>> would not be a bad thing for the USG.
>>
>> Cheers,
>>
>> Ran Atkinson
>>
>> --------------------------------
>> Randal Atkinson, PhD
>> Cheltenham Research for NRL 5520
>> randal.atkinson.ctr@nrl.navy.mil
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>


--------------93BDA7C57AD9161DF4494782
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Oops.  I made a mistake.  It is the key
      that is being hashed not the message.  

      

      But I still don't see where it helps.  An attacker does not choose
      the key.  

      

      Now there was this discussion about related keys they could
      generate the same output.  But if we fix the key to some
      protocol-specific value, then there is no easy way to get related
      keys that give the same output.  You would need to find a sort of
      double-collision where the hash internal state after the first
      block is the same for keyA ^ IPAD and keyB ^ IPAD and the internal
      state after the first block is the same for keyA ^ OPAD and keyB ^
      OPAD.  This seems much harder than just finding a collision.

      

         --David

      

      On 2/9/17 9:27 PM, David Jacobson wrote:

    

    

      
      
See interleaved comment.

        

        On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:

      

      

        
        
        

          
Randal, Michael and many others,

          


          

          
Thank you for your suggestions.

          


          

          
Kenny,

          


          

          
Thank you for your discussion email.

          


          

          
We are thinking about what would be the best option for
            HMAC.  Some technical possibilities are below. 

          


          

          
1) Don't change the HMAC
              spec.

          

          


            Ask a HMAC key always to have a fixed length such as
            HMAC-SHA256 having 256-bit key. Which means that all
            protocols using HMAC-SHA256 use 256-bit keys. 

          


          

          
If each protocol uses a different key length, then the
            issue would still exist across protocols. I don't know if
            this is a practical security problem, but it seems like a
            problem that should be avoided. 

            

          

          
Should ask HMAC keys to be processed/produced by a hash
            function or another PRF always. 

          

        

      

      

      I don't see the need or even desirability for this, assuming you
      ask each protocol to use a fixed (for that protocol) key length. 
      (That was the line above.)

      

      For an attacker to find two messages with the same HMAC, not
      knowing the key, he would have to find a collision in the first
      stage, not knowing the first block.  And if you add an extra hash,
      you are only making it easier.  He has to get a collision in the
      pre-hash, where he knows everything.

      

         --David Jacobson

      

        

          
 

            This option does not break interoperability of  the current
            HMAC implementations.

            

            2) Change the HMAC Spec. 

            

            a) Always hash the key regardless of its length, then
            perform step 3 in FIPS 198. 

            b) Use a hash-based KDF (not HKDF) to produce B bits from
            the key, then go to step 4 in the FIPS. (bad for
            performance). 

            c) Require key < B, then do multi-rate padding 10* to
            make the key B bits, then go to step 4 in the FIPS. (good
            for performance).

          


          

          
We recommend the use of KMAC in SP 800-185. KMAC's
            security is solid and proven, and it has great performance.
            Code to implement KMAC can be reused to implement many other
            Keccak-derived symmetric-key crypto functions.

          


          

          
Regards,

          
Quynh. 

          

            

              

              
From: Randal Atkinson <randal.atkinson.ctr@nrl.navy.mil>

                  Sent: Tuesday, February 7, 2017 12:34 PM

                  To: Dang, Quynh (Fed)

                  Cc: Randal Atkinson

                  Subject: Aside Re: [CFRG] erratum for hmac ...
                
 

              

            

            
                


                  One option available to NIST would be for NIST to open
                  comments 

                  on updating FIPS 198-1, even if opening comments on
                  that now/soon 

                  would be earlier than NIST ordinarily would do so.

                  

                  Given how long it takes to move from an approved FIPS
                  revision

                  to widespread US Government deployment, if data exists
                  from 

                  Kenny P and/or others that merits an update, then
                  starting sooner

                  would not be a bad thing for the USG.

                  

                  Cheers,

                  

                  Ran Atkinson

                  

                  --------------------------------

                  Randal Atkinson, PhD

                  Cheltenham Research for NRL 5520

                  randal.atkinson.ctr@nrl.navy.mil       
                  

                  

                

              

        

        

        

        

        
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


      

      


      

    

    


    

  


--------------93BDA7C57AD9161DF4494782--


From nobody Thu Feb  9 21:45:02 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C167F129FD6 for ; Thu,  9 Feb 2017 21:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmCrWS4ZXoy6 for ; Thu,  9 Feb 2017 21:44:59 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B014B129FD2 for ; Thu,  9 Feb 2017 21:44:59 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id s186so28828569qkb.1 for ; Thu, 09 Feb 2017 21:44:59 -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=pEtd0fEv8U6PQOY3b8h8LYIS+jtgiM/ZK3qdRssSQA8=; b=DW9veGmHWC8l6IejdO54hCUeH9G38cZW7v1+zMQm7avCsPea5+6KGcH9ghraHy+Kky eFVKQL0hc4MwOyJ95D77ofu6N773JDLpzdM4ZHM1mDZk4MT2on48nwTpM2hd/qv/Gbyc ksRvFhVeP6/h5CXZsLETM/Im5W8SRMpPEXKFGpdqUV5LRDkIlj+64tFOHKXfdBRxMAdl zsfs9FgCYcR6uEQ2HXqhrZQR6ptGf5HmBOXewG1IESNLMVJl6IrQIqwiXSAI29TVQF6m FuUVVaixpqhpfkwQ888tPnZIo9RR/vbHCv+TP52q/GoPj6uwEi0MQkVtwck1dE5XEfJD pwkw==
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=pEtd0fEv8U6PQOY3b8h8LYIS+jtgiM/ZK3qdRssSQA8=; b=tbqHT70dMSyXKNQ5HMx37bSVQrl7gUK6nADuKP6+NGb2yhIbTn/BGuhfSqXKxF182A rNu2Lyn4WEtJ/t/BRmK1qa9oqiXM7/a50I8pkGiQ0ep7IRbKMF7/s8ZVd6nEEntgssGh B/0HfA8Rq8KKrPxcA7bFvPWFAkKhMtTW4pcyV++dTrGPqfRpseadjyJjBzEW1Hx4IX47 a0v7jFUeTo3svBU9xoH3phoxzF9/qOkPAnZ9Y+QZhKfGt1ko4TAWKmDZpXm3vOFV3mA+ DYKVRYJZzFLOfc3HgcirxB5WRf7j9+3zgbo0fQRLABpVgQ3khPlXijCxhpa+l9qcnu3J MhgA==
X-Gm-Message-State: AMke39lvDV2M62rjta1KOKQUwlq10uZ8TiUYg4sJaM7/GklNrtq72rfjkEAFtHF2Z0npSCSB9fPNxBlziuSaeg==
X-Received: by 10.55.151.7 with SMTP id z7mr7060987qkd.316.1486705498946; Thu, 09 Feb 2017 21:44:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Thu, 9 Feb 2017 21:44:58 -0800 (PST)
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
From: Martin Thomson 
Date: Fri, 10 Feb 2017 16:44:58 +1100
Message-ID: 
To: Sean Turner 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 05:45:01 -0000

On 10 February 2017 at 16:07, Sean Turner  wrote:
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.


From nobody Thu Feb  9 22:23:14 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD11296FC for ; Thu,  9 Feb 2017 22:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 4xVwtpNdSc_L for ; Thu,  9 Feb 2017 22:23:11 -0800 (PST)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 5F7B412973A for ; Thu,  9 Feb 2017 22:23:11 -0800 (PST)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id B686060A8C; Fri, 10 Feb 2017 06:23:03 +0000 (UTC)
From: Taylor R Campbell 
To: David Jacobson 
In-reply-to: <9a95bf47-9fea-6a38-5bdf-d88f10b36323@sbcglobal.net> (dmjacobson@sbcglobal.net)
Date: Fri, 10 Feb 2017 06:23:09 +0000
Sender: Taylor R Campbell 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <20170210062303.B686060A8C@jupiter.mumble.net>
Archived-At: 
Cc: "cfrg@ietf.org" , Randal Atkinson 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 06:23:13 -0000

> Date: Thu, 9 Feb 2017 21:38:31 -0800
> From: David Jacobson 
>=20
> Oops.  I made a mistake.  It is the key that is being hashed not the=20
> message.
>=20
> But I still don't see where it helps.  An attacker does not choose the ke=
y.

Consider an authenticated encrypted content-addressed storage scheme
similar to Tahoe-LAFS.  Our goal is to store files in some server's
key/value store.  We hope to conceal the content of the files from the
server and detect any attempts at forgery by the server, excluding
replays of old files.

To store a file m, compute k =3D SHA512(m).  Let k0 be the first 256
bits of k.  Use k0 as an AES256-CTR encryption key and k as an
HMAC-SHA256 key with encrypt-then-MAC to obtain ciphertext c0,
authenticator a, and tagged ciphetext c, where:

   c0 =3D AES256-CTR(h, m)
   a =3D HMAC-SHA256(k, c0)
   c =3D c0 || a.

Then use SHA256(k) as the key to store the value c in the server's
key/value store.

Problem:  By revealing SHA256(k) to the server, we have allowed the
server to forge stored ciphertexts, because HMAC-SHA256(k, c0) =3D
HMAC-SHA256(SHA256(k), c0), the latter of which the server can now
compute for any c0.


This protocol is obviously quirky.  It is close to, but not quite,
Tahoe-LAFS's protocol; Tahoe-LAFS goes to some trouble to enforce
domain separation between its various uses of SHA256.  But it is not
far from a plausible protocol that someone might invent, and the only
practical problem I foresee with it is the HMAC key collision:

- Sharing key material between AES256-CTR and HMAC-SHA256 makes my
skin crawl, but -- particularly since the key is prehashed for
HMAC-SHA256! -- I can't imagine an attack arising from this.

- On the other hand, I can easily imagine someone trying to use a
512-bit key with AES256-CTR and HMAC-SHA256 and, on finding that the
nearest crypto library rejects it for AES256-CTR but accepts it for
HMAC-SHA256, simply truncating the AES256-CTR key.


From nobody Thu Feb  9 22:55:34 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140B2129509 for ; Thu,  9 Feb 2017 22:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 oHRtLizUqSjb for ; Thu,  9 Feb 2017 22:55:32 -0800 (PST)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 042431294CE for ; Thu,  9 Feb 2017 22:55:31 -0800 (PST)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id 223AC60AB1; Fri, 10 Feb 2017 06:55:25 +0000 (UTC)
From: Taylor R Campbell 
To: David Jacobson ,
In-reply-to: <20170210062303.B686060A8C@jupiter.mumble.net> (campbell+cfrg@mumble.net)
Date: Fri, 10 Feb 2017 06:55:30 +0000
Sender: Taylor R Campbell 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20170210065525.223AC60AB1@jupiter.mumble.net>
Archived-At: 
Cc: cfrg@ietf.org, Randal Atkinson 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 06:55:33 -0000

> Date: Fri, 10 Feb 2017 06:23:09 +0000
> From: Taylor R Campbell 
> 
> To store a file m, compute k = SHA512(m).  [...]
> 
> Problem:  By revealing SHA256(k) to the server, we have allowed the
> server to forge stored ciphertexts, because HMAC-SHA256(k, c0) =
> HMAC-SHA256(SHA256(k), c0), [...]

Oops -- this particular scenario doesn't work because if |k| <= 512,
the block size of SHA256, then HMAC-SHA256 uses k verbatim with no
prehash.  We would need to have chosen a >512-bit k, which makes this
whole scenario even less likely: typical block sizes are >=512 bits
(e.g., MD5, SHA1, SHA2, SHA3, BLAKE2), and typical output sizes are
<=512 bits.


From nobody Fri Feb 10 01:06:17 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62643129410 for ; Fri, 10 Feb 2017 01:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 3COBvq4IwOrq for ; Fri, 10 Feb 2017 01:06:10 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50042.outbound.protection.outlook.com [40.107.5.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3DA126BF7 for ; Fri, 10 Feb 2017 01:06:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XVhFIPgYnQorX5k4zcwGPLJ4e//ZP+2qn4OTlPF594c=; b=ro+SmDlHSq69EWfLPb37Ndbv+CFgbyz8TyH+r6Ke5I1LrQaeHklBvHNDUDhj02NNb42WZEjnflGU0uo4L/GjdGEkDOXVHmKAH9q4IohOEvM2xuxtBbfTG8+kJs1HOM1zCVFVIwP39ZcDVgaMdTGCXtg0bt1xuY51CJtdrkVuk5w=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 09:06:07 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 09:06:07 +0000
From: "Paterson, Kenny" 
To: Sean Turner 
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koA=
Date: Fri, 10 Feb 2017 09:06:07 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [78.146.76.254]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:Q90T0VHKTJU0ye1bHUqTpTTD0FhszZITv44tPIMbYfxWFyA47pBzSujqwOva3ViCmsDOn6DX5tnsSllDPbDrQ7fOhnEunojhhZrn5MG6Qp/Nlj3ZxK09xfRzoQWuuqSSXj9FDzcTzKHvkN0jCcfuvgKnnE03pMeWdpXjRYn8XS+YlCIbnLz06wdaMreWeXMKqx0cmskjUsd4XnUP1D7L6uddbra1xDUh/Od/BS5L5qxLwjoQqqKtLR0vn/tkZVhqK9jX9GVhKfGMcSPZfSxVxXAu9zILay/2Z4AShjOWf79XLM425fI4+KaKL3TjuhSZXvgdJz0wsFf0e5pvqqk2p9Diz6QwjxDV0TqsvrEuzOetogQ0xa6dGABqhUIUE1aLFyyltfCmYZ36nf2dTG9wH1jPaGwqIZTO+gl5xvm8FD/9nIrNJKLoLDlx6ELAMEiivZ0SreCdqZHCnNoOhMrhPF3Yx1xgxSyLMEUDbgzPTeDw77Rv3qeH8hZzbxbY3rQqMbYkITniknmUqJITBn+JVw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(101416001)(8936002)(106356001)(2950100002)(6916009)(106116001)(42882006)(74482002)(68736007)(105586002)(2906002)(4326007)(122556002)(86362001)(36756003)(7736002)(66066001)(3846002)(102836003)(6116002)(81156014)(5660300001)(53546003)(6246003)(229853002)(8676002)(53936002)(92566002)(2900100001)(81166006)(3280700002)(99286003)(54906002)(6486002)(4001350100001)(76176999)(50986999)(77096006)(6506006)(3660700001)(38730400002)(189998001)(25786008)(110136004)(83506001)(97736004)(6512007)(54356999)(68196006)(6436002)(305945005)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: e4265914-066f-468c-03a8-08d451940cca
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1907; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; 
x-forefront-prvs: 0214EB3F68
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <702D4EBAC6C88847AC69B3266840936D@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 09:06:07.5436 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 09:06:13 -0000

SGksDQoNCk15IHByZWZlcmVuY2UgaXMgdG8gZ28gd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgb3B0
aW9uIGEpLg0KDQpGcm9tIHRoZSBnaXRodWIgZGlzY3Vzc2lvbiwgSSB0aGluayBvcHRpb24gYykg
aW52b2x2ZXMgYSBsZXNzIGNvbnNlcnZhdGl2ZQ0Kc2VjdXJpdHkgYm91bmQgKHN1Y2Nlc3MgcHJv
YmFiaWxpdHkgZm9yIElORC1DUEEgYXR0YWNrZXIgYm91bmRlZCBieQ0KMl57LTMyfSBpbnN0ZWFk
IG9mIDJeey02MH0pLiBJIGNhbiBsaXZlIHdpdGggdGhhdCwgYnV0IHRoZSBXRyBzaG91bGQgYmUN
CmF3YXJlIG9mIHRoZSB3ZWFrZXIgc2VjdXJpdHkgZ3VhcmFudGVlcyBpdCBwcm92aWRlcy4NCg0K
SSBkbyBub3QgdW5kZXJzdGFuZCBvcHRpb24gYikuIEl0IHNlZW1zIHRvIHJlbHkgb24gYW4gYW5h
bHlzaXMgb2YNCmNvbGxpc2lvbnMgb2YgY2lwaGVydGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhl
IGVzdGFibGlzaGVkIHNlY3VyaXR5IHByb29mDQpmb3IgQUVTLUdDTS4NCg0KUmVnYXJkcywNCg0K
S2VubnkNCg0KT24gMTAvMDIvMjAxNyAwNTo0NCwgIkNmcmcgb24gYmVoYWxmIG9mIE1hcnRpbiBU
aG9tc29uIg0KPGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgbWFydGluLnRob21z
b25AZ21haWwuY29tPiB3cm90ZToNCg0KPk9uIDEwIEZlYnJ1YXJ5IDIwMTcgYXQgMTY6MDcsIFNl
YW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQo+PiBhKSBDbG9zZSB0aGVzZSB0d28g
UFJzIGFuZCBnbyB3aXRoIHRoZSBleGlzdGluZyB0ZXh0IFswXQ0KPj4gYikgQWRvcHQgUFIjNzY1
IFsxXQ0KPj4gYykgQWRvcHQgUFIjNzY5IFsyXQ0KPg0KPg0KPmEpIEknbSBoYXBweSBlbm91Z2gg
d2l0aCB0aGUgY3VycmVudCB0ZXh0IChJJ3ZlIGltcGxlbWVudGVkIHRoYXQgYW55DQo+aXQncyBy
ZWxhdGl2ZWx5IGVhc3kpLg0KPg0KPkkgY291bGQgbGl2ZSB3aXRoIGMsIGJ1dCBJJ20gb3Bwb3Nl
ZCB0byBiLiBJdCBqdXN0IGRvZXNuJ3QgbWFrZSBzZW5zZS4NCj5JdCdzIG5vdCBvYnZpb3VzbHkg
d3JvbmcgYW55IG1vcmUsIGJ1dCB0aGUgd2F5IGl0IGlzIHdyaXR0ZW4gaXQgaXMNCj52ZXJ5IGNv
bmZ1c2luZyBhbmQgZWFzaWx5IG9wZW4gdG8gbWlzaW50ZXJwcmV0YXRpb24uDQo+DQo+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DZnJnIG1haWxpbmcg
bGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2NmcmcNCg0K


From nobody Fri Feb 10 03:26:26 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71A11295D0 for ; Fri, 10 Feb 2017 03:26:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 d20Idpsj6mr5 for ; Fri, 10 Feb 2017 03:26:23 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 32B051294F6 for ; Fri, 10 Feb 2017 03:26:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 575141CEBB; Fri, 10 Feb 2017 13:26:21 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id pK1LaYVhC7ln; Fri, 10 Feb 2017 13:26:19 +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 E4F8921C; Fri, 10 Feb 2017 13:26:19 +0200 (EET)
Date: Fri, 10 Feb 2017 13:26:17 +0200
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20170210112617.GA21741@LK-Perkele-V2.elisa-laajakaista.fi>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: IRTF CFRG , "" , Sean Turner 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 11:26:25 -0000

On Fri, Feb 10, 2017 at 04:44:58PM +1100, Martin Thomson wrote:
> On 10 February 2017 at 16:07, Sean Turner  wrote:
> > a) Close these two PRs and go with the existing text [0]
> > b) Adopt PR#765 [1]
> > c) Adopt PR#769 [2]
> 
> 
> a) I'm happy enough with the current text (I've implemented that any
> it's relatively easy).
> 
> I could live with c, but I'm opposed to b. It just doesn't make sense.
> It's not obviously wrong any more, but the way it is written it is
> very confusing and easily open to misinterpretation.

I couldn't make out what b) says, c) is much clearer.

However, even in a), let alone b) or c), the limits are so high that
one should do some greasing, or this feature seems like a prime
candidate for rusting shut.


-Ilari


From nobody Fri Feb 10 04:38:44 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABA31295B2 for ; Fri, 10 Feb 2017 04:38:39 -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=unavailable 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 F_OaSkNUf71g for ; Fri, 10 Feb 2017 04:38:37 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0092.outbound.protection.outlook.com [23.103.201.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E86129613 for ; Fri, 10 Feb 2017 04:38:36 -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=FgRpksH1PX5jNzPkwBaheUWRuxHGFvtj8oE+6jvC41Y=; b=v7dugR6zuCShPGLspiMWxw+JdzjcSELC9MPqIVcCQPnzt3LL3hJIpdYW5ARXbfAHrBInDTJZr7Ai2u+Ug4vhfPyNpFSD/w2nxanRLmunjTYNh/MrKTjc18EgYwUKtaL/Inmu+qvfwnWLv+VUIWmfw1XneipJlv01jGO+Morr4p8=
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.888.16; Fri, 10 Feb 2017 12:38:35 +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.0888.026; Fri, 10 Feb 2017 12:38:35 +0000
From: "Dang, Quynh (Fed)" 
To: Sean Turner , "" 
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ujO2IdKSxzmEyFi9zUyMXxM6FiINGq
Date: Fri, 10 Feb 2017 12:38:34 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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-ms-office365-filtering-correlation-id: 7cf13fea-527e-4362-0fc3-08d451b1bac0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:Hq/mF2Aq8CpakIfcCLl18q0Wk1cJdXc+EwjKT0ZzUTGubGBubzGRoYYCZH1uObQ/Lhz5I/g0ZbG2tlaVEkSx0z4bbzmxHnIoljKoWSSzqYBcJEvpwyZPJRaYSHtF3I89BlPgAtWHT3PM/NEJTJsu1hTFcWsvl9Xg2MCrBbBUwmg8+iyj3CUXJt6zYjfo5K9TUkMc8c26I66MU595z86jiwd5qlEL/VnBToQlPMI4vOYDccX/WYHSSaeGiOunCmuR+56N/BJDMfOYemK46jDkdyhSj5UUIq2RkQIzW1gQy/gh9FvjIt13vS48JWiZbt8r/aoJzLphtWTj0bQH230zthKMigCostYuoHZQX4EyRPCmVwwq+6XmajiyBCoyUywHetfEXPOkGV8z7NPI3DHz245TyFMvRpVq0+613Rzpj1B6PjWwrUjlXr6oo0vr7w/CMosKYDwX1fF6O1H8Dl4wUBaJqI1QZefzxkByq+ZMPCpyCEtZMtmzJi3BDtwxEk4dwtJvOuuufGzZKuVFsIkbMQ==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; 
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39450400003)(199003)(377454003)(189002)(6116002)(54356999)(76176999)(3660700001)(50986999)(92566002)(25786008)(53936002)(74316002)(2950100002)(6436002)(55016002)(54896002)(606005)(3280700002)(77096006)(7906003)(9686003)(6306002)(3846002)(6506006)(81156014)(5660300001)(8676002)(101416001)(122556002)(81166006)(8936002)(7736002)(33656002)(4326007)(7696004)(102836003)(86362001)(97736004)(236005)(66066001)(2900100001)(68736007)(229853002)(99286003)(106356001)(189998001)(106116001)(38730400002)(105586002)(6246003)(53546003)(2906002)(491001); 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_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 12:38:34.8621 (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: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 12:38:39 -0000

--_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sean and all,


I agree with everyone that the text in (b) was not very good text.


The problem with (c) is that it is not precise at places and it leaves out =
a lot of informative discussions which users should know.


The sentence "The maximum amount of plaintext data that can be safely encry=
pted with  AES-GCM in a session is 2^48 128-bit blocks (2^52 bytes), assumi=
ng  probability of success at 1/2^32" is not clear.  What is the success he=
re? And, with 2^48 (full or partial) blocks, the collision probability is b=
elow (not at) 2^(-32).


And, "safely encrypted", what does this mean? I would like not having a col=
lision among 128-bit blocks of ciphertexts, but I dont see any damage to th=
e data owner who sends the encrypted data over a TLS session.


I copied the text that I later proposed under the discussion of PR#769 belo=
w.


" To use AES-GCM to provide authenticity of authenticated data, confidentia=
lity of plaintext content, and information leakage [0] protection for the p=
laintext safely, the limit of total ciphertext under a single key is ( (TLS=
CipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 =
128-bit blocks.


When the data limit is reached, the chance of having a collision among 128-=
bit blocks of the ciphertext is below 2^(-32) which is negligible.

Since the block size of AES is 128 bits, there will be collisions among dif=
ferent sets of ciphertext from multiple sessions using GCM (or any other mo=
des of AES) when the total amount of the ciphertext of all considered sessi=
ons is more than 2^64 128-bit blocks. This fact does not seem to create a p=
ractical security weakness of using AES GCM.

For ChaCha20/Poly1305, the record sequence number would wrap before the saf=
ety limit is reached. See [AEAD-LIMITS] for further analysis.

[0]: Information leakage in the context of TLS is a chosen-plaintext distin=
guishing attack where the attacker provides 2 128-bit plaintext blocks to a=
 GCM encryption engine, after seeing one encrypted block for one of the 2 p=
laintext blocks, the attacker knows which plaintext block was encrypted. Or=
, it means that there is a collision among 128-bit blocks of the ciphertext=
. "

  1.  The text above uses blocks instead of bytes or records of ciphertext.
  2.  The partial block situation is taken into account.

"


Or, using good text from PR769 provided by brainhub, the first paragraph co=
uld be replaced by the following.


"To use AES-GCM to provide authenticity of authenticated data, confidential=
ity of plaintext content, and information leakage [0] protection for the pl=
aintext, the limit of total ciphertext under a single key is 2^48 128-bit b=
locks with the ciphertext size being rounded up to the next 16-byte boundar=
y. "


Regards,

Quynh.



________________________________
From: Cfrg  on behalf of Sean Turner 
Sent: Friday, February 10, 2017 12:07:35 AM
To: 
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable















Hi Sean and all,







I agree with everyone that the text in (b) was not very good text.







The problem with (c) is that it is not precise at places and it lea=
ves out a lot of informative discussions which users should know. 







The sentence "The maximum amount of plaintext data that can b=
e safely encrypted with  AES-GCM in a session is 2^48 128-bit blocks (=
2^52 bytes), assuming  probability of success at 1/2^32" is not c=
lear.  What is the success here? And, with 2^48 (full
 or partial) blocks, the collision probability is below (not at) 2^(-3=
2). 







" <=
span style=3D"color:rgb(51,51,51); font-size:14px">To use AES-GCM to provid=
e authenticity of authenticated data, confidentiality of
plaintext conten=
t, and informati=
on leakage [0] protection for the plaintext safely, the limit of total ciph=
ertext under a single key is ( (TLSCipherText.length
 / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 128-bit blocks.







When t=
he data limit is reached, the chance of having a collision among 128-bit bl=
ocks of the ciphertext is below 2^(-32) which is negligible.


Since =
the block size of AES is 128 bits, there will be collisions among different=
 sets of ciphertext from multiple sessions using GCM (or any other modes of=
 AES) when the total amount of the
 ciphertext of all considered sessions is more than 2^64 128-bit blocks. Th=
is fact does not seem to create a practical security weakness of using AES =
GCM.


For Ch=
aCha20/Poly1305, the record sequence number would wrap before the safety li=
mit is reached. See [AEAD-LIMITS] for further analysis.


[0]: I=
nformation leakage in the context of TLS is a chosen-plaintext distinguishi=
ng attack where the attacker provides 2 128-bit plaintext blocks to a GCM e=
ncryption engine, after seeing one
 encrypted block for one of the 2 plaintext blocks, the attacker knows whic=
h plaintext block was encrypted. Or, it means that there is a collision amo=
ng 128-bit blocks of the ciphertext. "


    

  1. The text above uses blocks instead of bytes o=
r records of ciphertext.
  2. The partial block situation is taken into account.

" 



"To
 use AES-GCM to provide authenticity of authenticated data, confident=
iality of plaintext content, and information leakage [0] protec=
tion for the plaintext, the limit of total ciphertext under a single key is=
 2^48 128-bit blocks with the ciphertext
 size being rounded up to the next 16-byte boundary. "







Regards,


Quynh.
  




From: Cfrg <cfrg-bounc=
es@irtf.org> on behalf of Sean Turner <sean@sn3rd.com>

Sent: Friday, February 10, 2017 12:07:35 AM

To: <tls@ietf.org>

Cc: IRTF CFRG

Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" P=
Rs (#765/#769)

 







All,



We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, t=
hese limits have been discussed a couple of times and we need to resolve on=
ce and for all whether the TLS WG wants to:



a) Close these two PRs and go with the existing text [0]

b) Adopt PR#765 [1]

c) Adopt PR#769 [2]



Please indicate you preference to the TLS mailing list before Feb 17. =
 Note that unless there=92s clear consensus to change the text will remain =
as is (i.e., option a).



J&S



[0] https:/=
/tlswg.github.io/tls13-spec/#rfc.section.5.5

[1] https://github=
.com/tlswg/tls13-spec/pull/765

[2] https://github=
.com/tlswg/tls13-spec/pull/769

_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irtf.org=
/mailman/listinfo/cfrg







--_000_CY4PR09MB146491519DC49811E2A8CE79F3440CY4PR09MB1464namp_--


From nobody Fri Feb 10 04:48:51 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE14129483 for ; Fri, 10 Feb 2017 04:48:44 -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=unavailable 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 5rA1aautQPg5 for ; Fri, 10 Feb 2017 04:48:43 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0110.outbound.protection.outlook.com [23.103.201.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 29B21129637 for ; Fri, 10 Feb 2017 04:48:43 -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=VDJW7fswKUh9lKl3szACBtUEmkwvCD/WAZmiOSQ4ozY=; b=BFYe+rJCm8d3GEq16EVL1QC6zysmRsO53QdTF53B0a4z2ipZLuY+sw9zgTZYDQiT8DAPTUjG1a1chykqBkgnTD+Tbjf7UPDWnbeLO0rX/X0h6cnNWmGlOYU0/kvzrDAF4WWRf1YNuRnzZLHFPS9eWjjP892jf/eCIksEKJPr4t0=
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.888.16; Fri, 10 Feb 2017 12:48:41 +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.0888.026; Fri, 10 Feb 2017 12:48:41 +0000
From: "Dang, Quynh (Fed)" 
To: "Paterson, Kenny" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlg==
Date: Fri, 10 Feb 2017 12:48:41 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-ms-office365-filtering-correlation-id: 3c2cc685-ee47-4611-669c-08d451b3244a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:FNaw6j0epX9NwZAnWwwKsErqCnbjdjshHGKpmr6UTDLyAUJ0Gy+94I5CoqxF+ejEQPzOMdk7vgsWb+16zfyOdbletZWp9LeEzSCfzGeK3Ju3LChqVyn8a8BTjVHiiDnoHgwfvRRxpmyqlWi7YNlyOnX2zmnU4OzGxM598FBKJ7zXKCfgFoUD+rNCJaDE2KXyGoyHhSKAUMxqV/dsaT31kZ8dd0Y46eDsF1GDyz8SMtsK0K+s489e5NeIvGa9Y182kyhk9d8fill7TfkBKU4Ypw1QMna25Qo/8ElEear2/LZ0UTXjP22CjnTcMtBeSdFWLB9cot1wZwjAotZ/hBF/gwxLJ1QuZjhgOB9ur7ez2/MkfCvE58mtobENFE4QG7P8QG6igL3ROMjeempZHvkuSwN3Eovc0pMq1fG9wPOXkCHQYzj4CXKggsW0GNZcuclt5UzT/MpCIakzPXl0hnIuWibhccGhab/iXmmZj2PdjloUfje1EtMAR68fM+KBJ3iQ/++/LqcqgsCymBzmGq0DKA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(24454002)(189002)(377454003)(199003)(229853002)(2950100002)(77096006)(6436002)(5660300001)(92566002)(3846002)(102836003)(6116002)(6506006)(25786008)(606005)(6306002)(8656002)(54896002)(53936002)(236005)(97736004)(6512007)(99286003)(54906002)(101416001)(50986999)(66066001)(2900100001)(4001350100001)(2906002)(54356999)(3280700002)(68736007)(3660700001)(189998001)(76176999)(6486002)(122556002)(86362001)(4326007)(106356001)(105586002)(6246003)(106116001)(36756003)(53546003)(7906003)(81156014)(81166006)(7736002)(8676002)(8936002)(83506001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.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_D4C31FC42F5AFqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 12:48:41.4623 (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: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 12:48:45 -0000

--_000_D4C31FC42F5AFqdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Kenny,

From: TLS > on behalf of =
"Paterson, Kenny" >
Date: Friday, February 10, 2017 at 4:06 AM
To: Sean Turner >
Cc: IRTF CFRG >, ">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as bei=
ng a counter-mode encryption and each counter is a 96-bit nonce || 32-bit c=
ounter. I don=92t know if there is another kind of proof that is more preci=
se than that.

Regards,
Quynh.



Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 on behalf of martin.th=
omson@gmail.com> wrote:

On 10 February 2017 at 16:07, Sean Turner > wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

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


--_000_D4C31FC42F5AFqdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <81E61802C2AE14439A23D47F0A847436@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Kenny, 









From: TLS <tls-bounces@ietf.org> on behalf of "Paterson=
, Kenny" <Kenny.Paters=
on@rhul.ac.uk>

Date: Friday, February 10, 2017 at =
4:06 AM

To: Sean Turner <sean@sn3rd.com>

Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ie=
tf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hi,







My preference is to go with the existing text, option a).







From the github discussion, I think option c) involves a less conserva=
tive


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should b=
e


aware of the weaker security guarantees it provides.







I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security p=
roof


for AES-GCM.














My suggestion was based on counting.  I analyzed AES-GCM in TLS 1=
.3  as being a counter-mode encryption and each counter is a 96-bit no=
nce || 32-bit counter. I don=92t know if there is another kind of proof tha=
t is more precise than that.







Regards,


Quynh. 
























Regards,







Kenny







On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"









On 10 February 2017 at 16:07, Sean Turner <sean@sn3rd.com> wrote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]














a) I'm happy enough with the current text (I've implemented that any

it's relatively easy).







I could live with c, but I'm opposed to b. It just doesn't make sense.=



It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.







_______________________________________________


Cfrg mailing list











_______________________________________________


TLS mailing list


















--_000_D4C31FC42F5AFqdangnistgov_--


From nobody Fri Feb 10 05:23:35 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459181298C3 for ; Fri, 10 Feb 2017 05:23:34 -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 thvfQ5CGCupk for ; Fri, 10 Feb 2017 05:23:31 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0110.outbound.protection.outlook.com [23.103.201.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 8623912960E for ; Fri, 10 Feb 2017 05:23:31 -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=YrWmjCvKtjRpdqiRsbhTmQTjez8CY2EyNkid8pTZhXU=; b=K26A9ow7+SJVeMt+0QDmVkkfaUDN7FtE62TQGl6b7iVBVxfn/fd4uTXyhcCrKwGcyJe8clJM9SZknvzsdM65+Ge0AYYvrjI6Yb5T8C9cNXSiHgKT5zl2S0JSY+M4G9Bvm0gAKQnp0Airc4aIjUnx460ZwT4AA4YuVTIitSdOu2o=
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.888.16; Fri, 10 Feb 2017 13:23:29 +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.0888.026; Fri, 10 Feb 2017 13:23:29 +0000
From: "Dang, Quynh (Fed)" 
To: David Jacobson , "Dang, Quynh (Fed)" , Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
Thread-Topic: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
Thread-Index: AQHSgWiX/QOHsp+cqk6PweDPw/SKDKFfEXKkgAKodACAADEvAA==
Date: Fri, 10 Feb 2017 13:23:29 +0000
Message-ID: 
References:   <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>
In-Reply-To: <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:HpNlRXnfdGNX0a2DUHR594LSc0mdd5IXW3HUM+ErCwBPtdNYgWCa1wbuGzy31MtF5976pVDkIGI1c5aueSR2F63rVePdKUCafe9/ILGETotp+/xSQhoVyd5iPWm5EKzi9hu7UHHmvd4PDsxku47QPrzcYAEK27UmeaW8zQhbNBfac9hiFC7xLOFKwbzAitZVsv/8xOxP9eP2oMxM/LZwakG1HNaIxce5NpCUb93wQQl0K/aTAQPeoxpMqTbJB+sqOKFn54rPaEAKHtERKKEtJCe4+DWFJKACZ6+4p7GSUdvnY+a/cqY+AJtNlO82Xc0yLUbl04Z9efgQVoru3anvxrDC/1yjmB43LAjSEgZnTA8Kb3tXNJq2KMvlEgnZYJo4Vsl9AQsT/39abBEE82Y79McIU8IFjcLBHgAgKguYORBCYvtsaj8ZBNGlun/74fYVLWj8025qx6LHNbPt836kGZMmLa4O4EdquuLXQb9gX3QwGzwUrOPEgF72Duid/VI5qs5HqmpLrO9+TfKCx5Cksw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39840400002)(39850400002)(189002)(24454002)(377454003)(199003)(66066001)(68736007)(2900100001)(36756003)(236005)(345774005)(99286003)(229853002)(102836003)(86362001)(97736004)(4001350100001)(38730400002)(189998001)(106116001)(6246003)(2906002)(53546003)(105586002)(19627405001)(106356001)(83506001)(3280700002)(77096006)(6486002)(6436002)(53936002)(2950100002)(54896002)(606005)(3846002)(6506006)(6512007)(6306002)(7906003)(50986999)(92566002)(8656002)(3660700001)(6116002)(76176999)(54356999)(25786008)(7736002)(8936002)(4326007)(8676002)(101416001)(81156014)(5660300001)(81166006)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 9500ac65-e736-4a6e-4289-08d451b800ac
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(189930954265078)(13052087078022)(4659246709749)(112561432440764);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; 
x-forefront-prvs: 0214EB3F68
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_D4C323A12F5E8qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 13:23:29.2073 (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: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 13:23:34 -0000

--_000_D4C323A12F5E8qdangnistgov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

See my discussion below.

From: David Jacobson >
Date: Friday, February 10, 2017 at 12:27 AM
To: 'Quynh' >, Randal Atkin=
son >, Michael StJohns >, "Paterson, Kenny" >
Cc: "cfrg@ietf.org" >
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...

See interleaved comment.

On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:

Randal, Michael and many others,


Thank you for your suggestions.


Kenny,


Thank you for your discussion email.


We are thinking about what would be the best option for HMAC.  Some technic=
al possibilities are below.


1) Don't change the HMAC spec.

Ask a HMAC key always to have a fixed length such as HMAC-SHA256 having 256=
-bit key. Which means that all protocols using HMAC-SHA256 use 256-bit keys=
.

If each protocol uses a different key length, then the issue would still ex=
ist across protocols. I don't know if this is a practical security problem,=
 but it seems like a problem that should be avoided.

Should ask HMAC keys to be processed/produced by a hash function or another=
 PRF always.

I don't see the need or even desirability for this, assuming you ask each p=
rotocol to use a fixed (for that protocol) key length.  (That was the line =
above.)

For an attacker to find two messages with the same HMAC, not knowing the ke=
y, he would have to find a collision in the first stage, not knowing the fi=
rst block.  And if you add an extra hash, you are only making it easier.  H=
e has to get a collision in the pre-hash, where he knows everything.

Of course, the hash function must be a collision-resistant one.

The reason for hashing the key or the key is produced by a good hash functi=
on or a PRF is to make the key become more of a "random key" as you know HM=
AC is a PRF as keys are selected randomly, not selectively.

Quynh.





   --David Jacobson

This option does not break interoperability of  the current HMAC implementa=
tions.

2) Change the HMAC Spec.

a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198.
b) Use a hash-based KDF (not HKDF) to produce B bits from the key, then go =
to step 4 in the FIPS. (bad for performance).
c) Require key < B, then do multi-rate padding 10* to make the key B bits, =
then go to step 4 in the FIPS. (good for performance).

We recommend the use of KMAC in SP 800-185. KMAC's security is solid and pr=
oven, and it has great performance. Code to implement KMAC can be reused to=
 implement many other Keccak-derived symmetric-key crypto functions.

Regards,
Quynh.
________________________________
From: Randal Atkinson 
Sent: Tuesday, February 7, 2017 12:34 PM
To: Dang, Quynh (Fed)
Cc: Randal Atkinson
Subject: Aside Re: [CFRG] erratum for hmac ...


One option available to NIST would be for NIST to open comments
on updating FIPS 198-1, even if opening comments on that now/soon
would be earlier than NIST ordinarily would do so.

Given how long it takes to move from an approved FIPS revision
to widespread US Government deployment, if data exists from
Kenny P and/or others that merits an update, then starting sooner
would not be a bad thing for the USG.

Cheers,

Ran Atkinson

--------------------------------
Randal Atkinson, PhD
Cheltenham Research for NRL 5520
randal.atkinson.ctr@nrl.navy.mil




_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf=
rg


--_000_D4C323A12F5E8qdangnistgov_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







See my discussion below. 









From: David Jacobson <dmjacobson@sbcglobal.net>

Date: Friday, February 10, 2017 at =
12:27 AM

To: 'Quynh' <Quynh.Dang@nist.gov>, Randal Atkinson <randal.atkinson.ctr@nrl.navy.=
mil>, Michael StJohns <=
msj@nthpermutation.com>,
 "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>

Cc: "cfrg@ietf.org" <cfrg@i=
etf.org>

Subject: Re: [Cfrg] Aside Re: [CFRG=
] erratum for hmac ...















See interleaved comment.



On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:









Randal, Michael and many others,







Thank you for your suggestions.







Kenny,







Thank you for your discussion email.







We are thinking about what would be the best option for HMAC.  Some=
 technical possibilities are below. 







1) Don't change the HMAC spec.





Ask a HMAC key always to have a fixed length such as HMAC-SH=
A256 having 256-bit key. Which means that all protocols using HMAC-SHA256 u=
se 256-bit keys. 







If each protocol uses a different key length, then the issue would&nbs=
p;still exist across protocols. I don't know if this is a practical securit=
y problem, but it seems like a problem that should be avoided. 






Should ask HMAC keys to be processed/produced by a hash function or an=
other PRF always.










I don't see the need or even desirability for this, assuming you ask each p=
rotocol to use a fixed (for that protocol) key length.  (That was the =
line above.)



For an attacker to find two messages with the same HMAC, not knowing the ke=
y, he would have to find a collision in the first stage, not knowing the fi=
rst block.  And if you add an extra hash, you are only making it easie=
r.  He has to get a collision in the
 pre-hash, where he knows everything.












Of course, the hash function must be a collision-resistant one. <=
/div>






The reason for hashing the key or the key is produced by a good hash f=
unction or a PRF is to make the key become more of a "random key"=
 as you know HMAC is a PRF as keys are selected randomly, not selectively.&=
nbsp;







Quynh. 


























   --David Jacobson








This option does not break interoperability of  the current HMAC imple=
mentations.



2) Change the HMAC Spec. 



a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198. 

b) Use a hash-based KDF (not HKDF) to produce B bits from the key, the=
n go to step 4 in the FIPS. (bad for performance). 

c) Require key < B, then do multi-rate padding 10* to make the key B bit=
s, then go to step 4 in the FIPS. (good for performance).







We recommend the use of KMAC in SP 800-185. KMAC's security is solid a=
nd proven, and it has great performance. Code to implement KMAC can be reus=
ed to implement many other Keccak-derived symmetric-key crypto functio=
ns.







Regards,


Quynh. 








From: Randal Atkinson
<randal.atkinson.ctr@nrl.navy.mil>

Sent: Tuesday, February 7, 2017 12:34 PM

To: Dang, Quynh (Fed)

Cc: Randal Atkinson

Subject: Aside Re: [CFRG] erratum for hmac ...

 









One option available to NIST would be for NIST to open comments 

on updating FIPS 198-1, even if opening comments on that now/soon 

would be earlier than NIST ordinarily would do so.



Given how long it takes to move from an approved FIPS revision

to widespread US Government deployment, if data exists from 

Kenny P and/or others that merits an update, then starting sooner

would not be a bad thing for the USG.



Cheers,



Ran Atkinson



--------------------------------

Randal Atkinson, PhD

Cheltenham Research for NRL 5520

randal.atkinson.ctr@nrl.navy.mil    &nb=
sp;  













 


_______________________________________________
Cfrg mailing list
Cfrg@ir=
tf.orghttps://www.irtf.org/mailman/listinfo/cfrg


















--_000_D4C323A12F5E8qdangnistgov_--


From nobody Fri Feb 10 07:50:14 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BBF1299EB for ; Fri, 10 Feb 2017 07:50:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEsD59e3D2_7 for ; Fri, 10 Feb 2017 07:50:09 -0800 (PST)
Received: from nm3-vm3.access.bullet.mail.bf1.yahoo.com (nm3-vm3.access.bullet.mail.bf1.yahoo.com [216.109.114.98]) (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 D8FCD1299D0 for ; Fri, 10 Feb 2017 07:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1486741808; bh=t8lixResoAIVemV/XVmViUPTZC3MLRHc3D/RdBaM57M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=tPiPcy+zI6fwY6+BFPxDiRXCpnlzrp942G5CD/kYi1DDYzfynrnUUKNr8C3pGx8XlwodbqAdbZ4y5KwWZtdrKcL0leAW6DHrktoXegVWtamHmYSOoDLGfd8xwSm0Es4ePdP9n1Y5ajOaGFA2WvWCPgw98npz/AYioONb1oQSSxEL1yJzPpc8m1cJX+ZTUuVgE2pYClsx0dlgdqgMoaBW9UUxfZ2tXxjOqllcITh6qqYKmvzRipClZiAHPAMiS2c9xEYmGAch6SGLWLLlzHZnlytRxuT3xW3t2Lci7dLSFo5hDYqi30L0vvbnkAOiAYQlmdySiL35+jEm0oWHKqp4/A==
Received: from [66.196.81.163] by nm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 15:50:08 -0000
Received: from [98.138.226.243] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Feb 2017 15:50:07 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 10 Feb 2017 15:50:07 -0000
X-Yahoo-Newman-Id: 730902.2625.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 8u7.ihYVM1nxg5h8lGl1JbRE5aa15lB5uYIS4q8wupPDv7T gLAQZ2lJ3BpzAw1cPlF.SGTx2hqGyvuP1HFf1Wq9.P.MgBgoUkNijUJqDfOS E_oQCE0ipq6wYfCAzHHL_AFFbHeSR05NbiwoBxr0_PCcHmJdPo5Tyj8v1.vS NyLmHI_8k.fVs6ryuj8fJ3C9DGe3h6RH4IVq6U3U_ah9XoE5atm8IbJwBQ7v X10bF4jClGJ59dmN39RVPelA6GP651iN2_2jybx6M4EXh6QyUqGiPz1RRzVN 7uKrhIIea5sjaYpYznT7RbY4pjN3GwKVl0BHFyQzaAMQdZDdqxtWUfStod8V FGLgQrxOa106jyoa4sP7zHEAolF4VhmEyMoQzJ44bsvOMtyBVQi01pRL6t7. jpHXaobuHZaQIn_2NtCcv4ysP7mGNLa4ylawvMglT.FDNfG_jpqS4Ld2TDOc UdnDnHQyXYZLe_G02gfHRcVhjyzn9qh..YrTHJi7V0tyMbf8YKTRB5twVPr4 yifYGkxUopvQ0vViXX7zLEi7Qhvx3vlRnbgUNo1SpoIgCs1X7mcTFJKgNabv QA44pIg--
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: "Dang, Quynh (Fed)" , Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
References:   <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net> 
From: David Jacobson 
Message-ID: <0d9948b3-074a-ab89-9154-6f2c0c96b464@sbcglobal.net>
Date: Fri, 10 Feb 2017 07:50:05 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0A9D27E40B1CFD9C8CA4B06F"
Archived-At: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 15:50:13 -0000

This is a multi-part message in MIME format.
--------------0A9D27E40B1CFD9C8CA4B06F
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

In engineering, we like to be able to think of things as black boxes 
with specifications.  If you follow the rules in the specification, it 
works properly.

The problem here is that HMAC fails to do this.  If you use HMAC with a 
key larger that the input block size (allowed), and you reveal the hash 
of the key (a la original /etc/password), you can lose security.

My suggestion would be to add wording to the specification that says ( 
a) that use of keys larger than the input block size is discouraged, and 
(b) if the keys larger than the input block size are used, the H(K) is 
also sensitive and must be protected with the same diligence as the key 
would be protected.

     --David Jacobson


On 2/10/17 5:23 AM, Dang, Quynh (Fed) wrote:
> See my discussion below.
>
> From: David Jacobson  >
> Date: Friday, February 10, 2017 at 12:27 AM
> To: 'Quynh' >, Randal 
> Atkinson  >, Michael StJohns 
> >, "Paterson, 
> Kenny" >
> Cc: "cfrg@ietf.org "  >
> Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
>
>     See interleaved comment.
>
>     On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:
>>
>>     Randal, Michael and many others,
>>
>>
>>     Thank you for your suggestions.
>>
>>
>>     Kenny,
>>
>>
>>     Thank you for your discussion email.
>>
>>
>>     We are thinking about what would be the best option for HMAC.
>>      Some technical possibilities are below.
>>
>>
>>     1) Don't change the HMAC spec.
>>
>>
>>     Ask a HMAC key always to have a fixed length such as HMAC-SHA256
>>     having 256-bit key. Which means that all protocols using
>>     HMAC-SHA256 use 256-bit keys.
>>
>>     If each protocol uses a different key length, then the issue
>>     would still exist across protocols. I don't know if this is a
>>     practical security problem, but it seems like a problem that
>>     should be avoided.
>>
>>     Should ask HMAC keys to be processed/produced by a hash function
>>     or another PRF always.
>
>     I don't see the need or even desirability for this, assuming you
>     ask each protocol to use a fixed (for that protocol) key length. 
>     (That was the line above.)
>
>     For an attacker to find two messages with the same HMAC, not
>     knowing the key, he would have to find a collision in the first
>     stage, not knowing the first block.  And if you add an extra hash,
>     you are only making it easier.  He has to get a collision in the
>     pre-hash, where he knows everything.
>
>
> Of course, the hash function must be a collision-resistant one.
>
> The reason for hashing the key or the key is produced by a good hash 
> function or a PRF is to make the key become more of a "random key" as 
> you know HMAC is a PRF as keys are selected randomly, not selectively.
>
> Quynh.
>
>
>
>
>
>        --David Jacobson
>>
>>     This option does not break interoperability of  the current HMAC
>>     implementations.
>>
>>     2) Change the HMAC Spec.
>>
>>     a) Always hash the key regardless of its length, then perform
>>     step 3 in FIPS 198.
>>     b) Use a hash-based KDF (not HKDF) to produce B bits from the
>>     key, then go to step 4 in the FIPS. (bad for performance).
>>     c) Require key < B, then do multi-rate padding 10* to make the
>>     key B bits, then go to step 4 in the FIPS. (good for performance).
>>
>>     We recommend the use of KMAC in SP 800-185. KMAC's security is
>>     solid and proven, and it has great performance. Code to implement
>>     KMAC can be reused to implement many other
>>     Keccak-derived symmetric-key crypto functions.
>>
>>     Regards,
>>     Quynh.
>>     ------------------------------------------------------------------------
>>     *From:* Randal Atkinson 
>>     *Sent:* Tuesday, February 7, 2017 12:34 PM
>>     *To:* Dang, Quynh (Fed)
>>     *Cc:* Randal Atkinson
>>     *Subject:* Aside Re: [CFRG] erratum for hmac ...
>>
>>     One option available to NIST would be for NIST to open comments
>>     on updating FIPS 198-1, even if opening comments on that now/soon
>>     would be earlier than NIST ordinarily would do so.
>>
>>     Given how long it takes to move from an approved FIPS revision
>>     to widespread US Government deployment, if data exists from
>>     Kenny P and/or others that merits an update, then starting sooner
>>     would not be a bad thing for the USG.
>>
>>     Cheers,
>>
>>     Ran Atkinson
>>
>>     --------------------------------
>>     Randal Atkinson, PhD
>>     Cheltenham Research for NRL 5520
>>     randal.atkinson.ctr@nrl.navy.mil
>>
>>
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>
>


--------------0A9D27E40B1CFD9C8CA4B06F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
In engineering, we like to be able to
      think of things as black boxes with specifications.  If you follow
      the rules in the specification, it works properly.  

      

      The problem here is that HMAC fails to do this.  If you use HMAC
      with a key larger that the input block size (allowed), and you
      reveal the hash of the key (a la original /etc/password), you can
      lose security.

      

      My suggestion would be to add wording to the specification that
      says ( a) that use of keys larger than the input block size is
      discouraged, and (b) if the keys larger than the input block size
      are used, the H(K) is also sensitive and must be protected with
      the same diligence as the key would be protected.

      

          --David Jacobson

      

      

      On 2/10/17 5:23 AM, Dang, Quynh (Fed) wrote:

    

    

      
      
See my discussion below. 

      


      

      
        

          From: David Jacobson
          <dmjacobson@sbcglobal.net>

          Date: Friday, February
          10, 2017 at 12:27 AM

          To: 'Quynh' <Quynh.Dang@nist.gov>,
          Randal Atkinson <randal.atkinson.ctr@nrl.navy.mil>,
          Michael StJohns <msj@nthpermutation.com>,
          "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>

          Cc: "cfrg@ietf.org"
          <cfrg@ietf.org>

          Subject: Re: [Cfrg]
          Aside Re: [CFRG] erratum for hmac ...

        

        


        

        

          

            

              
See interleaved comment.

                

                On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:

              

              

                
                

                  
Randal, Michael and many others,

                  


                  

                  
Thank you for your suggestions.

                  


                  

                  
Kenny,

                  


                  

                  
Thank you for your discussion email.

                  


                  

                  
We are thinking about what would be the best option
                    for HMAC.  Some technical possibilities are below. 

                  


                  

                  
1) Don't change the
                      HMAC spec.

                  

                  


                    Ask a HMAC key always to have a fixed length such as
                    HMAC-SHA256 having 256-bit key. Which means that all
                    protocols using HMAC-SHA256 use 256-bit keys. 

                  


                  

                  
If each protocol uses a different key length,
                    then the issue would still exist across protocols. I
                    don't know if this is a practical security problem,
                    but it seems like a problem that should be avoided. 

                    

                  

                  
Should ask HMAC keys to be processed/produced by
                    a hash function or another PRF always.
                    

                  

                

              

              

              I don't see the need or even desirability for this,
              assuming you ask each protocol to use a fixed (for that
              protocol) key length.  (That was the line above.)

              

              For an attacker to find two messages with the same HMAC,
              not knowing the key, he would have to find a collision in
              the first stage, not knowing the first block.  And if you
              add an extra hash, you are only making it easier.  He has
              to get a collision in the pre-hash, where he knows
              everything.

          

        

      
      


      

      
Of course, the hash function must be a collision-resistant
        one. 

      


      

      
The reason for hashing the key or the key is produced by a
        good hash function or a PRF is to make the key become more of a
        "random key" as you know HMAC is a PRF as keys are selected
        randomly, not selectively. 

      


      

      
Quynh. 

      


      

      


      

      


      

      
        

          

            


              

                 --David Jacobson

              

                

                  


                    This option does not break interoperability of  the
                    current HMAC implementations.

                    

                    2) Change the HMAC Spec. 

                    

                    a) Always hash the key regardless of its length,
                    then perform step 3 in FIPS 198. 

                    b) Use a hash-based KDF (not HKDF) to produce B bits
                    from the key, then go to step 4 in the FIPS. (bad
                    for performance). 

                    c) Require key < B, then do multi-rate padding
                    10* to make the key B bits, then go to step 4 in the
                    FIPS. (good for performance).

                  


                  

                  
We recommend the use of KMAC in SP 800-185.
                    KMAC's security is solid and proven, and it has
                    great performance. Code to implement KMAC can be
                    reused to implement many other
                    Keccak-derived symmetric-key crypto functions.

                  


                  

                  
Regards,

                  
Quynh. 

                  

                    

                      

                      
From: Randal
                          Atkinson
                          <randal.atkinson.ctr@nrl.navy.mil>

                          Sent: Tuesday, February 7, 2017 12:34
                          PM

                          To: Dang, Quynh (Fed)

                          Cc: Randal Atkinson

                          Subject: Aside Re: [CFRG] erratum for
                          hmac ...
                        
 

                      

                    

                    
                        


                          One option available to NIST would be for NIST
                          to open comments 

                          on updating FIPS 198-1, even if opening
                          comments on that now/soon 

                          would be earlier than NIST ordinarily would do
                          so.

                          

                          Given how long it takes to move from an
                          approved FIPS revision

                          to widespread US Government deployment, if
                          data exists from 

                          Kenny P and/or others that merits an update,
                          then starting sooner

                          would not be a bad thing for the USG.

                          

                          Cheers,

                          

                          Ran Atkinson

                          

                          --------------------------------

                          Randal Atkinson, PhD

                          Cheltenham Research for NRL 5520

                          randal.atkinson.ctr@nrl.navy.mil       
                          

                          

                        

                      

                

                

                

                

                
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg

              

              


              

            

          

        

      
    

    


    

  


--------------0A9D27E40B1CFD9C8CA4B06F--


From nobody Fri Feb 10 07:51:53 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A441299D0 for ; Fri, 10 Feb 2017 07:51:48 -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=unavailable 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 e-R_N8fvfeDJ for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 A59B91299EB for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id v96so53510408ioi.0 for ; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=XPcXuB1iZWatzlaMyfATf2inUYKE9S/QLvLWARGRuDfvY5flgKlz2+OgLqXbqZSniZ z9ID57H8e5dYi8LWxlLA6rIqsXf7a8zGJIxrxePN31i7hxiRrN9mounL2IS6Atlg4i4y iAa+J+ACOqvOIdK+gZgWvGgADJLLhUMbyCvp/XUcd/gDn9xp9PqtOiiCxY27buffT1Aj pbSbj1w5PDVJx074WVssWmPuGXBLC6ocAnx7YBIdN+eMoIXwik3nSn4FHKgF+AVSCKA0 r7+3Pxmv+k0TUvk4j64x9QguWSPY7K4/3zASuGpnHLS8XlNCcgjOf3Yey44a+cRGRv6d P3Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=EGMu4+9ga8XRkQUQNcE8h3c1j7DL26aB/ocyd73sF/F5dEKYPeVUjU2d5Fg77YiEuV od+x8NcukiodfnPvh6DMiVGRb9q+MoZE9OqBvTUaMsjbueVT8KzHSim9E5EnKWNWId9P zLhfU3sug537Mf0zHJnim6SxJtRd/obBFV8ctlTgMvoNWpGqAf+9IAdTlpRzgE+LyRk5 3Ls5W42dxUbduCkA6b4UA5t5EJ84AZfEAcwWIEeeXgDCSBsRHRUDqfmzZ433S3foHytE 9QaWqnHHhUfQHquepBBfUW7PU05EJQuOVFE8btUX/5UJnNMUF1VT6CGu/dhK4afHqmax FfKw==
X-Gm-Message-State: AMke39nWXu6QkoPeHYpKEt2MiPb4PazDjWN5hLCYdCorLskp+EEIUWzH5u7rRKfV5OzxvA==
X-Received: by 10.107.20.13 with SMTP id 13mr9054953iou.0.1486741904935; Fri, 10 Feb 2017 07:51:44 -0800 (PST)
Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id h15sm508251ita.20.2017.02.10.07.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 07:51:44 -0800 (PST)
To: Sean Turner , "" 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
From: Rene Struik 
Message-ID: 
Date: Fri, 10 Feb 2017 10:51:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Content-Type: multipart/alternative; boundary="------------6F183E4431F40EF448049DCE"
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 15:51:49 -0000

This is a multi-part message in MIME format.
--------------6F183E4431F40EF448049DCE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be 
safely encrypted under a given set of keys.[AEAD-LIMITS] 
provides an analysis of 
these limits under the assumption that the underlying primitive (AES or 
ChaCha20) has no weaknesses. Implementations SHOULD do a key 
updateSection 4.6.3 
prior to reaching these 
limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 
encrypted on a given connection while keeping a safety margin of 
approximately 2^-57 for Authenticated Encryption (AE) security. For 
ChaCha20/Poly1305, the record sequence number would wrap before the 
safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel 
attacks, which - in some implementations - have been shown to be 
successful at recovering keying material with a relatively small number 
of messages encrypted using the same key. While results are highly 
implementation-specific, thereby making it hard to provide precise 
guidance, prudence suggests that implementations should not reuse keys 
ad infinitum. Implementations SHALL therefore always implement the key 
update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make 
sure people do not "forget" to implement key updates?}


See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:
> All,
>
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usageâ€.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:
>
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]
>
> Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).
>
> J&S
>
> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
> [1] https://github.com/tlswg/tls13-spec/pull/765
> [2] https://github.com/tlswg/tls13-spec/pull/769
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------6F183E4431F40EF448049DCE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear colleagues:

      

      I would suggest adding the following paragraph at the end of
      Section 5.5:

      

      [current text of Section 5.5]

      

      
There are cryptographic limits
        on the amount of plaintext which can be safely encrypted under a
        given set of keys. [AEAD-LIMITS] provides an analysis of
        these limits under the assumption that the underlying primitive
        (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a
        key update Section
          4.6.3 prior to
        reaching these limits.

      
For AES-GCM,
        up to 2^24.5 full-size records (about 24 million) may be
        encrypted on a given connection while keeping a safety margin of
        approximately 2^-57 for Authenticated Encryption (AE) security.
        For ChaCha20/Poly1305, the record sequence number would wrap
        before the safety limit is reached.

      [suggested additional text]

      

      The above upper limits do not take into account potential side
      channel attacks, which - in some implementations - have been shown
      to be successful at recovering keying material with a relatively
      small number of messages encrypted using the same key. While
      results are highly implementation-specific, thereby making it hard
      to provide precise guidance, prudence suggests that
      implementations should not reuse keys ad infinitum.
      Implementations SHALL therefore always implement the key update
      mechanism of Section 4.6.3. 

      

      {editorial note: perhaps, one should impose the limit 2^20, just
      to make sure people do not "forget" to implement key updates?}   

      

      

      See also my email of August 29, 2016:

https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

      

      On 2/10/2017 12:07 AM, Sean Turner wrote:

    

    

      
All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usageâ€.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


    

    

    


    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------6F183E4431F40EF448049DCE--


From nobody Fri Feb 10 09:22:51 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF54129A61 for ; Fri, 10 Feb 2017 09:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 Iw470sKT_57K for ; Fri, 10 Feb 2017 09:22:36 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0083.outbound.protection.outlook.com [104.47.2.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0BE129A69 for ; Fri, 10 Feb 2017 09:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n/LRRwKHM6QBMFVVxjJ/3tsQYtdVZW9VtPZJT7oHpzM=; b=p4tyD2Vw7s451TZtqhgKEy4r+cryOi4dEyOCAEJcZQAG4T52vyJwg4pGutO4WBbk4VS1sZpmlaGjcl0csnFplHQx3PBTqWh0UBTevZIIRmHwDTwD1PsCi5agOF9gYjU66ApM5svTxBHk17tk/R3AyINswRh221sqVcXU6Xe4Ju8=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 17:22:33 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 17:22:33 +0000
From: "Paterson, Kenny" 
To: "Dang, Quynh (Fed)" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koCAAD3QgIAATPYA
Date: Fri, 10 Feb 2017 17:22:32 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>   
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.227.30]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:pmFdocvmAxGE4SFBIix1OWUiObAnRMVo5ClVojqetHA+H9RosZ+yrvdXiIRlKDTRP/Nn+CpfFf/OOTX/v+1fEQTl5jIIU5wzu9u/nGECg8yCvGfbZH/T+LX9F6wTcCSniyToYQnXY+tzMh4Z6kYUoYqNuwOTyd326LD4xr3sQHz13Ybu9cEQSHm7EJSV7JhfVYULtK+BTLjKb1t6xc/oMv/uRz57bfpiVBLki5KA8ZZwCFjS6Ck658jGiyfk6I2l+AHPDELPSfdUaFhbbrwJsnyXO8QngzHfIfochof0iMeYQOhMQmgzlWB+FDcKlQcZb8t+oM9GWkiyQN/T5sIKd30Atr/bd9OAECbHFP3l0PEEdo8t28nva6DBKxx+w/edLkaQoWKQ4rAKM36gj4B6vwNOinfRB+RtXClhKSng2OnpTIlvzSQTK2nyhbQ89y25AviVVjp6ie2TwW4mRGCH2KeiZZwBiA+lnS0+xoU/i/ki2hAT0t+RQQKSLcJZWes9cYd64OkgL/6bgM00WHz9/Q==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(53546003)(8656002)(966004)(6246003)(5660300001)(81156014)(53936002)(8676002)(229853002)(3846002)(66066001)(7736002)(6116002)(102836003)(92566002)(83506001)(25786008)(189998001)(38730400002)(305945005)(6306002)(97736004)(6512007)(6436002)(54356999)(3280700002)(99286003)(2900100001)(54906002)(81166006)(76176999)(6506006)(77096006)(50986999)(3660700001)(4001350100001)(6486002)(8936002)(101416001)(2950100002)(106116001)(106356001)(42882006)(93886004)(86362001)(36756003)(68736007)(105586002)(2906002)(74482002)(122556002)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 5890bdce-02e8-42b5-84c0-08d451d96641
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1907; 
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)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; 
x-forefront-prvs: 0214EB3F68
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <928EBE543230574E92C16DBD0D5BB4EC@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 17:22:32.9273 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 17:22:45 -0000

RGVhciBRdXluaCwNCg0KT24gMTAvMDIvMjAxNyAxMjo0OCwgIkRhbmcsIFF1eW5oIChGZWQpIiA8
cXV5bmguZGFuZ0BuaXN0Lmdvdj4gd3JvdGU6DQoNCj5IaSBLZW5ueSwgDQo+DQo+PkhpLA0KPj4N
Cj4+DQo+Pk15IHByZWZlcmVuY2UgaXMgdG8gZ28gd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCwgb3B0
aW9uIGEpLg0KPj4NCj4+DQo+PkZyb20gdGhlIGdpdGh1YiBkaXNjdXNzaW9uLCBJIHRoaW5rIG9w
dGlvbiBjKSBpbnZvbHZlcyBhIGxlc3MNCj4+Y29uc2VydmF0aXZlDQo+PnNlY3VyaXR5IGJvdW5k
IChzdWNjZXNzIHByb2JhYmlsaXR5IGZvciBJTkQtQ1BBIGF0dGFja2VyIGJvdW5kZWQgYnkNCj4+
Ml57LTMyfSBpbnN0ZWFkIG9mIDJeey02MH0pLiBJIGNhbiBsaXZlIHdpdGggdGhhdCwgYnV0IHRo
ZSBXRyBzaG91bGQgYmUNCj4+YXdhcmUgb2YgdGhlIHdlYWtlciBzZWN1cml0eSBndWFyYW50ZWVz
IGl0IHByb3ZpZGVzLg0KPj4NCj4+DQo+PkkgZG8gbm90IHVuZGVyc3RhbmQgb3B0aW9uIGIpLiBJ
dCBzZWVtcyB0byByZWx5IG9uIGFuIGFuYWx5c2lzIG9mDQo+PmNvbGxpc2lvbnMgb2YgY2lwaGVy
dGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhlIGVzdGFibGlzaGVkIHNlY3VyaXR5DQo+PnByb29m
DQo+PmZvciBBRVMtR0NNLg0KPj4NCj4+DQo+DQo+DQo+TXkgc3VnZ2VzdGlvbiB3YXMgYmFzZWQg
b24gY291bnRpbmcuICBJIGFuYWx5emVkIEFFUy1HQ00gaW4gVExTIDEuMyAgYXMNCj5iZWluZyBh
IGNvdW50ZXItbW9kZSBlbmNyeXB0aW9uIGFuZCBlYWNoIGNvdW50ZXIgaXMgYSA5Ni1iaXQgbm9u
Y2UgfHwNCj4zMi1iaXQgY291bnRlci4gSSBkb27igJl0IGtub3cgaWYgdGhlcmUgaXMgYW5vdGhl
ciBraW5kIG9mIHByb29mIHRoYXQgaXMNCj5tb3JlIHByZWNpc2UgdGhhbiB0aGF0Lg0KDQpUaGFu
a3MgZm9yIGV4cGxhaW5pbmcuIEkgdGhpbmssIHRoZW4sIHRoYXQgd2hhdCB5b3UgYXJlIGRvaW5n
IGlzIChpbg0KZWZmZWN0KSBhY2NvdW50aW5nIGZvciB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVt
bWEgdGhhdCBpcyB1c2VkIChpbiBhDQpzdGFuZGFyZCB3YXkpIGFzIHBhcnQgb2YgdGhlIElORC1D
UEEgc2VjdXJpdHkgcHJvb2Ygb2YgQUVTLUdDTS4gT25lIGNhbg0Kb2J0YWluIGEgZ3JlYXRlciBk
ZWdyZWUgb2YgcHJlY2lzaW9uIGJ5IHVzaW5nIHRoZSBwcm92ZW4gYm91bmRzIGZvcg0KSU5ELUNQ
QSBzZWN1cml0eSBvZiBBRVMtR0NNLiBUaGVzZSBpbmNvcnBvcmF0ZSB0aGUgInNlY3VyaXR5IGxv
c3MiIGNvbWluZw0KZnJvbSB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVtbWEuIFRoZSBjdXJyZW50
IGJlc3QgZm9ybSBvZiB0aGVzZSBib3VuZHMgaXMNCmR1ZSB0byBJd2F0YSBldCBhbC4uIFRoaXMg
aXMgcHJlY2lzZWx5IHdoYXQgd2UgYW5hbHlzZSBpbiB0aGUgbm90ZSBhdA0KaHR0cDovL3d3dy5p
c2cucmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZiAtIHNwZWNpZmljYWxseSwgc2VlDQpl
cXVhdGlvbnMgKDUpIC0gKDcpIG9uIHBhZ2UgNiBvZiB0aGF0IG5vdGUuDQoNClJlZ2FyZHMsDQoN
Cktlbm55IA0KDQo+DQo+DQo+UmVnYXJkcywNCj5RdXluaC4gDQoNCg==


From nobody Fri Feb 10 10:44:57 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED63129A8C for ; Fri, 10 Feb 2017 10:44:56 -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 vkUkQOwv6Z0b for ; Fri, 10 Feb 2017 10:44:52 -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 AB53112958B for ; Fri, 10 Feb 2017 10:44:52 -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=1z9z6J/cc0t+QHnziI91nfIQXdVXNsXdr1zFm4w/Bx0=; b=wwcNd9aZ0nPI6T79Pz4PaM2I8D4KsVuW6SW3kGu8/qobNyd7YQaxicCLB2U3y1OCpXe9Z4dJ0i1s9LPbtOL6kFEW6AdOmjZmf3gMcye28fQqVbpRIzgCK7IV88PyuyASr80gueuGWLa4ISAlxW8mzjveYWpEEacKdB4/fnJW5l4=
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.888.16; Fri, 10 Feb 2017 18:44:51 +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.0888.026; Fri, 10 Feb 2017 18:44:50 +0000
From: "Dang, Quynh (Fed)" 
To: David Jacobson , "Dang, Quynh (Fed)" , Randal Atkinson , Michael StJohns , "Paterson, Kenny" 
Thread-Topic: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
Thread-Index: AQHSgWiX/QOHsp+cqk6PweDPw/SKDKFfEXKkgAKodACAADEvAIAAfMuA///c/wA=
Date: Fri, 10 Feb 2017 18:44:50 +0000
Message-ID: 
References:   <59d04ca7-aed8-e0e1-bf06-fdd44ccba697@sbcglobal.net>  <0d9948b3-074a-ab89-9154-6f2c0c96b464@sbcglobal.net>
In-Reply-To: <0d9948b3-074a-ab89-9154-6f2c0c96b464@sbcglobal.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:TrR1/p9fUGz1ga6TNNyD4MMyoXLjsQy2IhuUKbpm2Rwh1y0dSlhlYsvphAhTpHIpXKBQVZbcaEoZaaZ5OBSqdyiR5MTIKviA0UWqn2y/nGegPRMZqOUUVutixglYsHc3XJOkf6XKkt/BAdr4eo9S4X+NLiEt2p/rnxvSoWM1GYekkoyq1bHpxBSIgagJ7BtRApMQHF65qi4jlSUeDwx9aw0p0bKnTri+Ez0ADJeylhJDf51YlPHpIiCICZIwkFyy3cfEzZY0LdSbUoCO/u0OFIGvr/D9yfcO+4T4LPKDd0K+RZxFFDLqODhRYRG/NNGIKmEEP1dDT3bi3G7hRDp0jxZtdA7dKM9L0qNjjiXQZsG+CvFhwAdiqAJQfgNrICEFTeox+XH5fVD0xPfcVaALhSx0yzEfd5NUa5uOYn+xwnUEVO/QEcPF1SMG5ZmvDz4No2ye8+ni0vovLqbH+Q8MJj4fsJ+ORT3n3K5eM+fmEl7hlIx74zblma3FoLcJRT64GoBa1JYqoqz8LlMN2QmyBw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(199003)(24454002)(377454003)(189002)(6486002)(86362001)(122556002)(4001350100001)(50986999)(66066001)(54356999)(3280700002)(189998001)(76176999)(3660700001)(68736007)(2906002)(2900100001)(4326007)(81166006)(81156014)(7906003)(38730400002)(8936002)(83506001)(8676002)(7736002)(106356001)(105586002)(6246003)(53546003)(106116001)(36756003)(19627405001)(3846002)(92566002)(345774005)(77096006)(229853002)(6436002)(2950100002)(551544002)(5660300001)(99286003)(102836003)(93886004)(6512007)(97736004)(101416001)(236005)(606005)(8656002)(54896002)(25786008)(6116002)(6506006)(53936002)(6306002); 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: f58eb8ab-f5ec-41a0-de0d-08d451e4e55c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(189930954265078)(13052087078022)(4659246709749)(112561432440764);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 0214EB3F68
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_D4C372FD2F83Aqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:44:50.6753 (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: 
Cc: "cfrg@ietf.org" 
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 18:44:57 -0000

--_000_D4C372FD2F83Aqdangnistgov_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: David Jacobson >
Date: Friday, February 10, 2017 at 10:50 AM
To: 'Quynh' >, Randal Atkin=
son >, Michael StJohns >, "Paterson, Kenny" >
Cc: "cfrg@ietf.org" >
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...

In engineering, we like to be able to think of things as black boxes with s=
pecifications.  If you follow the rules in the specification, it works prop=
erly.

The problem here is that HMAC fails to do this.  If you use HMAC with a key=
 larger that the input block size (allowed), and you reveal the hash of the=
 key (a la original /etc/password), you can lose security.

In our guildlines, we require to keep K0 as secret key.



My suggestion would be to add wording to the specification that says ( a) t=
hat use of keys larger than the input block size is discouraged, and (b) if=
 the keys larger than the input block size are used, the H(K) is also sensi=
tive and must be protected with the same diligence as the key would be prot=
ected.

    --David Jacobson


Thank you,
Quynh.




On 2/10/17 5:23 AM, Dang, Quynh (Fed) wrote:
See my discussion below.

From: David Jacobson >
Date: Friday, February 10, 2017 at 12:27 AM
To: 'Quynh' >, Randal Atkin=
son >, Michael StJohns >, "Paterson, Kenny" >
Cc: "cfrg@ietf.org" >
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...

See interleaved comment.

On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:

Randal, Michael and many others,


Thank you for your suggestions.


Kenny,


Thank you for your discussion email.


We are thinking about what would be the best option for HMAC.  Some technic=
al possibilities are below.


1) Don't change the HMAC spec.

Ask a HMAC key always to have a fixed length such as HMAC-SHA256 having 256=
-bit key. Which means that all protocols using HMAC-SHA256 use 256-bit keys=
.

If each protocol uses a different key length, then the issue would still ex=
ist across protocols. I don't know if this is a practical security problem,=
 but it seems like a problem that should be avoided.

Should ask HMAC keys to be processed/produced by a hash function or another=
 PRF always.

I don't see the need or even desirability for this, assuming you ask each p=
rotocol to use a fixed (for that protocol) key length.  (That was the line =
above.)

For an attacker to find two messages with the same HMAC, not knowing the ke=
y, he would have to find a collision in the first stage, not knowing the fi=
rst block.  And if you add an extra hash, you are only making it easier.  H=
e has to get a collision in the pre-hash, where he knows everything.

Of course, the hash function must be a collision-resistant one.

The reason for hashing the key or the key is produced by a good hash functi=
on or a PRF is to make the key become more of a "random key" as you know HM=
AC is a PRF as keys are selected randomly, not selectively.

Quynh.





   --David Jacobson

This option does not break interoperability of  the current HMAC implementa=
tions.

2) Change the HMAC Spec.

a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198.
b) Use a hash-based KDF (not HKDF) to produce B bits from the key, then go =
to step 4 in the FIPS. (bad for performance).
c) Require key < B, then do multi-rate padding 10* to make the key B bits, =
then go to step 4 in the FIPS. (good for performance).

We recommend the use of KMAC in SP 800-185. KMAC's security is solid and pr=
oven, and it has great performance. Code to implement KMAC can be reused to=
 implement many other Keccak-derived symmetric-key crypto functions.

Regards,
Quynh.
________________________________
From: Randal Atkinson 
Sent: Tuesday, February 7, 2017 12:34 PM
To: Dang, Quynh (Fed)
Cc: Randal Atkinson
Subject: Aside Re: [CFRG] erratum for hmac ...


One option available to NIST would be for NIST to open comments
on updating FIPS 198-1, even if opening comments on that now/soon
would be earlier than NIST ordinarily would do so.

Given how long it takes to move from an approved FIPS revision
to widespread US Government deployment, if data exists from
Kenny P and/or others that merits an update, then starting sooner
would not be a bad thing for the USG.

Cheers,

Ran Atkinson

--------------------------------
Randal Atkinson, PhD
Cheltenham Research for NRL 5520
randal.atkinson.ctr@nrl.navy.mil




_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf=
rg



--_000_D4C372FD2F83Aqdangnistgov_
Content-Type: text/html; charset="us-ascii"
Content-ID: <18D28F409D91BD4BBD8E399EEABD0F6E@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable



















From: David Jacobson <dmjacobson@sbcglobal.net>

Date: Friday, February 10, 2017 at =
10:50 AM

To: 'Quynh' <Quynh.Dang@nist.gov>, Randal Atkinson <randal.atkinson.ctr@nrl.navy.=
mil>, Michael StJohns <=
msj@nthpermutation.com>,
 "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>

Cc: "cfrg@ietf.org" <cfrg@i=
etf.org>

Subject: Re: [Cfrg] Aside Re: [CFRG=
] erratum for hmac ...















In engineering, we like to be able to think =
of things as black boxes with specifications.  If you follow the rules=
 in the specification, it works properly. 




The problem here is that HMAC fails to do this.  If you use HMAC with =
a key larger that the input block size (allowed), and you reveal the hash o=
f the key (a la original /etc/password), you can lose security.














In our guildlines, we require to keep K0 as secret key. 


















My suggestion would be to add wording to the specification that says ( a) t=
hat use of keys larger than the input block size is discouraged, and (b) if=
 the keys larger than the input block size are used, the H(K) is also sensi=
tive and must be protected with
 the same diligence as the key would be protected.



    --David Jacobson





















Thank you,


Quynh. 























On 2/10/17 5:23 AM, Dang, Quynh (Fed) wrote:






See my discussion below. 









From: David Jacobson <dmjacobson@sbcgl=
obal.net>

Date: Friday, February 10, 2017 at =
12:27 AM

To: 'Quynh' <Quynh.Dang@nist.gov>, =
Randal Atkinson <randal.atkinson.ctr@nrl.navy.mil>,
 Michael StJohns <msj@nthpermutation.com>, "Paterson, Kenny" &l=
t;Ken=
ny.Paterson@rhul.ac.uk>

Cc: "cfrg@ietf.org" <cfrg@ietf.org>

Subject: Re: [Cfrg] Aside Re: [CFRG=
] erratum for hmac ...















See interleaved comment.



On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:









Randal, Michael and many others,







Thank you for your suggestions.







Kenny,







Thank you for your discussion email.







We are thinking about what would be the best option for HMAC.  Some=
 technical possibilities are below. 







1) Don't change the HMAC spec.





Ask a HMAC key always to have a fixed length such as HMAC-SH=
A256 having 256-bit key. Which means that all protocols using HMAC-SHA256 u=
se 256-bit keys. 







If each protocol uses a different key length, then the issue would&nbs=
p;still exist across protocols. I don't know if this is a practical securit=
y problem, but it seems like a problem that should be avoided. 






Should ask HMAC keys to be processed/produced by a hash function or an=
other PRF always.










I don't see the need or even desirability for this, assuming you ask each p=
rotocol to use a fixed (for that protocol) key length.  (That was the =
line above.)



For an attacker to find two messages with the same HMAC, not knowing the ke=
y, he would have to find a collision in the first stage, not knowing the fi=
rst block.  And if you add an extra hash, you are only making it easie=
r.  He has to get a collision in the
 pre-hash, where he knows everything.












Of course, the hash function must be a collision-resistant one. <=
/div>






The reason for hashing the key or the key is produced by a good hash f=
unction or a PRF is to make the key become more of a "random key"=
 as you know HMAC is a PRF as keys are selected randomly, not selectively.&=
nbsp;







Quynh. 


























   --David Jacobson








This option does not break interoperability of  the current HMAC imple=
mentations.



2) Change the HMAC Spec. 



a) Always hash the key regardless of its length, then perform step 3 in FIP=
S 198. 

b) Use a hash-based KDF (not HKDF) to produce B bits from the key, the=
n go to step 4 in the FIPS. (bad for performance). 

c) Require key < B, then do multi-rate padding 10* to make the key B bit=
s, then go to step 4 in the FIPS. (good for performance).







We recommend the use of KMAC in SP 800-185. KMAC's security is solid a=
nd proven, and it has great performance. Code to implement KMAC can be reus=
ed to implement many other Keccak-derived symmetric-key crypto functio=
ns.







Regards,


Quynh. 








From: Randal Atkinson

<randal.atkinson.ctr@nrl.navy.mil>

Sent: Tuesday, February 7, 2017 12:34 PM

To: Dang, Quynh (Fed)

Cc: Randal Atkinson

Subject: Aside Re: [CFRG] erratum for hmac ...

 









One option available to NIST would be for NIST to open comments 

on updating FIPS 198-1, even if opening comments on that now/soon 

would be earlier than NIST ordinarily would do so.



Given how long it takes to move from an approved FIPS revision

to widespread US Government deployment, if data exists from 

Kenny P and/or others that merits an update, then starting sooner

would not be a bad thing for the USG.



Cheers,



Ran Atkinson



--------------------------------

Randal Atkinson, PhD

Cheltenham Research for NRL 5520

randal.atkinson.ctr@nrl.navy.mil&n=
bsp;      













 


_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghtt=
ps://www.irtf.org/mailman/listinfo/cfrg































--_000_D4C372FD2F83Aqdangnistgov_--


From nobody Fri Feb 10 10:48:06 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44F12958B for ; Fri, 10 Feb 2017 10:48:02 -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=unavailable 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 ES1RvkwcxzhY for ; Fri, 10 Feb 2017 10:47:59 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0135.outbound.protection.outlook.com [23.103.200.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B312129A8E for ; Fri, 10 Feb 2017 10:47:59 -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=SWlHQSGNzXrUwlpYkIj1FyMXLO0pcIvMaQf70BdFMmk=; b=do9qw8Iha7GPBa5Ou/X8/luBqD92nOn29KfDFkRqn+vJPFyzbVXzQd4bgjxcS2lp5zdPCqaEcBKhT8u4rNo3epQ2mVh0PBkKgpwcLIYaPh42D5h1SdCcL9MlhzUUuGcGng4VssEaU4P6tLH/ntJMdXIyNfIjs5zhXDekSFJh1Ws=
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.888.16; Fri, 10 Feb 2017 18:47:57 +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.0888.026; Fri, 10 Feb 2017 18:47:57 +0000
From: "Dang, Quynh (Fed)" 
To: Rene Struik , Sean Turner , "" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0A==
Date: Fri, 10 Feb 2017 18:47:57 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-ms-office365-filtering-correlation-id: bb897306-0c91-4a53-d16e-08d451e554db
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:vjCOHdPXo2e/bEetYR/p871QNDIolpEpy6yRCuI8k+eFAXOfmAsennoSqAwWQP2S62VqElVPUCk+ZoNlwzYTlrZX40u9oinHZWqzIhqn6uujFk86kgqDHY78I6QFzO3EPARk43qfQtqKu3Y1pYh9xURBxN+U5k+1t4kMxm24wil1/mNQxv7P4dkiTBcjfduiTipu4jUdqyUgaHE1QsJNhCMcipQCmW8YR2v6aSa0LLlRVuQOQbyjG+T45yaddT56sSMdvKiN1zp/GONXxn1npnc7pa76JxOh7wvnkiztx3VVydqNxHGOrEo8MYdVZMw6XywpdepAScBBV45faGq+syOgki7s1llYvDfRpyC9QX/ke4BlW/Hd+ilG8UN47PehihcUlIFYyzjy6CziE/w4A8783ExEgXSH4peJJOhWFsw8mzo5cV0nmyVjVKih33eVjvR/AC5b6awhlpXYjzsnR2uDFjuPOQJvun1KJ+WaJivyXVfLWwhjWoDUEymbhruUED6g7PINt4rhQGyH9mUgrg==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(199003)(189002)(377454003)(24454002)(2900100001)(2906002)(8936002)(3280700002)(3846002)(81156014)(2950100002)(102836003)(4326007)(6116002)(53936002)(5660300001)(81166006)(8676002)(38730400002)(105586002)(92566002)(106116001)(6246003)(189998001)(53546003)(106356001)(66066001)(76176999)(4001350100001)(54356999)(3660700001)(50986999)(6486002)(97736004)(77096006)(6436002)(325944008)(39060400001)(6506006)(229853002)(6306002)(101416001)(6512007)(99286003)(54896002)(236005)(25786008)(606005)(86362001)(68736007)(7906003)(36756003)(122556002)(575784001)(83506001)(7736002)(491001); 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; 
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_D4C3749F2F856qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:47:57.6983 (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: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 18:48:02 -0000

--_000_D4C3749F2F856qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Rene,

From: TLS > on behalf of =
Rene Struik >
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner >, ">" >
Cc: IRTF CFRG >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]


There are cryptographic limits on the amount of plaintext which can be safe=
ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the =
assumption that the underlying primitive (AES or ChaCha20) has no weaknesse=
s. Implementations SHOULD do a key update Section 4.6.3 prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry=
pted on a given connection while keeping a safety margin of approximately 2=
^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the=
 record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel atta=
cks, which - in some implementations - have been shown to be successful at =
recovering keying material with a relatively small number of messages encry=
pted using the same key. While results are highly implementation-specific, =
thereby making it hard to provide precise guidance, prudence suggests that =
implementations should not reuse keys ad infinitum. Implementations SHALL t=
herefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make su=
re people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks w=
ork for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:

All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf=
rg



--
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

--_000_D4C3749F2F856qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Rene, 









From: TLS <tls-bounces@ietf.org> on behalf of Rene Struik &l=
t;rstruik.ext@gmail.com>
Date: Friday, February 10, 2017 at =
10:51 AM

To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tl=
s@ietf.org>

Cc: IRTF CFRG <cfrg@irtf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Dear colleagues:



I would suggest adding the following paragraph at the end of Section 5.5:


[current text of Section 5.5]





There are cryptographic limits on the amount of plaintext which can be safe=
ly encrypted under a given set of keys. [AEAD-LIMITS] provides
 an analysis of these limits under the assumption that the underlying primi=
tive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key u=
pdate Section
 4.6.3 prior to reach=
ing these limits.



For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry=
pted on a given connection while keeping a safety margin of approximately 2=
^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the=
 record sequence number would wrap
 before the safety limit is reached.

[suggested additional text]



The above upper limits do not take into account potential side channel atta=
cks, which - in some implementations - have been shown to be successful at =
recovering keying material with a relatively small number of messages encry=
pted using the same key. While results
 are highly implementation-specific, thereby making it hard to provide prec=
ise guidance, prudence suggests that implementations should not reuse keys =
ad infinitum. Implementations SHALL therefore always implement the key upda=
te mechanism of Section 4.6.3.




{editorial note: perhaps, one should impose the limit 2^20, just to make su=
re people do not "forget" to implement key updates?}  















How do you do side channel attacks on TLS ? Do these side-channel atta=
cks work for AES-GCM only in TLS 1.3 ?




















See also my email of August 29, 2016:

https://mailarchive.ietf.org/arch/m=
sg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno



On 2/10/2017 12:07 AM, Sean Turner wrote:






All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.=
5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@ir=
tf.orghttps://www.irtf.org/mailman/listinfo/cfrg











--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363











--_000_D4C3749F2F856qdangnistgov_--


From nobody Fri Feb 10 10:56:50 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEED12956D for ; Fri, 10 Feb 2017 10:56:41 -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=unavailable 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 BZ87KxppWKa6 for ; Fri, 10 Feb 2017 10:56:40 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0121.outbound.protection.outlook.com [23.103.200.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F027129AA2 for ; Fri, 10 Feb 2017 10:56:39 -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=0+sLTh04fK1cyaZhIJisGeM0u/+qNgKrsCb5IHXD3Ac=; b=0IT/dlgl9GlRlFeo0aSPWdxm8py6NXIldW4x9u781GCXT1QHfP5T6ih1GoSD5zhmTLZlsbtOasHw225YftpCzDUKrTRhCpEkuKRI1akor6c1LFgsxjasR59gQf3vycvy+IzW00bZDfzbRUdIVSrxnx7WsoVa5gNNiBMnHEoPwqg=
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.888.16; Fri, 10 Feb 2017 18:56:37 +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.0888.026; Fri, 10 Feb 2017 18:56:36 +0000
From: "Dang, Quynh (Fed)" 
To: "Paterson, Kenny" , "Dang, Quynh (Fed)" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlqFifU4A///GdAA=
Date: Fri, 10 Feb 2017 18:56:36 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:DhTKf2QAA3QnW4l7eidfclmEg7si5fgLD5l/CCGf3XSZ9TX6UfwGKHJp0Knyv9EJ0VItzxiPqqm0r6+lGx0gapH+Z6hq9Odcpqop8dsDBpF1Pn5jQYGqMYUlZ5cMhrnxbGiKMxonDeYfr0YwJPV2saWviL9xjrjPYoEbT5esDm/K01hca59eUjabtYpasv0mA0AB0bWEykHeUTCfmBvtUhLHxZG/Yv0/jDBUUqYeIO5Xq5OBvx3tOiFoIWzZ33W3u3v00gZh195Ad1199epovHXgckcdQDJUTcrT7loOKw7TkhQgbS2xRTtXDG2idJK9BbA4jrlzholBrLDeF107PkbtHrIzNTWcWxpns9Sqz0Kc15mjq8qg3Ia/7Q3oem402lFfQCxn7x1gCa9jAPY9jw5291ZHn9Vuh5U1pIv6ImBBF2iKvudVzzRmWoTaRAXEwy9VNUpaOWOpjsypoeE3L/xS0Fe0VwZ+VF+XpGHbr+yv4G3e5A4UUusyb4bz7vIr3p3y1jvQ3uhQ4v3d19auYw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(377454003)(24454002)(199003)(189002)(101416001)(6306002)(236005)(54906002)(6512007)(54896002)(99286003)(97736004)(77096006)(6486002)(93886004)(6506006)(229853002)(6436002)(7736002)(83506001)(86362001)(606005)(68736007)(7906003)(25786008)(8656002)(122556002)(36756003)(50986999)(53936002)(8676002)(81166006)(5660300001)(2900100001)(2906002)(8936002)(102836003)(4326007)(81156014)(2950100002)(966004)(6116002)(3280700002)(3846002)(4001350100001)(66066001)(76176999)(54356999)(3660700001)(92566002)(106116001)(38730400002)(105586002)(106356001)(53546003)(6246003)(189998001); 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: 866149e0-fbde-4faa-2d93-08d451e68a34
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); 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)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0214EB3F68
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_D4C375192F85Fqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:56:36.7844 (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: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 18:56:42 -0000

--_000_D4C375192F85Fqdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dear Kenny,


From: "Paterson, Kenny" >
Date: Friday, February 10, 2017 at 12:22 PM
To: 'Quynh' >, Sean Turner =
>
Cc: IRTF CFRG >, ">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)" > wrote:

Hi Kenny,

Hi,


My preference is to go with the existing text, option a).


>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.


I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.




My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
being a counter-mode encryption and each counter is a 96-bit nonce ||
32-bit counter. I don=92t know if there is another kind of proof that is
more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a
standard way) as part of the IND-CPA security proof of AES-GCM. One can
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss" coming
from the PRP/PRF switching lemma. The current best form of these bounds is
due to Iwata et al.. This is precisely what we analyse in the note at
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
equations (5) - (7) on page 6 of that note.

I reviewed the paper more than once. I highly value the work. I suggested t=
o reference  your paper in the text.  I think the result in your paper is t=
he same with what is being suggested when the collision probability allowed=
 is 2^(-32).

Regards,
Quynh.


Regards,

Kenny



Regards,
Quynh.



--_000_D4C375192F85Fqdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <0020D91BE04D324A82B75F5B07AB0C36@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Dear Kenny, 














From: "Paterson, Kenny" &=
lt;Kenny.Paterson@rhul.ac.uk>

Date: Friday, February 10, 2017 at =
12:22 PM

To: 'Quynh' <Quynh.Dang@nist.gov>, Sean Turner <sean@sn3rd.com>

Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ie=
tf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Dear Quynh,







On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote:









Hi Kenny, 









Hi,












My preference is to go with the existing text, option a).












From the github discussion, I think option c) involves a less


conservative


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should b=
e


aware of the weaker security guarantees it provides.












I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security

proof


for AES-GCM.
























My suggestion was based on counting.  I analyzed AES-GCM in =
TLS 1.3  as


being a counter-mode encryption and each counter is a 96-bit nonce ||<=
/div>

32-bit counter. I don=92t know if there is another kind of proof that =
is


more precise than that.









Thanks for explaining. I think, then, that what you are doing is (in

effect) accounting for the PRP/PRF switching lemma that is used (in a<=
/div>

standard way) as part of the IND-CPA security proof of AES-GCM. One ca=
n


obtain a greater degree of precision by using the proven bounds for

IND-CPA security of AES-GCM. These incorporate the "security loss=
" coming


from the PRP/PRF switching lemma. The current best form of these bound=
s is


due to Iwata et al.. This is precisely what we analyse in the note at<=
/div>


equations (5) - (7) on page 6 of that note.














I reviewed the paper more than once. I highly value the work. I sugges=
ted to reference  your paper in the text.  I think the result in =
your paper is the same with what is being suggested when the collision prob=
ability allowed is 2^(-32).







Regards,


Quynh. 



















Regards,







Kenny 



















Regards,


Quynh. 























--_000_D4C375192F85Fqdangnistgov_--


From nobody Fri Feb 10 11:02:26 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772CF129AA9 for ; Fri, 10 Feb 2017 11:02:24 -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 ICNU-omRIiGD for ; Fri, 10 Feb 2017 11:02:22 -0800 (PST)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E065F129AA6 for ; Fri, 10 Feb 2017 11:02:21 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id 203so148335949ith.0 for ; Fri, 10 Feb 2017 11:02:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=VshVjuaGnYDoLIfeWhr1N/FEJ4yP8/Y08IFsFVtMBwg=; b=Y+5OT/eleXl0i8kTpKj04UFZMK5me73C9inIIeC1IJ/YaIDIlY+s8lvXEGb9o+sUQM I+aLD0byMTNywUZDQ0wQjsSWXEyBfdid3O+J2ll8uEvPgozL6dhkLxHFQj+NMaPXFfrE 4W9WJfIYwnLwi+8mDSwcba9SMGVNtXZwyqHzbs7AmzxSV95J4lW4r+CKD19xmmZRvHel pJx4uLfHOVrKq6RylIBrms+jhe3uQvcBykN8z0FJspGeieKxvjwVvTA4IEwf0og6OlMP REuLbSI6hior9wp++lH5OeaVL1PhMWZuFpSJK/KXnv1HYKe3WmUwdXfCZPEnRDA3mphY N5XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=VshVjuaGnYDoLIfeWhr1N/FEJ4yP8/Y08IFsFVtMBwg=; b=GhS9S/xLmMze7QZdXV24WWkva6z6PHOsVkG3IU2tHpIXDUg47MYinPqWhFly5Li0ll 8/5Mvn3CYQ0wgyOxe73V4zgtvfTviGxgqu63+PAJRyyNpXqNpCE0NGHX1S9KPHcxoUJc b7KQqV5ODyYwJVFEiabtFE8tVvKp4k+W1tGBpn55F9h6q8Qt6D8JRCb9RV+50AU3oW00 ovk2I+4+DkACmPHDf2Z3gGyTAyZoZu5B/eLsr6AZjvhSwTIc1alagM1IidFf5rnij2D3 no/Hadq6d3Z5xx6ENB5qBCQBy5vVqlNiGS2cwzv7l724DrFXVBD1GLuZWrFW4XD/OT0d ZzAw==
X-Gm-Message-State: AMke39kAVK5Bog84lb3tiWozQtFgrsTJXjLHeI4fBexNZRcDNhrFzuDza0HY9+IbCtv8nA==
X-Received: by 10.36.217.150 with SMTP id p144mr10276224itg.90.1486753341219;  Fri, 10 Feb 2017 11:02:21 -0800 (PST)
Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id v85sm1367421iov.34.2017.02.10.11.02.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 11:02:20 -0800 (PST)
To: "Dang, Quynh (Fed)" , Sean Turner , "" 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>  
From: Rene Struik 
Message-ID: <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com>
Date: Fri, 10 Feb 2017 14:02:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F0B747543E16567D336E241B"
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 19:02:24 -0000

This is a multi-part message in MIME format.
--------------F0B747543E16567D336E241B
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Quynh:

Not sure where to start (there is vast literature on side channel 
attacks and other implementation attacks). A good starting point would 
be the book [1], but one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does 
not merely study I/O behavior of crypto contructs, but also looks into 
what information can be obtained from what is going on "under the hood" 
of the computations (power consumption, radiation, timing, etc; or even 
invasive attacks). Most commonly one looks at crypto building blocks, 
but ultimately side channels can comprise any system behavior ("Lucky13" 
does, e.g., exploit this, if I remember correctly).

 From the last page of [2]: Finally, the most important conclusion from 
this paper is that it is not only a necessity but also a must, in the 
coming version of FIPS 140-3 standard, to evaluate cryptographic modules 
for their resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis 
Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
> Hi Rene,
>
> From: TLS > on 
> behalf of Rene Struik  >
> Date: Friday, February 10, 2017 at 10:51 AM
> To: Sean Turner >, 
> ">"  >
> Cc: IRTF CFRG >
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
> (#765/#769)
>
>     Dear colleagues:
>
>     I would suggest adding the following paragraph at the end of
>     Section 5.5:
>
>     [current text of Section 5.5]
>
>     There are cryptographic limits on the amount of plaintext which
>     can be safely encrypted under a given set of keys.[AEAD-LIMITS]
>     provides an
>     analysis of these limits under the assumption that the underlying
>     primitive (AES or ChaCha20) has no weaknesses. Implementations
>     SHOULD do a key updateSection 4.6.3
>     prior to reaching
>     these limits.
>
>     For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
>     be encrypted on a given connection while keeping a safety margin
>     of approximately 2^-57 for Authenticated Encryption (AE) security.
>     For ChaCha20/Poly1305, the record sequence number would wrap
>     before the safety limit is reached.
>
>     [suggested additional text]
>
>     The above upper limits do not take into account potential side
>     channel attacks, which - in some implementations - have been shown
>     to be successful at recovering keying material with a relatively
>     small number of messages encrypted using the same key. While
>     results are highly implementation-specific, thereby making it hard
>     to provide precise guidance, prudence suggests that
>     implementations should not reuse keys ad infinitum.
>     Implementations SHALL therefore always implement the key update
>     mechanism of Section 4.6.3.
>
>     {editorial note: perhaps, one should impose the limit 2^20, just
>     to make sure people do not "forget" to implement key updates?}
>
>
> How do you do side channel attacks on TLS ? Do these side-channel 
> attacks work for AES-GCM only in TLS 1.3 ?
>
>
>
>
>     See also my email of August 29, 2016:
>     https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno
>
>     On 2/10/2017 12:07 AM, Sean Turner wrote:
>>     All,
>>
>>     We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:
>>
>>     a) Close these two PRs and go with the existing text [0]
>>     b) Adopt PR#765 [1]
>>     c) Adopt PR#769 [2]
>>
>>     Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).
>>
>>     J&S
>>
>>     [0]https://tlswg.github.io/tls13-spec/#rfc.section.5.5
>>     [1]https://github.com/tlswg/tls13-spec/pull/765
>>     [2]https://github.com/tlswg/tls13-spec/pull/769
>>     _______________________________________________
>>     Cfrg mailing list
>>     Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>
>
>     -- 
>     email:rstruik.ext@gmail.com  | Skype: rstruik
>     cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------F0B747543E16567D336E241B
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Quynh:

      

      Not sure where to start (there is vast literature on side channel
      attacks and other implementation attacks). A good starting point
      would be the book [1], but one could also look at some NIST
      publications [2]. 

      

      Side channel attacks differs from cryptanalytic attacks in that it
      does not merely study I/O behavior of crypto contructs, but also
      looks into what information can be obtained from what is going on
      "under the hood" of the computations (power consumption,
      radiation, timing, etc; or even invasive attacks). Most commonly
      one looks at crypto building blocks, but ultimately side channels
      can comprise any system behavior ("Lucky13" does, e.g., exploit
      this, if I remember correctly).

      

      From the last page of [2]: Finally, the most important conclusion
      from this paper is that it is not only a necessity but
      also a must, in the coming version of FIPS 140-3 standard, to
      evaluate cryptographic modules for
      their resistivity against SCA attacks. 

      

      Ref:

      [1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis
      Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.

      [2]
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf

      [2] 

      

      

      On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:

    

    

      
      
Hi Rene, 

      


      

      
        

          From: TLS <tls-bounces@ietf.org>
          on behalf of Rene Struik <rstruik.ext@gmail.com>

          Date: Friday, February
          10, 2017 at 10:51 AM

          To: Sean Turner <sean@sn3rd.com>,
          "<tls@ietf.org>"
          <tls@ietf.org>

          Cc: IRTF CFRG <cfrg@irtf.org>

          Subject: Re: [TLS]
          [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
          (#765/#769)

        

        


        

        

          

            

              
Dear colleagues:

                

                I would suggest adding the following paragraph at the
                end of Section 5.5:

                

                [current text of Section 5.5]

                

                

                  There are cryptographic limits on the amount of
                  plaintext which can be safely encrypted under a given
                  set of keys. [AEAD-LIMITS] provides an
                  analysis of these limits under the assumption that the
                  underlying primitive (AES or ChaCha20) has no
                  weaknesses. Implementations SHOULD do a key update Section 4.6.3 prior to
                  reaching these limits.

                

                  For AES-GCM, up to 2^24.5 full-size records (about 24
                  million) may be encrypted on a given connection while
                  keeping a safety margin of approximately 2^-57 for
                  Authenticated Encryption (AE) security. For
                  ChaCha20/Poly1305, the record sequence number would
                  wrap before the safety limit is reached.

                [suggested additional text]

                

                The above upper limits do not take into account
                potential side channel attacks, which - in some
                implementations - have been shown to be successful at
                recovering keying material with a relatively small
                number of messages encrypted using the same key. While
                results are highly implementation-specific, thereby
                making it hard to provide precise guidance, prudence
                suggests that implementations should not reuse keys ad
                infinitum. Implementations SHALL therefore always
                implement the key update mechanism of Section 4.6.3.
                

                

                {editorial note: perhaps, one should impose the limit
                2^20, just to make sure people do not "forget" to
                implement key updates?}  
              

            

          

        

      
      


      

      
How do you do side channel attacks on TLS ? Do these
        side-channel attacks work for AES-GCM only in TLS 1.3 ?

      


      

      
        

          

            

              


                

                

                See also my email of August 29, 2016:

                https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

                

                On 2/10/2017 12:07 AM, Sean Turner wrote:

              

              

                
All,

We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg

              

              

              


              

              
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

            

          

        

      
    

    

    


    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------F0B747543E16567D336E241B--


From nobody Fri Feb 10 11:06:57 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B400129AAE for ; Fri, 10 Feb 2017 11:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 VjjZcCCPBjq2 for ; Fri, 10 Feb 2017 11:06:49 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00081.outbound.protection.outlook.com [40.107.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69151129AA8 for ; Fri, 10 Feb 2017 11:06:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6OzyjzLP4WJShn+EviFTB8rJm0DEwLTxO2uFz5XZZS0=; b=1zdo3QaGqbYnRrcryKHpxTeOkIhLmDQFmtVn1btWMH8+5HEa6UYwmo7bO6dKkxM34MQycERnT5BN0WAwK1+wPv3sLM0nNnRgqKSouiLVkJIGGC8kNXVxVpfXH8otgqvUvAh4b8J+mzc1srwYzdnjeeBN/bHZQ8FY1Z+phN4AgJ4=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 19:06:47 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.029; Fri, 10 Feb 2017 19:06:46 +0000
From: "Paterson, Kenny" 
To: "Dang, Quynh (Fed)" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ulN42j3rwAVkipPJ3aFAzvI6FhuukAgAA4koCAAD3QgIAATPYAgAAZ1gCAAANQAA==
Date: Fri, 10 Feb 2017 19:06:46 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>     
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.227.30]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:H/2lUTPrOyXAtY+2gLqUbtqRo8ML8FVIXma7sQleAuLcnRtHgmC90Z2z7yevEPa5rw3/XAMiNyf/covmUzwxSub9T8Rr5hI+zly/1c8VUD+vSnRi0U4Rt2U42ki6nyBq83knbJ8PrwQCTbu0RQNperZgQlGNdN/8PeBZlgFriX5Ww2ggNriAG9WG8Hmq2dZtKhEIujZmV5XN8sQm29zNEZHHnRrmFS/CXRZZDUh28hypBk2cvA0S5Yvw6QQYk6QFYC4eVKOdFy93AQrXuH7SXfFGlmz68BSS5iSPqcyvPbPhcW0i8tKCMVQDMmsRtiCpvo4MlZwgiMUFbgGb8c3eHpwNvwLlmllTIeUongbj50L4wc/PlO5FJ8xvKPzFlitBEMEcdPYEf6eODOxnJsLINGDhkwY1xvVPoWS69yBuWQ3gX4diPuGAnHw1xc25jFfAb+CempBL2B04FRZIZMdJQqNPwlFnhV7txiUHBi+bTB5s/p9E7B2oQNQtn7keOGrYOdOR5MnIFeBW82aTvdXOIg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(199003)(24454002)(189002)(42882006)(2900100001)(36756003)(2950100002)(7736002)(68736007)(122556002)(92566002)(189998001)(99286003)(4326007)(8656002)(25786008)(38730400002)(3280700002)(3660700001)(2906002)(6436002)(102836003)(6116002)(229853002)(3846002)(6506006)(6512007)(6306002)(50986999)(54356999)(101416001)(54906002)(76176999)(6486002)(83506001)(77096006)(81166006)(81156014)(86362001)(53936002)(66066001)(8936002)(105586002)(106356001)(8676002)(74482002)(106116001)(97736004)(305945005)(4001350100001)(5660300001)(93886004)(53546003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: c22cc956-a16e-4a46-fb30-08d451e7f5c2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1905; 
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)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; 
x-forefront-prvs: 0214EB3F68
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6FFCA153BE3F9A48827B06F167E1D928@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:06:46.7423 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 19:06:53 -0000

SGksDQoNCk9uIDEwLzAyLzIwMTcgMTg6NTYsICJEYW5nLCBRdXluaCAoRmVkKSIgPHF1eW5oLmRh
bmdAbmlzdC5nb3Y+IHdyb3RlOg0KDQo+RGVhciBLZW5ueSwgDQo+DQo+RnJvbTogIlBhdGVyc29u
LCBLZW5ueSIgPEtlbm55LlBhdGVyc29uQHJodWwuYWMudWs+DQo+RGF0ZTogRnJpZGF5LCBGZWJy
dWFyeSAxMCwgMjAxNyBhdCAxMjoyMiBQTQ0KPlRvOiAnUXV5bmgnIDxRdXluaC5EYW5nQG5pc3Qu
Z292PiwgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KPkNjOiBJUlRGIENGUkcgPGNmcmdA
aXJ0Zi5vcmc+LCAiPHRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc+DQo+U3ViamVjdDogUmU6
IFtUTFNdIFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgIkxpbWl0cyBvbiBrZXkgdXNhZ2UiIFBS
cw0KPigjNzY1LyM3NjkpDQo+DQo+DQo+DQo+PkRlYXIgUXV5bmgsDQo+Pg0KPj4NCj4+T24gMTAv
MDIvMjAxNyAxMjo0OCwgIkRhbmcsIFF1eW5oIChGZWQpIiA8cXV5bmguZGFuZ0BuaXN0Lmdvdj4g
d3JvdGU6DQo+Pg0KPj4NCj4+PkhpIEtlbm55LCANCj4+Pg0KPj4+DQo+Pj4+SGksDQo+Pj4+DQo+
Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+TXkgcHJlZmVyZW5jZSBpcyB0byBnbyB3aXRoIHRoZSBleGlz
dGluZyB0ZXh0LCBvcHRpb24gYSkuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+RnJvbSB0
aGUgZ2l0aHViIGRpc2N1c3Npb24sIEkgdGhpbmsgb3B0aW9uIGMpIGludm9sdmVzIGEgbGVzcw0K
Pj4+PmNvbnNlcnZhdGl2ZQ0KPj4+PnNlY3VyaXR5IGJvdW5kIChzdWNjZXNzIHByb2JhYmlsaXR5
IGZvciBJTkQtQ1BBIGF0dGFja2VyIGJvdW5kZWQgYnkNCj4+Pj4yXnstMzJ9IGluc3RlYWQgb2Yg
Ml57LTYwfSkuIEkgY2FuIGxpdmUgd2l0aCB0aGF0LCBidXQgdGhlIFdHIHNob3VsZCBiZQ0KPj4+
PmF3YXJlIG9mIHRoZSB3ZWFrZXIgc2VjdXJpdHkgZ3VhcmFudGVlcyBpdCBwcm92aWRlcy4NCj4+
Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj5JIGRvIG5vdCB1bmRlcnN0YW5kIG9wdGlvbiBiKS4g
SXQgc2VlbXMgdG8gcmVseSBvbiBhbiBhbmFseXNpcyBvZg0KPj4+PmNvbGxpc2lvbnMgb2YgY2lw
aGVydGV4dCBibG9ja3MgcmF0aGVyIHRoYW4gdGhlIGVzdGFibGlzaGVkIHNlY3VyaXR5DQo+Pj4+
cHJvb2YNCj4+Pj5mb3IgQUVTLUdDTS4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+
DQo+Pj4NCj4+Pg0KPj4+TXkgc3VnZ2VzdGlvbiB3YXMgYmFzZWQgb24gY291bnRpbmcuICBJIGFu
YWx5emVkIEFFUy1HQ00gaW4gVExTIDEuMyAgYXMNCj4+PmJlaW5nIGEgY291bnRlci1tb2RlIGVu
Y3J5cHRpb24gYW5kIGVhY2ggY291bnRlciBpcyBhIDk2LWJpdCBub25jZSB8fA0KPj4+MzItYml0
IGNvdW50ZXIuIEkgZG9u4oCZdCBrbm93IGlmIHRoZXJlIGlzIGFub3RoZXIga2luZCBvZiBwcm9v
ZiB0aGF0IGlzDQo+Pj5tb3JlIHByZWNpc2UgdGhhbiB0aGF0Lg0KPj4NCj4+DQo+PlRoYW5rcyBm
b3IgZXhwbGFpbmluZy4gSSB0aGluaywgdGhlbiwgdGhhdCB3aGF0IHlvdSBhcmUgZG9pbmcgaXMg
KGluDQo+PmVmZmVjdCkgYWNjb3VudGluZyBmb3IgdGhlIFBSUC9QUkYgc3dpdGNoaW5nIGxlbW1h
IHRoYXQgaXMgdXNlZCAoaW4gYQ0KPj5zdGFuZGFyZCB3YXkpIGFzIHBhcnQgb2YgdGhlIElORC1D
UEEgc2VjdXJpdHkgcHJvb2Ygb2YgQUVTLUdDTS4gT25lIGNhbg0KPj5vYnRhaW4gYSBncmVhdGVy
IGRlZ3JlZSBvZiBwcmVjaXNpb24gYnkgdXNpbmcgdGhlIHByb3ZlbiBib3VuZHMgZm9yDQo+PklO
RC1DUEEgc2VjdXJpdHkgb2YgQUVTLUdDTS4gVGhlc2UgaW5jb3Jwb3JhdGUgdGhlICJzZWN1cml0
eSBsb3NzIiBjb21pbmcNCj4+ZnJvbSB0aGUgUFJQL1BSRiBzd2l0Y2hpbmcgbGVtbWEuIFRoZSBj
dXJyZW50IGJlc3QgZm9ybSBvZiB0aGVzZSBib3VuZHMNCj4+aXMNCj4+ZHVlIHRvIEl3YXRhIGV0
IGFsLi4gVGhpcyBpcyBwcmVjaXNlbHkgd2hhdCB3ZSBhbmFseXNlIGluIHRoZSBub3RlIGF0DQo+
Pmh0dHA6Ly93d3cuaXNnLnJodWwuYWMudWsvfmtwL1RMUy1BRWJvdW5kcy5wZGYgLSBzcGVjaWZp
Y2FsbHksIHNlZQ0KPj5lcXVhdGlvbnMgKDUpIC0gKDcpIG9uIHBhZ2UgNiBvZiB0aGF0IG5vdGUu
DQo+Pg0KPg0KPkkgcmV2aWV3ZWQgdGhlIHBhcGVyIG1vcmUgdGhhbiBvbmNlLiBJIGhpZ2hseSB2
YWx1ZSB0aGUgd29yay4gSSBzdWdnZXN0ZWQNCj50byByZWZlcmVuY2UgIHlvdXIgcGFwZXIgaW4g
dGhlIHRleHQuICBJIHRoaW5rIHRoZSByZXN1bHQgaW4geW91ciBwYXBlcg0KPmlzIHRoZSBzYW1l
IHdpdGggd2hhdCBpcyBiZWluZyBzdWdnZXN0ZWQgd2hlbiB0aGUgY29sbGlzaW9uIHByb2JhYmls
aXR5DQo+YWxsb3dlZCBpcyAyXigtMzIpLg0KDQpUaGFua3MgZm9yIHRoaXMgZmVlZGJhY2suIEkg
Z3Vlc3MgbXkgY29uZnVzaW9uIGFyaXNlcyBmcm9tIHdvbmRlcmluZyB3aGF0DQp5b3UgbWVhbiBi
eSBjb2xsaXNpb24gcHJvYmFiaWxpdHkgYW5kIHdoeSB5b3UgY2FyZSBhYm91dCBpdC4gVGhlcmUg
YXJlIG5vDQpjb2xsaXNpb25zIGluIHRoZSBibG9jayBjaXBoZXIncyBvdXRwdXRzIHBlciBzZSwg
YmVjYXVzZSBBRVMgaXMgYQ0KcGVybXV0YXRpb24gZm9yIGVhY2ggY2hvaWNlIG9mIGtleS4gQW5k
IGNvbGxpc2lvbnMgaW4gdGhlIGNpcGhlcnRleHQNCmJsb2NrcyBvdXRwdXQgYnkgQUVTLUdDTSBh
cmUgaXJyZWxldmFudCB0byBpdHMgZm9ybWFsIHNlY3VyaXR5IGFuYWx5c2lzLg0KDQpPbiB0aGUg
b3RoZXIgaGFuZCwgd2hlbiBpbiB0aGUgcHJvb2Ygb2YgSU5ELUNQQSBzZWN1cml0eSBvZiBBRVMt
R0NNIG9uZQ0Kc3dpdGNoZXMgZnJvbSBhIHJhbmRvbSBwZXJtdXRhdGlvbiAod2hpY2ggaXMgaG93
IHdlIG1vZGVsIEFFUykgdG8gYSByYW5kb20NCmZ1bmN0aW9uICh3aGljaCBpcyB3aGF0IHdlIG5l
ZWQgdG8gYXJndWUgaW4gdGhlIGVuZCB0aGF0IHRoZSBwbGFpbnRleHQgaXMNCm1hc2tlZCBieSBh
IG9uZS10aW1lIHBhZCwgZ2l2aW5nIGluZGlzdGluZ3Vpc2hhYmlsaXR5KSwgdGhlbiBvbmUgbmVl
ZHMgdG8NCmRlYWwgd2l0aCB0aGUgcHJvYmFiaWxpdHkgdGhhdCBjb2xsaXNpb25zIG9jY3VyIGlu
IHRoZSBmdW5jdGlvbidzIG91dHB1dHMNCmJ1dCBub3QgaW4gdGhlIHBlcm11dGF0aW9uJ3MuIFRo
aXMgZW5kcyB1cCBiZWluZyB0aGUgbWFpbiBjb250cmlidXRpb24gdG8NCnRoZSBzZWN1cml0eSBi
b3VuZCBpbiB0aGUgcHJvb2YgZm9yIElORC1DUEEgc2VjdXJpdHkuDQoNCklzIHRoYXQgd2hhdCB5
b3UgYXJlIGdldHRpbmcgYXQ/DQoNCklmIHNvLCB0aGVuIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdl
LCBhbmQgd2hhdCByZW1haW5zIGlzIHRvIGRlY2lkZSB3aGV0aGVyDQphIDJeey0zMn0gYm91bmQg
aXMgYSBnb29kIGVub3VnaCBzZWN1cml0eSBtYXJnaW4uDQoNClJlZ2FyZHMsDQoNCktlbm55DQoN
Cg0K


From nobody Fri Feb 10 11:36:39 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C090129B25 for ; Fri, 10 Feb 2017 11:36:33 -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=unavailable 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 F_7xSwNfeU2p for ; Fri, 10 Feb 2017 11:36:29 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0135.outbound.protection.outlook.com [23.103.200.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AA3129B24 for ; Fri, 10 Feb 2017 11:36:29 -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=/RC4K1ufqEUjFKfO3hV6JxqyREy5B+X+4Ap5X2ylSOE=; b=tb0AR19uLfrFkx+ChxBNK7ffOPlFEiPO9rRKvw1oLlzShMWaS0lmf2f05XngUCQ8K5zG9+ucIKVzFJcN96/jWTDmCuquLMylpjGnjPy16CmrU/MSZzYb3CnoRIl47GptwKwqgTBhtaN1qjsbxe1tYr015a66kGBi0KyUsQPdDeQ=
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.888.16; Fri, 10 Feb 2017 19:36:27 +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.0888.026; Fri, 10 Feb 2017 19:36:27 +0000
From: "Dang, Quynh (Fed)" 
To: Rene Struik , Sean Turner , "" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0KFimMQAgAAIvxk=
Date: Fri, 10 Feb 2017 19:36:27 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>  , <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com>
In-Reply-To: <51978c0d-f944-5ebf-ee85-cdc801568e8a@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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-ms-office365-filtering-correlation-id: af8743ad-29f3-4eb2-9bad-08d451ec1b1a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:Tvmz1I9smEOm634E2dtS/81MKf6JD46qJvRc18qtWl4vLJGdx5K2mrUpOLTzRH+s8Y9AQZrBdRmovUFkIm7RBv/VybzvDclEDzGQC1FgRmUlSKw47BH89xakgL95d4hwrXHtV3aMDQOV0JCfLjA6nh55TgyHq/fcLHVjtoJ7KiPzTFSH0wxZR4c9VMPJYNQ41XAVILS/SjlqvyawGzCrJsGvlWoKJ40ybni1Io5ehLnCTLVfLAz1bVzMZFzMpvehOvX/WusZuzTU9ILUymhU+fMtXDTjHB2zK5j+GctlBPieX7/Kel+44hON2aC6SOzf5PDZ1NQS83jnUbWXyfo0SjlOZdYVJi/8H/MKmXVXIFiiDLRAj+7ExeAPCycWlHyFAF8j+t+akG0qfBcL609eEs+yM/7+HtK7QPJne7iqcSf81akTh8oZURrODJHjcpS9garZ6BvY4bHXrFsX4/ysdCL7YnQgc3uPDmmenVBGvHvxjfGNdJ1DOheBvj6nV3fpUeV+RX3N4yXhCRtjnIw4Gw==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(65766998875637)(166708455590820)(100405760836317)(131022147185803); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(199003)(24454002)(377454003)(189002)(86362001)(122556002)(575784001)(50986999)(66066001)(54356999)(3280700002)(76176999)(189998001)(3660700001)(4326007)(68736007)(2906002)(2900100001)(81166006)(81156014)(38730400002)(7906003)(8936002)(16297215004)(39060400001)(74316002)(8676002)(7736002)(106356001)(105586002)(6246003)(53546003)(106116001)(19627405001)(3846002)(7696004)(92566002)(77096006)(229853002)(6436002)(2950100002)(966004)(5660300001)(9686003)(99286003)(102836003)(93886004)(55016002)(325944008)(33656002)(97736004)(101416001)(236005)(606005)(54896002)(25786008)(6116002)(6506006)(6306002)(53936002)(491001); 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; 
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_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:36:27.3491 (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: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2017 19:36:33 -0000

--_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Rene,


I care about side channel attacks in general as much as you do. But my ques=
tion was that how you carry out those attacks on GCM in TLS 1.3's servers a=
nd clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 ?


Quynh.

________________________________
From: Rene Struik 
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner; 
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Quynh:

Not sure where to start (there is vast literature on side channel attacks a=
nd other implementation attacks). A good starting point would be the book [=
1], but one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does not=
 merely study I/O behavior of crypto contructs, but also looks into what in=
formation can be obtained from what is going on "under the hood" of the com=
putations (power consumption, radiation, timing, etc; or even invasive atta=
cks). Most commonly one looks at crypto building blocks, but ultimately sid=
e channels can comprise any system behavior ("Lucky13" does, e.g., exploit =
this, if I remember correctly).

>From the last page of [2]: Finally, the most important conclusion from this=
 paper is that it is not only a necessity but also a must, in the coming ve=
rsion of FIPS 140-3 standard, to evaluate cryptographic modules for their r=
esistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks =
- Revealing the Secrets of Smart Cards", Springer, 2007.
[2] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/=
physecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene,

From: TLS > on behalf of =
Rene Struik >
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner >, ">" >
Cc: IRTF CFRG >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]


There are cryptographic limits on the amount of plaintext which can be safe=
ly encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the =
assumption that the underlying primitive (AES or ChaCha20) has no weaknesse=
s. Implementations SHOULD do a key update Section 4.6.3 prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry=
pted on a given connection while keeping a safety margin of approximately 2=
^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the=
 record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel atta=
cks, which - in some implementations - have been shown to be successful at =
recovering keying material with a relatively small number of messages encry=
pted using the same key. While results are highly implementation-specific, =
thereby making it hard to provide precise guidance, prudence suggests that =
implementations should not reuse keys ad infinitum. Implementations SHALL t=
herefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make su=
re people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks w=
ork for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner wrote:

All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cf=
rg



--
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



--
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

--_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










Hi Rene,







I care about side channel attacks in general as much as you do. But my q=
uestion was that how you carry out those attacks on GCM in TLS 1.3's server=
s and clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 =
?







Quynh. 






From: Rene Struik <rstru=
ik.ext@gmail.com>

Sent: Friday, February 10, 2017 2:02:14 PM

To: Dang, Quynh (Fed); Sean Turner; <tls@ietf.org>

Cc: IRTF CFRG

Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa=
ge" PRs (#765/#769)

 






Hi Quynh:



Not sure where to start (there is vast literature on side channel attacks a=
nd other implementation attacks). A good starting point would be the book [=
1], but one could also look at some NIST publications [2].




Side channel attacks differs from cryptanalytic attacks in that it does not=
 merely study I/O behavior of crypto contructs, but also looks into what in=
formation can be obtained from what is going on "under the hood" =
of the computations (power consumption, radiation,
 timing, etc; or even invasive attacks). Most commonly one looks at crypto =
building blocks, but ultimately side channels can comprise any system behav=
ior ("Lucky13" does, e.g., exploit this, if I remember correctly)=
.



>From the last page of [2]: Finally, the most important conclusion from this=
 paper is that it is not only a necessity but also a must, in the coming ve=
rsion of FIPS 140-3 standard, to evaluate cryptographic modules for their r=
esistivity against SCA attacks.




Ref:

[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Att=
acks - Revealing the Secrets of Smart Cards", Springer, 2007.

[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/phys=
ecpaper19.pdf

[2] 





On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:






Hi Rene, 









From: TLS <tls-bounces@ietf.org> on=
 behalf of Rene Struik <rstruik.ext@gmail.com>

Date: Friday, February 10, 2017 at =
10:51 AM

To: Sean Turner <sean@sn3rd.com>, "&=
lt;tls@ietf.org>" <tl=
s@ietf.org>

Cc: IRTF CFRG <cfrg@irtf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Dear colleagues:



I would suggest adding the following paragraph at the end of Section 5.5:


[current text of Section 5.5]





There are cryptographic limits on the amount of plaintext which can be safe=
ly encrypted under a given set of keys. [AEAD-LIMITS] provides
 an analysis of these limits under the assumption that the underlying primi=
tive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key u=
pdate Section
 4.6.3 prior to reach=
ing these limits.



For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encry=
pted on a given connection while keeping a safety margin of approximately 2=
^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the=
 record sequence number would wrap
 before the safety limit is reached.

[suggested additional text]



The above upper limits do not take into account potential side channel atta=
cks, which - in some implementations - have been shown to be successful at =
recovering keying material with a relatively small number of messages encry=
pted using the same key. While results
 are highly implementation-specific, thereby making it hard to provide prec=
ise guidance, prudence suggests that implementations should not reuse keys =
ad infinitum. Implementations SHALL therefore always implement the key upda=
te mechanism of Section 4.6.3.




{editorial note: perhaps, one should impose the limit 2^20, just to make su=
re people do not "forget" to implement key updates?}  















How do you do side channel attacks on TLS ? Do these side-channel atta=
cks work for AES-GCM only in TLS 1.3 ?




















See also my email of August 29, 2016:

https://ma=
ilarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno



On 2/10/2017 12:07 AM, Sean Turner wrote:






All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/t=
ls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-s=
pec/pull/765
[2] https://github.com/tlswg/tls13-s=
pec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghtt=
ps://www.irtf.org/mailman/listinfo/cfrg











--=20
email: rstruik.ext@gmail.com | Skype: rstrui=
k
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

















--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363






--_000_CY4PR09MB146415E668A3DA0484190BC9F3440CY4PR09MB1464namp_--


From nobody Sat Feb 11 03:45:57 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5123129487 for ; Sat, 11 Feb 2017 03:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 UGe93g1ybWtk for ; Sat, 11 Feb 2017 03:45:53 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0137.outbound.protection.outlook.com [23.103.200.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DAC12943F for ; Sat, 11 Feb 2017 03:45:53 -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=ffKQBAdY2pe2Gi4drtZbYY1DPdt5/4PYae54pkL7CJc=; b=uwFuU7ToqwBL5956rT/6x+u8ejae4BPp629RG/Fe60tWJk4uONLg8hkUSmxiAe47XUhSI/lVHDnEjzz2w0UYkFQYanwP6fQaf3ODY1WwjkE5k6MguSGB30wt7b2B2x2TGN/vnvb8Up+QKqA2YjsTklfCBNh8ifWHeag9OAt1k4o=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sat, 11 Feb 2017 11:45:51 +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.0888.029; Sat, 11 Feb 2017 11:45:51 +0000
From: "Dang, Quynh (Fed)" 
To: "Paterson, Kenny" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg5wBoDZYWLM7Y0meekq7MUVdlqFifU4A///GdACAAFarAIAACkUT
Date: Sat, 11 Feb 2017 11:45:50 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>     ,
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.220.15]
x-ms-office365-filtering-correlation-id: 010cf658-4236-4851-505c-08d452738747
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:77HJ+r0k39QXT6OJNTDLScniEDewV25aRVteVWKPP9iGc5tUWJMv9H0yZt/9PkWptGKLo50pl94w+cJ7LD7EKE86drDJXOP77C0OOhszfcgsH1WeuQSwpItCgqQ9BIolm0z16NqP86iH/xDacTORK86/Y+glnW9/Dy6vO/9AiAt3noTXzQTUZJ8fQbeejRwiO1pys/xlapYG2IvBJKzwtAnBQTkINcl/mMLhGUQtIHtQfKT4OJHEc0buG9eo/hdsGBCPIcEcmAnCiZXVpEwA12srJ4XtzkDkgO5kqHo7deooA0REAYC/6Le7npra1b3DOo2VIAhVkKkLpRnfRtKtpbkQ/nnRz1pkdyqDnyFm6qdzKfqdHNmREZnM4GsPnLWmUYnXL7zzG29JHy/NngO8KcQgck191x6WByRuyHX3+OaknAi6weSJ7FdYmfpzaOZfcfmaAzAzczQDBoX0n3CO3dF5Q6Z1T+rUQOw1Vly8ulnohJ5RlzH9f+4N4l6q4Cl6gtpNR5xPWHVXZaHG9/9Vyg==
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)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; 
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39860400002)(39410400002)(39450400003)(39840400002)(24454002)(199003)(377454003)(189002)(6246003)(53546003)(66066001)(6606003)(38730400002)(74316002)(3660700001)(93886004)(3846002)(6116002)(102836003)(2950100002)(189998001)(97736004)(68736007)(101416001)(122556002)(3280700002)(7736002)(4326007)(7906003)(2906002)(76176999)(7696004)(54356999)(50986999)(5660300001)(8656002)(54906002)(25786008)(54896002)(6306002)(92566002)(99286003)(55016002)(2900100001)(33656002)(105586002)(53936002)(86362001)(106356001)(106116001)(15974865002)(236005)(8936002)(229853002)(9686003)(77096006)(81166006)(8676002)(19627405001)(606005)(6436002)(81156014)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; 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_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2017 11:45:50.6413 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2017 11:45:56 -0000

--_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Kenny,


AES-permutation is a permutation.  But, AES-GCM (AES in counter mode) is a =
PRF as long as the 128-bit IVs are unique under the encryption key.  The am=
ount of plaintext is the same with the amount of ciphertext.


I originally talked about plaintext in my discussion, but several people as=
ked me to talk about ciphertext instead (I thought maybe measuring cipherte=
xt was easier than measuring plaintext in practice and that was why they as=
ked me that).


The number of 128-bit blocks of plaintext is the same with the number of 12=
8-bit "one-time pad" keys produced by the AES key and the unique 128-bit IV=
s. These 128-bit "one-time pad" keys and the corresponding 128-bit cipherte=
xt blocks are the same in the sense that they are both sets of pseudo-rando=
m 128-bit blocks.  But, the 128-bit "one-time pad" keys are not stored, the=
y have to either measure the amount of plaintext or ciphertext.


Regards,

Quynh.



________________________________
From: Paterson, Kenny 
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG; 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi,

On 10/02/2017 18:56, "Dang, Quynh (Fed)"  wrote:

>Dear Kenny,
>
>From: "Paterson, Kenny" 
>Date: Friday, February 10, 2017 at 12:22 PM
>To: 'Quynh' , Sean Turner 
>Cc: IRTF CFRG , "" 
>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>(#765/#769)
>
>
>
>>Dear Quynh,
>>
>>
>>On 10/02/2017 12:48, "Dang, Quynh (Fed)"  wrote:
>>
>>
>>>Hi Kenny,
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>
>>>>My preference is to go with the existing text, option a).
>>>>
>>>>
>>>>
>>>>
>>>>From the github discussion, I think option c) involves a less
>>>>conservative
>>>>security bound (success probability for IND-CPA attacker bounded by
>>>>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>>>>aware of the weaker security guarantees it provides.
>>>>
>>>>
>>>>
>>>>
>>>>I do not understand option b). It seems to rely on an analysis of
>>>>collisions of ciphertext blocks rather than the established security
>>>>proof
>>>>for AES-GCM.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
>>>being a counter-mode encryption and each counter is a 96-bit nonce ||
>>>32-bit counter. I don=92t know if there is another kind of proof that is
>>>more precise than that.
>>
>>
>>Thanks for explaining. I think, then, that what you are doing is (in
>>effect) accounting for the PRP/PRF switching lemma that is used (in a
>>standard way) as part of the IND-CPA security proof of AES-GCM. One can
>>obtain a greater degree of precision by using the proven bounds for
>>IND-CPA security of AES-GCM. These incorporate the "security loss" coming
>>from the PRP/PRF switching lemma. The current best form of these bounds
>>is
>>due to Iwata et al.. This is precisely what we analyse in the note at
>>http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
Limits on Authenticated Encryption Use in TLS - isg.rhul.ac.uk
www.isg.rhul.ac.uk
Limits on Authenticated Encryption Use in TLS Atul Luykx and Kenneth G. Pat=
erson March 8, 2016 Abstract Thistechnicalnotepresentslimitsonthesecurity(a=
safunctionofthe



>>equations (5) - (7) on page 6 of that note.
>>
>
>I reviewed the paper more than once. I highly value the work. I suggested
>to reference  your paper in the text.  I think the result in your paper
>is the same with what is being suggested when the collision probability
>allowed is 2^(-32).

Thanks for this feedback. I guess my confusion arises from wondering what
you mean by collision probability and why you care about it. There are no
collisions in the block cipher's outputs per se, because AES is a
permutation for each choice of key. And collisions in the ciphertext
blocks output by AES-GCM are irrelevant to its formal security analysis.

On the other hand, when in the proof of IND-CPA security of AES-GCM one
switches from a random permutation (which is how we model AES) to a random
function (which is what we need to argue in the end that the plaintext is
masked by a one-time pad, giving indistinguishability), then one needs to
deal with the probability that collisions occur in the function's outputs
but not in the permutation's. This ends up being the main contribution to
the security bound in the proof for IND-CPA security.

Is that what you are getting at?

If so, then we are on the same page, and what remains is to decide whether
a 2^{-32} bound is a good enough security margin.

Regards,

Kenny



--_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable




















Hi Kenny,







AES-permutation is a permutation.  But, AES-GCM (AES in counter mod=
e) is a PRF as long as the 128-bit IVs are unique under the encryption key.=
  The amount of plaintext is the same with the amount of ciphertext.






I originally talked about plaintext in my discussion, but several people=
 asked me to talk about ciphertext instead (I thought maybe measuring ciphe=
rtext was easier than measuring plaintext in practice and that was why they=
 asked me that). 







The number of 128-bit blocks of plaintext is the same with the number of=
 128-bit "one-time pad" keys produced by the AES key and the uniq=
ue 128-bit IVs. These 128-bit "one-time pad" keys and the co=
rresponding 128-bit ciphertext blocks are the same in the
 sense that they are both sets of pseudo-random 128-bit blocks.  But, =
the 128-bit "one-time pad" keys are not stored, they have to eith=
er measure the amount of plaintext or ciphertext. 







Regards,


Quynh. 


















From: Paterson, Kenny <=
;Kenny.Paterson@rhul.ac.uk>

Sent: Friday, February 10, 2017 2:06:46 PM

To: Dang, Quynh (Fed); Sean Turner

Cc: IRTF CFRG; <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa=
ge" PRs (#765/#769)

 







Hi,



On 10/02/2017 18:56, "Dang, Quynh (Fed)" <quynh.dang@nist.gov&=
gt; wrote:



>Dear Kenny, 

>

>From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>

>Date: Friday, February 10, 2017 at 12:22 PM

>To: 'Quynh' <Quynh.Dang@nist.gov>, Sean Turner <sean@sn3rd.com=
>

>Cc: IRTF CFRG <cfrg@irtf.org>, "<tls@ietf.org>" &=
lt;tls@ietf.org>

>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage&=
quot; PRs

>(#765/#769)

>

>

>

>>Dear Quynh,

>>

>>

>>On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.dang@n=
ist.gov> wrote:

>>

>>

>>>Hi Kenny, 

>>>

>>>

>>>>Hi,

>>>>

>>>>

>>>>

>>>>

>>>>My preference is to go with the existing text, option a).
>>>>

>>>>

>>>>

>>>>

>>>>From the github discussion, I think option c) involves a le=
ss

>>>>conservative

>>>>security bound (success probability for IND-CPA attacker bo=
unded by

>>>>2^{-32} instead of 2^{-60}). I can live with that, but the =
WG should be

>>>>aware of the weaker security guarantees it provides.

>>>>

>>>>

>>>>

>>>>

>>>>I do not understand option b). It seems to rely on an analy=
sis of

>>>>collisions of ciphertext blocks rather than the established=
 security

>>>>proof

>>>>for AES-GCM.

>>>>

>>>>

>>>>

>>>>

>>>

>>>

>>>

>>>

>>>My suggestion was based on counting.  I analyzed AES-GCM i=
n TLS 1.3  as

>>>being a counter-mode encryption and each counter is a 96-bit no=
nce ||

>>>32-bit counter. I don=92t know if there is another kind of proo=
f that is

>>>more precise than that.

>>

>>

>>Thanks for explaining. I think, then, that what you are doing is (i=
n

>>effect) accounting for the PRP/PRF switching lemma that is used (in=
 a

>>standard way) as part of the IND-CPA security proof of AES-GCM. One=
 can

>>obtain a greater degree of precision by using the proven bounds for=


>>IND-CPA security of AES-GCM. These incorporate the "security l=
oss" coming

>>from the PRP/PRF switching lemma. The current best form of these bo=
unds

>>is

>>due to Iwata et al.. This is precisely what we analyse in the note =
at

>>http://www.isg.rhul.ac.uk/~kp/TLS-AEboun=
ds.pdf - specifically, see





>>equations (5) - (7) on page 6 of that note.

>>

>

>I reviewed the paper more than once. I highly value the work. I suggest=
ed

>to reference  your paper in the text.  I think the result in =
your paper

>is the same with what is being suggested when the collision probability=


>allowed is 2^(-32).



Thanks for this feedback. I guess my confusion arises from wondering what
you mean by collision probability and why you care about it. There are no
collisions in the block cipher's outputs per se, because AES is a

permutation for each choice of key. And collisions in the ciphertext

blocks output by AES-GCM are irrelevant to its formal security analysis.


On the other hand, when in the proof of IND-CPA security of AES-GCM one

switches from a random permutation (which is how we model AES) to a random<=
br>
function (which is what we need to argue in the end that the plaintext is
masked by a one-time pad, giving indistinguishability), then one needs to
deal with the probability that collisions occur in the function's outputs
but not in the permutation's. This ends up being the main contribution to
the security bound in the proof for IND-CPA security.



Is that what you are getting at?



If so, then we are on the same page, and what remains is to decide whether<=
br>
a 2^{-32} bound is a good enough security margin.



Regards,



Kenny












--_000_CY4PR09MB146498613751F2C400FAC876F3440CY4PR09MB1464namp_--


From nobody Sat Feb 11 14:26:38 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5B1294A6 for ; Sat, 11 Feb 2017 14:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 1matrBJn5W4j for ; Sat, 11 Feb 2017 14:26:34 -0800 (PST)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 D2F711294A9 for ; Sat, 11 Feb 2017 14:26:34 -0800 (PST)
Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-04v.sys.comcast.net with SMTP id cg7ZcTMT9xUJacg7mchfFL; Sat, 11 Feb 2017 22:26:34 +0000
Received: from [192.168.0.10] ([24.5.144.109]) by resomta-po-16v.sys.comcast.net with SMTP id cg7kc7T1TZHQdcg7lcPdGg; Sat, 11 Feb 2017 22:26:34 +0000
To: cfrg@irtf.org
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
From: Andrey Jivsov 
Message-ID: 
Date: Sat, 11 Feb 2017 14:26:31 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfIrRNC2ECcq9hyxNxpRErWYylz0YiQYH9a9NSF+YkoXk5owrBNT6x9/uWoWdP+TXPMcUtavSt/qv0fwx7MKBkVKdsCPgfkbIwCpFRi8HxthmDL0olN1B SDBjWjavyWYClFwuaO0FijFpZ1PP2oeEgNxVERN5Rs6TxDDEFvVLIk2i
Archived-At: 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2017 22:26:37 -0000

On 02/09/2017 09:07 PM, Sean Turner wrote:
> All,
>
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usageâ€.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:
>
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]
>
> Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).
>
> J&S
>
> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
> [1] https://github.com/tlswg/tls13-spec/pull/765
> [2] https://github.com/tlswg/tls13-spec/pull/769

I am an author of [2].

I originally thought that [0] could be improved, but [1], as seems to be 
a consensus, made the text even less clear, which motivated me to 
contribute.

I see 2 main issues with [0]:

1. Counting in records. Worse, it counts in maximum-size records.

The original problem is measured in cipherblocks (16 bytes in TLS 1.3). 
Advanced products have the max TLS record size configurable. TLS stacks 
should not be expected to buffer the data to fill up the record, 
therefore, they are also sending many shorter records.

How should an implementer read [0]? If an implementation sends or 
receives shorter records, it has to re-key sooner.

Counting in bytes or cipher blocks is better. Implementers wishing to 
count in records can translate bytes into records easier that perform 
the reverse with [0] (however, I don't understand how counting in 
records can work correctly).

2. The numbers in [0] are not explained.

Given that I don't know the "components" of the formula, I am not 
exactly sure how to make adjustments for the #1.

The text in [0] should be clarified to show "components", e.g. what 
success probability was used.

( I recall that when [0] was worked on, there were discussions about 
multi-session issues. Was this a consideration? )


Finally, [1] assumed P=1/2^32 as a consensus-building choice. NIST uses 
this value to state limits on AES-GCM IVs 
(http://dx.doi.org/10.6028/NIST.SP.800-38D sec 8, 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf 
sec A.5)

I would be happy with a lower value of P.

I think, however, that a comparison with the 3DES can be helpful. The 
recent SWEET32 attack on 3DES works with the practical P=1/2. Using 
P=1/2^32 for 3DES implies rekeying after 0.5Mbytes of traffic. I suspect 
that these who implemented data limits for 3DES rekey less often than on 
each 0.5Mb.


From nobody Sat Feb 11 14:38:03 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5412958C for ; Sat, 11 Feb 2017 14:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZHwwhblxb0jy for ; Sat, 11 Feb 2017 14:37:59 -0800 (PST)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 F1EAB129583 for ; Sat, 11 Feb 2017 14:37:58 -0800 (PST)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-12v.sys.comcast.net with SMTP id cgIcc86kenZkvcgIoc1Bq0; Sat, 11 Feb 2017 22:37:58 +0000
Received: from [192.168.0.10] ([24.5.144.109]) by resomta-po-18v.sys.comcast.net with SMTP id cgIncdVZwCvcHcgIncPYsY; Sat, 11 Feb 2017 22:37:58 +0000
To: cfrg@irtf.org
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> 
From: Andrey Jivsov 
Message-ID: <74cbf937-7aae-1110-955c-3d04190bad0d@brainhub.org>
Date: Sat, 11 Feb 2017 14:37:55 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfOEE0kZtyfT7ncvO0gV1RGJG5TQMw2InD9Dm+SeYK406c4lrHYDvjtC/JkLZJybMk56PFc/Rw+/tlZ2sV7KLNYC0bVWOwRO8x4L77ON+RGa4DURaQ/nK +Iew6Ey1Dirfkjh4KfjesG2iRcydatGJAZdJatGsTHsWwfyE5LjuaQ24
Archived-At: 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2017 22:38:01 -0000

Correction: we rekey faster than needed when we count in records if the 
average record is shorter than the maximum allowed. Regardless, because 
the record size can vary by a factor of 1000 in size (up to 2^14), it's 
cleaner to count in bytes. This matters the most for 3DES, but I don't 
see much difference in implementation complexity between counting in 
records v.s. bytes.

On 02/11/2017 02:26 PM, Andrey Jivsov wrote:
>
> On 02/09/2017 09:07 PM, Sean Turner wrote:
>> All,
>>
>> We’ve got two outstanding PRs that propose changes to 
>> draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usageâ€.  As it 
>> relates to rekeying, these limits have been discussed a couple of 
>> times and we need to resolve once and for all whether the TLS WG 
>> wants to:
>>
>> a) Close these two PRs and go with the existing text [0]
>> b) Adopt PR#765 [1]
>> c) Adopt PR#769 [2]
>>
>> Please indicate you preference to the TLS mailing list before Feb 
>> 17.  Note that unless there’s clear consensus to change the text will 
>> remain as is (i.e., option a).
>>
>> J&S
>>
>> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
>> [1] https://github.com/tlswg/tls13-spec/pull/765
>> [2] https://github.com/tlswg/tls13-spec/pull/769
>
> I am an author of [2].
>
> I originally thought that [0] could be improved, but [1], as seems to 
> be a consensus, made the text even less clear, which motivated me to 
> contribute.
>
> I see 2 main issues with [0]:
>
> 1. Counting in records. Worse, it counts in maximum-size records.
>
> The original problem is measured in cipherblocks (16 bytes in TLS 
> 1.3). Advanced products have the max TLS record size configurable. TLS 
> stacks should not be expected to buffer the data to fill up the 
> record, therefore, they are also sending many shorter records.
>
> How should an implementer read [0]? If an implementation sends or 
> receives shorter records, it has to re-key sooner.
>
> Counting in bytes or cipher blocks is better. Implementers wishing to 
> count in records can translate bytes into records easier that perform 
> the reverse with [0] (however, I don't understand how counting in 
> records can work correctly).
>
> 2. The numbers in [0] are not explained.
>
> Given that I don't know the "components" of the formula, I am not 
> exactly sure how to make adjustments for the #1.
>
> The text in [0] should be clarified to show "components", e.g. what 
> success probability was used.
>
> ( I recall that when [0] was worked on, there were discussions about 
> multi-session issues. Was this a consideration? )
>
>
> Finally, [1] assumed P=1/2^32 as a consensus-building choice. NIST 
> uses this value to state limits on AES-GCM IVs 
> (http://dx.doi.org/10.6028/NIST.SP.800-38D sec 8, 
> http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf 
> sec A.5)
>
> I would be happy with a lower value of P.
>
> I think, however, that a comparison with the 3DES can be helpful. The 
> recent SWEET32 attack on 3DES works with the practical P=1/2. Using 
> P=1/2^32 for 3DES implies rekeying after 0.5Mbytes of traffic. I 
> suspect that these who implemented data limits for 3DES rekey less 
> often than on each 0.5Mb.



From nobody Sun Feb 12 01:44:28 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C756B1293E8 for ; Sun, 12 Feb 2017 01:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZkTTS1h4jLV for ; Sun, 12 Feb 2017 01:44:25 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A910C127A90 for ; Sun, 12 Feb 2017 01:44:25 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id w20so65032873qtb.1 for ; Sun, 12 Feb 2017 01:44:25 -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=B3mSRZtDtrzqx0u3Fpw+azbjokoktFDc7J9S9Em3PWs=; b=YxRTMNAp3hgnJiuXQt7Lc93hyyd8Amup16GkBEqZcA45CQKFJLya6yQkJZ+aiXsBAW nfTnKgFkBlvXDnUk9b6s7d6i36gvMYqQ8DGctZ0B2/1iDj+f0j22kryE+FS9qqB9xIev rC3LXEz1Y1Y+91zgFgj7dpskVTRZ+tQzlfkMqm1bOdbZL81AqNEdm8JPmvYNjuRTxyer 7LNk7ZRf8m/AqDhHngKx2fYmcvNvQADPqoGjsselI9EpLQiAD7ULNDWzakAAkDHWhowa m7SX6PJ59BZYIxyM4zVlycxi/ALgTA12KUsgXvzaHlFxI8UndNQTbGC+E1qw3B63L/TV miRQ==
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=B3mSRZtDtrzqx0u3Fpw+azbjokoktFDc7J9S9Em3PWs=; b=pSjHa+XPrFejUe/A56P4iXoRpn7nMC1aP53/1ltQCbJ25NBU+ui9XOrF8sleUaKSaa okA1lIMi3K0JVMkSNcQ/cSXrr53n/1VOlAqk3NM80fI8Egn0lB9eQ7KkxoGGJh7MEbIN ogu8/PXeS9rjtwz88DVz7PtQOEAKVUTJCbzCqjfOwWetiJJ2F6quW7H2QlIZrZ35f/KP 5eU0AxEbxTrHWlMB2yav55ZSoNkaU5twgiHZtwG2d7NaH7EcinFOti8rH2CslTE1ePbu Nr222J7VZphdCwpPb9f7uZ3cMwHr4otEbfnTItxX5VvkUBc5HTR7iXzIzDSgK+/uGhbW QoWw==
X-Gm-Message-State: AMke39npMCBC0B2d98mqG21mDQ2HcL7shQoRZEWxmEkyINRHtjeBBQvkNS66ncdFAAsHYLh0MIYNLWBbvuIGUQ==
X-Received: by 10.200.39.200 with SMTP id x8mr15875062qtx.159.1486892664764; Sun, 12 Feb 2017 01:44:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 12 Feb 2017 01:44:24 -0800 (PST)
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> 
From: Martin Thomson 
Date: Sun, 12 Feb 2017 20:44:24 +1100
Message-ID: 
To: Andrey Jivsov 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Feb 2017 09:44:27 -0000

On 12 February 2017 at 09:26, Andrey Jivsov  wrote:
> How should an implementer read [0]? If an implementation sends or receives
> shorter records, it has to re-key sooner.

[0] (the current text) says that there is a maximum number of records.
That's pretty straightforward.  You are required to count them anyway.
No accounting for partial records and other such things.

If that means rekeying sooner, I'd like evidence that this is in some
way harmful.  I think that it's fine.

I'm not disagreeing with the notion of correctness that has been
discussed on this thread and elsewhere, just offering a different set
of criteria upon which you might make this decision.

Ilari made a related point: if you don't rekey occasionally, you might
as well just forget the whole mechanism.  Given the actual limit - for
even the most conservative option, [0] - is so large that common usage
will never hit it, that means rekeying even more often than any
idealized 2^52 octets.


From nobody Sun Feb 12 08:19:41 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F64129891 for ; Sun, 12 Feb 2017 08:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BPmD1yDB1o0l for ; Sun, 12 Feb 2017 08:19:37 -0800 (PST)
Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 69803129A78 for ; Sun, 12 Feb 2017 08:19:36 -0800 (PST)
Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v1CGJTu1058520 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 12 Feb 2017 16:19:29 GMT
Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v1CGJGVx033575 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 12 Feb 2017 16:19:16 GMT
Received: from host209-14-dynamic.233-95-r.retail.telecomitalia.it (host209-14-dynamic.233-95-r.retail.telecomitalia.it [95.233.14.209]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Sun, 12 Feb 2017 17:19:32 +0100
Date: Sun, 12 Feb 2017 17:19:32 +0100
Message-ID: <20170212171932.Horde.f6UV06prjpHITqRg6kH1Ydp@webmail.math.unipd.it>
From: riccardo.lazzeretti@math.unipd.it
To: cfrg@irtf.org
User-Agent: Horde Application Framework 5
Content-Type: multipart/alternative; boundary="=_d7WwZBv8t5wgpzr8b3YH-6i"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-DCC-sonic.net-Metrics: server5.math.unipd.it 1156; Body=1 Fuz1=1 Fuz2=many
X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker
X-Spam-Warning: SpamAssassin says this -probably- is not SPAM
X-Scanned-By: MIMEDefang 2.78
Archived-At: 
Subject: [Cfrg] [IEEE ATC 2017] Call for Workshop and Special Session Proposal DEADLINE: Feb 15
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Feb 2017 16:19:40 -0000

This message is in MIME format.

--=_d7WwZBv8t5wgpzr8b3YH-6i
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Description: Plaintext Message
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

  Dear colleague,

  apologies for multiple postings.

  In conjunction with the 14th IEEE International Conference on  
Advanced and Trusted Computing (ATC 2017), we will organize some  
workshops.

  The workshop proposals should be submitted to ieee-atc2017@googlegroups.com

  Further information are provided in the ATC Call for Workshop page[1] .

  All accepted papers will be included in the ATC 2017 proceedings  
published by IEEE.

   

  Workshop/Special Session proposals should contain following information:

  ·  The title of the workshop/special session, including both full  
name and abbreviation (for workshop)

  ·  The objectives, scope, and contributions to the main conference  
(up to 1 page)

  ·  The short bios of the key organizers and their related experience

  ·  The procedure for selecting papers, plans for dissemination  
(e.g., how to advertise and special issues of journals), and the  
expected number of participants

  ·  A tentative list of program committee members

  ·  The (tentative) website/URL of the proposed workshop/special session

   

  Important Schedule for ATC Workshops and Special Sessions:

  ·  Proposal Due: extended to Feb 15, 2017

  ·  Proposal Notification: extended to Feb 20, 2017

  ·  Paper Submission, Notification: TBD by individual workshops

  ·  Final Camera-ready Paper Due: June 10, 2017

   

  Best regards,

   

  Riccardo Lazzeretti

  riccardo.lazzeretti@math.unipd.it

  Workshop Chair

  IEEE Advanced and Trusted Computing (ATC 2017)



Links:
------
[1] http://cse.stfx.ca/~smartworld/2017/atc/cfw.php

--=_d7WwZBv8t5wgpzr8b3YH-6i
Content-Type: text/html; charset=utf-8
Content-Description: HTML Message
Content-Disposition: inline









Dear colleague,


apologies for multiple postings.





In conjunction with the 14th IEEE International Conference on Advanced and Trusted Computing (ATC 2017), we will organize some workshops.


The workshop proposals should be submitted to ieee-atc2017@googlegroups.com





Further information are provided in the ATC Call for Workshop page .


All accepted papers will be included in the ATC 2017 proceedings published by IEEE.


 


Workshop/Special Session proposals should contain following information:


·  The title of the workshop/special session, including both full name and abbreviation (for workshop)


·  The objectives, scope, and contributions to the main conference (up to 1 page)


·  The short bios of the key organizers and their related experience


·  The procedure for selecting papers, plans for dissemination (e.g., how to advertise and special issues of journals), and the expected number of participants


·  A tentative list of program committee members


·  The (tentative) website/URL of the proposed workshop/special session


 


Important Schedule for ATC Workshops and Special Sessions:


·  Proposal Due: extended to Feb 15, 2017


·  Proposal Notification: extended to Feb 20, 2017


·  Paper Submission, Notification: TBD by individual workshops


·  Final Camera-ready Paper Due: June 10, 2017


 


Best regards,


 


Riccardo Lazzeretti


riccardo.lazzeretti@math.unipd.it


Workshop Chair


IEEE Advanced and Trusted Computing (ATC 2017)












--=_d7WwZBv8t5wgpzr8b3YH-6i--


From nobody Sun Feb 12 11:28:48 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D142A129ACA for ; Sun, 12 Feb 2017 11:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 0ByeRSlHBa4Y for ; Sun, 12 Feb 2017 11:28:45 -0800 (PST)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 3CF50129AC2 for ; Sun, 12 Feb 2017 11:28:44 -0800 (PST)
Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-11v.sys.comcast.net with SMTP id czoscand95l5NczpEcEAP0; Sun, 12 Feb 2017 19:28:44 +0000
Received: from [192.168.0.10] ([24.5.144.109]) by resomta-po-08v.sys.comcast.net with SMTP id czpDcFqaOJE5zczpDcc94U; Sun, 12 Feb 2017 19:28:44 +0000
To: Martin Thomson 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>  
From: Andrey Jivsov 
Message-ID: 
Date: Sun, 12 Feb 2017 11:28:18 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfCnPkPMscLXW8dhwWJkW1OxDVqvtPloQL4cHE6Rw8kmqOvrAFBjfR1J5duQc8/VCP0FwJbaB7xV6f/fFUWdPaQ0vVlDjCFV/uQaFRpr9TvC//QYIBE+E Tq9n7gfjpIPfD1GYkMW44In/bKqNyOUw4ABbp68J3kot48Ds+EwiygaiS8izSCfPgeMWkBeL5UmH5M+S+Rk9908DgSVd6Wc4Tlo=
Archived-At: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Feb 2017 19:28:47 -0000

On 02/12/2017 01:44 AM, Martin Thomson wrote:
> On 12 February 2017 at 09:26, Andrey Jivsov  wrote:
>> How should an implementer read [0]? If an implementation sends or receives
>> shorter records, it has to re-key sooner.
>
> [0] (the current text) says that there is a maximum number of records.
> That's pretty straightforward.  You are required to count them anyway.
> No accounting for partial records and other such things.
>
> If that means rekeying sooner, I'd like evidence that this is in some
> way harmful.  I think that it's fine.
>
> I'm not disagreeing with the notion of correctness that has been
> discussed on this thread and elsewhere, just offering a different set
> of criteria upon which you might make this decision.
>
> Ilari made a related point: if you don't rekey occasionally, you might
> as well just forget the whole mechanism.  Given the actual limit - for
> even the most conservative option, [0] - is so large that common usage
> will never hit it, that means rekeying even more often than any
> idealized 2^52 octets.
>

I don't disagree with the above.

If the stack shares code with 3DES, that code will probably count in 
bytes. This logic can be reused with TLS 1.3. Then the code can be 
tested with 3DES.


From nobody Mon Feb 13 07:34:24 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2397112961D for ; Mon, 13 Feb 2017 07:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 JbrZtAN8VKRU for ; Mon, 13 Feb 2017 07:34:19 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40135.outbound.protection.outlook.com [40.107.4.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA601296D3 for ; Mon, 13 Feb 2017 07:34:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23HkHZCUTFwnOxgymY1McYFkhnuINf3RQvo2WVHN/Zw=; b=COtoIi2/ja2maY4SQrlTq4dvR3gbjRqmRqoEx8qh5ciZxfwu55kBBTiV8FDDeE3RRBLsNYLkbvwB+F9wL/gf0ohzc8QMgrLXGEj2xnHSBn87O8l6ygAzKFF5k/jZsgs+AVC4UMNJ4V+ru5+OjJRdiZomKZpyk39F5FvHkb2hg0Q=
Received: from VI1PR8303MB0094.EURPRD83.prod.outlook.com (129.75.141.89) by VI1PR83MB0046.EURPRD83.prod.outlook.com (129.75.21.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.0; Mon, 13 Feb 2017 15:34:13 +0000
Received: from VI1PR8303MB0094.EURPRD83.prod.outlook.com ([129.75.141.89]) by VI1PR8303MB0094.EURPRD83.prod.outlook.com ([129.75.141.89]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 15:34:14 +0000
From: Markulf Kohlweiss 
To: "Paterson, Kenny" , Sean Turner 
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg1ujogZD2gIXgUWLhmF3SGaRd6FhuukAgAA4M4CABSHOcA==
Date: Mon, 13 Feb 2017 15:34:13 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=markulf@microsoft.com; 
x-originating-ip: [2a01:110:8012:1010::6b0]
x-ms-office365-filtering-correlation-id: b3f80bdb-6e7d-4284-eb95-08d45425c3b4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR83MB0046; 
x-microsoft-exchange-diagnostics: 1; VI1PR83MB0046; 7:F/lm1bTOHd04jyv8txdnKsrVy8KnMEw1YtKA67W4uB/x/8rX1XQXw1hGadK5+XsSf4fh9E7X1XRMwFkxTv/pHgUs5TL7B+LWOBqoJ2Y2aHVN2AgFthTV9KHh2uSfZdj3fV58MHx44XQa3PKX6fGAsD5CFha4iFJqeQJI+GCkYlsnTsh/8s7H2hOfhhzWicdvJ5BMBV90UJLqg+Xuxir2bcuuYcUyH16Gd6/R++tQ3t3pRlFsjC0t8GZeHn1bKTGUI9MEsbBKDl7gTyephEWQVFRIhRBRmjRxvsa3s+SiNe8u8PGd1nhJ1NXRLYW28P+s2kEfOkHEq7v7prKe0W3L5PRlei6xN6ISKa872nAqoAtU/bGJo6AU0eyoZ9DDstx8Tscvm2XAvhqYDj3gtP4qtZc/EaKBYAwRRRcrufVNso2+qnHdgTm8kCVE2tRMDtLSBG0lJUSuk4TBa+K7ptH37JlwDFcFFqh9Rt/PPZa+JcJgmip1zY3cj8d14CvzffiTlz+B3pRBgT2nEoYXcfi5zkqt4d2ikKj2F76zHOThXVw=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR83MB0046; BCL:0; PCL:0; RULEID:; SRVR:VI1PR83MB0046; 
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(189002)(24454002)(199003)(8936002)(4326007)(53936002)(55016002)(9686003)(105586002)(25786008)(99286003)(8656002)(6306002)(81166006)(2906002)(54906002)(6436002)(81156014)(6246003)(92566002)(5005710100001)(33656002)(2900100001)(107886003)(10090500001)(38730400002)(189998001)(10290500002)(86612001)(86362001)(97736004)(305945005)(76176999)(3280700002)(229853002)(68736007)(101416001)(106116001)(106356001)(54356999)(8990500004)(74316002)(6116002)(102836003)(2950100002)(7696004)(7736002)(3660700001)(8676002)(122556002)(6506006)(5660300001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR83MB0046; H:VI1PR8303MB0094.EURPRD83.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 15:34:13.4004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR83MB0046
Archived-At: 
Cc: Antoine Delignat-Lavaud , "karthikeyan.bhargavan@inria.fr" , IRTF CFRG , "" 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 15:34:21 -0000

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of v=
iew, especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or=
g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com=
bined bound for authenticity and confidentiality that is compatible with th=
e Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

>Hi,
>
>My preference is to go with the existing text, option a).
>
>From the github discussion, I think option c) involves a less conservative
>security bound (success probability for IND-CPA attacker bounded by
>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>aware of the weaker security guarantees it provides.
>
>I do not understand option b). It seems to rely on an analysis of
>collisions of ciphertext blocks rather than the established security proof
>for AES-GCM.
>
>Regards,
>
>Kenny
>
>On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
> wrote:
>
>>On 10 February 2017 at 16:07, Sean Turner  wrote:
>>> a) Close these two PRs and go with the existing text [0]
>>> b) Adopt PR#765 [1]
>>> c) Adopt PR#769 [2]
>>
>>
>>a) I'm happy enough with the current text (I've implemented that any
>>it's relatively easy).
>>
>>I could live with c, but I'm opposed to b. It just doesn't make sense.
>>It's not obviously wrong any more, but the way it is written it is
>>very confusing and easily open to misinterpretation.
>>
>>_______________________________________________
>>Cfrg mailing list
>>Cfrg at irtf.org
>>https://www.irtf.org/mailman/listinfo/cfrg


From nobody Mon Feb 13 07:45:46 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476A1296D0 for ; Mon, 13 Feb 2017 07:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 VlUzcUFezw4B for ; Mon, 13 Feb 2017 07:45:38 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0097.outbound.protection.outlook.com [23.103.200.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8619129524 for ; Mon, 13 Feb 2017 07:45:38 -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=PEgXnkS6fbjEzVpHjWRT5rK4sG/KCMbb7/b6CYh4uFE=; b=yDa3F2D6SIeGIpLT1vTr0C/B4omejZZrVnt3HPhunTIq24zQIZEdlDDACabTbzPOUgMuiRXItWJ+6gCjNUTPWtVlbR85rynOFv+nxMzXMBSnXb8SP817kKn/vVjauwu0N5PsxkEtoUkmEYrhNOEXRBFDwcuUlZe/Ti8FXHiViYo=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 15:45:36 +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.0888.030; Mon, 13 Feb 2017 15:45:36 +0000
From: "Dang, Quynh (Fed)" 
To: Markulf Kohlweiss , "Paterson, Kenny" , Sean Turner 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbA==
Date: Mon, 13 Feb 2017 15:45:36 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-ms-office365-filtering-correlation-id: f7b0ab25-26bf-46e1-53b3-08d454275ab3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:8T+8msbGNuDrd10T6Ky1UDdKdh8Y0kNlYdOTx3Wqh/B494AqmlmvDdzltkSRf06tcKMt1Wsf0jafjQqPLlmXAL4Yd0hvhwhfBcWwsLduwpyjCzVEsEla3ltvAQfeJv1tbZKTQrUUJIG0e5tsjIwcehysu6gmms+FHwQXfMLUt7I4hpyiT+dh8sOuGnxN3HgTioN989O1wjDPNAER8w1Gb0CUDw8QplVecsMNrBw+FlSzkAFWhd08iSbuF+cTykRq2O5VXbybej+sus3Phw6IJjwGW1NSxTIl8HS2ktRHVyMnHl1z/hyTK1lg9u/IAIEcy+3X1wyhRtOPrY01I2vxdiPPLB4ZPOmoKmy0Sg47haQ2/e9sZ+SKR07e3HqklHWRylriiNJOIU0dpZI4lxRHH2IIwvYi/VPrvS1xCkZ1qMDNk4ywhR6JblHUq9bDFmzP5i+sRw8I8lROModUKNX7zJUQhAR2CC4blo0QaR/9a6uFk9tSsTVP2CX885pJq0lnjBcdsCfpBXqaxZN/L305UA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; 
x-forefront-prvs: 02176E2458
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(189002)(199003)(377454003)(24454002)(25786008)(2561002)(66066001)(97736004)(6306002)(8936002)(3660700001)(122556002)(54896002)(2421001)(236005)(6512007)(105586002)(4001350100001)(6246003)(5660300001)(606005)(2900100001)(8666007)(83506001)(8656002)(7906003)(53546003)(38730400002)(1511001)(77096006)(7736002)(6486002)(6436002)(6506006)(2950100002)(68736007)(93886004)(54356999)(189998001)(76176999)(50986999)(99286003)(229853002)(101416001)(54906002)(3280700002)(2906002)(92566002)(81166006)(81156014)(102836003)(106116001)(8676002)(106356001)(36756003)(53936002)(3846002)(6116002)(4326007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.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_D4C73D192FB4Bqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 15:45:36.6740 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463
Archived-At: 
Cc: Antoine Delignat-Lavaud , IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 15:45:42 -0000

--_000_D4C73D192FB4Bqdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) 2^(-3=
3). It practically won=92t happen when the chance is 1 in 2^32. And, to ach=
ieve that chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh.

From: TLS > on behalf of =
Markulf Kohlweiss >
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner >
Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of v=
iew, especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or=
g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com=
bined bound for authenticity and confidentiality that is compatible with th=
e Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 wrote:

On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

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


--_000_D4C73D192FB4Bqdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Markulf,







The probability of a bad thing to happen is actually below (or about) =
2^(-33). It practically won=92t happen when the chance is 1 in 2^32. And, t=
o achieve that chance, you must collect 2^48 128-bit blocks.







Regards,


Quynh. 









From: TLS <tls-bounces@ietf.org> on behalf of Markulf Kohlwe=
iss <markulf@microsoft.com&=
gt;

Date: Monday, February 13, 2017 at =
10:34 AM

To: "Paterson, Kenny" <=
;Kenny.Paterson@rhul.ac.uk=
>, Sean Turner <sean@sn3rd.com&=
gt;

Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG =
<cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hello,







Our analysis of miTLS also supports option a)







A security level of 2^-32 seems too low from a provable security point=
 of view, especially for a confidentiality bound.







We verified an implementation of the TLS 1.3 record (https://eprint.iacr.org/2016/1178, to appe=
ar at Security & Privacy 2017) where we arrive at a combined bound for =
authenticity and confidentiality that
 is compatible with the Iwata et al. bound.







Regards,


Markulf (for the miTLS team)









Hi,







My preference is to go with the existing text, option a).







From the github discussion, I think option c) involves a less conserva=
tive


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should b=
e


aware of the weaker security guarantees it provides.







I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security p=
roof


for AES-GCM.







Regards,







Kenny







On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt; wrote:









On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]














a) I'm happy enough with the current text (I've implemented that any

it's relatively easy).







I could live with c, but I'm opposed to b. It just doesn't make sense.=



It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.







_______________________________________________


Cfrg mailing list


Cfrg at irtf.org












_______________________________________________


TLS mailing list


















--_000_D4C73D192FB4Bqdangnistgov_--


From nobody Mon Feb 13 15:21:35 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D12129428 for ; Mon, 13 Feb 2017 15:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 BHinQ0QqYIY2 for ; Mon, 13 Feb 2017 15:21:32 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 D4284129453 for ; Mon, 13 Feb 2017 15:21:31 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id c4so2908407wrd.2 for ; Mon, 13 Feb 2017 15:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=sgzii36livb6iTK/5DE352hM+CO4/o/o0eStg8Fklio=; b=hiczKypsXo2m1eBGbsb4bFcymLJBHF7ZjCUn0iTofKOYReYFNMQqfKjRYb7f0exlb9 vx1VlvEYhIMjb+LIJf+9yKle6B/YQhwA1/X18ODw0QIEyX/Pcl0Ltpubf0XlmPEjRs3d 5fg7SftVq1NYhHcahwzlu+NQAZ5ZBaaEGXdkA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=sgzii36livb6iTK/5DE352hM+CO4/o/o0eStg8Fklio=; b=KsR0xQlshn/P9yO1RxPbVouLyruCc4ZIWmGMRgGkRA/KEq4k0IJ/EOLyH3a0MFEb2K HaudJHyiyAO4Pda4vUgxc1Trs2Oqh2SKDlPCBtKP1EujeNs6l+6oOC8EQHj8qrBPD+D4 CzdnUL0Lhi9tFyqLlz7HRQfY5RQE8L/LFQHx9tUJsIpy8wI5RAY3D1T6TJcbvVuOPTDS A+BFtZqg1WyDsDtZ3cxV4IhbcqKe16e2U8ynydFFqCLA9GrHZ71zUEDE0Aap8r2W4N5A x5kxu7DtUcOcVvv4AYsBuUyv6k0fTNbzPtcCzTZVlyhaCg68QP+eVfdiL/3+Bz80duQ1 smPQ==
X-Gm-Message-State: AMke39mYccdI7tbcXR4m/M28iAosbbh0NYD9JzUotxe7NwOUS6Dte+eoijIC+cIzR4G/4g==
X-Received: by 10.223.135.80 with SMTP id 16mr20254402wrz.182.1487028090361; Mon, 13 Feb 2017 15:21:30 -0800 (PST)
Received: from [192.168.1.130] ([156.218.144.154]) by smtp.gmail.com with ESMTPSA id h75sm15611003wrh.37.2017.02.13.15.21.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Feb 2017 15:21:29 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Date: Tue, 14 Feb 2017 01:21:25 +0200
Message-Id: <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: IRTF CFRG , "" 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:21:33 -0000

--Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 10 Feb 2017, at 07:07, Sean Turner  wrote:
>=20
> All,
>=20
> We=E2=80=99ve got two outstanding PRs that propose changes to =
draft-ietf-tls-tls13 Section 5.5 =E2=80=9CLimits on Key Usage=E2=80=9D.  =
As it relates to rekeying, these limits have been discussed a couple of =
times and we need to resolve once and for all whether the TLS WG wants =
to:
>=20
> a) Close these two PRs and go with the existing text [0]

I thought the cited paper sorted this out like a year ago.

In favor of option a

Aaron

--Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYoj92AAoJEOTbZJL9ubXV2xUQAO8feVVxeB+HU/LWxV/tRHwW
bdyigIeRUOdjNkVBfk7KgKUvY7JIpV9LL+hfeuqrWGB51rccAwhcOgoe7RBGg4zE
jQpdTtxk+02x+3NVdEj9eJklwYpenlLbIUolNrZ7J4rMhlZV+Yt6NWz+9K/S7PsV
dkxufFyTcxjZXkh3U9Bim37Sm8+wlBe3ns9WPbhLNuUp7TZlvueBEmhNTc9j5+t4
Tne7Q3KWf0IIPNI009183QrH/SxVS1HXybD0+H2Y4ScQiMoXsbJbZCk9SZjLiFOb
7lHNKT0ZWUg25Z1MZNE5i0GquynvtbM6weJ/IzlI/Hu/zawOEulPo+j0H14PfL9r
t3vz/XO+7YDibx0XffkIcc40dnZfnqCk90199h4tDX1zAM90mzisQj+FQtmQfnBV
ykPav/4RhA4U528RZUAMSvbEcg1BDEfwZ63l3+JZr2TpxmlH4vs9zp632jwkXFsk
Vw3lm6iFvWbKV7mupJP/IglBzx0+rklH13TaEHHrwnnt1EJ6+kifzQ6yf7sVLWSy
Zxkpr+447ElY6eqNhPs4nY6JiMK1Sjje4EuGBx0CY7imNqiH3OOZWeD0ICCXjnmy
KUGOshEEQp/rRT/Jx9sXEGP3bW8U5vJuCA9bnF8ToOixU+tAM/ddzPoBOcNpHQkI
Mw4yA16juYJLN6Dvam9p
=9lQP
-----END PGP SIGNATURE-----

--Apple-Mail=_9B265044-7F50-458F-94C1-8E5C81357832--


From nobody Mon Feb 13 15:25:34 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B20129430 for ; Mon, 13 Feb 2017 15:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9oHUHFwox1ur for ; Mon, 13 Feb 2017 15:25:27 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F86112946E for ; Mon, 13 Feb 2017 15:25:27 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id r136so70789855vke.1 for ; Mon, 13 Feb 2017 15:25:27 -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=fJNE7OtKbDiV901D5n5md9yUJun4f+A02r7fHPg+AZE=; b=XV05Uzi9xuAsHj/GlD5UlaDKy0a4Kayg3DX56bClNb7lDA1x71Paa3RLSfvft2DxWT OUq/vJbbdYZ68NsDjqAis0RpPsQrZZ7+tyVkFXh6PVgUS+3FiCpMtYg8t57JVfjFtJ5T /M401TcGZfCNcqk8bfhbOh2Ofxx9lqTVrCTodubm2Kfs6BiCXrm9Jc6Fq+LNSGYX7gcu gKvG/CL4Djkw4hSsuBXzdlfI2ZMaIBqvnNO6Hsz0yNXWaxfvWE2C09RocRJOIehuYMIc p9nyk2XKfNDVIxHAXhQFrb/7xeeubnNt18FjAtDYyaiXkWiCKu/ZXcpYKpFSPk/vrBWP g5uQ==
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=fJNE7OtKbDiV901D5n5md9yUJun4f+A02r7fHPg+AZE=; b=oFCNaWxVpF85Nz/R1M3rtZqJEXZAZD3c9X+IjkRmjJkE+XDNvR2UQ8iloOxGCQkpq5 yIxPr+CycXc+xHi7VP7U99a9D06P4I3d6Vq2yk4/K3oxqhkQhEiOrNwPQxReQ9Y3W4Rj pthg5+MVn9ebHeyoNY9EbRtv3bnhjpCN8iQbQ2+xDP0s2BXfDWlCybKIqjTaW1D+/8by EmtlB5bQopUFjOKto20+x0JQ3PgkMqx+M0vQBftS8NbZ3VtwNwWihebIIQFOtKQiX800 4aJpEq9Z1GFASMx69RV5AsOXTJNXZf4UBN3hsu38rKBZOXfez1VyfI/DC+M0aTkoYcGL 0QBw==
X-Gm-Message-State: AMke39m+v39zsaUhOqA8WVJNlYYmqGu5qeiGPYir9JrEP/vQbFm0ICipp+uF2I5sf7QCrJ9BwEmA3ccnAjgnnw==
X-Received: by 10.31.213.7 with SMTP id m7mr11134474vkg.48.1487028326752; Mon, 13 Feb 2017 15:25:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.70.130 with HTTP; Mon, 13 Feb 2017 15:25:06 -0800 (PST)
In-Reply-To: <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com> <95D221C7-40A6-4BDD-B8CD-5C4F9C405D3F@azet.org>
From: Tony Arcieri 
Date: Mon, 13 Feb 2017 15:25:06 -0800
Message-ID: 
To: Aaron Zauner 
Content-Type: multipart/alternative; boundary=94eb2c07aadc2ff35b054871c36b
Archived-At: 
Cc: IRTF CFRG , "" , Sean Turner 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 23:25:30 -0000

--94eb2c07aadc2ff35b054871c36b
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 13, 2017 at 3:21 PM, Aaron Zauner  wrote:

> I thought the cited paper sorted this out like a year ago.
>
> In favor of option a


I am also in favor of option A.

The wording in option B is simultaneously much more unclear and much more
verbose. I consider it a regression.

Option C is more similar to option A, but not an improvement, IMO.

-- 
Tony Arcieri

--94eb2c07aadc2ff35b054871c36b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Feb 13, 2017 at 3:21 PM, Aaron Zauner <azet@azet.org> wrote:=

I thought the cited paper sorted this ou=
t like a year ago.



In favor of option a

I am also in favor of =
option A.

The wording in option B is simultaneousl=
y much more unclear and much more verbose. I consider it a regression.

Option C is more similar to option A, but not an impro=
vement, IMO.

-- 
Tony Arcieri




--94eb2c07aadc2ff35b054871c36b--


From nobody Tue Feb 14 01:02:38 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDBD129A1D for ; Tue, 14 Feb 2017 01:02:37 -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, RP_MATCHES_RCVD=-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 fE9REvDz0km7 for ; Tue, 14 Feb 2017 01:02:36 -0800 (PST)
Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (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 0228B1299D3 for ; Tue, 14 Feb 2017 01:02:35 -0800 (PST)
Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v1E92Trl022283 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2017 09:02:30 GMT
Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v1E92EQs063130 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2017 09:02:15 GMT
Received: from host166-226-static.197-31-b.business.telecomitalia.it (host166-226-static.197-31-b.business.telecomitalia.it [31.197.226.166]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Tue, 14 Feb 2017 10:02:31 +0100
Date: Tue, 14 Feb 2017 10:02:31 +0100
Message-ID: <20170214100231.Horde.aIyNYa6PGQwpjel-OeMp7VO@webmail.math.unipd.it>
From: riccardo.lazzeretti@math.unipd.it
To: cfrg@irtf.org
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-DCC--Metrics: server5.math.unipd.it 1481; Body=6 Fuz1=6 Fuz2=6
X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker
X-Spam-Warning: SpamAssassin says this -probably- is not SPAM
X-Scanned-By: MIMEDefang 2.78
Archived-At: 
Subject: [Cfrg] [IEEE ATC 2017] Call for Workshop and Special Session Proposal LAST DAYS
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 09:02:38 -0000

Dear colleague,
apologies for multiple postings.

In conjunction with the 14th IEEE International Conference on Advanced  
and Trusted Computing (ATC 2017), we will organize some workshops.
The workshop proposals should be submitted to ieee-atc2017@googlegroups.com

Further information are provided in the ATC Call for Workshop page:
http://cse.stfx.ca/~smartworld/2017/atc/cfw.php

All accepted papers will be included in the ATC 2017 proceedings  
published by IEEE.

Workshop/Special Session proposals should contain following information:
·  The title of the workshop/special session, including both full name  
and abbreviation (for workshop)
·  The objectives, scope, and contributions to the main conference (up  
to 1 page)
·  The short bios of the key organizers and their related experience
·  The procedure for selecting papers, plans for dissemination (e.g.,  
how to advertise and special issues of journals), and the expected  
number of participants
·  A tentative list of program committee members
·  The (tentative) website/URL of the proposed workshop/special session

Important Schedule for ATC Workshops and Special Sessions:
·  Proposal Due: extended to Feb 15, 2017
·  Proposal Notification: extended to Feb 20, 2017
·  Paper Submission, Notification: TBD by individual workshops
·  Final Camera-ready Paper Due: June 10, 2017

Best regards,

Riccardo Lazzeretti
riccardo.lazzeretti@math.unipd.it
Workshop Chair
IEEE Advanced and Trusted Computing (ATC 2017)





From nobody Tue Feb 14 03:59:50 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3A71295DF for ; Tue, 14 Feb 2017 03:59:49 -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 b0x0Q31-MEhU for ; Tue, 14 Feb 2017 03:59:46 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0091.outbound.protection.outlook.com [23.103.201.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7932F1295CB for ; Tue, 14 Feb 2017 03:59:46 -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=alcX0Sue+kyVeLg++Kbn9+lHWiS7nMrDsfnFJqvGnWs=; b=VtcukwHUtShAEMLFvUWzsivKpISmyu9rt7sqUtDCNtEVmsVPYua796Tw0Oe8r71oY8gbyBtbyRst5BcIc6B74+BqjXAhZXTa9bFdtlOKnqDVL/99xwNW+yuQ51b4v1DCHqlA+LvvOFwyzP9c8oAz6fehu6GElYCeamGbS9qTvzc=
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.888.16; Tue, 14 Feb 2017 11:59:44 +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.0888.030; Tue, 14 Feb 2017 11:59:44 +0000
From: "Dang, Quynh (Fed)" 
To: Markulf Kohlweiss 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QA
Date: Tue, 14 Feb 2017 11:59:44 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.32]
x-ms-office365-filtering-correlation-id: f39056d9-01a3-4057-155b-08d454d0f750
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:xBVGsHpvfGScMXbWYdBYDU2scucR4JPkNGHIGgsO9oFQjnEL8s5+B2LZ4YrA6o7DxwL5cotuWuSgEF6Vr+m819Bwl+WHQZdiG5VY9vkS+5UBvhcu20LdTDMc8+q1L6Fcze1XEU5xH06yJJu7rIU+w7AL9D0KOaNK2CnGsqNc4JapmcIIYloRW9XvJlZ7IZMsL94CAaNsh7gp6M/eui+lbH++dOFCNiuQtkcOiJaYuaqX7Y1qDZLZwLCtjpouZ+X2stZNjRrh1s1UUtK/Mjdh9Ycr5aMpv3GKN02rVNs/gEAAbDFgYiWaDh+8mb5MFCgCbFivCphoXzryJUaNdRy0tDHDyv5DsgjTaq7mtW7ADSmwJF7k+u/BHyuDcEeSkbQMW5/DAVgTgC60lEoHR2aIYNAJ07qfB4g+UdJk/YkvnI5NHRNIUVpOXuyZ63e5ZrdVQX73aZ6Endh99lVvqP88n12pZmLOeM5Z/tGUnjuS0P2gGBAeEre+6aJUBZzDg/6+pN9dYIdJRQPEOmGsdDRy7Q==
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)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39840400002)(39410400002)(39450400003)(39860400002)(377454003)(24454002)(199003)(189002)(229853002)(50986999)(101416001)(99286003)(54906002)(54356999)(76176999)(189998001)(93886004)(53936002)(36756003)(86362001)(3846002)(6116002)(8676002)(106116001)(102836003)(2906002)(3280700002)(81156014)(81166006)(92566002)(106356001)(606005)(6246003)(54896002)(122556002)(8936002)(3660700001)(6306002)(236005)(2421001)(4001350100001)(105586002)(66066001)(6512007)(4326007)(25786008)(2561002)(77096006)(6486002)(6436002)(7736002)(1511001)(83506001)(68736007)(2950100002)(6506006)(6916009)(8666007)(2900100001)(81003)(38730400002)(53546003)(110136004)(5660300001)(7906003)(97736004); 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; 
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_D4C850542FDA4qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 11:59:44.3692 (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: 
Cc: Antoine Delignat-Lavaud , IRTF CFRG , "" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 11:59:49 -0000

--_000_D4C850542FDA4qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Markulf and all,

I provided more explanation below.

From: 'Quynh' >
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss >=
, "Paterson, Kenny" >, Sean Turner >
Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) 2^(-3=
3). It practically won=92t happen when the chance is 1 in 2^32. And, to ach=
ieve that chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh.

From: TLS > on behalf of =
Markulf Kohlweiss >
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner >
Cc: Antoine Delignat-Lavaud >, IRTF CFRG >, ">" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of v=
iew, especially for a confidentiality bound.

When someone says AES-128 has 128 bits of security he or she means that 2^1=
28 AES operations will break the cipher with probability 100%: finding the =
key and the plaintext.  It does not mean that attackers have only 2^(-128) =
chance of success. If an attacker could run 2^100 AES operations, his or he=
r chance of success is way below 2^(-32): this does not mean that AES has a=
 security level of 2^(-32) or  2^(-28).

The success probability 1/2^32 means that after 2^48 AES operations, the at=
tacker has a success probability of 2^-32 which is practically zero.

Also, many users don=92t know what =93confidentiality bound=94 means.

The current text Eric wrote talks about a number 2^24.5 of full-size record=
s. In many situations, the record sizes are not full size, but different si=
zes. My latest suggestion text does not assume full size records, it covers=
 variable record sizes, it just counts AES-input blocks or AES operations.

Regards,
Quynh.






We verified an implementation of the TLS 1.3 record (https://eprint.iacr.or=
g/2016/1178, to appear at Security & Privacy 2017) where we arrive at a com=
bined bound for authenticity and confidentiality that is compatible with th=
e Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 wrote:

On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

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


--_000_D4C850542FDA4qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <491F1A64945B714DB274CEFE6B5D208E@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Markulf and all,







I provided more explanation below. 









From: 'Quynh' <Quynh.Dang@nist.gov>

Date: Monday, February 13, 2017 at =
10:45 AM

To: Markulf Kohlweiss <markulf@microsoft.com>, "Pate=
rson, Kenny" <Kenny.Pa=
terson@rhul.ac.uk>, Sean Turner <sean@sn3rd.com>

Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG =
<cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hi Markulf,







The probability of a bad thing to happen is actually below (or about) =
2^(-33). It practically won=92t happen when the chance is 1 in 2^32. And, t=
o achieve that chance, you must collect 2^48 128-bit blocks.







Regards,


Quynh. 









From: TLS <tls-bounces@ietf.org> on behalf of Markulf Kohlwe=
iss <markulf@microsoft.com&=
gt;

Date: Monday, February 13, 2017 at =
10:34 AM

To: "Paterson, Kenny" <=
;Kenny.Paterson@rhul.ac.uk=
>, Sean Turner <sean@sn3rd.com&=
gt;

Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG =
<cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hello,







Our analysis of miTLS also supports option a)







A security level of 2^-32 seems too low from a provable security point=
 of view, especially for a confidentiality bound.




















When someone says AES-128 has 128 bits of security he or she means tha=
t 2^128 AES operations will break the cipher with probability 100%: finding=
 the key and the plaintext.  It does not mean that attackers have only=
 2^(-128) chance of success. If an attacker
 could run 2^100 AES operations, his or her chance of success is way below =
2^(-32): this does not mean that AES has a security level of 2^(-32) or &nb=
sp;2^(-28). 







The success probability 1/2^32 means that after 2^48 AES operations, t=
he attacker has a success probability of 2^-32 which is practically zero. &=
nbsp;







Also, many users don=92t know what =93confidentiality bound=94 means.<=
/div>






The current text Eric wrote talks about a number 2^24.5 of full-size r=
ecords. In many situations, the record sizes are not full size, but differe=
nt sizes. My latest suggestion text does not assume full size records, it c=
overs variable record sizes, it
 just counts AES-input blocks or AES operations. 







Regards,


Quynh. 







 




































We verified an implementation of the TLS 1.3 record (https://eprint.iacr.org/2016/1178, to appe=
ar at Security & Privacy 2017) where we arrive at a combined bound for =
authenticity and confidentiality that
 is compatible with the Iwata et al. bound.







Regards,


Markulf (for the miTLS team)









Hi,







My preference is to go with the existing text, option a).







From the github discussion, I think option c) involves a less conserva=
tive


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should b=
e


aware of the weaker security guarantees it provides.







I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security p=
roof


for AES-GCM.







Regards,







Kenny







On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt; wrote:









On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]














a) I'm happy enough with the current text (I've implemented that any

it's relatively easy).







I could live with c, but I'm opposed to b. It just doesn't make sense.=



It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.







_______________________________________________


Cfrg mailing list


Cfrg at irtf.org












_______________________________________________


TLS mailing list
























--_000_D4C850542FDA4qdangnistgov_--


From nobody Tue Feb 14 08:18:01 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA38A129686 for ; Tue, 14 Feb 2017 08:17:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 ctSJYDinWtbq for ; Tue, 14 Feb 2017 08:17:57 -0800 (PST)
Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (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 E29BA12962B for ; Tue, 14 Feb 2017 08:17:56 -0800 (PST)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 5522A128046.AAE7E
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 5522A128046 for ; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 519D4403B; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 4B5AF2002C; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 468FB40; Tue, 14 Feb 2017 17:17:53 +0100 (CET)
Received: from c-73-71-218-252.hsd1.ca.comcast.net ([73.71.218.252]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 14 Feb 2017 17:17:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 14 Feb 2017 08:17:53 -0800
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx 
To: "Dang, Quynh (Fed)" 
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>     
Message-ID: 
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99.2 at cobalt
X-Virus-Status: Clean
Archived-At: 
Cc: Antoine Delignat-Lavaud , IRTF CFRG , tls@ietf.org
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 16:18:00 -0000

Hey Quynh,

> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext 
pairs available to the adversary, it will still take roughly 2^128 
operations to recover the key with AES. This contrasts with any mode of 
operation, where adversarial success probability increases according to 
the amount of data available and the computational complexity required 
to perform such an attack is not the limiting factor (which is the core 
of the problem we're discussing right now).

Regardless, correct me if I'm wrong Quynh, but you seem to have two 
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of 
caution instead of recommending that people switch when adversaries have 
success probability 2^{-32}. I don't see the discussion progressing on 
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough 
heuristic, however this can be fixed easily by minimally modifying the 
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
> Hi Markulf and all,
> 
> I provided more explanation below.
> 
>  From: 'Quynh' 
> Date: Monday, February 13, 2017 at 10:45 AM
> To: Markulf Kohlweiss , "Paterson, Kenny"
> , Sean Turner 
> Cc: Antoine Delignat-Lavaud , IRTF CFRG
> , "" 
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769)
> 
>> Hi Markulf,
>> 
>> The probability of a bad thing to happen is actually below (or
>> about) 2^(-33). It practically won’t happen when the chance is 1
>> in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
>> blocks.
>> 
>> Regards,
>> Quynh.
>> 
>> From: TLS  on behalf of Markulf Kohlweiss
>> 
>> Date: Monday, February 13, 2017 at 10:34 AM
>> To: "Paterson, Kenny" , Sean Turner
>> 
>> Cc: Antoine Delignat-Lavaud , IRTF CFRG
>> , "" 
>> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
>> PRs (#765/#769)
>> 
>>> Hello,
>>> 
>>> Our analysis of miTLS also supports option a)
>>> 
>>> A security level of 2^-32 seems too low from a provable security
>>> point of view, especially for a confidentiality bound.
> 
> When someone says AES-128 has 128 bits of security he or she means
> that 2^128 AES operations will break the cipher with probability 100%:
> finding the key and the plaintext.  It does not mean that attackers
> have only 2^(-128) chance of success. If an attacker could run 2^100
> AES operations, his or her chance of success is way below 2^(-32):
> this does not mean that AES has a security level of 2^(-32) or
> 2^(-28).
> 
> The success probability 1/2^32 means that after 2^48 AES operations,
> the attacker has a success probability of 2^-32 which is practically
> zero.
> 
> Also, many users don’t know what “confidentiality bound†means.
> 
> The current text Eric wrote talks about a number 2^24.5 of full-size
> records. In many situations, the record sizes are not full size, but
> different sizes. My latest suggestion text does not assume full size
> records, it covers variable record sizes, it just counts AES-input
> blocks or AES operations.
> 
> Regards,
> Quynh.
> 
>> We verified an implementation of the TLS 1.3 record
>> (https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
>> 2017) where we arrive at a combined bound for authenticity and
>> confidentiality that is compatible with the Iwata et al. bound.
>> 
>> Regards,
>> Markulf (for the miTLS team)
>> 
>> Hi,
>> 
>> My preference is to go with the existing text, option a).
>> 
>> From the github discussion, I think option c) involves a less
>> conservative
>> security bound (success probability for IND-CPA attacker bounded by
>> 2^{-32} instead of 2^{-60}). I can live with that, but the WG should
>> be
>> aware of the weaker security guarantees it provides.
>> 
>> I do not understand option b). It seems to rely on an analysis of
>> collisions of ciphertext blocks rather than the established security
>> proof
>> for AES-GCM.
>> 
>> Regards,
>> 
>> Kenny
>> 
>> On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
>> 
>> wrote:
>> 
>> On 10 February 2017 at 16:07, Sean Turner  wrote:
>> 
>> a) Close these two PRs and go with the existing text [0]
>> b) Adopt PR#765 [1]
>> c) Adopt PR#769 [2]
>> 
>> a) I'm happy enough with the current text (I've implemented that any
>> 
>> it's relatively easy).
>> 
>> I could live with c, but I'm opposed to b. It just doesn't make
>> sense.
>> It's not obviously wrong any more, but the way it is written it is
>> very confusing and easily open to misinterpretation.
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg at irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Feb 14 10:20:19 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164661293EB for ; Tue, 14 Feb 2017 10:20:18 -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 SnpubTVyxZug for ; Tue, 14 Feb 2017 10:20:15 -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 3B7931296CD for ; Tue, 14 Feb 2017 10:20:15 -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=/fE4UIrhydtnHpgZ/wFiryS2clsV6K7d8QcrozGVyTI=; b=JsRnhQGy/mnpjpVgIOqyQIwe2GbQFLDCVtWwpAa8fM7LmTz9Rbft+4fDKZMysktUpZH4/LYoxBXA+B9C1b9RQHbPpeFoeEa9jwECpgJV1sZbcyokefGDKB4SeTMvmw4enP5x81beymkOqiN/PwfuUiqvmEWBwgDOLNzP1FDVKr4=
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.888.16; Tue, 14 Feb 2017 18:20:13 +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.0888.030; Tue, 14 Feb 2017 18:20:13 +0000
From: "Dang, Quynh (Fed)" 
To: Atul Luykx , "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QAgACb9ID//85ZAA==
Date: Tue, 14 Feb 2017 18:20:12 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.32]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:cJavgSjCOIJJdkKQnL6nrUNwVu46dejnAw+NACjaWOLDwOsnPyD89cr8mZEdNMM203Vjj7dgN8VzDXSnj5CH4d5/VuZmqcYU+mRGCx0pHBZ/oCZfmlplerjj+bdfaCDFA8B+aH+ayCpW/4a8vbhWORJXe6MuSNgU09pmVZKbEFdZUWzFIdCiu8oj04t6udTFy+VEiLXJ8IaWX6wx/QIBwcsSQSjHy+yCM0eTfIOKHZqF2+x21RAUGreBD4h0vwh0gi6pTZmo4TBTSaRI8YR/a1lyjZi0GJ5s+Ijz7qL1iNvPYLF+xeDZ0KN6CX5fQ6/byeoNWl+HlKHvfhsx/hWt07CEpLukkJoa9iLrxy8ZqztBgX0cYgcP1G/Z3kUbO2HHtMaDAC3XiGDjELgy/EygODubE9tLfVP9yVDlIL6xLnXBayLvF0pM2o/6T+uLjGgVfkLGNBj4oC+ZVxeHqnUB9Ryw7Aw0Bdo67nDxIp2v2PoBc9/95vK2ml+lRft5P7GAGQHri6cBYj4qF7JvwCs9jQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(189002)(199003)(377454003)(377424004)(24454002)(86362001)(102836003)(6116002)(4326007)(93886004)(3846002)(2950100002)(6862003)(53936002)(3280700002)(2900100001)(81166006)(189998001)(5660300001)(606005)(38730400002)(81156014)(92566002)(2906002)(54356999)(8676002)(50986999)(4001350100001)(97736004)(76176999)(8936002)(101416001)(7736002)(7906003)(66066001)(229853002)(83506001)(6306002)(54906002)(236005)(122556002)(6486002)(54896002)(6436002)(106116001)(6506006)(106356001)(105586002)(3660700001)(6246003)(53546003)(36756003)(6512007)(8666007)(77096006)(25786008)(68736007)(99286003)(81003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: eb5c1027-041f-409b-5808-08d455061e2a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); 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)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0218A015FA
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_D4C8AE2830145qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:20:12.9137 (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: 
Cc: Antoine Delignat-Lavaud , IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 18:20:18 -0000

--_000_D4C8AE2830145qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Atul,

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' >
Cc: Markulf Kohlweiss >=
, Antoine Delignat-Lavaud >=
, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: jus=
t one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is=
 equivalent to computation in the sense that data are produced by computati=
on. 2^x blocks =3D 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). =
And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' >
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss >=
, "Paterson, Kenny"
>, Sean Turner =
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won=92t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS > on behalf of =
Markulf Kohlweiss
>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don=92t know what =93confidentiality bound=94 means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
Regards,
Quynh.
We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Regards,
Markulf (for the miTLS team)
Hi,
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
aware of the weaker security guarantees it provides.
I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.
Regards,
Kenny
On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

wrote:
On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).
I could live with c, but I'm opposed to b. It just doesn't make
sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.
_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--_000_D4C8AE2830145qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Atul,<=
/div>








From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 11:17 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Markulf Kohlweiss <markulf@microsoft.com>, Antoine De=
lignat-Lavaud <antdl@microsoft.co=
m>, IRTF CFRG <cfrg@irtf.org=
>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hey Quynh,









When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.




The claim is stronger: regardless of the number of plaintext-ciphertex=
t 


pairs available to the adversary, it will still take roughly 2^128 

operations to recover the key with AES. 














Actually =
the same claim: my claim did not require any data requirement: just one cip=
hertext block. 














This contrasts with any mode of 


operation, where adversarial success probability increases according t=
o 


the amount of data available and the computational complexity required=
 


to perform such an attack is not the limiting factor (which is the cor=
e 


of the problem we're discussing right now).














IND-CPA i=
s important. That is why I have always been supporting it. Data is equivale=
nt to computation in the sense that data are produced by computation. 2^x b=
locks =3D 2^x AES operations. 







With 2^48=
 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in=
 2^32 is 1 in 4,294, 967,296.00
 which is safe.







Quynh. 



















Regardless, correct me if I'm wrong Quynh, but you seem to have two 

issues with Eric's text:


1. the data limit recommendation is too strict, and


2. it only gives a data limit in terms of full records.







For point 1 it seems like most people would rather err on the side of =



caution instead of recommending that people switch when adversaries ha=
ve 


success probability 2^{-32}. I don't see the discussion progressing on=
 


this point, and basically a decision needs to be made.







I don't think point 2 is a problem because it gives people a good enou=
gh 


heuristic, however this can be fixed easily by minimally modifying the=
 


original text.







Atul












On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:




Hi Markulf and all,




I provided more explanation below.




  From: 'Quynh' <Q=
uynh.Dang@nist.gov>


Date: Monday, February 13, 2017 at 10:45 AM


To: Markulf Kohlweiss <mar=
kulf@microsoft.com>, "Paterson, Kenny"



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
" PRs


(#765/#769)






Hi Markulf,




The probability of a bad thing to happen is actually below (or


about) 2^(-33). It practically won=92t happen when the chance is 1

in 2^32. And, to achieve that chance, you must collect 2^48 128-bit

blocks.




Regards,


Quynh.




From: TLS <tls-bounces@ietf=
.org> on behalf of Markulf Kohlweiss



Date: Monday, February 13, 2017 at 10:34 AM


To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Sean Turner



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
"


PRs (#765/#769)






Hello,




Our analysis of miTLS also supports option a)




A security level of 2^-32 seems too low from a provable security


point of view, especially for a confidentiality bound.








When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.  It does not mean that at=
tackers


have only 2^(-128) chance of success. If an attacker could run 2^100

AES operations, his or her chance of success is way below 2^(-32):

this does not mean that AES has a security level of 2^(-32) or


2^(-28).




The success probability 1/2^32 means that after 2^48 AES operations,

the attacker has a success probability of 2^-32 which is practically

zero.




Also, many users don=92t know what =93confidentiality bound=94 means.<=
/div>



The current text Eric wrote talks about a number 2^24.5 of full-size

records. In many situations, the record sizes are not full size, but

different sizes. My latest suggestion text does not assume full size

records, it covers variable record sizes, it just counts AES-input

blocks or AES operations.




Regards,


Quynh.






We verified an implementation of the TLS 1.3 record


(https://eprint.iacr.org=
/2016/1178, to appear at Security & Privacy


2017) where we arrive at a combined bound for authenticity and


confidentiality that is compatible with the Iwata et al. bound.




Regards,


Markulf (for the miTLS team)




Hi,




My preference is to go with the existing text, option a).




From the github discussion, I think option c) involves a less


conservative


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should

be


aware of the weaker security guarantees it provides.




I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security

proof


for AES-GCM.




Regards,




Kenny




On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt;


wrote:




On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]




a) I'm happy enough with the current text (I've implemented that any



it's relatively easy).




I could live with c, but I'm opposed to b. It just doesn't make


sense.


It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.




_______________________________________________


Cfrg mailing list


Cfrg at irtf.org







_______________________________________________


TLS mailing list




_______________________________________________


TLS mailing list




















--_000_D4C8AE2830145qdangnistgov_--


From nobody Tue Feb 14 10:46:04 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA27129784 for ; Tue, 14 Feb 2017 10:46:02 -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 h1xPdfx_qt9h for ; Tue, 14 Feb 2017 10:45:57 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0103.outbound.protection.outlook.com [23.103.200.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36686129570 for ; Tue, 14 Feb 2017 10:45:57 -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=GB8P4EGPA4wHJUW0kCgbiUaObJD0uDz8pq0+phIcr1g=; b=u8/5GPv5ShDWD6Vm2J4vUihe6gQXo0NqqNV0mtrNQyMU/EzukDHf3AsWfsPTWNxRy/yPD9KG6+JtnNRMbGFa8TnsZPGG9XKfy0pA11spPyR6uCljzyqcLXM3X2CLa5149oySBEj18bvkxWxQuQ3he8sdG1FXUCgOTRzqtzxrVFc=
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.888.16; Tue, 14 Feb 2017 18:45:55 +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.0888.030; Tue, 14 Feb 2017 18:45:55 +0000
From: "Dang, Quynh (Fed)" 
To: Sean Turner , "tls@ietf.org" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShhA4I+OuT9Tx0Ei6xwYcFLEEbKFoE7QAgACb9ID//85ZAIAAVXBE
Date: Tue, 14 Feb 2017 18:45:55 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>      , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.32]
x-ms-office365-filtering-correlation-id: 03ac788c-a2f2-4f66-a5c6-08d45509b58f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:Bdtr1r5qlT1s7JX8f2rXc8cvJ/qbU7qiZNHejaB1z94MpqUq3+a7Z6fiB7zySi4CqzkZSzTisw+GG51eGm3mR6jlkWVeY26Coot1HoYL/7ooh8n43sXXqQ/GgUjntL7N3POrU+XZqn6iHfvIrM4dz5Dj65irp4lCHhQhp1r6faRVMBouAh/w2k3QIMlUk5DrLN66lX2JPphvD7n0sKmzUWBKvQB59GYLnkvfI4GUoGQ4SU0+3WNDuYVm7dtmwPt5NHj+uqxOL1Kw3xlzeVn52AS9E+sCpdvxuuI/POz1zZb8GiRVnbiWxs1ABpnbBcBdBk+ADJ89HbV+I7CDQo4k6yw1VEW44In2Qu/bAU8JGUtZyvbMvKM149hLCDMKWpUyFdRbG+Y8iTMR00HDZC+FaXevZGlaXV2lLqeCdGMC11xlnvkrJHFDBzfaQGvGWqgZLs8NWnMMMggB2jB+H1oYtJSjg59shQnyJPGIS0oW19plGFgu/KR6zyZjRE+gr3al6yBOWD7whvYKFMBGjvgNJQ==
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)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; 
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(24454002)(377424004)(377454003)(199003)(189002)(106116001)(6436002)(54896002)(105586002)(6506006)(106356001)(229853002)(19627405001)(122556002)(6306002)(9686003)(236005)(2501003)(77096006)(99286003)(33656002)(81003)(55016002)(25786008)(68736007)(3660700001)(6246003)(53546003)(189998001)(81166006)(2900100001)(5660300001)(606005)(38730400002)(7696004)(4326007)(102836003)(86362001)(6116002)(2950100002)(53936002)(3280700002)(93886004)(3846002)(74316002)(101416001)(8936002)(7906003)(66066001)(7736002)(2906002)(54356999)(92566002)(81156014)(76176999)(97736004)(8676002)(50986999); 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; 
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_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 18:45:55.2346 (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: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 18:46:02 -0000

--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sean and all,


Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/m=
sg22381.html, I have a second suggestion below.


Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.

" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or fu=
ll) input blocks may be encrypted with one key. For other suggestions and a=
nalysis, see the referred paper above."


Regards,

Quynh.

________________________________
From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Atul,

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' >
Cc: Markulf Kohlweiss >=
, Antoine Delignat-Lavaud >=
, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: jus=
t one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is=
 equivalent to computation in the sense that data are produced by computati=
on. 2^x blocks =3D 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). =
And, 1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' >
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss >=
, "Paterson, Kenny"
>, Sean Turner =
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won=92t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS > on behalf of =
Markulf Kohlweiss
>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" >, Sean Turner
>
Cc: Antoine Delignat-Lavaud >, IRTF CFRG
>, ">=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don=92t know what =93confidentiality bound=94 means.
The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.
Regards,
Quynh.
We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.
Regards,
Markulf (for the miTLS team)
Hi,
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
aware of the weaker security guarantees it provides.
I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.
Regards,
Kenny
On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

wrote:
On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).
I could live with c, but I'm opposed to b. It just doesn't make
sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.
_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











From: Dang, Quynh (Fed)

Sent: Tuesday, February 14, 2017 1:20:12 PM

To: Atul Luykx; Dang, Quynh (Fed)

Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.=
org

Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usa=
ge" PRs (#765/#769)

 






Hi Atul,<=
/div>








From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 11:17 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Markulf Kohlweiss <markulf@microsoft.com>, Antoine De=
lignat-Lavaud <antdl@microsoft.co=
m>, IRTF CFRG <cfrg@irtf.org=
>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hey Quynh,









When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.




The claim is stronger: regardless of the number of plaintext-ciphertex=
t 


pairs available to the adversary, it will still take roughly 2^128 

operations to recover the key with AES. 














Actually =
the same claim: my claim did not require any data requirement: just one cip=
hertext block. 














This contrasts with any mode of 


operation, where adversarial success probability increases according t=
o 


the amount of data available and the computational complexity required=
 


to perform such an attack is not the limiting factor (which is the cor=
e 


of the problem we're discussing right now).














IND-CPA i=
s important. That is why I have always been supporting it. Data is equivale=
nt to computation in the sense that data are produced by computation. 2^x b=
locks =3D 2^x AES operations. 







With 2^48=
 AES operations/input blocks, the actual margin is below 2^(-33). And, 1 in=
 2^32 is 1 in 4,294, 967,296.00
 which is safe.







Quynh. 



















Regardless, correct me if I'm wrong Quynh, but you seem to have two 

issues with Eric's text:


1. the data limit recommendation is too strict, and


2. it only gives a data limit in terms of full records.







For point 1 it seems like most people would rather err on the side of =



caution instead of recommending that people switch when adversaries ha=
ve 


success probability 2^{-32}. I don't see the discussion progressing on=
 


this point, and basically a decision needs to be made.







I don't think point 2 is a problem because it gives people a good enou=
gh 


heuristic, however this can be fixed easily by minimally modifying the=
 


original text.







Atul












On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:




Hi Markulf and all,




I provided more explanation below.




  From: 'Quynh' <Q=
uynh.Dang@nist.gov>


Date: Monday, February 13, 2017 at 10:45 AM


To: Markulf Kohlweiss <mar=
kulf@microsoft.com>, "Paterson, Kenny"



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
" PRs


(#765/#769)






Hi Markulf,




The probability of a bad thing to happen is actually below (or


about) 2^(-33). It practically won=92t happen when the chance is 1

in 2^32. And, to achieve that chance, you must collect 2^48 128-bit

blocks.




Regards,


Quynh.




From: TLS <tls-bounces@ietf=
.org> on behalf of Markulf Kohlweiss



Date: Monday, February 13, 2017 at 10:34 AM


To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Sean Turner



Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, IRTF CFRG



Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage=
"


PRs (#765/#769)






Hello,




Our analysis of miTLS also supports option a)




A security level of 2^-32 seems too low from a provable security


point of view, especially for a confidentiality bound.








When someone says AES-128 has 128 bits of security he or she means

that 2^128 AES operations will break the cipher with probability 100%:=



finding the key and the plaintext.  It does not mean that at=
tackers


have only 2^(-128) chance of success. If an attacker could run 2^100

AES operations, his or her chance of success is way below 2^(-32):

this does not mean that AES has a security level of 2^(-32) or


2^(-28).




The success probability 1/2^32 means that after 2^48 AES operations,

the attacker has a success probability of 2^-32 which is practically

zero.




Also, many users don=92t know what =93confidentiality bound=94 means.<=
/div>



The current text Eric wrote talks about a number 2^24.5 of full-size

records. In many situations, the record sizes are not full size, but

different sizes. My latest suggestion text does not assume full size

records, it covers variable record sizes, it just counts AES-input

blocks or AES operations.




Regards,


Quynh.






We verified an implementation of the TLS 1.3 record


(https://eprint.iacr.org=
/2016/1178, to appear at Security & Privacy


2017) where we arrive at a combined bound for authenticity and


confidentiality that is compatible with the Iwata et al. bound.




Regards,


Markulf (for the miTLS team)




Hi,




My preference is to go with the existing text, option a).




From the github discussion, I think option c) involves a less


conservative


security bound (success probability for IND-CPA attacker bounded by

2^{-32} instead of 2^{-60}). I can live with that, but the WG should

be


aware of the weaker security guarantees it provides.




I do not understand option b). It seems to rely on an analysis of

collisions of ciphertext blocks rather than the established security

proof


for AES-GCM.




Regards,




Kenny




On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

<cfrg-bounces at irtf.org on behalf of martin.thomson at gmail.com&=
gt;


wrote:




On 10 February 2017 at 16:07, Sean Turner <sean at sn3rd.com> wr=
ote:




a) Close these two PRs and go with the existing text [0]


b) Adopt PR#765 [1]


c) Adopt PR#769 [2]




a) I'm happy enough with the current text (I've implemented that any



it's relatively easy).




I could live with c, but I'm opposed to b. It just doesn't make


sense.


It's not obviously wrong any more, but the way it is written it is

very confusing and easily open to misinterpretation.




_______________________________________________


Cfrg mailing list


Cfrg at irtf.org







_______________________________________________


TLS mailing list




_______________________________________________


TLS mailing list





















--_000_CY4PR09MB1464278F1845979862CA9C8EF3580CY4PR09MB1464namp_--


From nobody Tue Feb 14 11:45:41 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7363412943B for ; Tue, 14 Feb 2017 11:45:39 -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 lcvMBYtOz6Nx for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 8CB8F1297C1 for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
Received: by mail-wm0-x241.google.com with SMTP id c85so5152750wmi.1 for ; Tue, 14 Feb 2017 11:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bzToNcj0dDUIpOb/RXD4K5BmSD4ioLRGrxo6Z4cPeRs=; b=PAUgx5Mu7Ah/ioHBtLDS0r/BF4bHW79s4+A8vpEWhypmPdwox32dUAQo/DOfyGRcIc us8zG2mTMj9Ryi1hnK5uH/nMiTht6DnRhs7+PqHyyYekR5TM2v8rEB17MbEcm6r0TkiF WbZgw4Dq/uJexyxx/r+QwzrNiEb2VHnauiFH4TzQrzFLeRV6B93ZhYzZvHWFmD2GVhQP LKrXGnwhv8p5wpwyVID3kfZO1P1pNbAu3kKBNjetxLMVYRAsS/ioT1ZA1UZvbGRaiIa7 Kw78V8N44KYE06eu0dC27BDx3JExXr4aG7jHGLZHsPwODsuxt6hFohGZ7vOK3rQL+mrY gFMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bzToNcj0dDUIpOb/RXD4K5BmSD4ioLRGrxo6Z4cPeRs=; b=OrLHcZt8FWLKO+Twi/fOD0vnoSeVZrSb8G4u7rqzqdY0BoHLK2Pf2m3D6MJ0hfg8UR u0ByM+A+Z/YZKrFzZaAUFtgKENhD6QEmRyrG5I/ZUwoALOrR5V0G71Ql/9Du3fJTSbTr XxNKKwI0zt5OO1AyMtzlge8uIy41O3HS9KUUCzo4TYU7dOqp0cSWM+PkexyrTQ/BTBkV BmcJXvs7cQS7WCztTRozYgsvJqlusUuLKLyEbkmWO3bGtAxKHl7Cc9fOm+auaEZBoKWM pzdxEIwFKfdghxHTn2+qunsd43szzEjZWShY6SYrML4oZ2cdM6fD2Kgsvv8akPd15bMY pOOg==
X-Gm-Message-State: AMke39nHfMD2VH2QiPBTTrmg84ojXwggBQj8bnN/isIZlOBEXMQqYdF2l6haDEeLGhWWqw==
X-Received: by 10.28.57.131 with SMTP id g125mr4744554wma.33.1487101536095; Tue, 14 Feb 2017 11:45:36 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z67sm1963135wrb.49.2017.02.14.11.45.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:45:35 -0800 (PST)
From: Yoav Nir 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 14 Feb 2017 21:45:32 +0200
In-Reply-To: 
To: "Dang, Quynh (Fed)" 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>        
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" , Sean Turner 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 19:45:39 -0000

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E"


--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Quynh

> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed)  =
wrote:
>=20
> Hi Sean and all,
>=20
> Beside my suggestion at =
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html =
, I =
have a second suggestion below.
>=20
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
>    encrypted on a given connection while keeping a safety margin of
>    approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial =
or full) input blocks may be encrypted with one key. For other =
suggestions and analysis, see the referred paper above."
>=20
> Regards,
> Quynh.

I like the suggestion, but I=E2=80=99m probably missing something pretty =
basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or (since =
an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10 blocks.

Why is that 2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav



--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, Quynh

On 14 Feb 2017, at 20:45, Dang, =
Quynh (Fed) <quynh.dang@nist.gov> wrote:

Hi Sean and all,

Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/msg22381.html=
, I have a second suggestion below.

Just replacing this sentence: "  
For AES-GCM, up to 2^24.5 =
full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) =
security.
" in Section 5.5 by this =
sentence: " For AES-GCM, up to 2^48 (partial or full) input blocks may =
be encrypted with one key. For other suggestions and analysis, see =
the referred paper =
above."

Regards,
Quynh. 

I like the suggestion, but I=E2=80=99m probably =
missing something pretty basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 =
bytes each, or (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 =
records of 2^10 blocks.

Why is that =
2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav


=

--Apple-Mail=_556D685C-4FDE-4DDB-957A-E64059C3A26E--

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYo15cAAoJELhJCxUKWMyZZLkH/jEz1cx2yXnvvPPB66DUdovW
02tezRPm1rzV7fqXRwuOUCWrBMTn9KicpH0e++7aVM4ZRIqNodD7SVjgxZomb05p
O+XILGnwL0ESlz3F9kpvGFpoZm1v6xnzM/yvWTmrHxL46gXgsHc8rA+uZprlrnF/
akCjnf+4hNu6C6g1oVWBHA/xb+hTluESnVc/LC4E1ZDU/eFJKLJMhAxoeiycr3Nf
TYjiXAPAXL5OM3EfKvfep5qMpsiJvdpJf5Tefi0taQoRgOI41lAk7gOz4oWYbfxh
pADuSEq+4HWL+g3+iQCQF7SPDr07JABSfnAzibCIDOB5zArRs26iEUJR+0s3j60=
=WfZ7
-----END PGP SIGNATURE-----

--Apple-Mail=_FEA34146-C7F0-46C7-8686-9290B478C5FA--


From nobody Tue Feb 14 13:52:17 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD61298D0 for ; Tue, 14 Feb 2017 13:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 6AJxotZGKkhU for ; Tue, 14 Feb 2017 13:52:08 -0800 (PST)
Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (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 8BE4012994F for ; Tue, 14 Feb 2017 13:52:07 -0800 (PST)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: D7BC51280A8.A9609
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id D7BC51280A8 for ; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id D3CC520098; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id CFB5D2002C; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id C7C5940; Tue, 14 Feb 2017 22:52:04 +0100 (CET)
Received: from c-73-71-218-252.hsd1.ca.comcast.net ([73.71.218.252]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 14 Feb 2017 22:52:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 14 Feb 2017 13:52:04 -0800
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx 
To: Yoav Nir 
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>         
Message-ID: 
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99.2 at cobalt
X-Virus-Status: Clean
Archived-At: 
Cc: IRTF CFRG , tls@ietf.org
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 21:52:11 -0000

> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. The original text 
recommends switching at 2^{34.5} input blocks, corresponding to a 
success probability of 2^{-60}, whereas his text recommends switching at 
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
> Hi, Quynh
> 
>> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
>> wrote:
>> 
>> Hi Sean and all,
>> 
>> Beside my suggestion at
>> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
>> I have a second suggestion below.
>> 
>> Just replacing this sentence: "
>> 
>> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
>> be
>> encrypted on a given connection while keeping a safety margin of
>> approximately 2^-57 for Authenticated Encryption (AE) security.
>> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
>> (partial or full) input blocks may be encrypted with one key. For
>> other suggestions and analysis, see the referred paper above."
>> 
>> Regards,
>> Quynh.
> 
> I like the suggestion, but I’m probably missing something pretty
> basic about it.
> 
> 2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
> (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
> blocks.
> 
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> 
> Thanks
> 
> Yoav
> 
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Feb 14 14:00:09 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574A8129585 for ; Tue, 14 Feb 2017 14:00:04 -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=unavailable 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 U3vb6Jq1OE3w for ; Tue, 14 Feb 2017 14:00:02 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 055D9129865 for ; Tue, 14 Feb 2017 14:00:02 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id v77so27699791wmv.0 for ; Tue, 14 Feb 2017 14:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7ma3ik0oPFELXGGpiTmYxBaOOf+IiXMYsUqCuEXlkNA=; b=pNLjuboxgjU1ydHBdNK7yTZ5FuTAp6I/XxR5k+PsNJaKD7aziOWL3/2nUgzoohk601 RdddLS3bD9j69S/PJ9vXhmLxRodgQP4rOD7NwxEdyF1997FToWqMVXOdQs3P6OCkzcqi 1LXPhW+xGUJuiXUXa6liIyUF1a9YHgWhTohObXXpwXv7xAgqfyrbJSNqekUzCDGQOY/z eDSt3x8cDQ+3s3ojNih/E10eHgj+N3vtHP3d1rK3/HZF3iOXnG9Iz6EZLlj8xPkJW8WI 2E22i73+YkDdLXYWdzHZR110T91GZzpTdgYYoMDydcQvmLnPZNiPasTjx5TqVNx7Yehn 5/Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7ma3ik0oPFELXGGpiTmYxBaOOf+IiXMYsUqCuEXlkNA=; b=JUK7zm7ANWXddCLFiQy5zkJm+KcFljBVtXiwC4facoQmXv3sCa/K6PzYQQfwVr4Lb+ 9lvJnULk3kriXf32cIoi0/gGLAR8aR9BKMI8iMo1IHHeqXWFfvEiuS2qg/c7I81s2bWB BZPaGzpiPjkPbbPJ8mt+NR5zgkdPjeaTASgfaDNpXOqVfzYWOeHEdgHBwA9B6GcQiOV2 UXzu2icTg7vivLLwEGxiXD2MJyhXCje1X2/E4ZJuhGp4T9FgsTCFIRec26hSOvCun4Ic uMzidIXaoywysZoVZIoO8gbHCn1auC6qWXKvMxtthEItde4ukWcCtItxGc1xRoF0JPF0 EOJw==
X-Gm-Message-State: AMke39mJZDcN2EoaWT0SPV8ieefphhjk6pzoYGggS1bZ1vxkPVsF58rrunp5OzL4xnX66Q==
X-Received: by 10.28.185.193 with SMTP id j184mr5383249wmf.86.1487109600526; Tue, 14 Feb 2017 14:00:00 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l130sm5075646wmf.0.2017.02.14.13.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 13:59:59 -0800 (PST)
From: Yoav Nir 
Message-Id: <2B24FC67-764A-47D1-8D24-09B652DF3611@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 14 Feb 2017 23:59:57 +0200
In-Reply-To: 
To: Atul Luykx 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org list" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 22:00:04 -0000

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF"


--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 14 Feb 2017, at 23:52, Atul Luykx  =
wrote:
>=20
>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> Because he wants to lower the security level. The original text =
recommends switching at 2^{34.5} input blocks, corresponding to a =
success probability of 2^{-60}, whereas his text recommends switching at =
2^{48} blocks, corresponding to a success probability of 2^{-32}.

OK, missed that.

So I=E2=80=99m in favor of switching the phrasing to be about blocks =
rather than maximum-sized records, but not in favor of lowering the =
security level.

Yoav


--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 14 Feb 2017, at 23:52, Atul Luykx <Atul.Luykx@esat.kuleuven.be> wrote:

Why is that 2^48 input =
blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. =
The original text recommends switching at 2^{34.5} input blocks, =
corresponding to a success probability of 2^{-60}, whereas his text =
recommends switching at 2^{48} blocks, corresponding to a success =
probability of 2^{-32}.

OK, missed that. 

So I=E2=80=99m in favor of switching =
the phrasing to be about blocks rather than maximum-sized records, but =
not in favor of lowering the security level.

Yoav

=

--Apple-Mail=_31819017-70B9-411A-9293-0193CD3E77BF--

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYo33dAAoJELhJCxUKWMyZ7+0H/1iVd+9jaw+NwrdstvmvlrRb
QDbFBa6OaTfcjCyR4OQ2fkegshilI0KHSzo/RxgQXWft3nThOk/PPIMPiY+LO+LQ
iejfqGC2DHAQ6c3dm6LyJA4CLQe5K7aC56aVZkaZRUGUxlUec4tdGa2d0VwS4ftV
lB8Q42TUHFBjTz/DYvdR0MtRQkZmq5O7T0EOQG3+P2BqoYx3wRgO+OHg1o2sea4M
o1L0rTASAdINHlBOwaFjPN8Yy6ydNzhLbBr7e9jIGmPZbMF5aIhFOEVGgci1rsjm
+lwoB8oMY0uMmAwAv//7m3zNGo0cjlRXueD0Kpm40pbAByMkYMiiPaymloNKBOo=
=w/QY
-----END PGP SIGNATURE-----

--Apple-Mail=_165036B6-63A5-4ACD-8DAB-277AC84BA695--


From nobody Wed Feb 15 04:12:02 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F25129495 for ; Wed, 15 Feb 2017 04:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 O1OpBe0Nvv24 for ; Wed, 15 Feb 2017 04:11:56 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0092.outbound.protection.outlook.com [23.103.201.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E87912955B for ; Wed, 15 Feb 2017 04:11:54 -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=D7veV6v2X2BlPwUiF362sH96WxmtHtgP7BmaOQF5x2Q=; b=MAV86Yvb00JvCPifQJMFThANJpz2fYenPu9ThyC9dn840Bm3gc5/elvSU3a74aZMIdP87Pc3jywhff3DAG/8zkrSrGIQr/bobocf/kQh8F7i1ToZBRJwvPyaTYA7fewYxHVFPgMhP2fr3IUf0eYdw1RC4UFoyZ/9F7X/Qetkxuk=
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.888.16; Wed, 15 Feb 2017 12:11:51 +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.0888.030; Wed, 15 Feb 2017 12:11:51 +0000
From: "Dang, Quynh (Fed)" 
To: Atul Luykx , Yoav Nir 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwyaNRpm4jTNwkW4fHeK7pLqGKFpp3IA
Date: Wed, 15 Feb 2017 12:11:50 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
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-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:3ioq2qNaXfhh2ZevHNxSFqw9v9soSxAmz8pjc9gy3+GlJVyUT+yfQfwpZ+hlq619joha/ZUxajhjRRC/b1Lr39KD7j7wUjW/LMlIVaLRgRSp/9HC7RdZgl5ZUYuFWJm0fN31mVrg297GfIuc3+K3jNzmUmanmeSpNpwdW9FxUWT3rYqd8QoajH+ORTbn+50UUXmZm70yRY+IobR7szBSQ53XutO+gSyRCzvQGQogiMzWr7F2cqDRGVzDX99gWDlKxf3Jk97ZDE5hv9ZyTCzf/CAb9f8JTe/wgqHcB00IdGZxk1fZPhQjQpDy2Ylt6m+U70oT3ivKUWFrMG6c1PNXFwgF23cDrXH/w49QMrnNtvOJhytMHVJKdTD6hK3oUWD3h+PKxcafroI06d0rvwapK2lrCs1FyTNOXDqvB670lr/aU4Hj37uewfifuyPiBJhwi87Ys1mLGp9bnf22jdcoRsFwzYGEYu6Ov1lYh5wiR724jsovabZRVx7huhm9DoEIlOl5rsSmzBc1mGHPxYsWIw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(199003)(189002)(377424004)(229853002)(99286003)(54906002)(50986999)(76176999)(101416001)(93886004)(102836003)(54356999)(36756003)(53936002)(3846002)(389900002)(2906002)(6116002)(86362001)(3280700002)(106116001)(81156014)(81166006)(92566002)(8676002)(106356001)(6246003)(606005)(54896002)(6512007)(6306002)(3660700001)(122556002)(105586002)(189998001)(236005)(4001350100001)(66066001)(25786008)(8936002)(4326007)(6436002)(77096006)(83506001)(2950100002)(68736007)(6506006)(7736002)(5660300001)(6486002)(53546003)(2900100001)(39060400002)(97736004)(38730400002)(7906003); 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: 8c7ee9a8-5fff-4500-262d-08d4559bd2c4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1461; 
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)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; 
x-forefront-prvs: 021975AE46
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_D4C9AB9C302D5qdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 12:11:50.8492 (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: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:11:57 -0000

--_000_D4C9AB9C302D5qdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir >
Cc: 'Quynh' >, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically=
 the same: they are practically zero.  And, 2^-32 is an absolute chance in =
this case meaning that all attackers can=92t improve their chance: no matte=
r how much computational power the attacker has.

I don=92t understand why the number 2^-60 is your special chosen number for=
 this ? In your =93theory=94, 2^-112 would be in =93higher=94 security than=
 2^-60.

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) >
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I=92m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--_000_D4C9AB9C302D5qdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Atul,







I hope you had a happy Valentine! 









From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 4:52 PM

To: Yoav Nir <ynir.ietf@gmail.com>

Cc: 'Quynh' <Quynh.Dang@nist.gov>, IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.=
org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)

















Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Because he wants to lower the security level. 














I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practi=
cally the same: they are practically zero.  And, 2^-32 is an absolute =
chance in this case meaning that all attackers can=92t improve their chance=
: no matter how much computational power
 the attacker has.   







I don=92t understand why the number 2^-60 is your special chosen numbe=
r for this ? In your =93theory=94, 2^-112 would be in =93higher=94 security=
 than 2^-60. 







Quynh.  



















The original text 


recommends switching at 2^{34.5} input blocks, corresponding to a 

success probability of 2^{-60}, whereas his text recommends switching =
at 


2^{48} blocks, corresponding to a success probability of 2^{-32}.






Atul







On 2017-02-14 11:45, Yoav Nir wrote:




Hi, Quynh






On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov>


wrote:




Hi Sean and all,




Beside my suggestion at



I have a second suggestion below.




Just replacing this sentence: "




For AES-GCM, up to 2^24.5 full-size records (about 24 million) may

be


encrypted on a given connection while keeping a safety margin of


approximately 2^-57 for Authenticated Encryption (AE) security.


" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48=



(partial or full) input blocks may be encrypted with one key. For

other suggestions and analysis, see the referred paper above."



Regards,


Quynh.






I like the suggestion, but I=92m probably missing something pretty

basic about it.




2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or

(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10

blocks.




Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Thanks




Yoav








Links:


------



_______________________________________________


TLS mailing list




















--_000_D4C9AB9C302D5qdangnistgov_--


From nobody Wed Feb 15 05:46:39 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76631295E8 for ; Wed, 15 Feb 2017 05:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.786
X-Spam-Level: 
X-Spam-Status: No, score=-3.786 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, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 L5sNvG2DcRzR for ; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20054.outbound.protection.outlook.com [40.107.2.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218D4127A90 for ; Wed, 15 Feb 2017 05:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zTl04xdrJ75e17uqBfz2L0OHNo/+X6LxAHPLUiveiaw=; b=zd0dEnLK0DOkYQw8OWrhyI6fh4QFNAog+OGa7tETBqd7OTqJJKc1KA3JwLefRQiFMTz0Jkaf+B2tevNYNUlc1UsCq1gZAzQt3WM9ePxA0ZCoPp91gtQvGYQG3yf/ZapJSJV4gMXoKhp1nVh6VID7y3WxqrwjkXRImI5Ve4OhFMM=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 13:46:28 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 13:46:28 +0000
From: "Paterson, Kenny" 
To: "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwykYuvgBCblgkOlDzVRxLEvWqFp+0YAgAAacIA=
Date: Wed, 15 Feb 2017 13:46:28 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>          , 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [219.59.14.82]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:UjeNrd4xMu3XNr7jy+YyHoJM9Imrl6CNIvn3/nNbJRoRcG/Uj80nnHTU/U3d0tNEi8cYlTQ3DFpcHaNGXyn5JTGDwHu9vbWYDmdGPAJRdADLmyCylP/TTv9JZE5H3erIecEK8aTpyxPVu+m6lDqKVLGYpqqEw6V2z+9p7OF2iUk/EWqyRFjO4Sp5H0z9xuK4wlK4QAl+ivZ/mei/hztpa8rg+rXFFyxwvi4PYMsHWo4PA9bC7iPrEihV1/6bwlvkJNKS4wKpMnKJU29V4dWajhSwP5V1iJC5XlaPhzFTKK/QhOgS0CNYONDjoWAQukhfdEU1P4M9jSSjHJ2ShJ1sGiOTFNGiDW8ESgLgC2OGAX4c00qOHSyybVTKnxP9Difh0mhvhFng8R5Eoh/IPDsO1HdeJMQSvwbUW7sur/bOO/13bt/pOfDTzNXVs0Keg/n753QijrANf5y3kZHiTijfmdsr3ZrXw9dk4meDtsXlDjp+7WiIhe3VOFoCk0zsb4KCDnucJfhDEmRFMUOT2CkN4w==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(189002)(24454002)(377424004)(199003)(6246003)(54356999)(7736002)(7906003)(106356001)(106116001)(105586002)(97736004)(101416001)(2906002)(50986999)(189998001)(74482002)(66066001)(4326007)(93886004)(33656002)(76176999)(3846002)(6116002)(102836003)(6916009)(81166006)(36756003)(2900100001)(53546003)(8936002)(8676002)(92566002)(229853002)(81156014)(38730400002)(236005)(82746002)(68736007)(83716003)(5660300001)(39060400002)(122556002)(53936002)(86362001)(54906002)(25786008)(77096006)(6512007)(2950100002)(42882006)(6436002)(8656002)(6306002)(3280700002)(6506006)(606005)(6486002)(110136004)(54896002)(389900002)(99286003)(3660700001)(104396002)(19625805005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 1c2bb23d-854c-4996-932f-08d455a90aae
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908; 
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)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908; 
x-forefront-prvs: 021975AE46
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_"
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 13:46:28.2359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: 
Cc: Atul Luykx , IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 13:46:35 -0000

--_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUXV5bmgsDQoNCkknbSBtZWFudCB0byBiZSBvbiB2YWNhdGlvbiwgYnV0IEknbSBmaW5kaW5n
IHRoaXMgb24tZ29pbmcgZGlzY3Vzc2lvbiBmYXNjaW5hdGluZywgc28gSSdtIGNoaXBwaW5nIGlu
IGFnYWluLg0KDQpPbiAxNSBGZWIgMjAxNywgYXQgMjE6MTIsIERhbmcsIFF1eW5oIChGZWQpIDxx
dXluaC5kYW5nQG5pc3QuZ292PG1haWx0bzpxdXluaC5kYW5nQG5pc3QuZ292Pj4gd3JvdGU6DQoN
CkhpIEF0dWwsDQoNCkkgaG9wZSB5b3UgaGFkIGEgaGFwcHkgVmFsZW50aW5lIQ0KDQpGcm9tOiBB
dHVsIEx1eWt4IDxBdHVsLkx1eWt4QGVzYXQua3VsZXV2ZW4uYmU8bWFpbHRvOkF0dWwuTHV5a3hA
ZXNhdC5rdWxldXZlbi5iZT4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxNyBhdCA0
OjUyIFBNDQpUbzogWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnluaXIuaWV0
ZkBnbWFpbC5jb20+Pg0KQ2M6ICdRdXluaCcgPFF1eW5oLkRhbmdAbmlzdC5nb3Y8bWFpbHRvOlF1
eW5oLkRhbmdAbmlzdC5nb3Y+PiwgSVJURiBDRlJHIDxjZnJnQGlydGYub3JnPG1haWx0bzpjZnJn
QGlydGYub3JnPj4sICJ0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0
Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1RMU10gW0NmcmddIENs
b3Npbmcgb3V0IHRsczEuMyAiTGltaXRzIG9uIGtleSB1c2FnZSIgUFJzICgjNzY1LyM3NjkpDQoN
CldoeSBpcyB0aGF0IDJeNDggaW5wdXQgYmxvY2tzIHJhdGhlciB0aGFuIDJeMzQuNSBpbnB1dCBi
bG9ja3M/DQpCZWNhdXNlIGhlIHdhbnRzIHRvIGxvd2VyIHRoZSBzZWN1cml0eSBsZXZlbC4NCg0K
SSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUuIDJeLTMyLCAyXi0zMywgMl4tNTcsIDJeLTYwLCAyXi0x
MTIgYXJlIHByYWN0aWNhbGx5IHRoZSBzYW1lOiB0aGV5IGFyZSBwcmFjdGljYWxseSB6ZXJvLg0K
DQpJJ20gbm90IGNsZWFyIHdoYXQgeW91IG1lYW4gYnkgInByYWN0aWNhbGx5IiBoZXJlLiBUaGV5
J3JlIGNsZWFybHkgbm90IHRoZSBzYW1lIGFzIHJlYWwgbnVtYmVycy4gQW5kIGlmIHdlIGFyZSBi
ZWluZyBjb25zZXJ2YXRpdmUgYWJvdXQgc2VjdXJpdHksIHRoZW4gdGhlIGV4dHJlbWVzIGluIHlv
dXIgbGlzdCBhcmUgYSBsb25nIHdheSBhcGFydC4NCg0KQW5kLCAyXi0zMiBpcyBhbiBhYnNvbHV0
ZSBjaGFuY2UgaW4gdGhpcyBjYXNlIG1lYW5pbmcgdGhhdCBhbGwgYXR0YWNrZXJzIGNhbuKAmXQg
aW1wcm92ZSB0aGVpciBjaGFuY2U6IG5vIG1hdHRlciBob3cgbXVjaCBjb21wdXRhdGlvbmFsIHBv
d2VyIHRoZSBhdHRhY2tlciBoYXMuDQoNCkEgc3VmZmljaWVudGx5IHBvd2VyZnVsIGFkdmVyc2Fy
eSBjb3VsZCBjYXJyeSBvdXQgYW4gZXhoYXVzdGl2ZSBrZXkgc2VhcmNoIGZvciBHQ00ncyB1bmRl
cmx5aW5nIEFFUyBrZXkuIFNvIEknbSBub3Qgc3VyZSB3aGF0IHlvdSdyZSBjbGFpbWluZyBoZXJl
IHdoZW4geW91IHNwZWFrIG9mICJhYnNvbHV0ZSBjaGFuY2UiLg0KDQpJIGRvbuKAmXQgdW5kZXJz
dGFuZCB3aHkgdGhlIG51bWJlciAyXi02MCBpcyB5b3VyIHNwZWNpYWwgY2hvc2VuIG51bWJlciBm
b3IgdGhpcyA/DQoNClRoaXMgaXMgYSBiaXQgc3VidGxlLCBidXQgSSdsbCB0cnkgdG8gZXhwbGFp
biBpbiBzaW1wbGUgdGVybXMuDQoNCldlIGNhbiBjb252ZW5pZW50bHkgcHJvdmUgYSBib3VuZCBv
ZiBhYm91dCB0aGlzIHNpemUgKGFjdHVhbGx5IDJeLTU3KSBmb3IgSU5ULUNUWFQgZm9yIGEgd2lk
ZSByYW5nZSBvZiBwYXJhbWV0ZXJzIGNvdmVyaW5nIGJvdGggVExTIGFuZCBEVExTICh3aGVyZSBt
YW55IHZlcmlmaWNhdGlvbiBmYWlsdXJlcyBtYXkgYmUgcGVybWl0dGVkKS4gVGhlbiwgc2luY2Ug
d2UncmUgdWx0aW1hdGVseSBpbnRlcmVzdGVkIGluIEFFIHNlY3VyaXR5LCB3ZSB3b3VsZCBsaWtl
IHRvIChyb3VnaGx5KSBtYXRjaCB0aGlzIGZvciBJTkQtQ1BBIHNlY3VyaXR5LCB0byBnZXQgYXMg
Z29vZCBhIGJvdW5kIGFzIHdlIGNhbiBmb3IgQUUgc2VjdXJpdHkgKHRoZSBzZWN1cml0eSBib3Vu
ZHMgZm9yIHRoZSB0d28gbm90aW9ucyBzdW0gdG8gZ2l2ZSBhbiBBRSBzZWN1cml0eSBib3VuZCAt
IHNlZSBwYWdlIDIgb2YgdGhlICJBRSBib3VuZHMiIG5vdGUpLg0KDQpJbiB2aWV3IG9mIHRoZSBJ
TlQtQ1RYVCBib3VuZCB0aGVyZSdzIG5vIHBvaW50IHB1c2hpbmcgdGhlIElORC1DUEEgYm91bmQg
bXVjaCBsb3dlciB0aGFuIDJeLTYwIGlmIHRoZSB1bHRpbWF0ZSB0YXJnZXQgaXMgQUUgc2VjdXJp
dHkuIEl0IGp1c3QgaHVydHMgdGhlIGRhdGEgbGltaXRzIG1vcmUgd2l0aG91dCBzaWduaWZpY2Fu
dGx5IGltcHJvdmluZyBBRSBzZWN1cml0eS4NCg0KRmluYWxseSwgMl4tNjAgaXMgbm90ICpvdXIq
IHNwZWNpYWwgY2hvc2VuIG51bWJlci4gV2Ugd3JvdGUgYSBub3RlIHRoYXQgY29udGFpbmVkIGEg
dGFibGUgb2YgdmFsdWVzLCBhbmQgaXQncyB3b3J0aCBub3RpbmcgdGhhdCB3ZSBkaWQgbm90IG1h
a2UgYSBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbiBpbiBvdXIgbm90ZSBmb3Igd2hpY2ggcm93IG9m
IHRoZSB0YWJsZSB0byBzZWxlY3QuDQoNCihOYXR1cmFsbHksIHRob3VnaCwgd2UnZCBsaWtlIHNl
Y3VyaXR5IHRvIGJlIGFzIGhpZ2ggYXMgcG9zc2libGUgd2l0aG91dCBtYWtpbmcgcmVrZXlpbmcg
YSBmcmVxdWVudCBldmVudC4gSXQncyBhIGNvbnRpbnVpbmcgc3VycHJpc2UgdG8gbWUgdGhhdCB5
b3UgYXJlIHB1c2hpbmcgZm9yIGFuIG9wdGlvbiB0aGF0IGFjdHVhbGx5IHJlZHVjZXMgc2VjdXJp
dHkgd2hlbiBhY2hpZXZpbmcgaGlnaGVyIHNlY3VyaXR5IGRvZXMgbm90IHNlZW0gdG8gY2F1c2Ug
YW55IHByb2JsZW1zIGZvciBpbXBsZW1lbnRvcnMuKQ0KDQpJbiB5b3VyIOKAnHRoZW9yeeKAnSwg
Ml4tMTEyIHdvdWxkIGJlIGluIOKAnGhpZ2hlcuKAnSBzZWN1cml0eSB0aGFuIDJeLTYwLg0KDQpJ
dCBjZXJ0YWlubHkgd291bGQsIGlmIGl0IHdlcmUgYWNoaWV2YWJsZSAod2hpY2ggaXQgaXMgbm90
IGZvciBHQ00gd2l0aG91dCBwdXR0aW5nIHNvbWUgcXVpdGUgZXh0cmVtZSBsaW1pdHMgb24gZGF0
YSBwZXIga2V5KS4NCg0KQ2hlZXJzLA0KDQpLZW5ueQ0KDQpRdXluaC4NCg0KDQpUaGUgb3JpZ2lu
YWwgdGV4dA0KcmVjb21tZW5kcyBzd2l0Y2hpbmcgYXQgMl57MzQuNX0gaW5wdXQgYmxvY2tzLCBj
b3JyZXNwb25kaW5nIHRvIGENCnN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTYwfSwgd2hlcmVh
cyBoaXMgdGV4dCByZWNvbW1lbmRzIHN3aXRjaGluZyBhdA0KMl57NDh9IGJsb2NrcywgY29ycmVz
cG9uZGluZyB0byBhIHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTMyfS4NCg0KQXR1bA0KDQpP
biAyMDE3LTAyLTE0IDExOjQ1LCBZb2F2IE5pciB3cm90ZToNCkhpLCBRdXluaA0KT24gMTQgRmVi
IDIwMTcsIGF0IDIwOjQ1LCBEYW5nLCBRdXluaCAoRmVkKSA8cXV5bmguZGFuZ0BuaXN0Lmdvdjxt
YWlsdG86cXV5bmguZGFuZ0BuaXN0Lmdvdj4+DQp3cm90ZToNCkhpIFNlYW4gYW5kIGFsbCwNCkJl
c2lkZSBteSBzdWdnZXN0aW9uIGF0DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL3Rscy9jdXJyZW50L21zZzIyMzgxLmh0bWwgWzFdLA0KSSBoYXZlIGEgc2Vjb25kIHN1Z2dl
c3Rpb24gYmVsb3cuDQpKdXN0IHJlcGxhY2luZyB0aGlzIHNlbnRlbmNlOiAiDQpGb3IgQUVTLUdD
TSwgdXAgdG8gMl4yNC41IGZ1bGwtc2l6ZSByZWNvcmRzIChhYm91dCAyNCBtaWxsaW9uKSBtYXkN
CmJlDQplbmNyeXB0ZWQgb24gYSBnaXZlbiBjb25uZWN0aW9uIHdoaWxlIGtlZXBpbmcgYSBzYWZl
dHkgbWFyZ2luIG9mDQphcHByb3hpbWF0ZWx5IDJeLTU3IGZvciBBdXRoZW50aWNhdGVkIEVuY3J5
cHRpb24gKEFFKSBzZWN1cml0eS4NCiIgaW4gU2VjdGlvbiA1LjUgYnkgdGhpcyBzZW50ZW5jZTog
IiBGb3IgQUVTLUdDTSwgdXAgdG8gMl40OA0KKHBhcnRpYWwgb3IgZnVsbCkgaW5wdXQgYmxvY2tz
IG1heSBiZSBlbmNyeXB0ZWQgd2l0aCBvbmUga2V5LiBGb3INCm90aGVyIHN1Z2dlc3Rpb25zIGFu
ZCBhbmFseXNpcywgc2VlIHRoZSByZWZlcnJlZCBwYXBlciBhYm92ZS4iDQpSZWdhcmRzLA0KUXV5
bmguDQpJIGxpa2UgdGhlIHN1Z2dlc3Rpb24sIGJ1dCBJ4oCZbSBwcm9iYWJseSBtaXNzaW5nIHNv
bWV0aGluZyBwcmV0dHkNCmJhc2ljIGFib3V0IGl0Lg0KMl4yNC41IGZ1bGwtc2l6ZSByZWNvcmRz
IGlzIDJeMjQuNSByZWNvcmRzIG9mIDJeMTQgYnl0ZXMgZWFjaCwgb3INCihzaW5jZSBhbiBBRVMg
YmxvY2sgaXMgMTYgYnl0ZXMgb3IgMl40IGJ5dGVzKSAyXjI0LjUgcmVjb3JkcyBvZiAyXjEwDQpi
bG9ja3MuDQpXaHkgaXMgdGhhdCAyXjQ4IGlucHV0IGJsb2NrcyByYXRoZXIgdGhhbiAyXjM0LjUg
aW5wdXQgYmxvY2tzPw0KVGhhbmtzDQpZb2F2DQpMaW5rczoNCi0tLS0tLQ0KWzFdIGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMjIzODEuaHRtbA0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls
aW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxt
YWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90bHMNCg==

--_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkhpIFF1eW5oLDxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj5JJ20gbWVhbnQgdG8gYmUgb24gdmFjYXRpb24sIGJ1dCBJJ20gZmluZGluZyB0aGlzIG9u
LWdvaW5nIGRpc2N1c3Npb24gZmFzY2luYXRpbmcsIHNvIEknbSBjaGlwcGluZyBpbiBhZ2Fpbi4m
bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KT24gMTUgRmViIDIwMTcsIGF0IDIxOjEyLCBEYW5nLCBR
dXluaCAoRmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1eW5oLmRhbmdAbmlzdC5nb3YiPnF1eW5o
LmRhbmdAbmlzdC5nb3Y8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+SGkgQXR1bCw8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PkkgaG9wZSB5b3UgaGFkIGEgaGFwcHkgVmFsZW50aW5lISZuYnNwOzwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln
bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M
RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47
IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF
Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BdHVsIEx1eWt4ICZsdDs8YSBocmVmPSJtYWls
dG86QXR1bC5MdXlreEBlc2F0Lmt1bGV1dmVuLmJlIj5BdHVsLkx1eWt4QGVzYXQua3VsZXV2ZW4u
YmU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw
YW4+VHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTcgYXQgNDo1MiBQTTxicj4NCjxzcGFuIHN0eWxl
PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPllvYXYgTmlyICZsdDs8YSBocmVmPSJtYWls
dG86eW5pci5pZXRmQGdtYWlsLmNvbSI+eW5pci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+J1F1eW5oJyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOlF1eW5oLkRhbmdAbmlzdC5nb3YiPlF1eW5oLkRhbmdAbmlzdC5nb3Y8L2E+
Jmd0OywgSVJURiBDRlJHICZsdDs8YSBocmVmPSJtYWlsdG86Y2ZyZ0BpcnRmLm9yZyI+Y2ZyZ0Bp
cnRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNA
aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq
ZWN0OiA8L3NwYW4+UmU6IFtUTFNdIFtDZnJnXSBDbG9zaW5nIG91dCB0bHMxLjMgJnF1b3Q7TGlt
aXRzIG9uIGtleSB1c2FnZSZxdW90OyBQUnMgKCM3NjUvIzc2OSk8YnI+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP
Q0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAw
IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B
Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1
YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pldo
eSBpcyB0aGF0IDJeNDggaW5wdXQgYmxvY2tzIHJhdGhlciB0aGFuIDJeMzQuNSBpbnB1dCBibG9j
a3M/PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkJlY2F1c2UgaGUgd2FudHMgdG8gbG93ZXIg
dGhlIHNlY3VyaXR5IGxldmVsLiA8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHJlc3BlY3RmdWxseSBkaXNhZ3Jl
ZS4gMl4tMzIsIDJeLTMzLCAyXi01NywgMl4tNjAsIDJeLTExMiBhcmUgcHJhY3RpY2FsbHkgdGhl
IHNhbWU6IHRoZXkgYXJlIHByYWN0aWNhbGx5IHplcm8uICZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ20gbm90IGNsZWFyIHdoYXQg
eW91IG1lYW4gYnkgJnF1b3Q7cHJhY3RpY2FsbHkmcXVvdDsgaGVyZS4gVGhleSdyZSBjbGVhcmx5
IG5vdCB0aGUgc2FtZSBhcyByZWFsIG51bWJlcnMuIEFuZCBpZiB3ZSBhcmUgYmVpbmcgY29uc2Vy
dmF0aXZlIGFib3V0IHNlY3VyaXR5LCB0aGVuIHRoZSBleHRyZW1lcyBpbiB5b3VyIGxpc3QgYXJl
IGEgbG9uZyB3YXkgYXBhcnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5BbmQsIDJeLTMyIGlzIGFuIGFic29sdXRl
IGNoYW5jZSBpbiB0aGlzIGNhc2UgbWVhbmluZyB0aGF0IGFsbCBhdHRhY2tlcnMgY2Fu4oCZdCBp
bXByb3ZlIHRoZWlyIGNoYW5jZTogbm8gbWF0dGVyIGhvdyBtdWNoIGNvbXB1dGF0aW9uYWwgcG93
ZXIgdGhlIGF0dGFja2VyIGhhcy4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpBIHN1ZmZpY2llbnRseSBwb3dlcmZ1bCBhZHZlcnNh
cnkgY291bGQgY2Fycnkgb3V0IGFuIGV4aGF1c3RpdmUga2V5IHNlYXJjaCBmb3IgR0NNJ3MgdW5k
ZXJseWluZyBBRVMga2V5LiBTbyBJJ20gbm90IHN1cmUgd2hhdCB5b3UncmUgY2xhaW1pbmcgaGVy
ZSB3aGVuIHlvdSBzcGVhayBvZiAmcXVvdDthYnNvbHV0ZSBjaGFuY2UmcXVvdDsuJm5ic3A7DQo8
ZGl2PiZuYnNwOw0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+
SSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHRoZSBudW1iZXIgMl4tNjAgaXMgeW91ciBzcGVjaWFs
IGNob3NlbiBudW1iZXIgZm9yIHRoaXMgPw0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYSBiaXQgc3VidGxlLCBidXQgSSdsbCB0
cnkgdG8gZXhwbGFpbiBpbiBzaW1wbGUgdGVybXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KV2UgY2FuIGNvbnZlbmllbnRseSBwcm92ZSBhIGJvdW5kIG9mIGFib3V0IHRoaXMgc2l6
ZSAoYWN0dWFsbHkgMl4tNTcpIGZvciBJTlQtQ1RYVCBmb3IgYSB3aWRlIHJhbmdlIG9mIHBhcmFt
ZXRlcnMgY292ZXJpbmcgYm90aCBUTFMgYW5kIERUTFMgKHdoZXJlIG1hbnkgdmVyaWZpY2F0aW9u
IGZhaWx1cmVzIG1heSBiZSBwZXJtaXR0ZWQpLiBUaGVuLCBzaW5jZSB3ZSdyZSB1bHRpbWF0ZWx5
IGludGVyZXN0ZWQgaW4gQUUgc2VjdXJpdHksIHdlIHdvdWxkDQogbGlrZSB0byAocm91Z2hseSkg
bWF0Y2ggdGhpcyBmb3IgSU5ELUNQQSBzZWN1cml0eSwgdG8gZ2V0IGFzIGdvb2QgYSBib3VuZCBh
cyB3ZSBjYW4gZm9yIEFFIHNlY3VyaXR5ICh0aGUgc2VjdXJpdHkgYm91bmRzIGZvciB0aGUgdHdv
IG5vdGlvbnMgc3VtIHRvIGdpdmUgYW4gQUUgc2VjdXJpdHkgYm91bmQgLSBzZWUgcGFnZSAyIG9m
IHRoZSAmcXVvdDtBRSBib3VuZHMmcXVvdDsgbm90ZSkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5JbiB2aWV3IG9mIHRoZSBJTlQtQ1RYVCBib3VuZCB0aGVyZSdzIG5vIHBv
aW50IHB1c2hpbmcgdGhlIElORC1DUEEgYm91bmQgbXVjaCBsb3dlciB0aGFuIDJeLTYwIGlmIHRo
ZSB1bHRpbWF0ZSB0YXJnZXQgaXMgQUUgc2VjdXJpdHkuIEl0IGp1c3QgaHVydHMgdGhlIGRhdGEg
bGltaXRzIG1vcmUgd2l0aG91dCBzaWduaWZpY2FudGx5IGltcHJvdmluZyBBRSBzZWN1cml0eS4m
bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZpbmFsbHksIDJeLTYwIGlzIG5v
dCAqb3VyKiBzcGVjaWFsIGNob3NlbiBudW1iZXIuIFdlIHdyb3RlIGEgbm90ZSB0aGF0IGNvbnRh
aW5lZCBhIHRhYmxlIG9mIHZhbHVlcywgYW5kIGl0J3Mgd29ydGggbm90aW5nIHRoYXQgd2UgZGlk
IG5vdCBtYWtlIGEgc3BlY2lmaWMgcmVjb21tZW5kYXRpb24gaW4gb3VyIG5vdGUgZm9yIHdoaWNo
IHJvdyBvZiB0aGUgdGFibGUgdG8gc2VsZWN0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+KE5hdHVyYWxseSwgdGhvdWdoLCB3ZSdkIGxpa2Ugc2VjdXJpdHkgdG8gYmUgYXMg
aGlnaCBhcyBwb3NzaWJsZSB3aXRob3V0IG1ha2luZyByZWtleWluZyBhIGZyZXF1ZW50IGV2ZW50
LiBJdCdzIGEgY29udGludWluZyBzdXJwcmlzZSB0byBtZSB0aGF0IHlvdSBhcmUgcHVzaGluZyBm
b3IgYW4gb3B0aW9uIHRoYXQgYWN0dWFsbHkgcmVkdWNlcyBzZWN1cml0eSB3aGVuIGFjaGlldmlu
ZyBoaWdoZXIgc2VjdXJpdHkgZG9lcyBub3Qgc2VlbSB0bw0KIGNhdXNlIGFueSBwcm9ibGVtcyBm
b3IgaW1wbGVtZW50b3JzLikmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5JbiB5b3VyIOKAnHRoZW9yeeKA
nSwgMl4tMTEyIHdvdWxkIGJlIGluIOKAnGhpZ2hlcuKAnSBzZWN1cml0eSB0aGFuIDJeLTYwLiZu
YnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5JdCBjZXJ0YWlubHkgd291bGQsIGlmIGl0IHdlcmUgYWNoaWV2YWJsZSAod2hpY2ggaXQgaXMg
bm90IGZvciBHQ00gd2l0aG91dCBwdXR0aW5nIHNvbWUgcXVpdGUgZXh0cmVtZSBsaW1pdHMgb24g
ZGF0YSBwZXIga2V5KS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVy
cyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pktlbm55Jm5ic3A7PC9kaXY+DQo8YnI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5RdXlu
aC4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz
cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP
T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg
c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj5UaGUgb3JpZ2luYWwgdGV4dCA8L2Rpdj4NCjxkaXY+cmVjb21tZW5kcyBzd2l0Y2hpbmcg
YXQgMl57MzQuNX0gaW5wdXQgYmxvY2tzLCBjb3JyZXNwb25kaW5nIHRvIGEgPC9kaXY+DQo8ZGl2
PnN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTYwfSwgd2hlcmVhcyBoaXMgdGV4dCByZWNvbW1l
bmRzIHN3aXRjaGluZyBhdCA8L2Rpdj4NCjxkaXY+Ml57NDh9IGJsb2NrcywgY29ycmVzcG9uZGlu
ZyB0byBhIHN1Y2Nlc3MgcHJvYmFiaWxpdHkgb2YgMl57LTMyfS48L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PkF0dWw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIDIwMTct
MDItMTQgMTE6NDUsIFlvYXYgTmlyIHdyb3RlOjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P
VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRk
ZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2PkhpLCBR
dXluaDwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS
SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg
UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj5PbiAxNCBGZWIgMjAxNywg
YXQgMjA6NDUsIERhbmcsIFF1eW5oIChGZWQpICZsdDs8YSBocmVmPSJtYWlsdG86cXV5bmguZGFu
Z0BuaXN0LmdvdiI+cXV5bmguZGFuZ0BuaXN0LmdvdjwvYT4mZ3Q7PC9kaXY+DQo8ZGl2Pndyb3Rl
OjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+SGkgU2VhbiBhbmQgYWxsLDwvZGl2Pg0KPGRpdj48
L2Rpdj4NCjxkaXY+QmVzaWRlIG15IHN1Z2dlc3Rpb24gYXQ8L2Rpdj4NCjxkaXY+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMjM4
MS5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50
L21zZzIyMzgxLmh0bWw8L2E+IFsxXSw8L2Rpdj4NCjxkaXY+SSBoYXZlIGEgc2Vjb25kIHN1Z2dl
c3Rpb24gYmVsb3cuPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5KdXN0IHJlcGxhY2luZyB0aGlz
IHNlbnRlbmNlOiAmcXVvdDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkZvciBBRVMtR0NNLCB1
cCB0byAyXjI0LjUgZnVsbC1zaXplIHJlY29yZHMgKGFib3V0IDI0IG1pbGxpb24pIG1heTwvZGl2
Pg0KPGRpdj5iZTwvZGl2Pg0KPGRpdj5lbmNyeXB0ZWQgb24gYSBnaXZlbiBjb25uZWN0aW9uIHdo
aWxlIGtlZXBpbmcgYSBzYWZldHkgbWFyZ2luIG9mPC9kaXY+DQo8ZGl2PmFwcHJveGltYXRlbHkg
Ml4tNTcgZm9yIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiAoQUUpIHNlY3VyaXR5LjwvZGl2Pg0K
PGRpdj4mcXVvdDsgaW4gU2VjdGlvbiA1LjUgYnkgdGhpcyBzZW50ZW5jZTogJnF1b3Q7IEZvciBB
RVMtR0NNLCB1cCB0byAyXjQ4PC9kaXY+DQo8ZGl2PihwYXJ0aWFsIG9yIGZ1bGwpIGlucHV0IGJs
b2NrcyBtYXkgYmUgZW5jcnlwdGVkIHdpdGggb25lIGtleS4gRm9yPC9kaXY+DQo8ZGl2Pm90aGVy
IHN1Z2dlc3Rpb25zIGFuZCBhbmFseXNpcywgc2VlIHRoZSByZWZlcnJlZCBwYXBlciBhYm92ZS4m
cXVvdDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlF1eW5o
LjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48L2Rpdj4NCjxkaXY+SSBsaWtlIHRoZSBzdWdn
ZXN0aW9uLCBidXQgSeKAmW0gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcgcHJldHR5PC9kaXY+
DQo8ZGl2PmJhc2ljIGFib3V0IGl0LjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Ml4yNC41IGZ1
bGwtc2l6ZSByZWNvcmRzIGlzIDJeMjQuNSByZWNvcmRzIG9mIDJeMTQgYnl0ZXMgZWFjaCwgb3I8
L2Rpdj4NCjxkaXY+KHNpbmNlIGFuIEFFUyBibG9jayBpcyAxNiBieXRlcyBvciAyXjQgYnl0ZXMp
IDJeMjQuNSByZWNvcmRzIG9mIDJeMTA8L2Rpdj4NCjxkaXY+YmxvY2tzLjwvZGl2Pg0KPGRpdj48
L2Rpdj4NCjxkaXY+V2h5IGlzIHRoYXQgMl40OCBpbnB1dCBibG9ja3MgcmF0aGVyIHRoYW4gMl4z
NC41IGlucHV0IGJsb2Nrcz88L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoYW5rczwvZGl2Pg0K
PGRpdj48L2Rpdj4NCjxkaXY+WW9hdjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj5MaW5rczo8L2Rpdj4NCjxkaXY+LS0tLS0tPC9kaXY+DQo8ZGl2Plsx
XSA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJy
ZW50L21zZzIyMzgxLmh0bWwiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl
Yi90bHMvY3VycmVudC9tc2cyMjM4MS5odG1sPC9hPjwvZGl2Pg0KPGRpdj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj5UTFMgbWFpbGlu
ZyBsaXN0PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRm
Lm9yZzwvYT48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz
PC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+VExTIG1haWxpbmcgbGlzdDwv
c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5v
cmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3RsczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CDDC781227AF4566AE336DF829FEB81Erhulacuk_--


From nobody Wed Feb 15 09:05:18 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099112955D for ; Wed, 15 Feb 2017 09:05:17 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 qJ8HdlZTEGdO for ; Wed, 15 Feb 2017 09:05:15 -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 9B79F12966D for ; Wed, 15 Feb 2017 09:05:15 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id u25so157475068qki.2 for ; Wed, 15 Feb 2017 09:05:15 -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=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=oLnwMPD6nMW1EX1vJ19xhi+46DT2g6dYbtn7Psc/wBfeha/b7UV7OkT38b0CXdnj7k OIGW5sFJRFucBPGrBXVOH+bCUK0iCyfWK60PlevhjbeQ8n2uZZp1QEX9F2tkgfbFln6m 6VVSOExDqRbaEEo9EkLDKhTscDmlvQ2CuAGT9e85A5BmY/+9cCLdcV3b3rVpvtMTfTx+ CPzRzncQmsrWd4itMs4RNxIUETIesbPVZU1wE6ZuuPsfbySyCWtuohYFhKtUShQ7Gwax 7/MnxQj4Gr17pJg86CS1HhsP4BDZOoio8V5d8r0OAsWYbmjC6DkS5HOTfJPR+eujDVD5 hIiQ==
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=rPQLotHZVefq48IRqlZOrechzCecrcx+PJ+tH863kbE=; b=kqgge3qFdAa8yjcygCAR4ZYJd3rLYxsZ+fQgepgiqNWc//VqqEpL72TErcQAr4Tt6m O33mp5LwpkBafMV//wMeR4NcndNjela9r80uo3Ndv0y9qT+8P97Ir30fqo6MZGB2IV1c c0Z3MYcKGpQZY0+UCk/YS8eINFP3bAYn71ceDjmCE8Oo9Y8JICiwbsWGEcPz+1Xxop1B ju+/bLcO+4pt60w5YTtdJCQ+09jnsSLc2j2hBe/BhBnop03KGBPG2IB7IxDs3AAYwxpU yFqN2kjgJ75BWtqVNYSx9bYSNd9b1jQah9Y4ux4J9HK8WUO2JVacmodZZsRXDpEwdXBT 7BzA==
X-Gm-Message-State: AMke39nTNrLvKaKJawbyoDscYLCBH5Rs1+0s72lLkBm3+mfynmNMd83cWJ6GBgL0gIA3BsBryHklRdPH4Utjkw==
X-Received: by 10.233.235.66 with SMTP id b63mr36433927qkg.144.1487178314706;  Wed, 15 Feb 2017 09:05:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:05:14 -0800 (PST)
In-Reply-To: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>            
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:05:14 +1100
Message-ID: 
To: "Paterson, Kenny" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:05:17 -0000

Kenny's response here is quite informative and clarifies this somewhat.

2^24.5 (the current text) is still a big number.  Though it might seem
a little small, I see no practical reason to change it.  In the most
perverse case, that means 520MB of one octet records (23MB of actual
data) before an update is forced.  It's hard to get excited about that
as a practical limitation.

Frankly, I'm more concerned that this isn't small enough and that it
could it be practical to deploy an implementation that don't support
KeyUpdate.  That would cause a real interop problem.

On 16 February 2017 at 00:46, Paterson, Kenny  w=
rote:
> Hi Quynh,
>
> I'm meant to be on vacation, but I'm finding this on-going discussion
> fascinating, so I'm chipping in again.
>
> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)  wrote:
>
> Hi Atul,
>
> I hope you had a happy Valentine!
>
> From: Atul Luykx 
> Date: Tuesday, February 14, 2017 at 4:52 PM
> To: Yoav Nir 
> Cc: 'Quynh' , IRTF CFRG , "tls@ietf.o=
rg"
> 
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769)
>
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>
> Because he wants to lower the security level.
>
>
> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practical=
ly
> the same: they are practically zero.
>
>
> I'm not clear what you mean by "practically" here. They're clearly not th=
e
> same as real numbers. And if we are being conservative about security, th=
en
> the extremes in your list are a long way apart.
>
> And, 2^-32 is an absolute chance in this case meaning that all attackers
> can=E2=80=99t improve their chance: no matter how much computational powe=
r the
> attacker has.
>
>
> A sufficiently powerful adversary could carry out an exhaustive key searc=
h
> for GCM's underlying AES key. So I'm not sure what you're claiming here w=
hen
> you speak of "absolute chance".
>
>
> I don=E2=80=99t understand why the number 2^-60 is your special chosen nu=
mber for
> this ?
>
>
> This is a bit subtle, but I'll try to explain in simple terms.
>
> We can conveniently prove a bound of about this size (actually 2^-57) for
> INT-CTXT for a wide range of parameters covering both TLS and DTLS (where
> many verification failures may be permitted). Then, since we're ultimatel=
y
> interested in AE security, we would like to (roughly) match this for IND-=
CPA
> security, to get as good a bound as we can for AE security (the security
> bounds for the two notions sum to give an AE security bound - see page 2 =
of
> the "AE bounds" note).
>
> In view of the INT-CTXT bound there's no point pushing the IND-CPA bound
> much lower than 2^-60 if the ultimate target is AE security. It just hurt=
s
> the data limits more without significantly improving AE security.
>
> Finally, 2^-60 is not *our* special chosen number. We wrote a note that
> contained a table of values, and it's worth noting that we did not make a
> specific recommendation in our note for which row of the table to select.
>
> (Naturally, though, we'd like security to be as high as possible without
> making rekeying a frequent event. It's a continuing surprise to me that y=
ou
> are pushing for an option that actually reduces security when achieving
> higher security does not seem to cause any problems for implementors.)
>
> In your =E2=80=9Ctheory=E2=80=9D, 2^-112 would be in =E2=80=9Chigher=E2=
=80=9D security than 2^-60.
>
>
> It certainly would, if it were achievable (which it is not for GCM withou=
t
> putting some quite extreme limits on data per key).
>
> Cheers,
>
> Kenny
>
> Quynh.
>
>
> The original text
> recommends switching at 2^{34.5} input blocks, corresponding to a
> success probability of 2^{-60}, whereas his text recommends switching at
> 2^{48} blocks, corresponding to a success probability of 2^{-32}.
>
> Atul
>
> On 2017-02-14 11:45, Yoav Nir wrote:
>
> Hi, Quynh
>
> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
> wrote:
> Hi Sean and all,
> Beside my suggestion at
> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
> I have a second suggestion below.
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
> be
> encrypted on a given connection while keeping a safety margin of
> approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
> (partial or full) input blocks may be encrypted with one key. For
> other suggestions and analysis, see the referred paper above."
> Regards,
> Quynh.
>
> I like the suggestion, but I=E2=80=99m probably missing something pretty
> basic about it.
> 2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
> (since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
> blocks.
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> Thanks
> Yoav
> Links:
> ------
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Wed Feb 15 09:20:47 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59D129627 for ; Wed, 15 Feb 2017 09:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uipWXP1DlelQ for ; Wed, 15 Feb 2017 09:20:45 -0800 (PST)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::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 C2B01129572 for ; Wed, 15 Feb 2017 09:20:44 -0800 (PST)
Received: by mail-wr0-x242.google.com with SMTP id c4so6515973wrd.1 for ; Wed, 15 Feb 2017 09:20:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ypd6iXJmbyw8ITdPYpT0JWT9mqayqe0kORvWYMLP3ms=; b=pasFOIXVkGX9epodVrdYvEMvw/cGAS5+znIaSzon8ktL033nQNkpHyrjjfDjszc21M WSroOU2Nxbiin91jL8MiXC8CXfYKUHGC9lAMTj3VqIlBGBkE33IQEaRzEOSt1gVus9FB 5sHwYbX3HB0zSCzZ8HMTMNJKzhsx1Iz6LKNdbiXyOfKH5JqRKDzmDNtS0WG5Baillc3C QoyI30tnPNeizAFk57ctAd7DQxmys/wrI5kNYmAABcBvpYUFCf0X5UOOwj4+2jqcn/OM LlysuABeJujgnCP2kJO1k8RM81WLTTss4cTry/5BvLuAmQzHKgepFkMLA9QNydoLgspM ++0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ypd6iXJmbyw8ITdPYpT0JWT9mqayqe0kORvWYMLP3ms=; b=enKd7enKa2Wseko/Zzg6Qcrlx4td9v9DKiAgP1J0PE9DmiUWnp1qqo0xc1OsctJkFZ UMswtaPZvIcCtfIpI1ldJeCjIBqbE4sNnhf/JTYXyqUp/5OK00F8peJpat1ipNDY/De/ 5z9moauL5rfG2yAduW8RYRzG5XSwHawAow/fqqT9rhpi2GzYwnc2rHSjx9LtMBSIjPnB G7VrduSBinpTY8KpP+9SfdiKnZ1qx0309F8NgmeeyND0DMe4Nz5ebaOOPrKNcjgyJaHe ONPIJ5YoQjLEr3JjsrJaWDJ2BJWOtj2NnmVDiE6QWhVTMo6kAeJQCN8WI3sUCWybyovI BlgA==
X-Gm-Message-State: AMke39kAGn/utYUWLv1z4YHKpzohIFQCjJ7f2zqy9OfametpEqXfXy+uNRpMa7EiCNHu3A==
X-Received: by 10.223.152.2 with SMTP id v2mr30972319wrb.109.1487179243317; Wed, 15 Feb 2017 09:20:43 -0800 (PST)
Received: from [192.168.137.219] ([176.13.243.119]) by smtp.gmail.com with ESMTPSA id s18sm171632wmb.18.2017.02.15.09.20.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:20:42 -0800 (PST)
From: Yoav Nir 
Message-Id: <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Feb 2017 19:20:39 +0200
In-Reply-To: 
To: Martin Thomson 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>             
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:20:46 -0000

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748"


--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 15 Feb 2017, at 19:05, Martin Thomson  =
wrote:
>=20
> Frankly, I'm more concerned that this isn't small enough and that it
> could it be practical to deploy an implementation that don't support
> KeyUpdate.  That would cause a real interop problem.

Maybe we should resurrect [1] and add 3DES support so as to grease =
KeyUpdate.

No, not really, but TLS is not just the web, and there are connections =
that last for a long time and transfer large amounts of data. Think =
datacenter synchronization. At packet-sized records 24 million records =
amounts to 36 GB. That is considerably larger than a 4 GB software =
update I downloaded over HTTPS a few years ago, but not out of the =
ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 =



--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 15 Feb 2017, at 19:05, =
Martin Thomson <martin.thomson@gmail.com> wrote:

Frankly, I'm more concerned that this isn't small enough and =
that it
could it be practical to deploy an implementation =
that don't support
KeyUpdate.  That would cause a =
real interop problem.

Maybe we should resurrect [1] and add 3DES =
support so as to grease KeyUpdate.

No, not really, but TLS is not just the =
web, and there are connections that last for a long time and transfer =
large amounts of data. Think datacenter synchronization. At packet-sized =
records 24 million records amounts to 36 GB. That is considerably larger =
than a 4 GB software update I downloaded over HTTPS a few years ago, but =
not out of the ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2=
-05

=

--Apple-Mail=_0F3C71CD-16F1-497A-B712-69DBA5B1F748--

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYpI3oAAoJELhJCxUKWMyZxCoH/i78Njd11PRpuJ7mYbuDY1TH
mnRUTGoxtXDl6WpZNIxBhXyTewrH6HMEUlc7E6EESLwF2YN0uAPAnZZRlEqgjA8V
rI1sZ8R6zJhIIg2Zhp1gmEbQTH6DhVsA+FLkEddKtqVK9k1Htac72saurbK1kqzo
fg529uv2+/WxxENbnqzDFi6KSOjVxaFERjuR8pNWBMbkuFVWJcdeRQIo6+hH7xqn
GoqEV8hGeBLwlWMq0epSrr/QxZzDGIkj6lxbjMeugYb2dQ7fl0YaRWAc85HVf+DL
JvEHwCR6VfRbK0V2ApSREJMuC/qDQW1ZWGxkZjDWljQ1zp/0/rIZqnkXVhCQ+RY=
=Eibu
-----END PGP SIGNATURE-----

--Apple-Mail=_ED3FB0F0-8D1A-4099-AD1B-C0C107D677C6--


From nobody Wed Feb 15 09:25:39 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F188129674 for ; Wed, 15 Feb 2017 09:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dofT82zCRcja for ; Wed, 15 Feb 2017 09:25:37 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F6B12964C for ; Wed, 15 Feb 2017 09:25:37 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id k15so143442490qtg.3 for ; Wed, 15 Feb 2017 09:25:37 -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=AK113fekdUpSZpTf7ils2iO0GpV9Ztdr0+lCD+1QXq0=; b=DTtlvJwRiIvFFuSpI2eLMzO8SWX1LDecUp09RNz+QzcQcZnWWTXLEEIyhYCS4sDAZ/ EJvbtrU+4ugn38BeDbpCKNosI5pv+6h+MI9go5gFi3gkAjdLQZDTjf3voy4cSp1wlqtE Lt3S1GH/7pUpLU8Y7tP+eDODvG+dZB86NIQgMTtMAJvXJBzHZ8h5HA/P42CM6vYW80vv 3TVY+l9NMmIUFHI74JXJq5Gh+35e/8ifEN+Go46PXPCEQJqJbHiXXdrxtSjyyeLYk0f9 a/6umb6p6fTksybphjV6jpT9NWfULcoAIfLS89Dy6rkvL3zJTPiksngcn43ek5fQeRtz cQrg==
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=AK113fekdUpSZpTf7ils2iO0GpV9Ztdr0+lCD+1QXq0=; b=JJx9veDJwJLLw6WFGyyKDXtyN7Kf6WVVOnMjQcKMIGO4VcB8iIWrWwsBwS3Yanpo9y 1gCly7bKg91CUnF15i2iNhMlNGIgrobbjtB0URPbjCaAT6qTc/V19aqT0KPsr+/fiQ9a RGrDc9AjjxvJ9tRhTGC+4+eIFzTssS1XMmZXC4aOsJOU2qTi4zA8XNY0PLICRab/0F9t qVkeH7ClATjpDx7BbvaAV0rXgWVMHWhnAuo+i3NgFrMfWZsvNmCSR9tTfaT3lZAcMD/v wYAvvw8cieDhtS5ev3CZv2yOyeVKxYMb3mjvYm3WPRFsqLpATyrPiXx/JMPzTUNsqP8R qX9w==
X-Gm-Message-State: AMke39n57Fz/QIIioFEAL09N/Ix27jq7uC4zBshwjmIENgaYpE/XdT8nP98qNmjekMnWLpXNdLrQWZ+jKyjwnA==
X-Received: by 10.200.55.112 with SMTP id p45mr36746074qtb.278.1487179536228;  Wed, 15 Feb 2017 09:25:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:25:35 -0800 (PST)
In-Reply-To: <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:25:35 +1100
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:25:38 -0000

On 16 February 2017 at 04:20, Yoav Nir  wrote:
> No, not really, but TLS is not just the web, and there are connections that
> last for a long time and transfer large amounts of data. Think datacenter
> synchronization. At packet-sized records 24 million records amounts to 36
> GB. That is considerably larger than a 4 GB software update I downloaded
> over HTTPS a few years ago, but not out of the ballpark.

I realize that's going to require updates pretty often (once you open
up the CWND), but I don't think that it is frequent enough to be a
concern.

I well know that HTTP gets used at these volumes more often than
people realize.  I'd rather recommend ChaCha for those niche uses
though if the rate was sufficiently high.


From nobody Wed Feb 15 09:30:17 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF44A129572 for ; Wed, 15 Feb 2017 09:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 TgnoTBQFN3od for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0DE1293DC for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
Received: by mail-wr0-x244.google.com with SMTP id q39so1391171wrb.2 for ; Wed, 15 Feb 2017 09:30:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+P9AJ22m0W1uR0IeGX8lhwirkFyNvSm4ddY0ivyy1EE=; b=l2G2/eWiTmKtTmyxMJSTgK9UaOIK9so4V60VJ3ZOpTEc3AcnpdRXaS50KcxbDxYcGC qv7br8TfEkdxbnIeyI2kLOclKMQSn24igR3IZGxSDiumkoFdyUwpRV4vO+na7+81lZX3 hD4dW5iVqSvoMHchS9QAgoce5GQ2Ds5EK+N80A+Q72tH5xaC7kuPTyPJvVAoV5G8WRzA vVqLw9DQsV63yRrscmU6+gG1eTh1sXdLrEQ7oBgPWMl9EuVPj5KaAsPki+SxrkztY4/U JKzftGXBCVfFNBDGhOs9Q7G/pTDzwOFpwXz88chAj6uVkmBlVrkiVQLtwOatYJLrE7pm 8//w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+P9AJ22m0W1uR0IeGX8lhwirkFyNvSm4ddY0ivyy1EE=; b=Dm2tsaICyzfnLM69+xLJQ0UskznAd1VC8oB/lAC7ERvtENHk82RDzogkt7qibKM61t lcSpIYAgwQ/lBrtMNuQ8f7W33TWPAdS9374mxLsQGBlFGUWVBmnnQv8n5E3p7pETRdhx 0+y4XkumTVXTSo4ZiwYm8bWi/HzH7uenonwWQg7fqltfaQc6P25L3NCNsrnRw2z01pQ7 baWm2/s+R03ipQg6FfauGXO+MfXlgcpSYcWM3D7hIi/y7CgCjPm70mm421hBI/Iz/nRF JlskFM+7HbGTS8G0AEltdAwcxhZko1MRWLpzQxq0PBI84wEtFXguDkMn4v7qIRAcFymt CJQw==
X-Gm-Message-State: AMke39nzHb3tR1NnDom1aoTbEYONri9J57jgBR82AiNmyhejCA8uDBglJ1qaQpNSd6wJpw==
X-Received: by 10.223.161.130 with SMTP id u2mr35286995wru.127.1487179807685;  Wed, 15 Feb 2017 09:30:07 -0800 (PST)
Received: from [192.168.137.219] ([176.13.243.119]) by smtp.gmail.com with ESMTPSA id i73sm212628wmd.11.2017.02.15.09.30.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:30:06 -0800 (PST)
From: Yoav Nir 
Message-Id: <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 15 Feb 2017 19:30:04 +0200
In-Reply-To: 
To: Martin Thomson 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com> 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:30:11 -0000

--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 15 Feb 2017, at 19:25, Martin Thomson  =
wrote:
>=20
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are =
connections that
>> last for a long time and transfer large amounts of data. Think =
datacenter
>> synchronization. At packet-sized records 24 million records amounts =
to 36
>> GB. That is considerably larger than a 4 GB software update I =
downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
>=20
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
>=20
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

And now I=E2=80=99ve lost you. A moment ago I thought you were concerned =
that people would fail to implement KeyUpdate. Are you now suggesting =
that it be removed entirely from TLS 1.3?

There=E2=80=99s no getting around the fact that AES-GCM is faster on =
certain processors than ChaCha, and speed is likely to be a major =
concern for exactly the same systems that use the high data volumes.

Yoav



--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYpJAcAAoJELhJCxUKWMyZFHMH/jaqnZ0ip7jimuowadDp4sEU
STdxpj3GcmISV/+f+J1Aeod/ZSa4WniM+R+liPsONEVQOOkbBI/aCqb5HnuyDskn
R3old6vEGfbzk5JWAEB9WtCQWVpOeuruJgAMpvI+32HyX6j7nDxzpEqtvKMWff+V
d97+o0hvW3jI+9dPmOkVN/FXfw2Eh/2qx4aqyotbw11iZxTaFvSAIgOGiI3DsF8Z
ULq5B4laFejs454CukmctJ/TShWqHUSDJTnft5l8AcdDSskwqIkxzy3o5k8sytzx
q4I/CXHkeVgG+M4otbM+uBnps4fvhAyqRrXS5HtBAfyLPQXpQIjG+vOvNCmZIGs=
=amz4
-----END PGP SIGNATURE-----

--Apple-Mail=_89B8EC13-4F33-4FF1-AD79-19F8A4074C04--


From nobody Wed Feb 15 09:33:36 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ADE1296B4 for ; Wed, 15 Feb 2017 09:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf8C1fnYNEqw for ; Wed, 15 Feb 2017 09:33:22 -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 82DC21296A9 for ; Wed, 15 Feb 2017 09:33:22 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id p22so66592076qka.0 for ; Wed, 15 Feb 2017 09:33:22 -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=zJYzbrH0hTyIR14j/7bll3X852dqxW5Den39cRhYLCo=; b=svnN8FTt0+W3K2etYF3e1STN5Ceh2NBGhu32C2nJvG3K0LFdaQFp/2Hfe2ZuOfvPjP lHuzgcTciQADC4xbCk26BAq6ye7pFoEaNDPIcHxUDGVPMmGi60jW9mcO1HNCJotCQf6h 0AoFW/awysYdlubSC2mLDJNaTwL+/zFjJy6QiMjxscchziokl9CQR6eQwLI6xABRklpj sQ69qfB2YpA9pSsf2hWptfACIuhgGlysO6Vp36ymg5NlPbQPVS6SQ981o6j51fs9CD7W FDo/U16Y3Y1LeScgOHZDgh9f6QlKK26Jn+WaQL6RfF6GO1SzotEUR4sERjc9aIcpc+7o hg2w==
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=zJYzbrH0hTyIR14j/7bll3X852dqxW5Den39cRhYLCo=; b=aplOJwQwI3IJZDS64wcI6FkFnRf6KJq8equz72hckTFPxKDS6vUJh/2SEpsS6l8qPz WEEIEfGQRmtIVkgW7VeuO/8eD+egPW14fv17jOe0dQnWJ/6zq1OwVvKfkwxwwVnyz8p6 jaCHusD5ztHFMRf3E8fjgy5+rRlX2BnLtNMoyraBUKWfyKc0am9wqd6iNdwrDS+bVZIO DSbByb23nW6cCjvRozp/O0TNcqL6qbIVgTFNzAhdrcMecMC9ld/07M9IWvG7UWH+5Qv5 MyhBu0QORZJ+8t/OKpNMCkyKQHwEreznXUkCbrTHmbi/3hIB/od6xsIYRSnuw6+VOWYL 9jjQ==
X-Gm-Message-State: AMke39m1KtCIdk1GrOKGMgQ8nB64+iump9Kp70iPey57W1q6mKo4Lc9N760JQgjwGXeFBPWSne+QTt1Eq628RA==
X-Received: by 10.233.235.66 with SMTP id b63mr36582482qkg.144.1487180001787;  Wed, 15 Feb 2017 09:33:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 09:33:21 -0800 (PST)
In-Reply-To: <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com>  <4639F8A9-1DD7-48E5-ABE4-2658311E0C33@gmail.com>
From: Martin Thomson 
Date: Thu, 16 Feb 2017 04:33:21 +1100
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:33:35 -0000

On 16 February 2017 at 04:30, Yoav Nir  wrote:
> And now I=E2=80=99ve lost you. A moment ago I thought you were concerned =
that people would fail to implement KeyUpdate. Are you now suggesting that =
it be removed entirely from TLS 1.3?


No.  My point was that if GCM requires more updates than you can
handle (because you are running well in excess of 1Tbps perhaps, I
don't know, my crystal ball isn't that good), then use ChaCha where
you don't need to update so often.  Obviously there is a tradeoff
there given the relative availability of hardware support, which you
likely need at those rates, but again the crystal ball is imperfect in
telling us how that story plays out.


From nobody Thu Feb 16 04:23:13 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040AA129AC7 for ; Thu, 16 Feb 2017 04:23:12 -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=unavailable 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 yBFwM1ygYYaB for ; Thu, 16 Feb 2017 04:23:08 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0091.outbound.protection.outlook.com [23.103.201.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC67129AC5 for ; Thu, 16 Feb 2017 04:23:08 -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=Mn427C0mM0Y1SKWnGL0lLQfr4uMnjO2JxwenELlWOjg=; b=dT3KPENs+l9JSnAPpaPIba6ZVlO11b53psU6lxpHwY1zShArPJLv8kRmSmeDgMmFd+qPf3aj9xjwL0C2tLk5w4+3zxnPWRD2MN9kObo5zqyKZr0lDkBIzzqHBumwg9p4LeK2VZ+R4Hr9SODIhilxXe/y5gDsx9kHoiRGdL1AT3s=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 12:23:06 +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.0888.034; Thu, 16 Feb 2017 12:23:05 +0000
From: "Dang, Quynh (Fed)" 
To: "Paterson, Kenny" , "Dang, Quynh (Fed)" 
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHShwyaNRpm4jTNwkW4fHeK7pLqGKFpp3IAgABuRACAASc0AA==
Date: Thu, 16 Feb 2017 12:23:05 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>            
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.219.235]
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 7:PNqhs7Oz7bssgbJDv8FflZ5IyyGxCn67rxc6v4oUTehPAkehfhi/AjVPmyirnpII+pE3aw8ahmf9hiSGbjWMdiznZxrje37UOGw7iu/O5QYqpQ28eWj9nZkxpB1XMuHc6PfaEcUQtRSpcB/YJJSpqneKnZjv+8siaLzuJzISCtH1LqQ+6wNL7ucVmmyEiRv2rRG3cWFYDtZif0By6jDyyMr31OwS6OQ5FLuUV3T8BSRX+z7/tuAmPu/F+XVRgrkDEC02R28+NR4eduLeZin3h8lkgkDq424qL8/bbK4hgn0YolyssB8qi8fyZxWiR7TNugX51j7hD5RSY8jfLXq4qg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(377424004)(377454003)(24454002)(6306002)(6512007)(25786008)(66066001)(83506001)(97736004)(3660700001)(606005)(54896002)(4001350100001)(6246003)(8936002)(105586002)(5660300001)(122556002)(236005)(7906003)(53546003)(6506006)(7736002)(389900003)(39060400002)(6436002)(2900100001)(6486002)(38730400002)(8656002)(68736007)(77096006)(2950100002)(102836003)(4326007)(2906002)(54356999)(93886004)(50986999)(76176999)(229853002)(99286003)(101416001)(189998001)(92566002)(54906002)(81166006)(8676002)(106356001)(3280700002)(106116001)(81156014)(3846002)(86362001)(36756003)(53936002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 44fe5b57-84a4-4403-6e9e-08d456668f4a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1463; 
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)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1463; 
x-forefront-prvs: 0220D4B98D
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_D4CAF7363040Cqdangnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 12:23:05.5154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463
Archived-At: 
Cc: Atul Luykx , IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 12:23:12 -0000

--_000_D4CAF7363040Cqdangnistgov_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Kenny,

I am glad to see that you enjoyed the discussion more than what you planed =
for the time on your vacation.  We love crypto and the IETF!

From: "Paterson, Kenny" >
Date: Wednesday, February 15, 2017 at 8:46 AM
To: 'Quynh' >
Cc: Atul Luykx >, Yoav Nir >, IRTF CFR=
G >, "tls@ietf.org=
" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion fasci=
nating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) > wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx >
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir >
Cc: 'Quynh' >, IRTF CFRG >, "tls@ietf.org" >
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#76=
5/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically=
 the same: they are practically zero.

I'm not clear what you mean by "practically" here.

As far as I know, such chance has not happened in history for any targeted =
search where the chance for hitting the target is 1 in 2^32.

They're clearly not the same as real numbers. And if we are being conservat=
ive about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers ca=
n=92t improve their chance: no matter how much computational power the atta=
cker has.

A sufficiently powerful adversary could carry out an exhaustive key search =
for GCM's underlying AES key. So I'm not sure what you're claiming here whe=
n you speak of "absolute chance".

I described my point not in a best way, sorry. For key recovery, if an atta=
cker can do 2^96 AES operations, his chance of finding the key is 2^-32, bu=
t this chance will get improved if the attacker does more computation. On t=
he contrary, the chance for the distinguishing attack won=92t change with t=
he proposed data limit.


I don=92t understand why the number 2^-60 is your special chosen number for=
 this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for I=
NT-CTXT for a wide range of parameters covering both TLS and DTLS (where ma=
ny verification failures may be permitted). Then, since we're ultimately in=
terested in AE security, we would like to (roughly) match this for IND-CPA =
security, to get as good a bound as we can for AE security (the security bo=
unds for the two notions sum to give an AE security bound - see page 2 of t=
he "AE bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound mu=
ch lower than 2^-60 if the ultimate target is AE security. It just hurts th=
e data limits more without significantly improving AE security.

I just checked the paper. There is a small error I think. AES-GCM in TLS 1.=
3 is a prf. Under a given key, every input block or just one repeated block=
 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks assumin=
g the key has 128 bits of entropy. If there is a collision among the cipher=
text blocks, it does not mean anything because it does not say anything abo=
ut the plaintext blocks.



Finally, 2^-60 is not *our* special chosen number. We wrote a note that con=
tained a table of values, and it's worth noting that we did not make a spec=
ific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without ma=
king rekeying a frequent event. It's a continuing surprise to me that you a=
re pushing for an option that actually reduces security when achieving high=
er security does not seem to cause any problems for implementors.)

I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are =
all safe choices. If someone wants to rekey sooner (or often) for operation=
al reason or any other reason, that would be just fine. I just hope that we=
 don=92t have text which might imply that 2^-32 is not a safe choice.  In o=
ur guidelines, we basically indicate that 2^-32 or below is safe.



In your =93theory=94, 2^-112 would be in =93higher=94 security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without =
putting some quite extreme limits on data per key).

Cheers,

Kenny

I am going to propose another option and I hope that you and all other peop=
le will be happy with.

Thank you and Regards,
Quynh.


Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) >
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I=92m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
------
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

--_000_D4CAF7363040Cqdangnistgov_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <5ACDD6F01661D047B3EB2DC07E8FB180@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Kenny,







I am glad to see that you enjoyed the discussion more than what you pl=
aned for the time on your vacation.  We love crypto and the IETF! =
;









From: "Paterson, Kenny" &=
lt;Kenny.Paterson@rhul.ac.uk>

Date: Wednesday, February 15, 2017 =
at 8:46 AM

To: 'Quynh' <Quynh.Dang@nist.gov>

Cc: Atul Luykx <Atul.Luykx@esat.kuleuven.be>, Yoav Ni=
r <ynir.ietf@gmail.com>, I=
RTF CFRG <cfrg@irtf.org>,
 "tls@ietf.org" <tls@ietf.org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)















Hi Quynh,






I'm meant to be on vacation, but I'm finding=
 this on-going discussion fascinating, so I'm chipping in again. 



On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:










Hi Atul,







I hope you had a happy Valentine! 









From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>

Date: Tuesday, February 14, 2017 at=
 4:52 PM

To: Yoav Nir <ynir.ietf@gmail.com>

Cc: 'Quynh' <Quynh.Dang@nist.gov>, IRTF CFRG <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.=
org>

Subject: Re: [TLS] [Cfrg] Closing o=
ut tls1.3 "Limits on key usage" PRs (#765/#769)

















Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Because he wants to lower the security level. 














I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practi=
cally the same: they are practically zero.  











I'm not clear what you mean by "practically" here.














As far as I know, such chance has not happened in history for any targ=
eted search where the chance for hitting the target is 1 in 2^32. 













They're clearly not the same as real numbers. And if we are being cons=
ervative about security, then the extremes in your list are a long way apar=
t. 











And, 2^-32 is an absolute chance in this case meaning that all attacke=
rs can=92t improve their chance: no matter how much computational power the=
 attacker has.   










A sufficiently powerful adversary could carry out an exhaustive key search =
for GCM's underlying AES key. So I'm not sure what you're claiming here whe=
n you speak of "absolute chance". 












I described my point not in a best way, sorry. For key recovery, if an=
 attacker can do 2^96 AES operations, his chance of finding the key is 2^-3=
2, but this chance will get improved if the attacker does more computation.=
 On the contrary, the chance for
 the distinguishing attack won=92t change with the proposed data limit.&nbs=
p;














 







I don=92t understand why the number 2^-60 is your special chosen numbe=
r for this ?












This is a bit subtle, but I'll try to explain in simple terms. 





We can conveniently prove a bound of about this size (actually 2^-57) for I=
NT-CTXT for a wide range of parameters covering both TLS and DTLS (where ma=
ny verification failures may be permitted). Then, since we're ultimately in=
terested in AE security, we would
 like to (roughly) match this for IND-CPA security, to get as good a bound =
as we can for AE security (the security bounds for the two notions sum to g=
ive an AE security bound - see page 2 of the "AE bounds" note).&n=
bsp;







In view of the INT-CTXT bound there's no point pushing the IND-CPA bou=
nd much lower than 2^-60 if the ultimate target is AE security. It just hur=
ts the data limits more without significantly improving AE security. <=
/div>















I just checked the paper. There is a small error I think. AES-GCM in T=
LS 1.3 is a prf. Under a given key, every input block or just one repeated =
block 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks as=
suming the key has 128 bits of entropy.
 If there is a collision among the ciphertext blocks, it does not mean anyt=
hing because it does not say anything about the plaintext blocks.  

























Finally, 2^-60 is not *our* special chosen number. We wrote a note tha=
t contained a table of values, and it's worth noting that we did not make a=
 specific recommendation in our note for which row of the table to select.&=
nbsp;







(Naturally, though, we'd like security to be as high as possible witho=
ut making rekeying a frequent event. It's a continuing surprise to me that =
you are pushing for an option that actually reduces security when achieving=
 higher security does not seem to
 cause any problems for implementors.) 
















I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60=
 are all safe choices. If someone wants to rekey sooner (or often) for oper=
ational reason or any other reason, that would be just fine. I just hope th=
at we don=92t have text which might
 imply that 2^-32 is not a safe choice.  In our guidelines, we basical=
ly indicate that 2^-32 or below is safe. 
































In your =93theory=94, 2^-112 would be in =93higher=94 security than 2^=
-60. 











It certainly would, if it were achievable (which it is not for GCM wit=
hout putting some quite extreme limits on data per key). 







Cheers,







Kenny 


















I am going to propose another option and I hope that you and all other=
 people will be happy with. 







Thank you and Regards,


Quynh. 

























Quynh.  



















The original text 


recommends switching at 2^{34.5} input blocks, corresponding to a 

success probability of 2^{-60}, whereas his text recommends switching =
at 


2^{48} blocks, corresponding to a success probability of 2^{-32}.






Atul







On 2017-02-14 11:45, Yoav Nir wrote:




Hi, Quynh






On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.dang@nist.gov>


wrote:




Hi Sean and all,




Beside my suggestion at



I have a second suggestion below.




Just replacing this sentence: "




For AES-GCM, up to 2^24.5 full-size records (about 24 million) may

be


encrypted on a given connection while keeping a safety margin of


approximately 2^-57 for Authenticated Encryption (AE) security.


" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48=



(partial or full) input blocks may be encrypted with one key. For

other suggestions and analysis, see the referred paper above."



Regards,


Quynh.






I like the suggestion, but I=92m probably missing something pretty

basic about it.




2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or

(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10

blocks.




Why is that 2^48 input blocks rather than 2^34.5 input blocks?




Thanks




Yoav








Links:


------



_______________________________________________


TLS mailing list























_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.iet=
f.org/mailman/listinfo/tls



















--_000_D4CAF7363040Cqdangnistgov_--


From nobody Thu Feb 16 11:33:48 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B405129697 for ; Thu, 16 Feb 2017 11:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 729kz6G_IP2Q for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB1012955E for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id i10so18617403wrb.0 for ; Thu, 16 Feb 2017 11:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=fw2jktFOTSwYWkYtcPGQS13BqI8oauZo3a0+Xvpcc9Q=; b=ID6PGVxtjoWxu9B/gfGZTeClZQEATGGW5CC5hsKjTAT5JtIBFHNaTEI4Yzi911DhFh qMpZXHaytKRRWx1t9c4IDnxGgkwcjsTq8h/LNhrfsJPwMPcNrNw1AGTkT4yCuNbJmn93 xpZHnEpKlgT5dk5xpjl/oUX2Cy21T0ADGMrao=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=fw2jktFOTSwYWkYtcPGQS13BqI8oauZo3a0+Xvpcc9Q=; b=bKyzfWsmvnEZEP/Lg5eMfQ3ZxnxN7+9udtdJAmZE35+1zx1tv6oKF2ZeBFDmZc84VM JWWd9qrsv0dJV4ozlI3avZ8jU6UdIzBoepRTB6FsQ4lZMP05kekan5O2NpvDuTChyP7J ZHsXsp/n5yNOH3cqIgagT/+49iYsH+datclBEhKpoxhtIce2bXYsDpxJ+S9wDiTn6D9i sDViAXdWP/erV7qqqG26uga7YrGNNMMWs3xKRzWT1N8ekH+AcXOZXqw0pTHCfbpOTkWK Hq4k0EnJ1l/4WuiTdkVVOLO+RdlyVKqICxRtGQP5NM+IBhE+1LLZcdRvoVJc0PyRFLWY 6IlA==
X-Gm-Message-State: AMke39ls3ztHkr3DX9NqQuoVmW0NiX5H6AIFf2V75LvwcSOEXJcKZ/BJeYfTHeeDTAPgmw==
X-Received: by 10.223.131.99 with SMTP id 90mr3791850wrd.146.1487273623585; Thu, 16 Feb 2017 11:33:43 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id v128sm1464652wmv.2.2017.02.16.11.33.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:33:42 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: 
Date: Thu, 16 Feb 2017 21:33:39 +0200
Message-Id: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>              <859B3094-61BF-40B3-9473-4220E830D70F@gmail.com> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 19:33:46 -0000

--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 15 Feb 2017, at 19:25, Martin Thomson  =
wrote:
>=20
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are =
connections that
>> last for a long time and transfer large amounts of data. Think =
datacenter
>> synchronization. At packet-sized records 24 million records amounts =
to 36
>> GB. That is considerably larger than a 4 GB software update I =
downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
>=20
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
>=20
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

I agree with Yoav Nir here, it's certainly not a niche use* and one's =
implementation should not be forced to use a certain cipher mode if =
there would be better options (e.g. because -- as pointed out earlier -- =
hardware support is available).

* We'll all agree that most of the TLS traffic is made up by HTTPS =
requests, still, there are many other uses and we design protocols not =
just for the web. That's W3C.

Aaron


--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYpf6UAAoJEOTbZJL9ubXVaBoQAIOmxMA1AwJ8CJTdqugN+jUS
t65bY6qAJA0trFn+aQy/U3HAAZ8GF5QfoYqKlenUI5t7M9Hh392yIp81DahEfa0E
f/n1YRWM+oxiwRpxM0QYHI9DEcseexwW4A9JIoByj4aNay/yhLazMSzv6bfJ6sMS
V2DC+64VbfyPAGLZbD4dsyWsL4JYigm347bN13Iw5LqNqK6M0t7J26o3iUp5wISl
BW8LSeTn3R354y7junwBk9sMbJCOcutREYHRzj2rgyfwbth+A+oi66xkeVY7nuXH
ImjlBVMugVhs59wnwH6AAdoqVl6Ky9/+8Jc+bPNROnlziaHprx67wvhQeM6FkbUn
CXWs/ShYgsptAYh60GsNFEgcgdT0Vzb508y0Ga+xC6NzQ8o5p5+4jEouWcFIEcHo
DHIPgo1Ds8hs86tVrgrR6Zkub0canTmU4rHv+M3ypl9UQbD/twnqPt68t+h3LkVf
yfZCKTrUiz5t4PLKnQvJyR2zYCZ3G4yBGeAzcwIBQTHmjQTulJGjKOqhHJMsizdM
4B03obkE08w3Y+Oot+CcrwLbhpi7AvedOmDESW8l2APanElLv6Uo/KAsw6K3+gS3
WjKaQtMv1Z6RqBIKGcViT+3wg4quvrZvcwgwXK73lVRZmyLsDLsOpnvOZSNBtJBg
Dc9iA3OMOsgZj4IN2rLx
=UNkw
-----END PGP SIGNATURE-----

--Apple-Mail=_461E11DF-8232-41A2-B8E2-A699F4C242C4--


From nobody Thu Feb 16 11:51:32 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591081294A5 for ; Thu, 16 Feb 2017 11:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 U0zAj51K7FsT for ; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 8B021129470 for ; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id i10so18852777wrb.0 for ; Thu, 16 Feb 2017 11:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=Af4dCvKReirZmYe9Qg7O37V4D39sHCQ6eGwmA+sD6v1px8L4p6R1GJpzPF3r9zvr0t SOqW22TOQboo8oISjcYbJ3wke0cY+XFGK2ROQ67OSNfZoroqxT0OZQ8amvuoz36L9aEw NXxy7Mtdc9T6++Xjz5PSzaVFnFAUUdwv7+2Tc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=RP4xmjiRaKg7T4jJ97gb2pPn4Ltw9WKeNIyOX3mryIg=; b=NQzOqRlcHzGMjD+BycWXAHAglNv7s2Qhj9XsVBu08DNgg1U26thdTxrGBVBU4i1qyv dD1GGBgA+O2/sKTG+tC9Ygmno+VVxWAEmxxWud63q3iQ9t5ztXsmhwSS63vhdMyN3bpV MKPuIQr7GVpK3g0qBVuTpLWgkR/xnmMOfcV2ppf/XlI05vjnuqIO4WmnPw6ZLT2ClB5d bZAghFjDV/Kge00QnmrlHOZr7SQqCuAEoOv6EBBOlKm+1QlBulIIOiFB4ixEVohUa8wZ ovLBjJX37tA+CUgUZiCx42O/A19BFDQa1HWGvdSEyMUCMPMcHAizjWFybZ0ADj2SWqec DE3g==
X-Gm-Message-State: AMke39lvkhVmPkSmJ1gzoQkkMklUY3GNjbE0dQZ18C49PdJ2+ZUIem5n9FLlHJpW0jvF7Q==
X-Received: by 10.223.179.87 with SMTP id k23mr4226551wrd.32.1487274686969; Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id c202sm1492730wmd.10.2017.02.16.11.51.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:51:26 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: 
Date: Thu, 16 Feb 2017 21:51:22 +0200
Message-Id: <8EEF5E9A-FFCD-44F9-9A68-920EDC4C9FA7@azet.org>
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>             
To: "Dang, Quynh (Fed)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Atul Luykx , IRTF CFRG , "tls@ietf.org" 
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 19:51:30 -0000

--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed)  =
wrote:
>=20
> Hi Kenny,
>=20
> I am glad to see that you enjoyed the discussion more than what you =
planed for the time on your vacation.  We love crypto and the IETF!
>=20
> From: "Paterson, Kenny" 
> Date: Wednesday, February 15, 2017 at 8:46 AM
> To: 'Quynh' 
> Cc: Atul Luykx , Yoav Nir =
, IRTF CFRG , "tls@ietf.org" =

> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs =
(#765/#769)
>=20
>> Hi Quynh,
>>=20
>> I'm meant to be on vacation, but I'm finding this on-going discussion =
fascinating, so I'm chipping in again.
>>=20
>> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)  =
wrote:
>>=20
>>> Hi Atul,
>>>=20
>>> I hope you had a happy Valentine!
>>>=20
>>> From: Atul Luykx 
>>> Date: Tuesday, February 14, 2017 at 4:52 PM
>>> To: Yoav Nir 
>>> Cc: 'Quynh' , IRTF CFRG , =
"tls@ietf.org" 
>>> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" =
PRs (#765/#769)
>>>=20
>>>>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>>>> Because he wants to lower the security level.
>>>=20
>>> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are =
practically the same: they are practically zero.
>>=20
>> I'm not clear what you mean by "practically" here.
>=20
> As far as I know, such chance has not happened in history for any =
targeted search where the chance for hitting the target is 1 in 2^32.
>=20
>> They're clearly not the same as real numbers. And if we are being =
conservative about security, then the extremes in your list are a long =
way apart.
>>=20
>>> And, 2^-32 is an absolute chance in this case meaning that all =
attackers can=92t improve their chance: no matter how much computational =
power the attacker has.
>>=20
>> A sufficiently powerful adversary could carry out an exhaustive key =
search for GCM's underlying AES key. So I'm not sure what you're =
claiming here when you speak of "absolute chance".
>=20
> I described my point not in a best way, sorry. For key recovery, if an =
attacker can do 2^96 AES operations, his chance of finding the key is =
2^-32, but this chance will get improved if the attacker does more =
computation. On the contrary, the chance for the distinguishing attack =
won=92t change with the proposed data limit.

Maybe I don't comprehend what you're trying to propose - but why change =
this paragraph then?

Coming from an HPC background: It seems to be that with frequent =
rekeying the chance of successfully performing an exhaustive search =
attack is -- even for the most advanced adversary -- so slim that we do =
not need to worry about that. In reality this is a cost-for-computation =
tradeoff that no one is going to invest in if there're more practical =
ways to attack (e.g. HUMINT/bad OPSEC, steal a private key, intrude a =
given network etc.) given the resources and thus money/power needed.

>=20
>>=20
>>> I don=92t understand why the number 2^-60 is your special chosen =
number for this ?
>>=20
>> This is a bit subtle, but I'll try to explain in simple terms.
>>=20
>> We can conveniently prove a bound of about this size (actually 2^-57) =
for INT-CTXT for a wide range of parameters covering both TLS and DTLS =
(where many verification failures may be permitted). Then, since we're =
ultimately interested in AE security, we would like to (roughly) match =
this for IND-CPA security, to get as good a bound as we can for AE =
security (the security bounds for the two notions sum to give an AE =
security bound - see page 2 of the "AE bounds" note).
>>=20
>> In view of the INT-CTXT bound there's no point pushing the IND-CPA =
bound much lower than 2^-60 if the ultimate target is AE security. It =
just hurts the data limits more without significantly improving AE =
security.
>=20
> I just checked the paper. There is a small error I think. AES-GCM in =
TLS 1.3 is a prf. Under a given key, every input block or just one =
repeated block 2^35 times, their ciphertext blocks are 2^35 random =
128-bit blocks assuming the key has 128 bits of entropy. If there is a =
collision among the ciphertext blocks, it does not mean anything because =
it does not say anything about the plaintext blocks.
>=20
>=20
>>=20
>> Finally, 2^-60 is not *our* special chosen number. We wrote a note =
that contained a table of values, and it's worth noting that we did not =
make a specific recommendation in our note for which row of the table to =
select.
>>=20
>> (Naturally, though, we'd like security to be as high as possible =
without making rekeying a frequent event. It's a continuing surprise to =
me that you are pushing for an option that actually reduces security =
when achieving higher security does not seem to cause any problems for =
implementors.)
>=20
> I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 =
are all safe choices. If someone wants to rekey sooner (or often) for =
operational reason or any other reason, that would be just fine. I just =
hope that we don=92t have text which might imply that 2^-32 is not a =
safe choice.  In our guidelines, we basically indicate that 2^-32 or =
below is safe.

...

>=20
>=20
>>=20
>>> In your =93theory=94, 2^-112 would be in =93higher=94 security than =
2^-60.
>>=20
>> It certainly would, if it were achievable (which it is not for GCM =
without putting some quite extreme limits on data per key).
>>=20
>> Cheers,
>>=20
>> Kenny
>=20
> I am going to propose another option and I hope that you and all other =
people will be happy with.

I'd strongly suggest that any changes made to this text are as clear as =
possible to non-mathematicians/cryptographers. Years of dealing with TLS =
implementation and protocol vulnerabilities tell us that uncertain =
wording and missing, clear, explanation for certain choices in standards =
have caused real-world security problems. It seems to me that the =
general consensus is that option A is preferable anyhow.

Aaron


--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYpgK6AAoJEOTbZJL9ubXVsJEQANBLO8lUu6DeslzpstBMWPvF
hywZbI38GH+4tYNZxJsH6vhAgAQawaaCt7ex7MpiPSA1hezT+rPZIJbDZt+K2kKx
M5g9nsqJoXzbLKxgbs/HERGU+3RSuC55XZhT6W9D5AuBFtuieLqPkQwadGvJbWyv
ITlFKPQu8ocMaTXWhjiUZ2fQlX3IMw7xkxPgO4tI7btyRr2D/jCmFHLckxLlp+If
A6omkKmTcDPyWaMymXLEYFC5RA1/dTazzEJiqxTlfHwllCDmOWfCOcMJKtgizY92
/UznpTtAnIoqqCL7oJ24aWbqjCUtTjLP5Ovd4yzwtR9f46nvhufJQ3vIMly/LgHi
IN6RkJn22nTIzN0u0RJq+sibKIhBa1X2zEka8Zdav+s0nF6E7LQc3agtxW77VKl3
U0OS+ybJ+SQu+dFth2l5VgUUqKxidksFpaxXY3AK/YRSLy4XnIVR7gx8Cv8e0cmG
Xqft4+6Sl/T9UTTHhPtFoU9dk8yH7ISfyd/8X6w9r7mYHIQxWeDrhTmu3ZF2LiNn
7VVlhmKCtXDU9OtQB5B4YYTQLyFMF8bUR87CHNn7/UZtVs7ZJkk7gs0Oy9HbqZST
SrM1+ocrhC+7BgrHZCe/YiZgRT5Xrsx8Ns9xHygpKdptx41ozReSCjpX9tE6DfRN
i+WAEa9q5j4F5TghjJH0
=nMe+
-----END PGP SIGNATURE-----

--Apple-Mail=_CCC50BF9-9974-4826-9AA3-BB3678A146E9--


From nobody Thu Feb 16 16:02:56 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308AD1294E9 for ; Thu, 16 Feb 2017 16:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJy-Q2JEl69Y for ; Thu, 16 Feb 2017 16:02:52 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615EE1293EE for ; Thu, 16 Feb 2017 16:02:52 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id o140so1577925lff.1 for ; Thu, 16 Feb 2017 16:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=date:from:to:subject:message-id:mime-version:content-disposition;  bh=Js/75KJWrIg8ps1K9cUklKR0ayF5VmSYDtIdkYkMGZk=; b=CxlvNs1wcm9bVPAB1JDmbOXNZn37V/9oLibCr0rlQUa9fqsjpA4AakfJnHfl9gKOWe +Jo4ygsbonRIXuMWUJ90jjJIn1srAKyLxl1292kn7J8q3afppaQBrrerg22KTFWAH4Li 9OzvqS2s1Gf2N7HaT5GdkA3C2AEiDNvEH2e0A130qELci0LPSG7KssgAXEfRh+PMmOXT Gcc4HIdIfocQY6BAF1K4H63g/3XS3Fi7DER9bDDl5Ot+6Q2gSeDMcatkqCkXnXgDD+wb qpB9sKwCFNFVm+6v0WjC5L52zubh4SZSNcO2BTG9xnFZ5qViTyj3JmVr5096ZqMnZyVs MAhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=Js/75KJWrIg8ps1K9cUklKR0ayF5VmSYDtIdkYkMGZk=; b=bjeEZgDng9J/eCWM5kqoNZ+sCRUgc/uh8DAFQQBV0zKqEDXgsq5DsmoS2UI3z0ENvp ag8CT9+vARe5AMxqDkpvqhtZP0BKn5UvbNz9R+AnEu4Duga1fkxI9swZTjipPv3WOOfK RsSQn0OnDGeEi4EpXFBcQM3eZiqsxMIKn5gXi5G/kawoIrzASNNvSVDM5fB1RfHjBY4m /jQiSKRA6IyJ6+T61NX8fDaml3W0kZAIIDJKf1xosA1KBHbtI2aNeQW5sSQzML4h0l21 Hp7HhdKGbFgpjZaaELd6vMdHDCJ8ZFbNUUX+TbdvnOY6YiUeHcUCqb6eD2gFsyXfMhc/ eHwQ==
X-Gm-Message-State: AMke39lL+ee5P17JCdezjF+NkCGXpa7QDisbyRQnhQgT6gs+7wnUoD+Nf1bn+3oHxioE8Q==
X-Received: by 10.46.0.68 with SMTP id 65mr1152793lja.64.1487289770074; Thu, 16 Feb 2017 16:02:50 -0800 (PST)
Received: from gmail.com (103-169-191-90.dyn.estpak.ee. [90.191.169.103]) by smtp.gmail.com with ESMTPSA id s7sm2087368lja.27.2017.02.16.16.02.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 16:02:49 -0800 (PST)
Date: Fri, 17 Feb 2017 02:02:47 +0200
From: Marko Kreen 
To: CFRG 
Message-ID: <20170217000247.GB23785@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: 
Subject: [Cfrg] Critique of AES-GCM-SIV
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 00:02:54 -0000

Hello CFRG!

I have reviewed the AES-GCM-SIV proposal (draft 3).  And while there
are parts I like - overall direction to higher security and
getting rid of GCM bitflipping - current design feels "ugly".
(That's a cryptographic term.)

Specifically, it is supposed to be Nonce-Misuse-Resistant mode.
That means even if nonce+key repeat, you get enough unpredictability
from message hash, so security does not fundamentally change.
Except it is now possible to detect if same message repeats.

But this does not apply to draft-03 version - if key+nonce repeat,
mode fundamentally changes - it uses fresh key and counter in one
case and only fresh counter other case.  That is ugly.

Instead it would be clearer (less ugly) if MAC(message) is always
used as extension of nonce.  They both affect counter.  Similarly,
either both affect encryption key or neither affects encryption key:

1) No rekey, only counter is synthesized - that would be basically AES-SIV
   with modern hash.  This would be strict improvement over AES-GCM,
   better security (but not too good), but same performance.

2) MAC(Plaintext) always affects encryption key.  This would give
   significantly better boundaries than just synthesized counter.
   But at the cost of extra keygen per message, which is slow for AES,
   so the mode will seem more costly than current AES-GCM.

While I like the current direction of AES-GCM-SIV of trying to achieve
higher security level by using rekey, I wonder if it would be
good to standardise a simple AES-POLYVAL mode like 1) that is also
clearly securitywise better than AES-GCM.  For use in new designs
that do care about maximum performance.  Just a thought.


To throw out some ideas on 2), here is my proposal how to synthesize
both key and counter based on MAC.


AES-GCM-SAFE
============

Cipher mode that uses key, nonce and MAC(message)
to synthesize both counter and encryption key.

Input:
  K = 128/256-bit key
  N = 128-bit Nonce
  P = plaintext
  A = additional data

Process:
  AuthKey = AES(K, N)
  SubKey1 = AES(K, N xor 1)
  RawTag = POLYVAL(AuthKey, PAD(A) || PAD(P) || LEN(A) || LEN(P))
  Tag = AES(K, N xor RawTag)
  Counter = AES(K, Tag)
  SubKey2 = AES(K, Tag xor 1)
  EncKey/128 = SubKey1 xor SubKey2
  EncKey/256 = SubKey1 || SubKey2
  CipherText = AES-CTR(EncKey, Counter, P) || Tag

Where:
  || - concat
  xor 1 - flip lowest bit of first byte
  LEN(V) - number of bits in V in 64-bit little-endian format
  PAD(V) - zero-pad to full block
  AES(K, V) - Encrypt V with key K
  AES-CTR(K, C, V) - Encrypt V with key K and counter C

Improvements

+ When key and nonce repeat, then same AuthKey is used.  But both
  counter and encryption key will be synthesized based on MAC.

+ EncKey is used only for encrypting plaintext, so no need to waste
  bits on domain-separation.  Thus full 128-bit counter can be used.

* There are no steps that need dropping bits so 128-bit nonce can
  be used.  As this is supposed to be high-security mode.

+ More natural 128/256-bit keygen for EncKey.  It's faster too
  due to less blocks encrypted. 

+ Counter is not sent in clear.  While sending counter in clear does
  not change probability of catastrophic failure, it does make
  exploiting it less expensive.

Notes

* If AES256 has related-key problems when only half of the key changes,

    EncKey/256 = (SubKey1 xor Counter) || SubKey2

  should fix it.  This may be also useful if shorter nonce is used.

* Its possible to use domain-separation for AES(K,N) vs. AES(K,Tag)
  but it does not seem necessary.

Comments?

-- 
marko


From nobody Fri Feb 17 02:01:01 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AC5129480 for ; Fri, 17 Feb 2017 02:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JSqcw_0dGA42 for ; Fri, 17 Feb 2017 02:00:58 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 C44181294E2 for ; Fri, 17 Feb 2017 02:00:57 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id l19so20880991ywc.2 for ; Fri, 17 Feb 2017 02:00:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=okqRaRwBwVNX5SAIcpeULV4CquW5m/XtV0qY0tI1RzE=; b=WV9xvBbJiw7WorVBx17tVGmggDbIpHw4hiqd/9sRtteBP1Q4rzRojh1fsB3KIkx1Wo 48NfjGd86cfqiLYiTWw1QE1KWJQERpraQB1zZX1DNKa2ySSai86vdptnMnMSVzck7SeZ J+Hgos56llCv6wIBDyEGREMrrv3fBDUco5LlGh1HwUqMhvjl61m+6LG3nLDxfFWwI83u 6kKyBYgP9UId30A7k3TIaXfMYq8ybuAyX68kSmKuW3iq5rWQ3I4rmQUU9YAwNU7mTxQ+ 32r7BbpRyiWx3A7E87eGba54lm25tuFpuplgtLxuFerLlQBkSUD4BEoj9Jla15VjYJY0 jHUg==
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=okqRaRwBwVNX5SAIcpeULV4CquW5m/XtV0qY0tI1RzE=; b=HWXKJdYuWQ6r7KRW3kGqsp/VXuIF4AP2WSdAKM18SBPMNWGR90ApmS6GWidol5KTtf v9ae3aCxpVBkCcD1nfIaAeKvVYJC53sN5XwbBblVtOtKPXZsNmNQxp9TzbDYBW8Oepc0 2xrljtANcICppNXAvRSVTZwFKohJi+sFxSKY80x7qfnDoU74dP7ZO4PNfzp01B+BO4Kd S/0PBSQBhcTvsKCVbbtTlGN1KqAIfTos1WRxWvBaaJ3HeLyNurPOjtjYyE9PwmlrWLHA 4zJNHkyVSM2BUittoJpOCQU1DdAD35qT7HHXitPeRdmCMHj9Ic0s+2KedRUQqKfyy/5C 0JXQ==
X-Gm-Message-State: AMke39l7WnRPmpg4CoTV27kDXWCH0zgYljXmqkeIPZ+DML2PFVJ1IEzrVLu4SdcFiUiVViuwFxci8Rs8CVzCmRt0
X-Received: by 10.129.129.3 with SMTP id r3mr5056463ywf.0.1487325656770; Fri, 17 Feb 2017 02:00:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.207.149 with HTTP; Fri, 17 Feb 2017 02:00:56 -0800 (PST)
In-Reply-To: <20170217000247.GB23785@gmail.com>
References: <20170217000247.GB23785@gmail.com>
From: Daniel Bleichenbacher 
Date: Fri, 17 Feb 2017 11:00:56 +0100
Message-ID: 
To: Marko Kreen 
Content-Type: multipart/alternative; boundary=94eb2c07dd3e701d9f0548b6fd04
Archived-At: 
Cc: CFRG 
Subject: Re: [Cfrg] Critique of AES-GCM-SIV
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 10:01:00 -0000

--94eb2c07dd3e701d9f0548b6fd04
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 17, 2017 at 1:02 AM, Marko Kreen  wrote:

>
> Hello CFRG!
>
> I have reviewed the AES-GCM-SIV proposal (draft 3).  And while there
> are parts I like - overall direction to higher security and
> getting rid of GCM bitflipping - current design feels "ugly".
> (That's a cryptographic term.)
>
> Specifically, it is supposed to be Nonce-Misuse-Resistant mode.
> That means even if nonce+key repeat, you get enough unpredictability
> from message hash, so security does not fundamentally change.
> Except it is now possible to detect if same message repeats.
>
> But this does not apply to draft-03 version - if key+nonce repeat,
> mode fundamentally changes - it uses fresh key and counter in one
> case and only fresh counter other case.  That is ugly.
>
> Instead it would be clearer (less ugly) if MAC(message) is always
> used as extension of nonce.  They both affect counter.  Similarly,
> either both affect encryption key or neither affects encryption key:
>
> 1) No rekey, only counter is synthesized - that would be basically AES-SIV
>    with modern hash.  This would be strict improvement over AES-GCM,
>    better security (but not too good), but same performance.
>
> 2) MAC(Plaintext) always affects encryption key.  This would give
>    significantly better boundaries than just synthesized counter.
>    But at the cost of extra keygen per message, which is slow for AES,
>    so the mode will seem more costly than current AES-GCM.
>
> While I like the current direction of AES-GCM-SIV of trying to achieve
> higher security level by using rekey, I wonder if it would be
> good to standardise a simple AES-POLYVAL mode like 1) that is also
> clearly securitywise better than AES-GCM.  For use in new designs
> that do care about maximum performance.  Just a thought.
>
>
> To throw out some ideas on 2), here is my proposal how to synthesize
> both key and counter based on MAC.
>
>
> AES-GCM-SAFE
> ============
>
> Cipher mode that uses key, nonce and MAC(message)
> to synthesize both counter and encryption key.
>
> Input:
>   K = 128/256-bit key
>   N = 128-bit Nonce
>   P = plaintext
>   A = additional data
>
> Process:
>   AuthKey = AES(K, N)
>   SubKey1 = AES(K, N xor 1)
>   RawTag = POLYVAL(AuthKey, PAD(A) || PAD(P) || LEN(A) || LEN(P))
>   Tag = AES(K, N xor RawTag)
>   Counter = AES(K, Tag)
>   SubKey2 = AES(K, Tag xor 1)
>   EncKey/128 = SubKey1 xor SubKey2
>   EncKey/256 = SubKey1 || SubKey2
>   CipherText = AES-CTR(EncKey, Counter, P) || Tag
>
> Where:
>   || - concat
>   xor 1 - flip lowest bit of first byte
>   LEN(V) - number of bits in V in 64-bit little-endian format
>   PAD(V) - zero-pad to full block
>   AES(K, V) - Encrypt V with key K
>   AES-CTR(K, C, V) - Encrypt V with key K and counter C
>
> Improvements
>
> + When key and nonce repeat, then same AuthKey is used.  But both
>   counter and encryption key will be synthesized based on MAC.
>
> + EncKey is used only for encrypting plaintext, so no need to waste
>   bits on domain-separation.  Thus full 128-bit counter can be used.
>
> * There are no steps that need dropping bits so 128-bit nonce can
>   be used.  As this is supposed to be high-security mode.
>
> + More natural 128/256-bit keygen for EncKey.  It's faster too
>   due to less blocks encrypted.
>
> + Counter is not sent in clear.  While sending counter in clear does
>   not change probability of catastrophic failure, it does make
>   exploiting it less expensive.
>
> Notes
>
> * If AES256 has related-key problems when only half of the key changes,
>
>     EncKey/256 = (SubKey1 xor Counter) || SubKey2
>
>   should fix it.  This may be also useful if shorter nonce is used.
>
> * Its possible to use domain-separation for AES(K,N) vs. AES(K,Tag)
>   but it does not seem necessary.
>
> Comments?
>
> --
> marko
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

I have problems to see how this proposal is safe.
I.e. Cooley used that POLYVAL returns 0 if A and P are empty in the
AES-GCM-SIV cryptanalysis.
In the proposal above using A="" and P = "" results in
Tag = AES(K,N)
Therefore an attacker can use the proposal above as an oracle to for
encrypting single blocks with K.
This is all that is needed to break the proposal.
Hence it seems to me that even a nonce respecting adversary can break this
proposal.

I actually don't know what "ugly" means as a cryptographic term.
My guess would something like difficult to formally analyze.
E.g. in the proposal above if N and N xor 1 are both used as nonces then
AuthKey and SubKey1 change their role and that seems to add a lot of
complexity
to a potential analysis.

--94eb2c07dd3e701d9f0548b6fd04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Fri, Feb 17, 2017 at 1:02 AM, Marko Kreen <markokr@gmail.com> wrote:


Hello CFRG!



I have reviewed the AES-GCM-SIV proposal (draft 3).=C2=A0 And while there
are parts I like - overall direction to higher security and

getting rid of GCM bitflipping - current design feels "ugly".

(That's a cryptographic term.)



Specifically, it is supposed to be Nonce-Misuse-Resistant mode.

That means even if nonce+key repeat, you get enough unpredictability

from message hash, so security does not fundamentally change.

Except it is now possible to detect if same message repeats.



But this does not apply to draft-03 version - if key+nonce repeat,

mode fundamentally changes - it uses fresh key and counter in one

case and only fresh counter other case.=C2=A0 That is ugly.



Instead it would be clearer (less ugly) if MAC(message) is always

used as extension of nonce.=C2=A0 They both affect counter.=C2=A0 Similarly=
,

either both affect encryption key or neither affects encryption key:



1) No rekey, only counter is synthesized - that would be basically AES-SIV<=
br>
=C2=A0 =C2=A0with modern hash.=C2=A0 This would be strict improvement over =
AES-GCM,

=C2=A0 =C2=A0better security (but not too good), but same performance.



2) MAC(Plaintext) always affects encryption key.=C2=A0 This would give

=C2=A0 =C2=A0significantly better boundaries than just synthesized counter.=


=C2=A0 =C2=A0But at the cost of extra keygen per message, which is slow for=
 AES,

=C2=A0 =C2=A0so the mode will seem more costly than current AES-GCM.



While I like the current direction of AES-GCM-SIV of trying to achieve

higher security level by using rekey, I wonder if it would be

good to standardise a simple AES-POLYVAL mode like 1) that is also

clearly securitywise better than AES-GCM.=C2=A0 For use in new designs

that do care about maximum performance.=C2=A0 Just a thought.





To throw out some ideas on 2), here is my proposal how to synthesize

both key and counter based on MAC.





AES-GCM-SAFE

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Cipher mode that uses key, nonce and MAC(message)

to synthesize both counter and encryption key.



Input:

=C2=A0 K =3D 128/256-bit key

=C2=A0 N =3D 128-bit Nonce

=C2=A0 P =3D plaintext

=C2=A0 A =3D additional data



Process:

=C2=A0 AuthKey =3D AES(K, N)

=C2=A0 SubKey1 =3D AES(K, N xor 1)

=C2=A0 RawTag =3D POLYVAL(AuthKey, PAD(A) || PAD(P) || LEN(A) || LEN(P))
=C2=A0 Tag =3D AES(K, N xor RawTag)

=C2=A0 Counter =3D AES(K, Tag)

=C2=A0 SubKey2 =3D AES(K, Tag xor 1)

=C2=A0 EncKey/128 =3D SubKey1 xor SubKey2

=C2=A0 EncKey/256 =3D SubKey1 || SubKey2

=C2=A0 CipherText =3D AES-CTR(EncKey, Counter, P) || Tag



Where:

=C2=A0 || - concat

=C2=A0 xor 1 - flip lowest bit of first byte

=C2=A0 LEN(V) - number of bits in V in 64-bit little-endian format

=C2=A0 PAD(V) - zero-pad to full block

=C2=A0 AES(K, V) - Encrypt V with key K

=C2=A0 AES-CTR(K, C, V) - Encrypt V with key K and counter C



Improvements



+ When key and nonce repeat, then same AuthKey is used.=C2=A0 But both

=C2=A0 counter and encryption key will be synthesized based on MAC.



+ EncKey is used only for encrypting plaintext, so no need to waste

=C2=A0 bits on domain-separation.=C2=A0 Thus full 128-bit counter can be us=
ed.



* There are no steps that need dropping bits so 128-bit nonce can

=C2=A0 be used.=C2=A0 As this is supposed to be high-security mode.



+ More natural 128/256-bit keygen for EncKey.=C2=A0 It's faster too

=C2=A0 due to less blocks encrypted.



+ Counter is not sent in clear.=C2=A0 While sending counter in clear does
=C2=A0 not change probability of catastrophic failure, it does make

=C2=A0 exploiting it less expensive.



Notes



* If AES256 has related-key problems when only half of the key changes,



=C2=A0 =C2=A0 EncKey/256 =3D (SubKey1 xor Counter) || SubKey2



=C2=A0 should fix it.=C2=A0 This may be also useful if shorter nonce is use=
d.



* Its possible to use domain-separation for AES(K,N) vs. AES(K,Tag)

=C2=A0 but it does not seem necessary.



Comments?



--

marko



_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg



I hav=
e problems to see how this proposal is safe.
I.e. Cooley used that POLYVAL returns 0 if A and P are empty in the AES-G=
CM-SIV cryptanalysis.
In the proposal above=
 using A=3D"" and P =3D "" results in=C2=A0
Tag =3D AES(K,N)
There=
fore an attacker can use the proposal above as an oracle to for encrypting =
single blocks with K.
This is all that is n=
eeded to break the proposal.
Hence it seems=
 to me that even a nonce respecting adversary can break this proposal.

I actually=
 don't know what "ugly" means as a cryptographic term.
<=
div class=3D"gmail_extra">My guess would something like difficult to formal=
ly analyze.
E.g. in the proposal above if N=
 and N xor 1 are both used as nonces then
A=
uthKey and SubKey1 change their role and that seems to add a lot of complex=
ity
to a potential analysis.=C2=A0



--94eb2c07dd3e701d9f0548b6fd04--


From nobody Fri Feb 17 04:53:03 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F01299D9 for ; Fri, 17 Feb 2017 04:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOU3tG2JP052 for ; Fri, 17 Feb 2017 04:53:00 -0800 (PST)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF7A1299D6 for ; Fri, 17 Feb 2017 04:53:00 -0800 (PST)
Received: by mail-lf0-x244.google.com with SMTP id q89so3778892lfi.1 for ; Fri, 17 Feb 2017 04:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gxq7BeN2t5XP32Qco0S2n54IdrHiUws5hEaZoiGuuD0=; b=pzfm2n8Zw34Mjky1xCwLhVL4NtayYNZch7q6GRvJMptcLoaHxOE0WZwcfOo4Ki/02K hQt7R5UUvqd6djCaBkimrFUdSNLIAiw3VcT2GffzwltEkLHscjcuCSX19jJ2WAukMZIl EpHn2wN49kFut6VlvfxyGWTf9G1CpsZWntIEz8v7dkPV0XIa8rmczviDJE/lNg7ruCBt Hk3cmq93Qjohc2qwdHP1o+7wBpboW/l66FD+1pzBcdo23X1oN9gPCR8Q1zramgUlrLYa WBo5K/xcFMbMiDljjf28hhsz0nFE3tAixifGEwcpFrYcauhv3w+JBcQj6IM05Hjr3pNf dhfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gxq7BeN2t5XP32Qco0S2n54IdrHiUws5hEaZoiGuuD0=; b=eCMOXhV56MEOSEhNIiY5kLw8881v4DV9eLSAbaQQ+jbz4tcwisl8AJG/uRTwM+Vwea DGGiqGnVOhsPx71u5FrFQcQ70Qi25H2a9P045jIA9x6LtdEj2VaK1DmZKKYP43UV+7+u OJ5rUBM+RarRi1FvnzMwOHvyrzeOPUq8BbuFetvvw8IokT/W3/TeASOeLl1+sd6lTCXP 5K/iCcJEZXsLUiGxohkCLMhwEEhsKRgvgZ8GwfI3H58wTht9A7OalXycZdiJThRoTA9c CPFTRzon218HAsBCpq94QNM8dhE7xTcIuqDvju4MMfOarNWrz1G4d+VpJyC92jqIn48z 6WxA==
X-Gm-Message-State: AMke39mKhZtM46q4/JHfYg/JZhpKoGf09uVVr6L+CjYmDZcrUkHmsQ0vIXPK6HamjBpZ7A==
X-Received: by 10.25.196.146 with SMTP id u140mr1832384lff.21.1487335978499; Fri, 17 Feb 2017 04:52:58 -0800 (PST)
Received: from gmail.com (138.246.50.84.sta.estpak.ee. [84.50.246.138]) by smtp.gmail.com with ESMTPSA id 12sm2506604lju.16.2017.02.17.04.52.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 04:52:57 -0800 (PST)
Date: Fri, 17 Feb 2017 14:52:55 +0200
From: Marko Kreen 
To: Daniel Bleichenbacher 
Message-ID: <20170217125255.GA16732@gmail.com>
References: <20170217000247.GB23785@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
Archived-At: 
Cc: CFRG 
Subject: Re: [Cfrg] Critique of AES-GCM-SIV
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 12:53:02 -0000

On Fri, Feb 17, 2017 at 11:00:56AM +0100, Daniel Bleichenbacher wrote:
> On Fri, Feb 17, 2017 at 1:02 AM, Marko Kreen  wrote:
> > I have reviewed the AES-GCM-SIV proposal (draft 3).  And while there
> > are parts I like - overall direction to higher security and
> > getting rid of GCM bitflipping - current design feels "ugly".
> > (That's a cryptographic term.)

> I actually don't know what "ugly" means as a cryptographic term.

Well, it was supposed to be a joke...

> My guess would something like difficult to formally analyze.

But I think we are mostly on same page.  My main complaint was that
if it's nonce-misuse-resistant mode, then why does nonce misuse
have such a big effect on behaviour: on one case message is protected
by fresh key and counter, on other case only fresh counter.

So nonce misuse makes it behave as different mode that needs to
be analyzed separately.

> E.g. in the proposal above if N and N xor 1 are both used as nonces then
> AuthKey and SubKey1 change their role and that seems to add a lot of
> complexity
> to a potential analysis.

But they are used for completely different algorithms?  If such
cross-algorithm usage is exploitable, it seems to mean both
algorithms are unexpectedly weak and should not be used?

Still, it should be simple to fix it.

> > Comments?

> I have problems to see how this proposal is safe.
> I.e. Cooley used that POLYVAL returns 0 if A and P are empty in the
> AES-GCM-SIV cryptanalysis.
> In the proposal above using A="" and P = "" results in
> Tag = AES(K,N)
> Therefore an attacker can use the proposal above as an oracle to for
> encrypting single blocks with K.
> This is all that is needed to break the proposal.
> Hence it seems to me that even a nonce respecting adversary can break this
> proposal.

Thank you for your review.  Funny thing is that I was rather unsure
about xor N part when encrypting RawTag, but then I simply copied
what current AES-GCM-SIV does.

But main thing I take from your comment is that encrypting with K
does need domain separation between public and private values.

Here is draft 2 of AES-GCM-SAFE with following changes:
- remove xor 1, instead use recursive encryption
- remove xor N when encrypting RawTag
- spent 1 bit to separate public and private encryptions with K.
- add xor N to SubKey2 to keep all nonce bits in play.
- add AuthIV to get rid of special cases of zero-len and zero-filled
  data for POLYVAL.

AES-GCM-SAFE (draft 2)
======================

Cipher mode that uses key, nonce and MAC(message)
to synthesize both counter and encryption key.

Input:
  K = 128/256-bit key
  N = 128-bit Nonce
  P = plaintext
  A = additional data

Process:
  AuthKey = AES(K, SetBit(N, 0))
  SubKey1 = AES(K, SetBit(AuthKey, 0))
  AuthIV = AES(K, SetBit(SubKey1, 0))
  RawTag = POLYVAL(AuthKey, AuthIV || PAD(A) || PAD(P) || LEN(A) || LEN(P))
  Tag = AES(K, SetBit(RawTag, 1))
  SubKey2 = AES(K, SetBit(Tag, 0)) xor N
  Counter = AES(K, SetBit(SubKey2, 0))
  EncKey/128 = SubKey1 xor SubKey2
  EncKey/256 = SubKey1 || SubKey2
  CipherText = AES-CTR(EncKey, Counter, P) || Tag

Where:
  || - concat
  SetBit(v, bit) - set low bit value
  LEN(V) - number of bits in V in 64-bit little-endian format
  PAD(V) - zero-pad to full block
  AES(K, V) - Encrypt V with key K
  AES-CTR(K, C, V) - Encrypt V with key K and counter C

I don't see the need to separate internal encryptions, but than means
any of (AuthKey, AuthIV, SubKey1, SubKey2, Counter) may be equal.  It seems
like a good thing - less constrants for attacker to expoit.

Your thoughts?


-- 
marko


From nobody Fri Feb 17 06:23:27 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1615A129A9D for ; Fri, 17 Feb 2017 06:23:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 I-4S7W-fjpE8 for ; Fri, 17 Feb 2017 06:23:23 -0800 (PST)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41C7129A9A for ; Fri, 17 Feb 2017 06:23:22 -0800 (PST)
Received: by mail-wr0-x235.google.com with SMTP id z61so30743081wrc.1 for ; Fri, 17 Feb 2017 06:23:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=/9c/zluxLLGSksyRj6iiDlygv2CG5c0k+zAkk7noBos=; b=CMbkdys746soUHyUBP0cmDAEUsTKmZrsLCQa1FNV0efZK8YlL2TWuy9GhummLMOQHl 0VktRYxm9IaZS+0gIjQy20xxRcPvHMinqTox6tsOCPaziwELqSw5wBL+mV5CHV7G25Yy tfBCGBvJe+tTgUkGMCGU5NGJY0nPEThUSJh0E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=/9c/zluxLLGSksyRj6iiDlygv2CG5c0k+zAkk7noBos=; b=jjSf8gslZZ+kBBqWKms2Ez5grUfj1HHx3FLrwxbYw5bAlHhYd9wOp2G2QvySnFZkZI xoNevGIGPLvQPddJJku5RI3wnAHiCoIxqwjMIZ/LwdD3Jz1Nr3/UlD9Z1DxV4jSQ0DOL GdKLowJIVHlvYqgwWI5RmaSLhl7HfGjDe9wihw5pZslF+zbMhwvo5Z1UbqlrwJ9dL848 EjAqoQSzfTTzXt5X5rsw77fSmjK2JMOEICLlmtUMTxNKErR2dGRKg3ghiypRx32TMrbo nsDOYddKwSDAZfVkcglXXF2Qabcvfstwtyi3nv9lhkSANbStkbK8nhu8U31EcpBTH9aI ymCQ==
X-Gm-Message-State: AMke39liJtf69Kz98KP6zY+szYeebCQX1btwuq/8aexxz6cFG1cLVGpK6pFAJtB1uLbT7g==
X-Received: by 10.223.160.206 with SMTP id n14mr6810658wrn.31.1487341401264; Fri, 17 Feb 2017 06:23:21 -0800 (PST)
Received: from [192.168.1.120] ([156.218.58.77]) by smtp.gmail.com with ESMTPSA id k44sm13143269wrk.59.2017.02.17.06.23.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Feb 2017 06:23:20 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1E848329-558C-47DE-9CE7-7C9331AB8C77"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner 
In-Reply-To: <20170217125255.GA16732@gmail.com>
Date: Fri, 17 Feb 2017 16:23:16 +0200
Message-Id: 
References: <20170217000247.GB23785@gmail.com>  <20170217125255.GA16732@gmail.com>
To: Marko Kreen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: CFRG 
Subject: Re: [Cfrg] Critique of AES-GCM-SIV
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 14:23:26 -0000

--Apple-Mail=_1E848329-558C-47DE-9CE7-7C9331AB8C77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 17 Feb 2017, at 14:52, Marko Kreen  wrote:
>=20
> On Fri, Feb 17, 2017 at 11:00:56AM +0100, Daniel Bleichenbacher wrote:
>> On Fri, Feb 17, 2017 at 1:02 AM, Marko Kreen  =
wrote:
>>> I have reviewed the AES-GCM-SIV proposal (draft 3).  And while there
>>> are parts I like - overall direction to higher security and
>>> getting rid of GCM bitflipping - current design feels "ugly".
>>> (That's a cryptographic term.)
>=20
>> I actually don't know what "ugly" means as a cryptographic term.
>=20
> Well, it was supposed to be a joke...
>=20
>> My guess would something like difficult to formally analyze.
>=20
> But I think we are mostly on same page.  My main complaint was that
> if it's nonce-misuse-resistant mode, then why does nonce misuse
> have such a big effect on behaviour: on one case message is protected
> by fresh key and counter, on other case only fresh counter.

Quick comment: This came up in an earlier thread on that topic already, =
I've also brought it up last spring. I think for this I-D in it's =
current form "nonce misuse resistant" might not be the best term (too =
strong, many people assume you can do what you want with the nonce with =
such a construction -- which certainly isn't the case for AES-GCM-SIV as =
proposed here). "nonce-misuse tolerant" came up and other suggestions. I =
haven't seen an update yet.

Aaron

--Apple-Mail=_1E848329-558C-47DE-9CE7-7C9331AB8C77
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYpwdVAAoJEOTbZJL9ubXVXz8P/itBtVMqd5Bf3Zf3xyJMKc/n
QHyKyLxHgDYbnzJ2NBvTcZ+sFEJM6/KGwTk61bgLVZpGi6pc/pQwGSUPpdlr1MGN
dST9cNOsF1JLuyTB0/9wNhHXhDaYXffUcmzB4QHZ+mUNn2gi6aV+dvwYrp3FdFzn
8I8UP4vEtfl7gLcqORyoTdr9RrWUCdsknmKkzC60EnaB45lb5Rxdpo6Zkk0/bnV4
bN6JCf17N2Rt+Yy7ylYEUwCz6fne9GAbA+m4kRwLlZYnXMrYm1JENBF6Tye34pGU
dKnfMCmGxxxgGqXPO/Fc2AmNswTLaUv7IEz6s6VFWJ5WfYf52zDj/ZgTu6vbD0fj
9LbnsqTkX+5IpLGGJPtssmCRnNnVLfXCgw3y8BwuAC0/hyKnvAO22bLRJyWgDRBa
hcZjhlWvSMoRdm8LVQAiw/oSoII5Glvshc/csia0Wmu7hKREJeNWKsfQQta5Pbyb
rgmKSwTycvF2zEwF1sKWDe/fHbMAwG5fvrmv7868RHbSeXv3u4/YCiEiVFZqhGY4
rsOPN8wwFw1BQuM/tc8XkLV5DTPHM86JaPbmtypXZEXf+89yeDwQnhCAq20MpxG0
wt4pH0E5DphDvhgtzulLnWWRhEuuCdNssfwnRnA7Y0D2krKE9oFQ5Y3s/9XG8paL
PyMtLEHjXseJAzSQHDt9
=J7Nb
-----END PGP SIGNATURE-----

--Apple-Mail=_1E848329-558C-47DE-9CE7-7C9331AB8C77--


From nobody Fri Feb 17 07:05:26 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC411294A7 for ; Fri, 17 Feb 2017 07:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UXcor5MsE0c for ; Fri, 17 Feb 2017 07:05:23 -0800 (PST)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D16126BF7 for ; Fri, 17 Feb 2017 07:05:22 -0800 (PST)
Received: by mail-lf0-x243.google.com with SMTP id z127so1676011lfa.2 for ; Fri, 17 Feb 2017 07:05:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9RiXnDKq9s0WGPhgQdA1kmsQsLzW8JAHdNM1PJSrl7k=; b=iQqi8s3LhuaNJBK5mxe43QtC2WvpNgMHyV6gC7o8BZqwDystIf40PuBP62nnYu6Ljm cruqju5mH95eqouun/uZj1/HgfvlqK3pnvO/gSdwEyH1/QamMoK7YAMQNW0JA+NzwJRX HpasK8Plr8TzBKQ+oO3Nx7ol8dP1VBnrZ5hPoDMpfO+t5aV5gTAH5K+V2eDoSKgAmlGR XTDR5TFTH8AzassfQDKMOWXOnpezJPJ+RXwoH3kb/wNjcrAZ3Cg4tEIJwBvFmzVyxOCF xig56x/ToCAfizhlXQGZ8ZOuAdegUxVB8PE0PRPrLaAHspUAJqJnZrCYlUcPkpaw9FH/ vCkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9RiXnDKq9s0WGPhgQdA1kmsQsLzW8JAHdNM1PJSrl7k=; b=ciM7lBhHeWrULpyL5JJIyNRbABqKMh7Gmwk0tdeNRonYbcpRlhjIB934p/VB98+hIw +G92L0BOiSZhx4Z1e8sX1asl0IT2oTF1NwD4u80HweXOhz/mXJ8QlDtWLTiZ7zCUCrLU jQCVOs//JDxAUlPTUm/tb+/np1GyY5tjtmHXMDqpt7029v8EdxZNXFywWN0jknIedIn5 yia2VfIEpGQVcvyGuCjBvbh/tY82fJrVwjYOy6R2KgcUwCCIQIgJHFmC8U/Td1KdEvHP ownZ4kB70zHl2Nw4kAE0rGSV1zdajDO85/lvYcO2zX37V3rrNtwx6LlYifrTWt3YjTYv 5k3A==
X-Gm-Message-State: AMke39lvEVrpbSp7eNb6V85nHRLn4nhkw9+06UOcGvE2tDO/FDBNSUzH4wl1KE1S5ow54A==
X-Received: by 10.25.44.21 with SMTP id s21mr2422425lfs.56.1487343921118; Fri, 17 Feb 2017 07:05:21 -0800 (PST)
Received: from gmail.com (138.246.50.84.sta.estpak.ee. [84.50.246.138]) by smtp.gmail.com with ESMTPSA id 187sm2559560ljf.12.2017.02.17.07.05.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 07:05:20 -0800 (PST)
Date: Fri, 17 Feb 2017 17:05:18 +0200
From: Marko Kreen 
To: Aaron Zauner 
Message-ID: <20170217150518.GA23850@gmail.com>
References: <20170217000247.GB23785@gmail.com>  <20170217125255.GA16732@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
Archived-At: 
Cc: CFRG 
Subject: Re: [Cfrg] Critique of AES-GCM-SIV
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 15:05:24 -0000

On Fri, Feb 17, 2017 at 04:23:16PM +0200, Aaron Zauner wrote:
> 
> > On 17 Feb 2017, at 14:52, Marko Kreen  wrote:
> > 
> > On Fri, Feb 17, 2017 at 11:00:56AM +0100, Daniel Bleichenbacher wrote:
> >> On Fri, Feb 17, 2017 at 1:02 AM, Marko Kreen  wrote:
> >>> I have reviewed the AES-GCM-SIV proposal (draft 3).  And while there
> >>> are parts I like - overall direction to higher security and
> >>> getting rid of GCM bitflipping - current design feels "ugly".
> >>> (That's a cryptographic term.)
> > 
> >> I actually don't know what "ugly" means as a cryptographic term.
> > 
> > Well, it was supposed to be a joke...
> > 
> >> My guess would something like difficult to formally analyze.
> > 
> > But I think we are mostly on same page.  My main complaint was that
> > if it's nonce-misuse-resistant mode, then why does nonce misuse
> > have such a big effect on behaviour: on one case message is protected
> > by fresh key and counter, on other case only fresh counter.
> 
> Quick comment: This came up in an earlier thread on that topic
> already, I've also brought it up last spring. I think for this I-D in
> it's current form "nonce misuse resistant" might not be the best term
> (too strong, many people assume you can do what you want with the
> nonce with such a construction -- which certainly isn't the case for
> AES-GCM-SIV as proposed here). "nonce-misuse tolerant" came up and
> other suggestions. I haven't seen an update yet.

I'm not complaining about security level as their goal is to replace
AES-GCM, so anything better is a win.

Although better categorization may be good idea, I still feel current
approach can be categorized as "clumsy":

- AEAD with synthesized key and IV when master key or nonce are unique.
- AEAD with only synthesized IV when master key and nonce repeat.

Clearer would be just one mode which does not change category if nonce
repeats:

- AEAD with just synthesized IV (like AES-SIV), no rekey.
- AEAD with synthesized key and IV.

If there is already decision that rekey is OK, then I think it's better
to take time and synthesize both key and IV properly, thus
achieve full nonce misuse resistance.

-- 
marko


From nobody Mon Feb 20 18:12:23 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8299129595 for ; Mon, 20 Feb 2017 18:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 R-S6DVAHdfTz for ; Mon, 20 Feb 2017 18:12:18 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0074.outbound.protection.outlook.com [104.47.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF2E129586 for ; Mon, 20 Feb 2017 18:12:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e4wW8ONYGSlz26J8ioUS+XU9mmZa/W0G2FzLr9BeFqE=; b=WkRJo4yCVWpEH5wPchY4Q6lcJtVk4NyU2+Cd4VzTDE+I+bt5BnkI/c1+1iOMrg9Dfxh/nRQYyxzB9n+tRZhUih+E/MeNHkYLHTxDdbpEb2cXrc1SOn2U5a0HTQzPmfDoUlLWY94b2QBR/yinSb96fQ5AOVV/A1mZ+PSCjvXB3pA=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 02:12:14 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0919.015; Tue, 21 Feb 2017 02:12:13 +0000
From: "Paterson, Kenny" 
To: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" 
Thread-Topic: Review of draft-irtf-cfrg-xmss-hash-based-signatures-07 
Thread-Index: AQHSi+fq7bZUKu69YEqbWcQECptCAA==
Date: Tue, 21 Feb 2017 02:12:13 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [153.224.139.152]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:aoS90lQ3BiIHIgNktV/3H40/1wm9W4bLTeJsVdTn22kdrI8mim6O8eeCh9cAV2zx5pGDGOAGlmK8hmvAYgJNeKDsqIS9dKc2SQ9HCXFf0O1PMjt/1LgiepOpZ96/cGPIre0VA2/x6a864upFeo7f/949y1MCM6E9pgah4bFOEWZACbr3/x8/saY7P+eqfolekxuOcA2gufKnRQdScv3MYZN9Q3wttyzv+RpmeKbtE2BDKlzLh7RNjxa0LMlU0VkrEQ87BGBsg7WQ4d88AZnEmhyf/VxxSwOqpE7MCq2cT05isj+F9Jfjm/YODUGsOserRrVrU+UTiwU7xrN42Wj4nA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(7736002)(106116001)(92566002)(2900100001)(66066001)(54356999)(97736004)(101416001)(230783001)(2501003)(36756003)(3280700002)(50986999)(8676002)(189998001)(54906002)(6512007)(122556002)(305945005)(81166006)(4001350100001)(81156014)(99286003)(6306002)(4326007)(53936002)(2351001)(25786008)(86362001)(38730400002)(6916009)(110136004)(42882006)(3660700001)(68736007)(77096006)(106356001)(6486002)(3846002)(6116002)(105586002)(5640700003)(5660300001)(74482002)(2906002)(102836003)(8936002)(6436002)(83506001)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 17fa0581-52c0-49d9-fdc3-08d459ff0d23
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908; 
x-forefront-prvs: 0225B0D5BC
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <056BBFAC91FF8049B13697D884C1941F@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 02:12:13.7347 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: 
Cc: Andreas Huelsing , "cfrg@irtf.org" 
Subject: [Cfrg] Review of draft-irtf-cfrg-xmss-hash-based-signatures-07
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 02:12:22 -0000

RGVhciBBdXRob3JzLA0KDQpQbGVhc2UgZmluZCBiZWxvdyBteSByZXZpZXcgb2YNCmRyYWZ0LWly
dGYtY2ZyZy14bXNzLWhhc2gtYmFzZWQtc2lnbmF0dXJlcy0wNw0KKGh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gtYmFzZWQtc2lnbmF0dXJl
DQpzLykuDQoNClJlZ2FyZHMsDQoNCktlbm55IA0KDQotLS0tDQoNClJldmlldyBvZiBkcmFmdC1p
cnRmLWNmcmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMDcNCg0KVGhlIGRyYWZ0IGlzIGEg
bWF0dXJlLCBjbGVhciwgYW5kIHVzZWZ1bCBkb2N1bWVudC4gSXQgaXMgYWxtb3N0IHJlYWR5IGZv
cg0KcHVibGljYXRpb247IG9ubHkgbWlub3Igbml0cyBiZWxvdy4NCg0KcC4xOiAiaGFzaC1iYXNl
ZCBzaWduYXR1cmVzIHdpdGhzdGFuZCBhdHRhY2tzIHVzaW5nIHF1YW50dW0gY29tcHV0ZXJzIg0K
LS0tPiAiImhhc2gtYmFzZWQgc2lnbmF0dXJlcyBhcmUgYmVsaWV2ZWQgdG8gd2l0aHN0YW5kIGF0
dGFja3MgdXNpbmcNCnF1YW50dW0gY29tcHV0ZXJzIiBvciAiImhhc2gtYmFzZWQgc2lnbmF0dXJl
cyBjYW4gd2l0aHN0YW5kIGF0dGFja3MgdXNpbmcNCnF1YW50dW0gY29tcHV0ZXJzIg0KcC4zOiAi
ZnJvbSAyMDA2IG9ud2FyZHMiIC0tPiAiZnJvbSB0aGUgbWlkIDIwMDBzIG9ud2FyZHMiLg0KcC4z
OiAiY29tcG9zZWQgb2YiIC0tPiAiY29tcG9zZWQgZnJvbSIuDQpwLjQ6ICJzdGFuZGFyZGl6aW5n
IGFuZCBpbnRyb2R1Y2luZyIgLS0+ICJpbnRyb2R1Y2luZyBhbmQgc3RhbmRhcmRpemluZyINCihk
ZXBlbmRzIHRvIHdob20gdGhlIGludHJvZHVjaW5nIGlzIGJlaW5nIGRvbmUgaGVyZSEpLg0KcC40
OiBjaGVjayBmb3IgdXBkYXRlIHRvIHRoZSB0ZXh0IGNsYWltaW5nIHRoYXQgW0JESDExXSBpcyB0
aGUgImxhdGVzdA0Kc3RhdGVmdWwgaGFzaC1iYXNlZCBzaWduYXR1cmUgc2NoZW1lIi4NCnAuNTog
IkFkZGl0aW9uIGZvciBYTVNTIi0tPiAiQWRkaXRpb25hbGx5LCBmb3IgWE1TUzoiDQpwLjY6ICJ1
c2VkIGltcGxpY2l0bHkiIC0tPiAib21pdHRlZCIuDQpwLjc6ICJhc2lkZSBvZiIgLS0+ICJhc2lk
ZSBmcm9tIi4NCnAuNzogImEgbi1ieXRlIHZhbHVlIiAtLT4gImFuIG4tYnl0ZSB2YWx1ZSIuDQpw
Ljc6IHNldHRlciBtZXRob2RzPw0KcC44OiB0ZXh0IGJlZ2lubmluZzogIk9uZSB0eXBlIGZvciB0
aGUgaGFzaGVzIC4uLiIgaXMgbm90IGEgZ3JhbW1hdGljYWwNCnNlbnRlbmNlIC0gaXQgbGFja3Mg
dmVyYnMuIFlvdSBjb3VsZCBpbnNlcnQgImlzIHVzZWQiIGluIGEgY291cGxlIG9mDQpwbGFjZXMu
DQpwLjg6ICJUaGUgbGF0dGVyIGJlaW5nIiAtLT4gIlRoZSBsYXR0ZXIgaXMiLg0KcC4xMjogImhv
bGQiIC0tPiAiaGVsZCIuDQpwLjEzOiBoZXJlIHlvdSBpbnRyb2R1Y2UgZnVuY3Rpb25zIEYgYW5k
IFBSRiBmb3IgdGhlIGZpcnN0IHRpbWUsIHJlZmVycmluZw0KdG8gc2VjdXJpdHkgcmVxdWlyZW1l
bnRzIGluIFNlY3Rpb24gOCBmb3Igc29tZSBtb3JlIGRldGFpbHMuIEkgdGhpbmsgeW91DQpzaG91
bGQgYWxzbyBpbmNsdWRlIGEgZm9yd2FyZCByZWZlcmVuY2UgaGVyZSB0byBTZWN0aW9uIDUgZm9y
IHNwZWNpZmljDQppbnN0YW50aWF0aW9ucy4NCnAuMTQ6ICJlbmQgb2YgdGhpcyBzZWN0aW9uIiAt
LT4gInNlY3Rpb24gMy4xLjciLg0KcC4xNjogdGhlIHBzZXVkb2NvZGUgZm9yIEFsZ29yaXRobSA1
IChXT1RTX3NpZ24pIGhhcyBhIGxvb3AgaW4gd2hpY2ggY3N1bQ0KaXMgaW5jcmVhc2VkIGJ5IHZh
bHVlcyB3LTEtbXNnW2ldLiBJcyBpdCBwb3NzaWJsZSB0aGF0IGNzdW0gY291bGQgb3ZlcmZsb3cN
CmluIGFuIGltcGxlbWVudGF0aW9uLCBhbmQgd2hhdCB3b3VsZCBiZSB0aGUgY29uc2VxdWVuY2Vz
PyBJcyBhIG5vdGUgbmVlZGVkDQp0byBleHBsYWluIHRoZSByZXF1aXJlZCBiaXRzaXplIG9mIGNz
dW0gdG8gYXZvaWQgdGhpcz8NCnAuMTk6ICJJZiB0aGV5IG1hdGNoLCB0aGUgc2lnbmF0dXJlIGlz
IHZhbGlkLiIgLS0+ICJJZiB0aGV5IG1hdGNoLCB0aGUNCnNpZ25hdHVyZSBpcyBkZWNsYXJlZCB2
YWxpZC4iLg0KcC4xOTogIEluIFNlY3Rpb24gNC4xLjIsIHlvdSBpbnRyb2R1Y2UgZnVuY3Rpb25z
IEggYW5kIEhfbXNnLiBIZXJlIHlvdQ0Kc2hvdWxkIHJlZmVyIHRvIFNlY3Rpb24gNSBmb3Igc3Bl
Y2lmaWMgaW5zdGFudGlhdGlvbnMgYW5kIFNlY3Rpb24gOCBmb3INCnNlY3VyaXR5IGNvbnNpZGVy
YXRpb25zLg0KcC4xOTogIjIgKiBuIiAtLT4gIjJuIiAoZm9yIGNvbnNpc3RlbmN5KS4NCnAuMjA6
ICJUaGUgV09UUysgcHJpdmF0ZSBrZXlzIE1VU1QgYmUgZ2VuZXJhdGVkIGFzIGRlc2NyaWJlZCBp
biBTZWN0aW9uDQozLjEuIFRvIHJlZHVjZSB0aGUgcHJpdmF0ZSBrZXkgc2l6ZSwgYSBjcnlwdG9n
cmFwaGljIHBzZXVkb3JhbmRvbSBtZXRob2QNCk1BWSBiZSB1c2VkIGFzIGRpc2N1c3NlZCBhdCB0
aGUgZW5kIG9mIHRoaXMgc2VjdGlvbi4iIFRoZSAiTVVTVCIgYW5kIHRoZQ0KIk1BWSIgaGVyZSBp
bml0aWFsbHkgc2VlbSBpbmNvbXBhdGlibGUuIElmIHlvdSBNVVNUIGRvIFgsIHRoZW4geW91IGNh
bm5vdA0KZXZlciBkbyBZIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIFguIEJ1dCBpdCB0dXJucyBv
dXQgdGhhdCBTZWN0aW9uIDMuMQ0KYWxzbyBtZW50aW9ucyB0aGUgcHNldWRvcmFuZG9tIGFwcHJv
YWNoIGFzIGFuIG9wdGlvbiwgYW5kIHJlZmVycyB0byBhDQpsYXRlciBzZWN0aW9uLCBzbyB0aGUg
Ik1VU1QiIGFuZCAiTUFZIiBhcmUgbm90IHN0cmljdGx5IGluY29tcGF0aWJsZS4NCkhvd2V2ZXIs
IGl0IHdvdWxkIGJlIG5pY2UgdG8gZmluZCBhIHdheSB0byBhZGRyZXNzIHRoaXMgc21hbGwgaXNz
dWUuDQpwLjIzOiBJbiB0aGUgcHNldWRvY29kZSBmb3IgQWxnb3JpdGhtIDEwLCB3ZSBoYXZlICJQ
SyA9IHJvb3QgfHwgU0VFRCIuDQpTaG91bGQgT0lEIGJlIGluY2x1ZGVkIGhlcmUgYWxzbz8gSXQn
cyBpbmNsdWRlZCBpbiB0aGUgYnl0ZSBzdHJ1Y3R1cmUgb24NCnBhZ2UgMjQuDQpwLjI0OiBZb3Ug
dGFsayBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gcGF0aCBiZWluZyBoKm4gYnl0ZXMgYW5kIGJl
aW5nIGFuDQphcnJheSBvZiBoIG4tYnl0ZSBzdHJpbmdzLiBBcmUgdGhlIGNvbnZlcnNpb25zIGNs
ZWFyPyAoUGVyaGFwcyB0aGlzIGlzDQpjb3ZlcmVkIGJ5IG5vdGF0aW9uIGludHJvZHVjZWQgaW4g
U2VjdGlvbiAyPykNCnAuMjU6ICJiZWZvcmUgdGhlIHVwZGF0ZWQgcHJpdmF0ZSBrZXkiIC0tPiAi
YmVmb3JlIHRoZSBwcml2YXRlIGtleSBpcw0KdXBkYXRlZCIuIChUaGlzIG9uZSBpcyBpbXBvcnRh
bnQ6IHRoZSBjdXJyZW50IHRleHQgY291bGQgcmVhZCBhczogIm91dHB1dA0KdGhlIHNpZ25hdHVy
ZSBmaXJzdCwgdGhlbiBvdXRwdXQgdGhlIHVwZGF0ZWQgcHJpdmF0ZSBrZXkiIQ0KcC4yNjogZGVs
ZXRlICJqdXN0Ii4NCnAuMzI6IGFnYWluLCBzaG91bGQgT0lEIGJlIHBhcnQgb2YgdGhlIHB1Ymxp
YyBrZXksIFBLX01UPw0KcC4zOTogIkZpbmFsbHksIGZvciB0aGUgUFJGIG5vIGZ1bGwtZmxlZGdl
ZCBITUFDIGlzIG5lZWRlZCBhcyB0aGUgbWVzc2FnZQ0KbGVuZ3RoIGlzIGZpeGVkLiIgSGVyZSB5
b3UgY291bGQgYWRkICJtZWFuaW5nIHRoYXQgc3RhbmRhcmQgbGVuZ3RoDQpleHRlbnNpb24gYXR0
YWNrcyBhcmUgbm90IGEgY29uY2VybiBoZXJlIi4NCnAuMzk6ICJXZSB1c2Ugbi1ieXRlcyBmb3Ig
ZG9tYWluIHNlcGFyYXRpb24gZm9yIGNvbnNpc3RlbmN5IHdpdGggdGhlIFNIQTINCmltcGxlbWVu
dGF0aW9ucyIuIFRoaXMgd2FzIGEgYml0IHVuY2xlYXIgdG8gbWUuIFdoYXQgZG9tYWluIHNlcGFy
YXRpb24/IERvDQp5b3UgbWVhbiBpbiB0aGUgY2FsbHMgdG8gdGhlICJ0b0J5dGUiIGZ1bmN0aW9u
Pw0KcC40MzogRGVsZXRlIHRoZSB0ZXh0ICJPdGhlciBzaWduYXR1cmVzIG1ldGhvZHMgYXJlIG91
dCBvZiBzY29wZS4uLi4NCmZvbGxvdy11cCB3b3JrLiIgVGhpcyBpcyBub3QgYSByZXNlYXJjaCBw
YXBlciENCnAuNDM6ICJUaGUgZHJhZnQiIC0tPiAiVGhpcyBub3RlIi4NCnAuNDQ6ICJhdmFpbGFi
bGUgb24gbW9zdCBwbGF0Zm9ybXMiIGRvZXMgbm90IHNlZW0gdG8gbWFrZSBzZW5zZSAtIHRoZSBw
YXJ0DQphYm91dCBhdmFpbGFiaWxpdHkgaW4gY3J5cHRvIGxpYnJhcmllcyBkb2VzLg0KcC40NDog
ImxlYWRzIHBhcmFtZXRlcnMgdGhhdCBwcm92aWRlcyIgLS0+ICJsZWFkcyB0byBwYXJhbWV0ZXJz
IHRoYXQNCnByb3ZpZGUiLg0KcC40NDogImxlc3MgY29tbW9uIiAtLT4gImxlc3Mgd2lkZWx5IHN1
cHBvcnRlZCIuDQpwLjQ0OiAibW9yZSBhc3NpZ25tZW50cyIgLS0+ICJmdXJ0aGVyIGFzc2lnbm1l
bnRzIi4NCnAuNDQ6ICJzdWZmaWNpZW50IGRldGFpbHMiIC0tPiAic3VmZmljaWVudCBkZXRhaWwi
Lg0KcC40ODogIm1lc3NhZ2Ugc2lnbmF0dXJlIHBhaXIiIC0tPiAibWVzc2FnZSwgc2lnbmF0dXJl
IHBhaXIiID8NCnAuNDg6ICJlc3RpbWF0ZXMgd2hlbiIgLS0+ICJlc3RpbWF0ZXMgZm9yIHdoZW4i
Lg0KcC40ODogIkEgZnVsbCBzZWN1cml0eSBwcm9vZiBmb3IgdGhlIHNjaGVtZSBkZXNjcmliZWQg
aGVyZSBjYW4gYmUgZm91bmQgaW4NCltIUlMxNl0iLiBDYW4geW91IGJlIG1vcmUgcHJlY2lzZSBh
Ym91dCB3aGljaCBzY2hlbWVzIGFyZSBjb3ZlcmVkIGluDQpbSFJTMTZdPyBXT1RTKywgWE1TUywg
b3IgWE1TU15NVCAob3IgYWxsIHRocmVlPykuDQpwLjQ4OiAiVGhpcyBwcm9vZiBzaG93cyB0aGF0
IGFuIGF0dGFja2VyLi4uIiAtIHRoaXMgdGV4dCBtYXkgbmVlZCB0byBiZQ0KbW9kaWZpZWQsIGRl
cGVuZGluZyBvbiB3aGljaCBzY2hlbWVzIHlvdSBhcmUgdGFsa2luZyBhYm91dC4NCnAuNDk6ICJh
bGxvd3MgdG8gcHJvdmUgdGhhdCBpdCBpcyBub3QgZW5vdWdoIGZvciBhbiBhZHZlcnNhcnkgdG8g
YnJlYWsgdGhlDQpjb2xsaXNpb24gcmVzaXN0YW5jZSBvZiB0aGUgdW5kZXJseWluZyBoYXNoIGZ1
bmN0aW9uIi4gVGhpcyBmZWVscyBsaWtlDQphd2t3YXJkIHBocmFzaW5nLiBJIGRvbid0IHRoaW5r
IHlvdSd2ZSBwcm92ZWQgYW4gaW1wb3NzaWJpbGl0eSByZXN1bHQ7DQpyYXRoZXIgSSB0aGluayB5
b3UgaGF2ZSBwcm9vZiBvZiB1bmZvcmdlYWJpbGl0eSB1bmRlciBhIGRpZmZlcmVudA0KYXNzdW1w
dGlvbiB0aGFuIGNvbGxpc2lvbiByZXNpc3RhbmNlLiBJcyB0aGUgYXNzdW1wdGlvbiB5b3UgbmVl
ZCBzdHJpY3RseQ0Kd2Vha2VyIHRoYW4gY29sbGlzaW9uIHJlc2lzdGFuY2U/IFRoaXMgdGV4dCBu
ZWVkcyBzb21lIHJld29ya2luZywgSSB0aGluay4NCkhvdyBhYm91dCAiYWxsb3dzIGEgcHJvb2Yg
b2Ygc2VjdXJpdHkgdW5kZXIgYSB3ZWFrZXIgYXNzdW1wdGlvbiB0aGFuDQpjb2xsaXNpb24gcmVz
aXN0YW5jZSI/DQpwLjQ5OiAiVGhpcyBjYW4gYWxzbyBiZSBzaG93biBmb3JtYWxseSBpbiB0aGUg
cmFuZG9tIG9yYWNsZSBtb2RlbC4iIFdoYXQNCmNhbj8gVGhhdCB0aGUgImFib3ZlIGF0dGFjayIg
aXMgdGh3YXJ0ZWQ/IElmIHNvLCB3aGF0IHBvc2l0aXZlIHNlY3VyaXR5DQpyZXN1bHQgZG8geW91
IHRoZW4gb2J0YWluPyBJIHRoaW5rIGl0J3MgcHJvYmFibHkgd29ydGggc3RhdGluZyBhdCB0aGlz
DQpwb2ludC4NCnAuNDk6ICJUaGUgZ2l2ZW4gYml0IHNlY3VyaXR5IHZhbHVlcy4uLiIuIEkgd291
bGQgc3VnZ2VzdCBhZGRpbmcgYW4gZXh0cmENCnNlbnRlbmNlIGhlcmUgdG8gc2F5IHRoYXQgd2hp
bGUgZ2VuZXJpYyBhdHRhY2tzIGFyZSBwcmV2ZW50ZWQgYnkgeW91cg0KY2hvaWNlcyBvZiBwYXJh
bWV0ZXJzLCB0aGVyZSBjb3VsZCBiZSBxdWFudHVtIHNwZWVkLXVwcyBmb3Igc3BlY2lmaWMgaGFz
aA0KZnVuY3Rpb25zIChzaW5jZSB3ZSBkb24ndCB5ZXQga25vdyB0aGUgZnVsbCBwb3dlciBvZiBx
dWFudHVtIGFsZ29yaXRobXMpLg0KcC41MDogInJlbGllcyBvbiB0aGUgc2VjdXJpdHkgb2YgYSBj
cnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24iLiBUaGlzIGlzIGENCmJpdCB2YWd1ZS4gQ2FuIHlv
dSBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHdoaWNoIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJlDQpy
ZWxpZWQgdXBvbiwgb3IgbWF5YmUganVzdCBzYXkgInJlbGllcyBvbiBzcGVjaWZpYyBzZWN1cml0
eSBwcm9wZXJ0aWVzIG9mDQpjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb25zIj8NCnAuNTA6IFNl
Y3Rpb24gOC4zOiBzYW1lIGlzc3VlIGFzIGFib3ZlOiB0aGVyZSBjb3VsZCBiZSBxdWFudHVtIHNw
ZWVkLXVwcw0KZm9yIHNwZWNpZmljIGhhc2ggZnVuY3Rpb25zLCBidXQgdGhlIHRleHQgb25seSBj
b3ZlcnMgZ2VuZXJpYw0KYXR0YWNrcy4gQWRkaXRpb25hbCBjbGFyaXR5IHdvdWxkIGJlIGJlbmVm
aWNpYWwgaGVyZS4NCnAuNTI6IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBzdHlsZSByZXF1aXJlbWVu
dHMgb24gcmVmZXJlbmNlcyBhcmUsIGJ1dCBpdA0Kd291bGQgYmUgZ29vZCB0byBpbmNsdWRlIHN0
YWJsZSBVUkxzIGZvciB0aGluZ3MgbGlrZSBbSHVlbHNpbmcxM2FdLg0KcC42NTogV2Ugc2hvdWxk
IGRlbGV0ZSBBcHBlbmRpeCBEIGluIGR1ZSBjb3Vyc2UuDQoNCg0KDQo=


From nobody Tue Feb 21 03:49:56 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701571298CA; Tue, 21 Feb 2017 03:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 vHoGXE46m2rb; Tue, 21 Feb 2017 03:49:53 -0800 (PST)
Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C501298C1; Tue, 21 Feb 2017 03:49:51 -0800 (PST)
Received: from mail.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.167.6]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id v1LBnYr0012452; Tue, 21 Feb 2017 12:49:34 +0100 (envelope-from dbutin@cdc.informatik.tu-darmstadt.de)
Received: from roundcube.cdc.informatik.tu-darmstadt.de (roundcube.cdc.informatik.tu-darmstadt.de [130.83.167.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTPSA id 9D9DA23A52; Tue, 21 Feb 2017 12:49:34 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 21 Feb 2017 12:49:34 +0100
From: Denis Butin 
To: "Paterson, Kenny" 
Organization: TU Darmstadt
In-Reply-To: 
References: 
Message-ID: <6196590934811e6740dffbb8417cd1ad@cdc.informatik.tu-darmstadt.de>
X-Sender: dbutin@cdc.informatik.tu-darmstadt.de
User-Agent: Roundcube Webmail/1.1.5
X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2017.2.21.113616
X-PMX-RELAY: outgoing
Archived-At: 
Cc: Andreas Huelsing , draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org, cfrg@irtf.org, Stefan Gazdag 
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-xmss-hash-based-signatures-07
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 11:49:55 -0000

Hi Kenny,

Many thanks for your efforts, much appreciated! We are now revising the 
document based your comments and will come up with a new version 
shortly.

Best,
Denis

On 2017-02-21 03:12, Paterson, Kenny wrote:
> Dear Authors,
> 
> Please find below my review of
> draft-irtf-cfrg-xmss-hash-based-signatures-07
> (https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signature
> s/).
> 
> Regards,
> 
> Kenny
> 
> ----
> 
> Review of draft-irtf-cfrg-xmss-hash-based-signatures-07
> 
> The draft is a mature, clear, and useful document. It is almost ready 
> for
> publication; only minor nits below.
> 
> p.1: "hash-based signatures withstand attacks using quantum computers"
> ---> ""hash-based signatures are believed to withstand attacks using
> quantum computers" or ""hash-based signatures can withstand attacks 
> using
> quantum computers"
> p.3: "from 2006 onwards" --> "from the mid 2000s onwards".
> p.3: "composed of" --> "composed from".
> p.4: "standardizing and introducing" --> "introducing and 
> standardizing"
> (depends to whom the introducing is being done here!).
> p.4: check for update to the text claiming that [BDH11] is the "latest
> stateful hash-based signature scheme".
> p.5: "Addition for XMSS"--> "Additionally, for XMSS:"
> p.6: "used implicitly" --> "omitted".
> p.7: "aside of" --> "aside from".
> p.7: "a n-byte value" --> "an n-byte value".
> p.7: setter methods?
> p.8: text beginning: "One type for the hashes ..." is not a grammatical
> sentence - it lacks verbs. You could insert "is used" in a couple of
> places.
> p.8: "The latter being" --> "The latter is".
> p.12: "hold" --> "held".
> p.13: here you introduce functions F and PRF for the first time, 
> referring
> to security requirements in Section 8 for some more details. I think 
> you
> should also include a forward reference here to Section 5 for specific
> instantiations.
> p.14: "end of this section" --> "section 3.1.7".
> p.16: the pseudocode for Algorithm 5 (WOTS_sign) has a loop in which 
> csum
> is increased by values w-1-msg[i]. Is it possible that csum could 
> overflow
> in an implementation, and what would be the consequences? Is a note 
> needed
> to explain the required bitsize of csum to avoid this?
> p.19: "If they match, the signature is valid." --> "If they match, the
> signature is declared valid.".
> p.19:  In Section 4.1.2, you introduce functions H and H_msg. Here you
> should refer to Section 5 for specific instantiations and Section 8 for
> security considerations.
> p.19: "2 * n" --> "2n" (for consistency).
> p.20: "The WOTS+ private keys MUST be generated as described in Section
> 3.1. To reduce the private key size, a cryptographic pseudorandom 
> method
> MAY be used as discussed at the end of this section." The "MUST" and 
> the
> "MAY" here initially seem incompatible. If you MUST do X, then you 
> cannot
> ever do Y which is different from X. But it turns out that Section 3.1
> also mentions the pseudorandom approach as an option, and refers to a
> later section, so the "MUST" and "MAY" are not strictly incompatible.
> However, it would be nice to find a way to address this small issue.
> p.23: In the pseudocode for Algorithm 10, we have "PK = root || SEED".
> Should OID be included here also? It's included in the byte structure 
> on
> page 24.
> p.24: You talk about the authentication path being h*n bytes and being 
> an
> array of h n-byte strings. Are the conversions clear? (Perhaps this is
> covered by notation introduced in Section 2?)
> p.25: "before the updated private key" --> "before the private key is
> updated". (This one is important: the current text could read as: 
> "output
> the signature first, then output the updated private key"!
> p.26: delete "just".
> p.32: again, should OID be part of the public key, PK_MT?
> p.39: "Finally, for the PRF no full-fledged HMAC is needed as the 
> message
> length is fixed." Here you could add "meaning that standard length
> extension attacks are not a concern here".
> p.39: "We use n-bytes for domain separation for consistency with the 
> SHA2
> implementations". This was a bit unclear to me. What domain separation? 
> Do
> you mean in the calls to the "toByte" function?
> p.43: Delete the text "Other signatures methods are out of scope....
> follow-up work." This is not a research paper!
> p.43: "The draft" --> "This note".
> p.44: "available on most platforms" does not seem to make sense - the 
> part
> about availability in crypto libraries does.
> p.44: "leads parameters that provides" --> "leads to parameters that
> provide".
> p.44: "less common" --> "less widely supported".
> p.44: "more assignments" --> "further assignments".
> p.44: "sufficient details" --> "sufficient detail".
> p.48: "message signature pair" --> "message, signature pair" ?
> p.48: "estimates when" --> "estimates for when".
> p.48: "A full security proof for the scheme described here can be found 
> in
> [HRS16]". Can you be more precise about which schemes are covered in
> [HRS16]? WOTS+, XMSS, or XMSS^MT (or all three?).
> p.48: "This proof shows that an attacker..." - this text may need to be
> modified, depending on which schemes you are talking about.
> p.49: "allows to prove that it is not enough for an adversary to break 
> the
> collision resistance of the underlying hash function". This feels like
> awkward phrasing. I don't think you've proved an impossibility result;
> rather I think you have proof of unforgeability under a different
> assumption than collision resistance. Is the assumption you need 
> strictly
> weaker than collision resistance? This text needs some reworking, I 
> think.
> How about "allows a proof of security under a weaker assumption than
> collision resistance"?
> p.49: "This can also be shown formally in the random oracle model." 
> What
> can? That the "above attack" is thwarted? If so, what positive security
> result do you then obtain? I think it's probably worth stating at this
> point.
> p.49: "The given bit security values...". I would suggest adding an 
> extra
> sentence here to say that while generic attacks are prevented by your
> choices of parameters, there could be quantum speed-ups for specific 
> hash
> functions (since we don't yet know the full power of quantum 
> algorithms).
> p.50: "relies on the security of a cryptographic hash function". This 
> is a
> bit vague. Can you be more specific about which security properties are
> relied upon, or maybe just say "relies on specific security properties 
> of
> cryptographic hash functions"?
> p.50: Section 8.3: same issue as above: there could be quantum 
> speed-ups
> for specific hash functions, but the text only covers generic
> attacks. Additional clarity would be beneficial here.
> p.52: I'm not sure what the style requirements on references are, but 
> it
> would be good to include stable URLs for things like [Huelsing13a].
> p.65: We should delete Appendix D in due course.


From nobody Thu Feb 23 08:28:28 2017
Return-Path: 
X-Original-To: cfrg@ietf.org
Delivered-To: cfrg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E57129A25; Thu, 23 Feb 2017 08:28:26 -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.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com>
Date: Thu, 23 Feb 2017 08:28:26 -0800
Archived-At: 
Cc: cfrg@ietf.org
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 16:28:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
        Authors         : Shay Gueron
                          Adam Langley
                          Yehuda Lindell
	Filename        : draft-irtf-cfrg-gcmsiv-04.txt
	Pages           : 46
	Date            : 2017-02-23

Abstract:
   This memo specifies two authenticated encryption algorithms that are
   nonce misuse-resistant - that is that they do not fail
   catastrophically if a nonce is repeated.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-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 Feb 23 08:32:16 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C7129A20 for ; Thu, 23 Feb 2017 08:32:15 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 e00ScJGsjGOp for ; Thu, 23 Feb 2017 08:32:13 -0800 (PST)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6328312995A for ; Thu, 23 Feb 2017 08:32:13 -0800 (PST)
Received: by mail-it0-x230.google.com with SMTP id y135so7554769itc.1 for ; Thu, 23 Feb 2017 08:32:13 -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:content-transfer-encoding; bh=AD/YOXnU/fUv+gA7zMSbIqGMPNwqql2YpdAFwD5jglw=; b=R4ArHgIiL2cz6Zfq0FFCsP3Pj7tcGKGkABRIkpSLivg13dz9pHt/CBmRX4pKR9tJVM W6mhTx/d0D0Mjmeb6mMV2TKcnu/pcg+STG3X/K8O8Mpq3Q9si57RppHJoJNsEp3ti6dC Agz6pukWmbvBZ86FH18dcaNY05cUuf0oGW51BOE5/p95NP8kkJ3rmtO72SHSZtZE28U1 ZPlNSWVOAd1GbeP/o2S9QVD21j+kvrC4ZNJtU8K756JOBhLHw74Hci4uxvOgzaRG6scy qmwVw6jyzIAmsHzi255pNKzr7RxOrzTrDybE2hxwCtPaXjq/26+3NMlP7gJmLQQoXgpc b38g==
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:content-transfer-encoding; bh=AD/YOXnU/fUv+gA7zMSbIqGMPNwqql2YpdAFwD5jglw=; b=fac9qyYlenH2H2odxMFu0aMnuotowjX/qSQRYvGsSX1g3yZxZH4RQO2AadRBM2fYOO 4oNjRsA+WcRvv2oVvqABTcwN8LyQfsWHxQYfVe1IRklIcLP1ICdTa1gApgzstLZ7MLmv k2pvMpz04WITsLD3jfMx4J6t9VG5gIaywC+Gm1282pVqTYH8xN2IcxI84wVSpX/QgPEH PNFy10dkyqsONiWX0n270ZEKPs8XGu7URzHz6P0EwTT6blIL86fMxmWqVsNMHGROiDOa U9rCG9qjqaTKCS7cLnvIUF1lXC3sSZQNb81R9/uAH/VlS3HuWo8QvvHwMLCVPMFT/s3+ jmvw==
X-Gm-Message-State: AMke39nRSUKyatCPbgIs/7TJTa01Pomg+E9UZl126bV+5mkRvscHtNImVDZ/Yud2ZoUJpMTz4eeHkRvXsnbtfw==
X-Received: by 10.36.216.9 with SMTP id b9mr3205867itg.82.1487867532646; Thu, 23 Feb 2017 08:32:12 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.144.4 with HTTP; Thu, 23 Feb 2017 08:32:12 -0800 (PST)
In-Reply-To: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com>
References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com>
From: Adam Langley 
Date: Thu, 23 Feb 2017 08:32:12 -0800
X-Google-Sender-Auth: 8_zqpajoGt_8Tpd4i35EAgTkfxI
Message-ID: 
To: cfrg@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Yehuda Lindell 
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 16:32:15 -0000

On Thu, Feb 23, 2017 at 8:28 AM,   wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Crypto Forum of the IETF.
>
>         Title           : AES-GCM-SIV: Nonce Misuse-Resistant Authenticat=
ed Encryption
>         Authors         : Shay Gueron
>                           Adam Langley
>                           Yehuda Lindell
>         Filename        : draft-irtf-cfrg-gcmsiv-04.txt
>         Pages           : 46
>         Date            : 2017-02-23

Dear all,

Revision 04 of the AES-GCM-SIV draft
(https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-04) has just been
published. This contains only tidy-ups from revision 03=E2=80=94no substant=
ive
changes have been made.

Most importantly, it now references a paper
(https://eprint.iacr.org/2017/168) by Shay and Yehuda in which they
give precise security bounds for AES-GCM-SIV. Specifically I'd like to
highlight to the group theorem six (which gives those bounds) and
section 5.3 (which gives concrete values of those bounds at a number
of locations in the configuration space).

In light of previous discussions in the working group, section seven
includes some remarks about the meaning of nonce-misuse resistance.

(Comments about the paper, including sightings of typos, are welcome
to be sent to us directly; no need to clutter this list with them.)


Cheers

AGL


From nobody Thu Feb 23 15:12:30 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E2A129C33 for ; Thu, 23 Feb 2017 15:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzeAeHc3RHXi for ; Thu, 23 Feb 2017 15:12:27 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E2B129B08 for ; Thu, 23 Feb 2017 15:12:27 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id n127so5855749qkf.0 for ; Thu, 23 Feb 2017 15:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=DiuHQyc6mQhyqmaU6urgYHTx9gjoqwpQEY1s55JkPOI=; b=fS84jPwtBUsEj23Bwx9PHkRrJedY3na4kUJtacV1N3B40q22XLCAK+mUei4i9MItlh RzcxXtQI+4DACClh60LG8MR0/6JnSnJz+q3edOjVZJ0Yw5xWc5N/VnX0kMLtr9IzmBWt DSP+txNO5+qj5yeRAIseYw/dI3rFpS+xQaQ5o28Gu/5BBgqkaTNB+S9O5S8Gg3gMc4es WhKOCdHbRiCJvNl62PM9UDLc0bYj38Ur4+t49rU2hTo3P0d3Qy+J4nPHmTHekcN9YhhU VpiHYK7jJIxmJlBPRMIP3Uq8YAbvMj7quzfqZdKQoI3zQJ32X4r9Fm8YYalYlq6/omyN /3UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DiuHQyc6mQhyqmaU6urgYHTx9gjoqwpQEY1s55JkPOI=; b=aOtbkmQczZfsbkq799YMuo8s0jVIL2BmvEO/vXF42/Cop7iPbz927F31ucBcDNHqQT tTmQxPE0zvm1kptO1P95Sdbvk8Kz+fWelQZE/IXKjeWiM8ybUAhjyk+PZvu/kjOb1Qug /jQPPmAALCFfHrZQyCR/9v8odvfNP+gqY8+/1sKVRBd4M+CvCzrXKR1t0EB3VGjPey6F WVlbr0H2fGoC/+i4oMEllkWTlahgCXEeKQgcPgQNFL8BQU4vCQk1H3jAoBtDeB8bamVQ fIRTk4H7VnNbio1hsuKRhUaIvjsDCXaY7CMCpzyDaRisDiBlHl7/Vw0/RP16M7vaUFOu 1NyQ==
X-Gm-Message-State: AMke39lP+CoYtXp0Io04XZ3qHjPq1vACyC63OVtSM1JocrjTKawCtphfpMw4ePeYvB1sK7QymObWyvuuyggzvA==
X-Received: by 10.55.95.131 with SMTP id t125mr43886033qkb.279.1487891546806;  Thu, 23 Feb 2017 15:12:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.136.33 with HTTP; Thu, 23 Feb 2017 15:12:26 -0800 (PST)
From: Daniel Franke 
Date: Thu, 23 Feb 2017 18:12:26 -0500
Message-ID: 
To: dharkins@arubanetworks.com, cfrg@irtf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [Cfrg] RFC 5297 and absent vs. zero-length nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 23:12:29 -0000

The IANA considerations section of RFC 5297 (Synthetic Initialization
Vector (SIV) Authenticated Encryption Using the Advanced Encryption
Standard (AES)) gives N_MIN as 1. However, S2V is perfectly capable of
accepting zero-length arguments. Furthermore, passing a zero-length
argument to S2V is distinct from not passing that argument at all (as
done in the case deterministic encryption). How should an
implementation behave when provided with a zero-length nonce?

Should it return an error, since its length is under N_MIN?

Should it pass it along to S2V just like any other nonce input?

Or should it treat this as a request for deterministic encryption and
not pass any nonce to S2V?


From nobody Thu Feb 23 16:07:09 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A881293E4 for ; Thu, 23 Feb 2017 16:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 ipDfE034ft3O for ; Thu, 23 Feb 2017 16:07:05 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0040.outbound.protection.outlook.com [104.47.2.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102E91293E1 for ; Thu, 23 Feb 2017 16:07:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ySXGpx671osuMLs5y7fdW0E5l069fhfPnVYSrNyVX4o=; b=SHhvz//7P32q2nnjbezO0IvdduruqFY+w8fvdPhmz04GUet/I5DNjz3HQhUZlNdZphTnKT0+n4UeHSKGfaknp6eOlz+Xv/ImusqN2NNqWI+74XQI9N9h+4hSDm/xOjotOFdex4tzDyV+TPv8dsxtw0hGpf9iz9PVBFjtP68DmDg=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 00:07:00 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 00:06:59 +0000
From: "Paterson, Kenny" 
To: Adam Langley , "cfrg@ietf.org" 
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
Thread-Index: AQHSjfILPJEKyD2c8U+2aZYUqmbh9aF2yOAAgAB/nAA=
Date: Fri, 24 Feb 2017 00:06:59 +0000
Message-ID: 
References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [183.77.227.125]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:4xrXIyaHcqiKHnZHzuGTDZegQZ9S+pu9jdTV6vD/2b8x+Td2qmKMfEvIi+kNguI8NyJtSHnJCax/5kV6Y/Aw3eIZByYKco+Y+dgUP4oixz0onjyUEnnoyXjN35C0+MymRBEewDWrepMrw3EKJ5T+YjOB5yI7cgQQ0l38U4bHxfYpfU/veKOI2fFaSeHmQOH9KpZX/v4oJ6XCLgQ5hlF+jUy4EuSglwSQwDeBKn2JRawdhJb4M286gZTOsMmHqFkGwSMhKDAn2brELj8iCqPaihOgkDzn/sQSZs63Xp4zJT1ZEYkRoZjPl+3hJLiNWJjEPoPjIubRKZ3MpdrfKDDudA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(24454002)(189002)(199003)(377424004)(2900100001)(74482002)(106356001)(92566002)(5660300001)(53546006)(3280700002)(50986999)(229853002)(81156014)(97736004)(54356999)(81166006)(3660700001)(2906002)(36756003)(76176999)(8676002)(101416001)(25786008)(106116001)(105586002)(4001350100001)(102836003)(68736007)(6436002)(6486002)(66066001)(230783001)(99286003)(189998001)(77096006)(2950100002)(6506006)(6116002)(83506001)(2501003)(8936002)(38730400002)(7736002)(305945005)(42882006)(86362001)(122556002)(6306002)(3846002)(6246003)(6512007)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 75fe67d4-b8e4-4259-cc32-08d45c490d8b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1905; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905; 
x-forefront-prvs: 0228DDDDD7
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 00:06:59.5175 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905
Archived-At: 
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 00:07:08 -0000

RGVhciBBZGFtLCANCg0KVGhhbmsgeW91IHRvIHlvdSwgU2hheSBhbmQgWWVodWRhIGZvciBwdXR0
aW5nIHRoaXMgcGFwZXIgdG9nZXRoZXIgYW5kIGZvcg0KdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpJ
IHRoaW5rIFNlY3Rpb24gNyBvZiB0aGUgcGFwZXIgaXMgcGFydGljdWxhcmx5IGhlbHBmdWwsIGFu
ZCBJIHdvdWxkIGxpa2UNCnRvIGRpcmVjdCBwZW9wbGUgdGhlcmUgZm9yIGEgZ29vZCBkaXNjdXNz
aW9uIG9mIG5vbmNlIG1pc3VzZSByZXNpc3RhbmNlDQphbmQgYW4gZXhwbGFuYXRpb24gb2Ygd2hh
dCB0aGlzIHNjaGVtZSBhY2hpZXZlcy4NCg0KUmVnYXJkcywNCg0KS2VubnkgDQoNCk9uIDIzLzAy
LzIwMTcgMTY6MzIsICJDZnJnIG9uIGJlaGFsZiBvZiBBZGFtIExhbmdsZXkiDQo8Y2ZyZy1ib3Vu
Y2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnPiB3cm90ZToN
Cg0KPk9uIFRodSwgRmViIDIzLCAyMDE3IGF0IDg6MjggQU0sICA8aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnPiB3cm90ZToNCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t
IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj5kaXJlY3Rvcmllcy4NCj4+IFRoaXMgZHJh
ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENyeXB0byBGb3J1bSBvZiB0aGUgSUVURi4NCj4+DQo+
PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEFFUy1HQ00tU0lWOiBOb25jZSBNaXN1c2UtUmVz
aXN0YW50DQo+PkF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KPj4gICAgICAgICBBdXRob3JzICAg
ICAgICAgOiBTaGF5IEd1ZXJvbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBBZGFtIExh
bmdsZXkNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWWVodWRhIExpbmRlbGwNCj4+ICAg
ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNC50eHQNCj4+
ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogNDYNCj4+ICAgICAgICAgRGF0ZSAgICAgICAgICAg
IDogMjAxNy0wMi0yMw0KPg0KPkRlYXIgYWxsLA0KPg0KPlJldmlzaW9uIDA0IG9mIHRoZSBBRVMt
R0NNLVNJViBkcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1j
ZnJnLWdjbXNpdi0wNCkgaGFzIGp1c3QgYmVlbg0KPnB1Ymxpc2hlZC4gVGhpcyBjb250YWlucyBv
bmx5IHRpZHktdXBzIGZyb20gcmV2aXNpb24gMDPigJRubyBzdWJzdGFudGl2ZQ0KPmNoYW5nZXMg
aGF2ZSBiZWVuIG1hZGUuDQo+DQo+TW9zdCBpbXBvcnRhbnRseSwgaXQgbm93IHJlZmVyZW5jZXMg
YSBwYXBlcg0KPihodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE3LzE2OCkgYnkgU2hheSBhbmQg
WWVodWRhIGluIHdoaWNoIHRoZXkNCj5naXZlIHByZWNpc2Ugc2VjdXJpdHkgYm91bmRzIGZvciBB
RVMtR0NNLVNJVi4gU3BlY2lmaWNhbGx5IEknZCBsaWtlIHRvDQo+aGlnaGxpZ2h0IHRvIHRoZSBn
cm91cCB0aGVvcmVtIHNpeCAod2hpY2ggZ2l2ZXMgdGhvc2UgYm91bmRzKSBhbmQNCj5zZWN0aW9u
IDUuMyAod2hpY2ggZ2l2ZXMgY29uY3JldGUgdmFsdWVzIG9mIHRob3NlIGJvdW5kcyBhdCBhIG51
bWJlcg0KPm9mIGxvY2F0aW9ucyBpbiB0aGUgY29uZmlndXJhdGlvbiBzcGFjZSkuDQo+DQo+SW4g
bGlnaHQgb2YgcHJldmlvdXMgZGlzY3Vzc2lvbnMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAsIHNlY3Rp
b24gc2V2ZW4NCj5pbmNsdWRlcyBzb21lIHJlbWFya3MgYWJvdXQgdGhlIG1lYW5pbmcgb2Ygbm9u
Y2UtbWlzdXNlIHJlc2lzdGFuY2UuDQo+DQo+KENvbW1lbnRzIGFib3V0IHRoZSBwYXBlciwgaW5j
bHVkaW5nIHNpZ2h0aW5ncyBvZiB0eXBvcywgYXJlIHdlbGNvbWUNCj50byBiZSBzZW50IHRvIHVz
IGRpcmVjdGx5OyBubyBuZWVkIHRvIGNsdXR0ZXIgdGhpcyBsaXN0IHdpdGggdGhlbS4pDQo+DQo+
DQo+Q2hlZXJzDQo+DQo+QUdMDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj5DZnJnIG1haWxpbmcgbGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRw
czovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0K


From nobody Thu Feb 23 18:09:02 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BCA12948A for ; Thu, 23 Feb 2017 18:09:00 -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, 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 DjgD41gYjSVt for ; Thu, 23 Feb 2017 18:08:59 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D5E91129488 for ; Thu, 23 Feb 2017 18:08:59 -0800 (PST)
Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id A818BA888004 for ; Thu, 23 Feb 2017 18:08:59 -0800 (PST)
To: cfrg@irtf.org
References: 
From: Dan Harkins 
Message-ID: <288933e2-c982-1761-9b14-3b6215978bb6@lounge.org>
Date: Thu, 23 Feb 2017 18:08:57 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cfrg] RFC 5297 and absent vs. zero-length nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 02:09:01 -0000

   Hi Daniel,

On 2/23/17 3:12 PM, Daniel Franke wrote:
> The IANA considerations section of RFC 5297 (Synthetic Initialization
> Vector (SIV) Authenticated Encryption Using the Advanced Encryption
> Standard (AES)) gives N_MIN as 1. However, S2V is perfectly capable of
> accepting zero-length arguments. Furthermore, passing a zero-length
> argument to S2V is distinct from not passing that argument at all (as
> done in the case deterministic encryption). How should an
> implementation behave when provided with a zero-length nonce?

The registry that RFC 5297 updated with its IANA Considerations was
created by RFC 5116 to specify parameters for nonce-based AEAD modes. So
when using RFC 5297 through that interface you're saying you want to
use a nonce. RFC 5297 places the most minimal of requirements on such
use: N_MIN of 1 octet.

   The registry does not say what to do if someone tries to use the
mode in a way that is not defined for the registry so officially I
don't know what the answer is. We can evaluate your suggestions though.

(As an example, AES-GCM can take a nonce of 16 octets but the registry
makes N_MIN = N_MAX = 12. What do you do if you send 16 octets to
AES-GCM through this interface? Got me.)

> Should it return an error, since its length is under N_MIN?

   That would seem like the prudent thing to do since it is in violation
of the registry parameters.
>
> Should it pass it along to S2V just like any other nonce input?

   Since the registry mandates N_MIN as 1 then passing a zero length
nonce "just like any other nonce input" seems wrong. So I'd say don't
do that.

>
> Or should it treat this as a request for deterministic encryption and
> not pass any nonce to S2V?

   Well the registry is not for deterministic encryption so I would
say using it that way is not appropriate and would not think this
is correct.

   Seems to me that if you want to use AES-SIV (or any of the AEAD
modes from RFC 5116) in a way that is not defined by RFC 5116 then
use them through some raw interface and not the constrained one
created by RFC 5116. You'll note that the RFC 5116 interface also
assumes that all AAD is a single blob and does not support AES-SIV's
vector of AAD. What do you do with this registry if you need/want
to pass a vector of AAD to AES-SIV? Well, I'd say you don't use this
registry as your interface.

   Hope this helps,

   Dan.



From nobody Fri Feb 24 04:26:41 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FA5129D65 for ; Fri, 24 Feb 2017 04:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KxLF_nSc4CyE for ; Fri, 24 Feb 2017 04:26:38 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3671296D1 for ; Fri, 24 Feb 2017 04:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5798; q=dns/txt; s=iport; t=1487939198; x=1489148798; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VSePYKds/J+Ff/jxjOAnRIV5+0l+UEGUg4nwWEqhlls=; b=ULBsOGAsORip9ftqYifTa0Mws4MyFXPbG0U8Oq0vpVIRBrLmZ1h+CjKf JdTaMnJYdLy5Mh6fCM3evNTaBbi1a6+o6fMPtFoEm4rPax2hpbBp50DPg tKKeRMMHKDbftMxWjaIpVIBlSmj3D1dM0bFjQbJnJdBE6yiyO0Hq5JFo9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBACwJbBY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SbSB+VNYINHwuFeAIagwVAFwECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEDAQEBIRE6GwIBCA4KAgImAgICJQsVEAIEARKJbAgOrQeCJotCAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBC4dGCIJigTyBOoFegwYugjEFnBoBkiSRFpMsASE?= =?us-ascii?q?DM4EBVBU+EQGESoFxdYkcgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.35,200,1484006400"; d="scan'208";a="202192637"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 12:26:37 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1OCQbmM027015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2017 12:26:37 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 24 Feb 2017 06:26:36 -0600
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Fri, 24 Feb 2017 06:26:36 -0600
From: "David McGrew (mcgrew)" 
To: Dan Harkins , "cfrg@irtf.org" 
Thread-Topic: [Cfrg] RFC 5297 and absent vs. zero-length nonces
Thread-Index: AQHSjipTl+Ef8WslxECa2966+7UoSqF3zimAgABYwAA=
Date: Fri, 24 Feb 2017 12:26:36 +0000
Message-ID: <47B1124D-F656-49A7-9385-A06F68428B27@cisco.com>
References:  <288933e2-c982-1761-9b14-3b6215978bb6@lounge.org>
In-Reply-To: <288933e2-c982-1761-9b14-3b6215978bb6@lounge.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.10.228]
Content-Type: text/plain; charset="utf-8"
Content-ID: <744565D0AF6E8448B09EA7F4A56C1BA8@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Cfrg] RFC 5297 and absent vs. zero-length nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 12:26:40 -0000

SGkgRGFuLA0KDQoNCg0KUkZDIDUxMTYgZG9lcyBhbGxvdyB6ZXJvLWxlbmd0aCBub25jZXMgYW5k
IHByb3ZpZGUgZ3VpZGFuY2UgYXJvdW5kIHRoZWlyIHVzZS4gICBGcm9tIHRoYXQgZG9jOg0KDQog
ICAgICBBIG5vbmNlIE4uICBFYWNoIG5vbmNlIHByb3ZpZGVkIHRvIGRpc3RpbmN0IGludm9jYXRp
b25zIG9mIHRoZQ0KICAgICAgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIG9wZXJhdGlvbiBNVVNU
IGJlIGRpc3RpbmN0LCBmb3IgYW55DQogICAgICBwYXJ0aWN1bGFyIHZhbHVlIG9mIHRoZSBrZXks
IHVubGVzcyBlYWNoIGFuZCBldmVyeSBub25jZSBpcyB6ZXJvLQ0KICAgICAgbGVuZ3RoLiAgQXBw
bGljYXRpb25zIHRoYXQgY2FuIGdlbmVyYXRlIGRpc3RpbmN0IG5vbmNlcyBTSE9VTEQgdXNlDQog
ICAgICB0aGUgbm9uY2UgZm9ybWF0aW9uIG1ldGhvZCBkZWZpbmVkIGluIFNlY3Rpb24gMy4yLCBh
bmQgTUFZIHVzZSBhbnkNCiAgICAgIG90aGVyIG1ldGhvZCB0aGF0IG1lZXRzIHRoZSB1bmlxdWVu
ZXNzIHJlcXVpcmVtZW50LiAgT3RoZXINCiAgICAgIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHpl
cm8tbGVuZ3RoIG5vbmNlcy4NCg0KDQogICBFYWNoIEFFQUQgYWxnb3JpdGhtIE1VU1QgYWNjZXB0
IGFueSBub25jZSB3aXRoIGEgbGVuZ3RoIGJldHdlZW4gTl9NSU4NCiAgIGFuZCBOX01BWCBvY3Rl
dHMsIGluY2x1c2l2ZSwgd2hlcmUgdGhlIHZhbHVlcyBvZiBOX01JTiBhbmQgTl9NQVggYXJlDQog
ICBzcGVjaWZpYyB0byB0aGF0IGFsZ29yaXRobS4gIFRoZSB2YWx1ZXMgb2YgTl9NQVggYW5kIE5f
TUlOIE1BWSBiZQ0KICAgZXF1YWwuICBFYWNoIGFsZ29yaXRobSBTSE9VTEQgYWNjZXB0IGEgbm9u
Y2Ugd2l0aCBhIGxlbmd0aCBvZiB0d2VsdmUNCiAgICgxMikgb2N0ZXRzLiAgUmFuZG9taXplZCBv
ciBzdGF0ZWZ1bCBhbGdvcml0aG1zLCB3aGljaCBhcmUgZGVzY3JpYmVkDQogICBiZWxvdywgTUFZ
IGhhdmUgYW4gTl9NQVggdmFsdWUgb2YgemVyby4NCg0KDQpDbGVhcmx5IFNJViBtb2RlcyBjYW4g
YW5kIHNob3VsZCBzZXQgTl9NSU4gdG8gemVyby4gIEkgZ3Vlc3MgdGhlIE5fTUlOPTEgZ290IG1p
c3NlZCBkdXJpbmcgdGhlIHJldmlldyBvZiBSRkMgNTI5Ny4gIChJIHJlY2FsbCBkaXNjdXNzaW5n
IHRoZSBOX01BWCBndWlkYW5jZSBkdXJpbmcgdGhlIHJldmlldyBwcm9jZXNzLCBidXQgSSB0aGlu
ayBOX01JTiB3ZW50IHVubm90aWNlZC4pDQoNCklmIE5fTUlOIGNhbiBiZSBjaGFuZ2VkIGluIFJG
QyA1Mjk3IGZyb20gMSB0byAwIHdpdGggYW4gRXJyYXRhLCB0aGF0IHdvdWxkIGJlIHRoZSBiZXN0
IHdheSB0byBnby4gICBPdGhlcndpc2UsIEkgc3VnZ2VzdCBjcmVhdGluZyBuZXcgSUFOQSBlbnRy
aWVzIGZvciB0aGUgZXhpc3RpbmcgU0lWIG1vZGVzIHRoYXQgcmVmZXJlbmNlIHRoYXQgUkZDLCBi
dXQgY2hhbmdlIE5fTUlOIHRvIHplcm8uICAgIA0KDQpCZXN0LA0KDQpEYXZpZA0KDQpPbiAyLzIz
LzE3LCA5OjA4IFBNLCAiQ2ZyZyBvbiBiZWhhbGYgb2YgRGFuIEhhcmtpbnMiIDxjZnJnLWJvdW5j
ZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIGRoYXJraW5zQGxvdW5nZS5vcmc+IHdyb3RlOg0KDQo+
DQo+ICAgSGkgRGFuaWVsLA0KPg0KPk9uIDIvMjMvMTcgMzoxMiBQTSwgRGFuaWVsIEZyYW5rZSB3
cm90ZToNCj4+IFRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgUkZDIDUyOTcgKFN5
bnRoZXRpYyBJbml0aWFsaXphdGlvbg0KPj4gVmVjdG9yIChTSVYpIEF1dGhlbnRpY2F0ZWQgRW5j
cnlwdGlvbiBVc2luZyB0aGUgQWR2YW5jZWQgRW5jcnlwdGlvbg0KPj4gU3RhbmRhcmQgKEFFUykp
IGdpdmVzIE5fTUlOIGFzIDEuIEhvd2V2ZXIsIFMyViBpcyBwZXJmZWN0bHkgY2FwYWJsZSBvZg0K
Pj4gYWNjZXB0aW5nIHplcm8tbGVuZ3RoIGFyZ3VtZW50cy4gRnVydGhlcm1vcmUsIHBhc3Npbmcg
YSB6ZXJvLWxlbmd0aA0KPj4gYXJndW1lbnQgdG8gUzJWIGlzIGRpc3RpbmN0IGZyb20gbm90IHBh
c3NpbmcgdGhhdCBhcmd1bWVudCBhdCBhbGwgKGFzDQo+PiBkb25lIGluIHRoZSBjYXNlIGRldGVy
bWluaXN0aWMgZW5jcnlwdGlvbikuIEhvdyBzaG91bGQgYW4NCj4+IGltcGxlbWVudGF0aW9uIGJl
aGF2ZSB3aGVuIHByb3ZpZGVkIHdpdGggYSB6ZXJvLWxlbmd0aCBub25jZT8NCj4NCj5UaGUgcmVn
aXN0cnkgdGhhdCBSRkMgNTI5NyB1cGRhdGVkIHdpdGggaXRzIElBTkEgQ29uc2lkZXJhdGlvbnMg
d2FzDQo+Y3JlYXRlZCBieSBSRkMgNTExNiB0byBzcGVjaWZ5IHBhcmFtZXRlcnMgZm9yIG5vbmNl
LWJhc2VkIEFFQUQgbW9kZXMuIFNvDQo+d2hlbiB1c2luZyBSRkMgNTI5NyB0aHJvdWdoIHRoYXQg
aW50ZXJmYWNlIHlvdSdyZSBzYXlpbmcgeW91IHdhbnQgdG8NCj51c2UgYSBub25jZS4gUkZDIDUy
OTcgcGxhY2VzIHRoZSBtb3N0IG1pbmltYWwgb2YgcmVxdWlyZW1lbnRzIG9uIHN1Y2gNCj51c2U6
IE5fTUlOIG9mIDEgb2N0ZXQuDQo+DQo+ICAgVGhlIHJlZ2lzdHJ5IGRvZXMgbm90IHNheSB3aGF0
IHRvIGRvIGlmIHNvbWVvbmUgdHJpZXMgdG8gdXNlIHRoZQ0KPm1vZGUgaW4gYSB3YXkgdGhhdCBp
cyBub3QgZGVmaW5lZCBmb3IgdGhlIHJlZ2lzdHJ5IHNvIG9mZmljaWFsbHkgSQ0KPmRvbid0IGtu
b3cgd2hhdCB0aGUgYW5zd2VyIGlzLiBXZSBjYW4gZXZhbHVhdGUgeW91ciBzdWdnZXN0aW9ucyB0
aG91Z2guDQo+DQo+KEFzIGFuIGV4YW1wbGUsIEFFUy1HQ00gY2FuIHRha2UgYSBub25jZSBvZiAx
NiBvY3RldHMgYnV0IHRoZSByZWdpc3RyeQ0KPm1ha2VzIE5fTUlOID0gTl9NQVggPSAxMi4gV2hh
dCBkbyB5b3UgZG8gaWYgeW91IHNlbmQgMTYgb2N0ZXRzIHRvDQo+QUVTLUdDTSB0aHJvdWdoIHRo
aXMgaW50ZXJmYWNlPyBHb3QgbWUuKQ0KPg0KPj4gU2hvdWxkIGl0IHJldHVybiBhbiBlcnJvciwg
c2luY2UgaXRzIGxlbmd0aCBpcyB1bmRlciBOX01JTj8NCj4NCj4gICBUaGF0IHdvdWxkIHNlZW0g
bGlrZSB0aGUgcHJ1ZGVudCB0aGluZyB0byBkbyBzaW5jZSBpdCBpcyBpbiB2aW9sYXRpb24NCj5v
ZiB0aGUgcmVnaXN0cnkgcGFyYW1ldGVycy4NCj4+DQo+PiBTaG91bGQgaXQgcGFzcyBpdCBhbG9u
ZyB0byBTMlYganVzdCBsaWtlIGFueSBvdGhlciBub25jZSBpbnB1dD8NCj4NCj4gICBTaW5jZSB0
aGUgcmVnaXN0cnkgbWFuZGF0ZXMgTl9NSU4gYXMgMSB0aGVuIHBhc3NpbmcgYSB6ZXJvIGxlbmd0
aA0KPm5vbmNlICJqdXN0IGxpa2UgYW55IG90aGVyIG5vbmNlIGlucHV0IiBzZWVtcyB3cm9uZy4g
U28gSSdkIHNheSBkb24ndA0KPmRvIHRoYXQuDQo+DQo+Pg0KPj4gT3Igc2hvdWxkIGl0IHRyZWF0
IHRoaXMgYXMgYSByZXF1ZXN0IGZvciBkZXRlcm1pbmlzdGljIGVuY3J5cHRpb24gYW5kDQo+PiBu
b3QgcGFzcyBhbnkgbm9uY2UgdG8gUzJWPw0KPg0KPiAgIFdlbGwgdGhlIHJlZ2lzdHJ5IGlzIG5v
dCBmb3IgZGV0ZXJtaW5pc3RpYyBlbmNyeXB0aW9uIHNvIEkgd291bGQNCj5zYXkgdXNpbmcgaXQg
dGhhdCB3YXkgaXMgbm90IGFwcHJvcHJpYXRlIGFuZCB3b3VsZCBub3QgdGhpbmsgdGhpcw0KPmlz
IGNvcnJlY3QuDQo+DQo+ICAgU2VlbXMgdG8gbWUgdGhhdCBpZiB5b3Ugd2FudCB0byB1c2UgQUVT
LVNJViAob3IgYW55IG9mIHRoZSBBRUFEDQo+bW9kZXMgZnJvbSBSRkMgNTExNikgaW4gYSB3YXkg
dGhhdCBpcyBub3QgZGVmaW5lZCBieSBSRkMgNTExNiB0aGVuDQo+dXNlIHRoZW0gdGhyb3VnaCBz
b21lIHJhdyBpbnRlcmZhY2UgYW5kIG5vdCB0aGUgY29uc3RyYWluZWQgb25lDQo+Y3JlYXRlZCBi
eSBSRkMgNTExNi4gWW91J2xsIG5vdGUgdGhhdCB0aGUgUkZDIDUxMTYgaW50ZXJmYWNlIGFsc28N
Cj5hc3N1bWVzIHRoYXQgYWxsIEFBRCBpcyBhIHNpbmdsZSBibG9iIGFuZCBkb2VzIG5vdCBzdXBw
b3J0IEFFUy1TSVYncw0KPnZlY3RvciBvZiBBQUQuIFdoYXQgZG8geW91IGRvIHdpdGggdGhpcyBy
ZWdpc3RyeSBpZiB5b3UgbmVlZC93YW50DQo+dG8gcGFzcyBhIHZlY3RvciBvZiBBQUQgdG8gQUVT
LVNJVj8gV2VsbCwgSSdkIHNheSB5b3UgZG9uJ3QgdXNlIHRoaXMNCj5yZWdpc3RyeSBhcyB5b3Vy
IGludGVyZmFjZS4NCj4NCj4gICBIb3BlIHRoaXMgaGVscHMsDQo+DQo+ICAgRGFuLg0KPg0KPg0K
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q2ZyZyBt
YWlsaW5nIGxpc3QNCj5DZnJnQGlydGYub3JnDQo+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9jZnJnDQo=


From nobody Fri Feb 24 04:40:54 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D8129D97 for ; Fri, 24 Feb 2017 04:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kuKH_fdhxn1U for ; Fri, 24 Feb 2017 04:40:51 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37A41296CD for ; Fri, 24 Feb 2017 04:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2842; q=dns/txt; s=iport; t=1487940050; x=1489149650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bMdphacCpZv4y8WQBzUPC9gHb3HURQwB0Wsr1ZmSQC8=; b=LQHnFQ8ygXlkxxa4nzrBpW+mfFerKVm965/vR/NWKJyzmN3aoOLaBXTr FOqUvKpv9hwZ6SxdZxA1CD+i5ap5bOQ+HT/giA2SgNtPZ8p7yyO8oeM8T ctxX5mzuqJG2CNQA6JHj67vVyxIOn9yxKLWfFcy26OCPJX1I7ruLsPTsN 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQDFKLBY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFflTWCDR8LhXgCGoJ9PxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xAQEEAQEhEToLEAIBCA4KAgImAgICJQsVEAIEAQ0FiXQOrQaCJotCAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBC4dGgmqEVIMGLoIxBYkGkxQBhnOLMZEWiFqKUgE?= =?us-ascii?q?fOIEBVBUYJhEBhjt1iRyBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,200,1484006400"; d="scan'208";a="389884664"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2017 12:40:50 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1OCenxI013398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2017 12:40:50 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 24 Feb 2017 06:40:49 -0600
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Fri, 24 Feb 2017 06:40:49 -0600
From: "David McGrew (mcgrew)" 
To: Adam Langley , "cfrg@ietf.org" 
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
Thread-Index: AQHSjfICKnIXjxyGdEilsml5swIbPaF3LXYAgAD93AA=
Date: Fri, 24 Feb 2017 12:40:49 +0000
Message-ID: 
References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.10.228]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Yehuda Lindell 
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 12:40:52 -0000

SGkgQWRhbSwNCg0KT25lIHF1aWNrIGNvbW1lbnQ6IHRoZSBkcmFmdCBkb2VzbuKAmXQgcmVxdWVz
dCB0aGF0IElBTkEgY3JlYXRlIHJlZ2lzdHJ5IGVudHJpZXMgZm9yIHRoZSBhbGdvcyB0aGF0IGl0
IGRlZmluZXMgKGFzIHBlciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTExNiNzZWN0
aW9uLTYpOyB3ZSBzdXJlbHkgd2FudCB0byBpbmNsdWRlIHRoZW0gaW4gdGhlIHJlZ2lzdHJ5Lg0K
DQpiZXN0DQoNCkRhdmlkDQoNCnAucy4gLSBhIG5pdCB0aGF0IEkgbm90aWNlZCBpbiB0aGUgQWNr
IHNlY3Rpb246IE1vc25hJiMyNjk7ZWsNCg0KDQoNCg0KDQoNCk9uIDIvMjMvMTcsIDExOjMyIEFN
LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgQWRhbSBMYW5nbGV5IiA8Y2ZyZy1ib3VuY2VzQGlydGYub3Jn
IG9uIGJlaGFsZiBvZiBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnPiB3cm90ZToNCg0KPk9uIFRodSwg
RmViIDIzLCAyMDE3IGF0IDg6MjggQU0sICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90
ZToNCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l
IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0
ZW0gb2YgdGhlIENyeXB0byBGb3J1bSBvZiB0aGUgSUVURi4NCj4+DQo+PiAgICAgICAgIFRpdGxl
ICAgICAgICAgICA6IEFFUy1HQ00tU0lWOiBOb25jZSBNaXN1c2UtUmVzaXN0YW50IEF1dGhlbnRp
Y2F0ZWQgRW5jcnlwdGlvbg0KPj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBTaGF5IEd1ZXJv
bg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBBZGFtIExhbmdsZXkNCj4+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgWWVodWRhIExpbmRlbGwNCj4+ICAgICAgICAgRmlsZW5hbWUgICAg
ICAgIDogZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNC50eHQNCj4+ICAgICAgICAgUGFnZXMgICAg
ICAgICAgIDogNDYNCj4+ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMi0yMw0KPg0K
PkRlYXIgYWxsLA0KPg0KPlJldmlzaW9uIDA0IG9mIHRoZSBBRVMtR0NNLVNJViBkcmFmdA0KPiho
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNCkgaGFz
IGp1c3QgYmVlbg0KPnB1Ymxpc2hlZC4gVGhpcyBjb250YWlucyBvbmx5IHRpZHktdXBzIGZyb20g
cmV2aXNpb24gMDPigJRubyBzdWJzdGFudGl2ZQ0KPmNoYW5nZXMgaGF2ZSBiZWVuIG1hZGUuDQo+
DQo+TW9zdCBpbXBvcnRhbnRseSwgaXQgbm93IHJlZmVyZW5jZXMgYSBwYXBlcg0KPihodHRwczov
L2VwcmludC5pYWNyLm9yZy8yMDE3LzE2OCkgYnkgU2hheSBhbmQgWWVodWRhIGluIHdoaWNoIHRo
ZXkNCj5naXZlIHByZWNpc2Ugc2VjdXJpdHkgYm91bmRzIGZvciBBRVMtR0NNLVNJVi4gU3BlY2lm
aWNhbGx5IEknZCBsaWtlIHRvDQo+aGlnaGxpZ2h0IHRvIHRoZSBncm91cCB0aGVvcmVtIHNpeCAo
d2hpY2ggZ2l2ZXMgdGhvc2UgYm91bmRzKSBhbmQNCj5zZWN0aW9uIDUuMyAod2hpY2ggZ2l2ZXMg
Y29uY3JldGUgdmFsdWVzIG9mIHRob3NlIGJvdW5kcyBhdCBhIG51bWJlcg0KPm9mIGxvY2F0aW9u
cyBpbiB0aGUgY29uZmlndXJhdGlvbiBzcGFjZSkuDQo+DQo+SW4gbGlnaHQgb2YgcHJldmlvdXMg
ZGlzY3Vzc2lvbnMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAsIHNlY3Rpb24gc2V2ZW4NCj5pbmNsdWRl
cyBzb21lIHJlbWFya3MgYWJvdXQgdGhlIG1lYW5pbmcgb2Ygbm9uY2UtbWlzdXNlIHJlc2lzdGFu
Y2UuDQo+DQo+KENvbW1lbnRzIGFib3V0IHRoZSBwYXBlciwgaW5jbHVkaW5nIHNpZ2h0aW5ncyBv
ZiB0eXBvcywgYXJlIHdlbGNvbWUNCj50byBiZSBzZW50IHRvIHVzIGRpcmVjdGx5OyBubyBuZWVk
IHRvIGNsdXR0ZXIgdGhpcyBsaXN0IHdpdGggdGhlbS4pDQo+DQo+DQo+Q2hlZXJzDQo+DQo+QUdM
DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5D
ZnJnIG1haWxpbmcgbGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2NmcmcNCg==


From nobody Fri Feb 24 07:49:31 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C15612989E for ; Fri, 24 Feb 2017 07:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuUKzN5xqhkR for ; Fri, 24 Feb 2017 07:49:29 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A3812968F for ; Fri, 24 Feb 2017 07:49:29 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id u188so21686730qkc.2 for ; Fri, 24 Feb 2017 07:49:29 -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;  bh=OM90YpFMibhhfnH7fiy4s2VdH+ssmMjKcoky9QPwY38=; b=PkSDhi/RxaEH4G6GVj/uLbuUpEe8Cu0eyC/dWU41x4sKqUBYiKmvOcLATXBsHBnlaK f6LES5cr6H8qmr9i/PL2ykRE6tg5x2rlDbvooB+wSpGwbLoDwVeJkZQ0X2sQGU1Qy36e 20VDfiO2XrImDCinkYru8/QR1niBnhW3Sg7+8Y+h9DI9pOVLBNsWMkp/j1zx4f/nPf/1 hGJf4l5bWj98ssRD/VYjrgXJvanYES10979j5Rd1cQRkQjb/ZASBhXGXpVZtFXpbGEEA gvv9WW40eEkQ2C/S6S6XKi3U1H/BADMVfzRvdmaORJd5kIbuTrnxjekDEORq5gfcjIrM oH2A==
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; bh=OM90YpFMibhhfnH7fiy4s2VdH+ssmMjKcoky9QPwY38=; b=mViWm1V9DckGpWplIZ1NUS098IyPSYk2gIr7G50u+77ereT3Z2rLoQQwMql1SrEx7U nR3u4z0mBmrrpG2WfmRzKUHLX14NFF27fhANhOrHSm5usZEoje3DO8RIFFvm7Q0kOSeO Np91hIDwxLm5cE0sDPdaqqL0UZfxMwi8DlYIBv9zxSjjSsDtut143N+UTCGXbom8yBTx V3pvZwkB26AkNyJyYHM2puC5R3NggmMdFx0lPVupFO5MoGl5xwkgod8hXkQooCZMBkxX ibwcE5KX47OabCe+Pzh+xIhSZitdSlM1LC4tansmA9wKH9FpwRG56BSJgY7eJXGHP6zI LwNg==
X-Gm-Message-State: AMke39kBkpAWvyIEyC6+prsIc+TOUzwmm8cl0iWZyVG9x2Jt5pYJf5eS7c5HsWugd1LQL1Ot6fYhTDvU2aGpXw==
X-Received: by 10.55.18.232 with SMTP id 101mr3026823qks.10.1487951368345; Fri, 24 Feb 2017 07:49:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.136.33 with HTTP; Fri, 24 Feb 2017 07:49:27 -0800 (PST)
In-Reply-To: <22B2CCFE-368C-4659-8828-FC11AC685441@cisco.com>
References:  <288933e2-c982-1761-9b14-3b6215978bb6@lounge.org> <47B1124D-F656-49A7-9385-A06F68428B27@cisco.com> <22B2CCFE-368C-4659-8828-FC11AC685441@cisco.com>
From: Daniel Franke 
Date: Fri, 24 Feb 2017 10:49:27 -0500
Message-ID: 
To: "David McGrew (mcgrew)" , dharkins , cfrg@irtf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [Cfrg] RFC 5297 and absent vs. zero-length nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 15:49:30 -0000

On 2/24/17, David McGrew (mcgrew)  wrote:
>Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1
> got missed during the review of RFC 5297.  (I recall discussing the N_MAX
> guidance during the review process, but I think N_MIN went unnoticed.)
>
>If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would
> be the best way to go.   Otherwise, I suggest creating new IANA entries
> for the existing SIV modes that reference that RFC, but change N_MIN to
> zero.

If we agree that a change is in order, that I hope we can also agree
that an erratum would suffice. Having two different IANA codepoints
that differ only in the value of N_MIN sounds like it would sow a
hideous amount of confusion.

It sounds like the three of us agree, at least, that my option 3,
treating a zero-length nonce as a request for deterministic
encryption, is the Wrong Thing. For my own purposes, I'm just doing an
RFC 5297 implementation (look for a release announcement RSN) and not
aspiring to create a general RFC 5116 interface, so I think I can go
ahead and allow zero-length nonces regardless of whether it's strictly
RFCily-correct to do so. My function signature looks like this:

int AES_SIV_Encrypt(AES_SIV_CTX *ctx,
                    uint8_t *out, size_t *out_len,
                    uint8_t const* key, size_t key_len,
                    uint8_t const* nonce, size_t nonce_len,
                    uint8_t const* plaintext, size_t plaintext_len,
                    uint8_t const* ad, size_t ad_len);

It'll give you deterministic encryption if the `nonce` argument is
NULL, and encryption with a zero-length nonce if `nonce` is non-NULL
and `nonce_len` is 0.


From nobody Fri Feb 24 11:57:29 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A061294EA for ; Fri, 24 Feb 2017 11:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 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, 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 BaDyGUjioS-V for ; Fri, 24 Feb 2017 11:57:26 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CAA1294ED for ; Fri, 24 Feb 2017 11:57:24 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id j13so671736iod.3 for ; Fri, 24 Feb 2017 11:57:24 -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:content-transfer-encoding; bh=CF+WkHPi8ABa0ldKiY28oP1poX233YKj9veyo/ZSMhk=; b=u/RhYswMnIzyN++AK4gm3CyqoUpWbpOX1vWAV02Bgj5t4oT3Ay156yyiC+l9Fldvli e5gMqHDz51tbaOhkUx6dlvdMxUd65bL7ceTJ3AcrBcCqJX8C5s1SCF1Npa7DVZkkcKI0 daZMDbtpcMyVcfI37FSWTpWMKKZ0IbiwGqrHtGd/la0OLDttrdXiQa2zXsOfJhEuQxWi YX4CGrbh3KT5E7vqJReS4q+Fq9on2wZzegQnUjn1h1F67CfcGdM9z7gs8u7wd5bMnsIu qWv3asQQDlPqRSlUZ9Cdo2+nmAcxvw1LnTdD9moQ/TithjAQOwvlqhQY4g5fRK6BrYhh XHeg==
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:content-transfer-encoding; bh=CF+WkHPi8ABa0ldKiY28oP1poX233YKj9veyo/ZSMhk=; b=X0i/wTyYhHkczFS15m+S7J3T2+LjSWqEXHnmmaJ6z97vd1Y9PuSoG45kQsYId18uUV PR4PhB39DWl4mRG64EUHH1RbkjQUm94E8pMf8WoJMptFgfLsWIvcc7QhhR1AOCiImz4P wEY1rnDF/DNqhxeSQN4SueKGUbIV5zXRHoiXDjUhlA857RmChUZ8yqFDiTZpBoUw+2jk 7BYkGLoGLMdOo/VVUezEkECqJBwPxA1a6nZwE/D7mmeRQpdevbd8Bu+0RTNWY1f4a0Jq j9ochhWPR0XvEoJLeZw3s30Fuka/SX9Fee71OLKYapIMIRu55zJPhgHRc2Ha1qyasRW2 b3rQ==
X-Gm-Message-State: AMke39kJe8s3gllfwHRCHM8bySzHVcUaEtMx2T666xedFmVpG9x35DdE+d8b8GfZruRBBMm1J8pOtE29259O3Q==
X-Received: by 10.107.141.80 with SMTP id p77mr4228208iod.97.1487966243439; Fri, 24 Feb 2017 11:57:23 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.144.4 with HTTP; Fri, 24 Feb 2017 11:57:23 -0800 (PST)
In-Reply-To: 
References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com>  
From: Adam Langley 
Date: Fri, 24 Feb 2017 11:57:23 -0800
X-Google-Sender-Auth: IFzFhThrKeorMe6wg9jnmj4qluU
Message-ID: 
To: "David McGrew (mcgrew)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Yehuda Lindell , "cfrg@ietf.org" 
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 19:57:28 -0000

On Fri, Feb 24, 2017 at 4:40 AM, David McGrew (mcgrew)  w=
rote:
> One quick comment: the draft doesn=E2=80=99t request that IANA create reg=
istry entries for the algos that it defines (as per https://tools.ietf.org/=
html/rfc5116#section-6); we surely want to include them in the registry.

Good point, thanks. The next version will include this.

> p.s. - a nit that I noticed in the Ack section: Mosnaček

Yes, it appears that the IETF processing doesn't handle UTF-8 :( I've
hammered that name into ASCII, I hope Ondrej doesn't mind.


Cheers

AGL


From nobody Fri Feb 24 13:26:18 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A5129515 for ; Fri, 24 Feb 2017 13:26:16 -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, 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 KAFnBaN5utqZ for ; Fri, 24 Feb 2017 13:26:15 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 52293129511 for ; Fri, 24 Feb 2017 13:26:15 -0800 (PST)
Received: from thinny.local (ext-104-36-248-13.arubanetworks.com [104.36.248.13]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id B81363E000A; Fri, 24 Feb 2017 13:26:14 -0800 (PST)
To: "David McGrew (mcgrew)" , "cfrg@irtf.org" 
References:  <288933e2-c982-1761-9b14-3b6215978bb6@lounge.org> <47B1124D-F656-49A7-9385-A06F68428B27@cisco.com>
From: Dan Harkins 
Message-ID: 
Date: Fri, 24 Feb 2017 13:26:11 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <47B1124D-F656-49A7-9385-A06F68428B27@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cfrg] RFC 5297 and absent vs. zero-length nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 21:26:16 -0000

   Hi David,

On 2/24/17 4:26 AM, David McGrew (mcgrew) wrote:
> Hi Dan,
>
>
>
> RFC 5116 does allow zero-length nonces and provide guidance around their use.   From that doc:
>
>        A nonce N.  Each nonce provided to distinct invocations of the
>        Authenticated Encryption operation MUST be distinct, for any
>        particular value of the key, unless each and every nonce is zero-
>        length.  Applications that can generate distinct nonces SHOULD use
>        the nonce formation method defined in Section 3.2, and MAY use any
>        other method that meets the uniqueness requirement.  Other
>        applications SHOULD use zero-length nonces.
>
>
>     Each AEAD algorithm MUST accept any nonce with a length between N_MIN
>     and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are
>     specific to that algorithm.  The values of N_MAX and N_MIN MAY be
>     equal.  Each algorithm SHOULD accept a nonce with a length of twelve
>     (12) octets.  Randomized or stateful algorithms, which are described
>     below, MAY have an N_MAX value of zero.
>
>
> Clearly SIV modes can and should set N_MIN to zero.  I guess the N_MIN=1 got missed during the review of RFC 5297.  (I recall discussing the N_MAX guidance during the review process, but I think N_MIN went unnoticed.)

   Yes, SIV _can_ accept a zero-length nonce but since SIV is unique in that
it is both a probabilistic AEAD mode and a deterministic "keywrapping" mode
that also accepts AAD such a change might create some confusion. (Option 
3 of
Daniel's question).

>
> If N_MIN can be changed in RFC 5297 from 1 to 0 with an Errata, that would be the best way to go.   Otherwise, I suggest creating new IANA entries for the existing SIV modes that reference that RFC, but change N_MIN to zero.

   I can see why one would want to use SIV deterministically as a better
keywrapping scheme than AES-Keywrap (accepts AAD, no odd length requirements
on plaintext, no padding needed, has a security proof) but I don't see why
someone would want to use it probabilistically with a zero length nonce.
RFC 5116 is for AE modes not deterministic keywrapping modes and if someone
wants to use SIV in its AE mode then what's wrong with mandating he or she
passes at least a 1 byte nonce?

   Unless you can think of a way to avoid the confusion I'd rather not make
the change.

   regards,

   Dan.

> Best,
>
> David
>
> On 2/23/17, 9:08 PM, "Cfrg on behalf of Dan Harkins"  wrote:
>
>>    Hi Daniel,
>>
>> On 2/23/17 3:12 PM, Daniel Franke wrote:
>>> The IANA considerations section of RFC 5297 (Synthetic Initialization
>>> Vector (SIV) Authenticated Encryption Using the Advanced Encryption
>>> Standard (AES)) gives N_MIN as 1. However, S2V is perfectly capable of
>>> accepting zero-length arguments. Furthermore, passing a zero-length
>>> argument to S2V is distinct from not passing that argument at all (as
>>> done in the case deterministic encryption). How should an
>>> implementation behave when provided with a zero-length nonce?
>> The registry that RFC 5297 updated with its IANA Considerations was
>> created by RFC 5116 to specify parameters for nonce-based AEAD modes. So
>> when using RFC 5297 through that interface you're saying you want to
>> use a nonce. RFC 5297 places the most minimal of requirements on such
>> use: N_MIN of 1 octet.
>>
>>    The registry does not say what to do if someone tries to use the
>> mode in a way that is not defined for the registry so officially I
>> don't know what the answer is. We can evaluate your suggestions though.
>>
>> (As an example, AES-GCM can take a nonce of 16 octets but the registry
>> makes N_MIN = N_MAX = 12. What do you do if you send 16 octets to
>> AES-GCM through this interface? Got me.)
>>
>>> Should it return an error, since its length is under N_MIN?
>>    That would seem like the prudent thing to do since it is in violation
>> of the registry parameters.
>>> Should it pass it along to S2V just like any other nonce input?
>>    Since the registry mandates N_MIN as 1 then passing a zero length
>> nonce "just like any other nonce input" seems wrong. So I'd say don't
>> do that.
>>
>>> Or should it treat this as a request for deterministic encryption and
>>> not pass any nonce to S2V?
>>    Well the registry is not for deterministic encryption so I would
>> say using it that way is not appropriate and would not think this
>> is correct.
>>
>>    Seems to me that if you want to use AES-SIV (or any of the AEAD
>> modes from RFC 5116) in a way that is not defined by RFC 5116 then
>> use them through some raw interface and not the constrained one
>> created by RFC 5116. You'll note that the RFC 5116 interface also
>> assumes that all AAD is a single blob and does not support AES-SIV's
>> vector of AAD. What do you do with this registry if you need/want
>> to pass a vector of AAD to AES-SIV? Well, I'd say you don't use this
>> registry as your interface.
>>
>>    Hope this helps,
>>
>>    Dan.
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg


From nobody Sat Feb 25 06:28:50 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71310129FF3 for ; Sat, 25 Feb 2017 06:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 Dc_OhVGsAhlh for ; Sat, 25 Feb 2017 06:28:43 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0117.outbound.protection.outlook.com [23.103.201.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1592D129FE4 for ; Sat, 25 Feb 2017 06:28:42 -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=Od3Ef4DCLz8hNSHvVNx4JVtf0Mky28hWGoN9Y+UJaF0=; b=0euVVzJtewUt/61bEEikJmV8WCKJ2Oa0ELUIbJVpXQhm7dSBC0wapO/IC6WmZNUBAq7d1oh1a77edOWvSwmM9nn3avLVnnuG0r4DXOcaANKPRkl9hx1R0SBf4o/u3ZsSnwmt4nbs27mJ1nzmaFPJD4Q4kgirxQ5nxL0rRG0FNDA=
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.919.13; Sat, 25 Feb 2017 14:28:40 +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.0919.020; Sat, 25 Feb 2017 14:28:40 +0000
From: "Dang, Quynh (Fed)" 
To: Sean Turner , "" 
Thread-Topic: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
Thread-Index: AQHSj3N1z8IXvDyfJEuMUkRo/k0w1A==
Date: Sat, 25 Feb 2017 14:28:40 +0000
Message-ID: 
References: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
In-Reply-To: <352D31A3-5A8B-4790-9473-195C256DEEC8@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.222.69]
x-ms-office365-filtering-correlation-id: f4717a3b-d5fa-4dc8-7c92-08d45d8a9830
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464; 
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:aFdcPV0BTTlXJbSHfbMQU4d5FIcE57SmcmMXLypSaAfsDrXI2ss3tQGU4ehsxoiTtYPluFI9XNxIqqRWYlLo6hYl41Jw+JXst0MhQFbHAP5se+UJmUAWXQMp8y2qjZQpGuWJb3eXlDpJxYEziF3lKUwTabUsHoKYu5itf5FtA7y04OlyJXvr0mlOSqVdsd1qAjcAenEcqxmPM2g/yhD5sjEe+die/s/P9su4gXFMUc42cgHzFIQcSp6x+4UAOkGoezL0s9hWzVyio4/Wdi7DiOL/gQERAOqlPHlcfAItiiZFQGCAFFGAJ0CuaAGVLQJ9fDgHraDrJkasNdTOUewFbA==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; 
x-forefront-prvs: 02296943FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(189002)(199003)(377454003)(102836003)(5660300001)(3846002)(2950100002)(6116002)(81166006)(6436002)(6506006)(53936002)(19627405001)(7906003)(7696004)(74316002)(7736002)(229853002)(68736007)(2900100001)(8676002)(81156014)(8936002)(86362001)(97736004)(92566002)(54356999)(76176999)(50986999)(55016002)(99286003)(77096006)(38730400002)(105586002)(106116001)(53546006)(101416001)(106356001)(122556002)(6246003)(3280700002)(6606003)(606005)(4326007)(66066001)(2906002)(25786008)(189998001)(33656002)(3660700001)(236005)(9686003)(54896002)(6306002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.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_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2017 14:28:40.3925 (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: 
Cc: IRTF CFRG 
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2017 14:28:49 -0000

--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Sean, Joe, Eric and all,


I would like to address my thoughts/suggestions on 2 issues in option a.


1) The data limit should be addressed in term of blocks, not records. When =
the record size is not the full size, some user might not know what to do. =
When the record size is 1 block, the limit of 2^24.5 blocks (records) is wa=
y too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-bl=
ock records is the limit which still achieves the margin of 2^-60.


2) To achieve the margin of 2^-57 as the current text says, the limit numbe=
r should be 2^36 blocks.


Regards,

Quynh.


________________________________
From: Cfrg  on behalf of Sean Turner 
Sent: Friday, February 10, 2017 12:07 AM
To: 
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All,

We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, these =
limits have been discussed a couple of times and we need to resolve once an=
d for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note=
 that unless there=92s clear consensus to change the text will remain as is=
 (i.e., option a).

J&S

[0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1] https://github.com/tlswg/tls13-spec/pull/765
[2] https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










Hi Sean, Joe, Eric and all,







I would like to address my thoughts/suggestions on 2 issues in option a.=
 







1) The data limit should be addressed in term of blocks, not records. Wh=
en the record size is not the full size, some user might not know what to d=
o. When the record size is 1 block, the limit of 2^24.5 blocks (records) is=
 way too low unnecessarily for the
 margin of 2^-60.  In that case, 2^34.5 1-block records is the limit w=
hich still achieves the margin of 2^-60. 







2) To achieve the margin of 2^-57 as the current text says, the limit nu=
mber should be 2^36 blocks.







Regards,


Quynh. 












From: Cfrg <cfrg-bounc=
es@irtf.org> on behalf of Sean Turner <sean@sn3rd.com>

Sent: Friday, February 10, 2017 12:07 AM

To: <tls@ietf.org>

Cc: IRTF CFRG

Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" P=
Rs (#765/#769)

 







All,



We=92ve got two outstanding PRs that propose changes to draft-ietf-tls-tls1=
3 Section 5.5 =93Limits on Key Usage=94.  As it relates to rekeying, t=
hese limits have been discussed a couple of times and we need to resolve on=
ce and for all whether the TLS WG wants to:



a) Close these two PRs and go with the existing text [0]

b) Adopt PR#765 [1]

c) Adopt PR#769 [2]



Please indicate you preference to the TLS mailing list before Feb 17. =
 Note that unless there=92s clear consensus to change the text will remain =
as is (i.e., option a).



J&S



[0] 
https://tlswg.github.io/tls13-spec/#rfc.section.5.5

[1] 
https://github.com/tlswg/tls13-spec/pull/765

[2] 
https://github.com/tlswg/tls13-spec/pull/769

_______________________________________________

Cfrg mailing list

Cfrg@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg










--_000_CY4PR09MB1464243342F19FCBE48C37E7F3550CY4PR09MB1464namp_--


From nobody Sun Feb 26 06:32:58 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A547D129957 for ; Sun, 26 Feb 2017 06:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Level: 
X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 yQlCw6zP6OAu for ; Sun, 26 Feb 2017 06:32:54 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20074.outbound.protection.outlook.com [40.107.2.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF45129715 for ; Sun, 26 Feb 2017 06:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com;  s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mU6maG6cZrFZAKLiBazsLKZ0UAH3CxCPRXypjtJGhlk=; b=FlDsNyrTmAXwoPWD7Hc9yqHhIoPpgQJcYsrP2+xIXnvT32J28p9LDqXjCi74Z9tgY6DH5AR8SR+p4YYXLdHoBazAIbXN6dsLIQwDH4hp2KSy4gGEtmIJL6maWGvFyUCPN/21wgdrwkM4QmKOsZejDFci87XfIWnZuBKNiCr4a34=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Sun, 26 Feb 2017 14:32:50 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0919.021; Sun, 26 Feb 2017 14:32:49 +0000
From: "Paterson, Kenny" 
To: "cfrg@irtf.org" 
Thread-Topic: CFRG NOT meeting at IETF 98/interim meeting in Paris, April 30th
Thread-Index: AQHSkD00i+Qp1q9N30m3Ote044DYuQ==
Date: Sun, 26 Feb 2017 14:32:49 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [183.77.227.119]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:G44tQQLhsebZq3nYipxgtmtEmFOjtzLZCGjEUqjcVxDBAdhEdPKdjPIUJUDpS2mJy7R64XaYsPCy9J95NtgDVEeB57MZ1YRULidW6ih25RZck47p35gdpv3CFR9ty0zLbr/dBSJLxnkOOMXFMpFBFJ0JBVG/YE9ZgI7NjNHpvOCx/rMC841evU7ROsUjc1MdRJFrTiBlPlHpts2+EpMiOY7vbEU2ljPh8Ud4vwOHBhF3kVAIGL4/JfKoiWwQq/CkWXKnGcMss1HQx3M+mcqdEU1qQh7XbObleE2pJT0DO+oJ6pYeHsw4lFmHp6tKSss3XTY9DbJNvCZLo6LfNtF4iw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(50854003)(106116001)(66066001)(54356999)(6486002)(106356001)(6436002)(36756003)(77096006)(50986999)(101416001)(6506006)(2501003)(83506001)(6916009)(53936002)(110136004)(6306002)(3280700002)(38730400002)(6512007)(3660700001)(42882006)(25786008)(189998001)(5640700003)(74482002)(4001350100001)(5660300001)(105586002)(97736004)(2900100001)(450100001)(99286003)(3846002)(92566002)(2351001)(86362001)(305945005)(7736002)(2906002)(122556002)(8676002)(81156014)(81166006)(68736007)(1730700003)(8936002)(102836003)(6116002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: 841694af-3b70-4334-01d2-08d45e545724
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908; 
x-forefront-prvs: 0230B09AC4
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2017 14:32:49.6522 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: 
Subject: [Cfrg] CFRG NOT meeting at IETF 98/interim meeting in Paris, April 30th
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Feb 2017 14:32:56 -0000

RGVhciBDRlJHLA0KDQpXZSB3aWxsIG5vdCBiZSBtZWV0aW5nIGF0IElFVEYgOTggaW4gQ2hpY2Fn
by4gUGxlYXNlIGFjY2VwdCBteSBhcG9sb2dpZXMNCmlmIHlvdSBoYWQgcGxhbm5lZCBhIHRyaXAg
c3BlY2lmaWNhbGx5IGFyb3VuZCBDRlJHLg0KDQpPdXIgbmV4dCBtZWV0aW5nIHdpbGwgYmUgYW4g
aW50ZXJpbSBvbmUsIGp1c3QgYmVmb3JlIEV1cm9jcnlwdCAyMDE3IGluDQpQYXJpcywgb24gU3Vu
ZGF5IDMwdGggQXByaWwuDQoNCklmIHlvdSBhcmUgcGxhbm5pbmcgdG8gYXR0ZW5kIEV1cm9jcnlw
dCBhbmQvb3Igb3RoZXIgb2YgdGhlIGFzc29jaWF0ZWQNCndvcmtzaG9wcyAob2Ygd2hpY2ggdGhl
cmUgYXJlIG1hbnksIHNlZToNCmh0dHBzOi8vZXVyb2NyeXB0MjAxNy5kaS5lbnMuZnIvYWNjZXB0
ZWRFdmVudHMuaHRtbCkgdGhlbiB5b3Ugd2lsbCBuZWVkIHRvDQpyZWdpc3RlciB0aHJvdWdoIHRo
ZSBFdXJvY3J5cHQgd2Vic2l0ZSwgYXMgdGhlcmUgaXMgYSBzbWFsbCBldmVudCBhbmQNCmNhdGVy
aW5nIGZlZSBmb3IgdGhlIHdvcmtzaG9wcy4NCg0KSG93ZXZlciBpZiB5b3UgYXJlIE9OTFkgcGxh
bm5pbmcgdG8gYXR0ZW5kIHRoZSBDRlJHIG1lZXRpbmcsIHRoZW4gZ29vZA0KbmV3czogSSd2ZSBu
ZWdvdGlhdGVkIHdpdGggdGhlIEV1cm9jcnlwdCBvcmdhbmlzYXRpb24gdGVhbSB0aGF0IGl0IHdp
bGwNCk5PVCBiZSBuZWNlc3NhcnkgdG8gcGF5IHRoZSB3b3Jrc2hvcCByZWdpc3RyYXRpb24gZmVl
LiBIb3dldmVyLCBpbiB0aGlzDQppbnN0YW5jZSBpdCB3aWxsIGJlIGltcG9ydGFudCB0byBsZXQg
bWUga25vdywgb2ZmLWxpc3QsIHRoYXQgeW91IGFyZQ0KcGxhbm5pbmcgdG8gYXR0ZW5kLCBzbyB0
aGF0IHRoZSBvcmdhbmlzZXJzIGNhbiB0cmFjayBob3cgbWFueSBwZW9wbGUgdG8NCmV4cGVjdCBp
biB0aGUgQ0ZSRyBtZWV0aW5nLiBQbGVhc2UganVzdCBkcm9wIG1lIGFuIGUtbWFpbCBpZiB5b3Un
cmUgaW4NCnRoaXMgcG9zaXRpb24uDQoNClRoZSBleGFjdCB0aW1pbmcgb2YgdGhlIENGUkcgbWVl
dGluZyBpcyBub3QgeWV0IGZpbmFsaXNlZCwgYW5kIEkgaG9wZSB0bw0KaGF2ZSB0aGF0IGluZm9y
bWF0aW9uIGZvciB5b3Ugc29vbi4gQnV0IHdoeSBub3QgY29tZSBhbG9uZyBmb3IgdGhlIHdob2xl
DQpkYXkgb3Igd2Vla2VuZCBvZiB3b3Jrc2hvcHM/IFRoZXJlJ3Mgb25lIG9uIFRMUyAxLjMsIGFu
b3RoZXIgb24NClF1YW50dW0tc2FmZSBDcnlwdG8sIGEgd29ya3Nob3Agb24gcmFuZG9tIG51bWJl
ciBnZW5lcmF0aW9uLCBhbmQgZXZlbg0KY2F0YUNyeXB0OiAiY2F0YXN0cm9waGljIGV2ZW50cyBy
ZWxhdGVkIHRvIENyeXB0b2dyYXBoeSBhbmQgc2VjdXJpdHkgd2l0aA0KdGhlaXIgcG9zc2libGUg
c29sdXRpb25zIi4gTG9va3MgbGlrZSBhIGZ1biB3ZWVrZW5kIC0gYXQgbGVhc3QgZm9yIHNvbWUN
CmRlZmluaXRpb24gb2YgImZ1biIhDQoNClJlZ2FyZHMsDQoNCktlbm55IA0KDQoNCg==


From nobody Sun Feb 26 15:21:51 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C611295C6 for ; Sun, 26 Feb 2017 15:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTR4aRNaXrB8 for ; Sun, 26 Feb 2017 15:21:47 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4D91295CF for ; Sun, 26 Feb 2017 15:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1488151307; x=1519687307; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=3X8j7qUjbKzrl3V20691yBiySW/kP0BR2pf4UzRUQM0=; b=BKFaaoH789eNdZJCz5sQ8wz8LN5A6Xfj7aqf+9iNaILNIfvDKsaw0J/J c3G1K6Hzf/qCAPqRmxh6UseU4YmXEw1ebWXc7ZwnlojnKk7QgawvJF5v8 ks2maXL0UqZlgjHgX+GEP+Rs/Hwh/70J+S9eiJIoSaePzil76JILthpTz NEpEJp4lLFiEO/K1fptnJR38Ezq/yi+ua4eHUMFndHaIouiWxwgnYYxWX odpVtejdTBMDn8iAmtdenkIC4+zYO5pK6xTkqtA6qVYILkwnr6XrB+0Az FjxB/5FD7Qk9GNcLarepBKa2n8T/Z6VY6j0NLWgUlMxWaclrnsO9WuC27 g==;
X-IronPort-AV: E=Sophos;i="5.35,211,1483959600"; d="scan'208";a="137617427"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL
Received: from sc-cs-316051.cs.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 27 Feb 2017 12:21:42 +1300
To: cfrg Review Panel 
From: Nevil Brownlee 
Message-ID: <00a06d56-5186-4150-5ba5-810e8961d2e8@auckland.ac.nz>
Date: Mon, 27 Feb 2017 12:21:42 +1300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: ISE 
Subject: [Cfrg] ISE needs reviews for draft-hao-jpake-04 and draft-hao-schnorr-04
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Feb 2017 23:21:50 -0000

Hi CFRG Review Panel members:

I don't have a mail alias for the review panel, so I'm sending to
the CFRG list.

These two drafts have been sent to me as Independent Submissions,
please review them for me.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand


From nobody Sun Feb 26 17:46:58 2017
Return-Path: 
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468EE1295B2 for ; Sun, 26 Feb 2017 17:46:57 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 PQ5TFPXs6uc4 for ; Sun, 26 Feb 2017 17:46:56 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1269C1295A5 for ; Sun, 26 Feb 2017 17:46:56 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id n127so76960357qkf.0 for ; Sun, 26 Feb 2017 17:46:56 -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=wVhsJj52WXhugqzTEPPQOWK9iAjsvEBPQhDin4v2KFo=; b=IQUEBxDK5cS/V0dDEB35ce2m3uUgJxAPBTu4Hi8sQ3KEPvnjp2CR9ezoqVxlLheKij yqOKHoaQebWEC6oHcGsl2knGC9BbD47nWwI3StjUUSIL+xZMrzNtBj0k8Qh2RhFZIFcq PQqpCCANFySH3r1mPc6oUnJGAyygKQSiGUYGDKWt/4N/pwE80DnzMZFlsSi7g+uJ1dQn Oxqj02ZTUsWffGHzjdYmS4wQO6PGHBtKnFFS+TBZiTlLe3rfs5+017nzO05BJwPAxnLr wuUTgsyjFYfuUizj9EspvtPdB8bmLiC05rsGGM4gxzaPQHslMG9+VBoQzqu2jxaDWYcL OGpg==
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=wVhsJj52WXhugqzTEPPQOWK9iAjsvEBPQhDin4v2KFo=; b=YWOi3RpCH+kuAS7ihGN2Djm98G2xIuQRzMmaUvzvaXp6FGB1WwzdaYKlepny4iImjo pwiSBmqf47tM4w1wWS/Ix6vFMApMnLXKLllNn3ykmBeMx7pO2CtYC5SfBDayJ9XDUuz3 Fr9hBtoP1KQUj7wuHiAx2ytL9ESwF7NhYv1CXJ9VNAEBZKH6kXzKF0VB5CsvuPCMt5Ix CWcht8AlUJ0QtWFuqd4sZbCpQADAOQyRVaYJ7MPyqbKPwj+3u8I8/72UqzTLyC+VpqjM qThq3KheRqZn4dBqN/wxbx/04WAh1bfKdOppl5nucRC+KgUuYkmI9Q7U+wkA6O/K8qQO kODQ==
X-Gm-Message-State: AMke39n1z7mTNzS2WQH+O8wq1lUeUIcZwpgnPs8+vG7OqJSFnN+GBnxuAcMm45PQcMczMZ1QFpD7J02OWyIzpg==
X-Received: by 10.55.27.219 with SMTP id m88mr4623682qkh.147.1488160015301; Sun, 26 Feb 2017 17:46:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 26 Feb 2017 17:46:54 -0800 (PST)
In-Reply-To: 
References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com>   
From: Martin Thomson 
Date: Mon, 27 Feb 2017 12:46:54 +1100
Message-ID: 
To: Adam Langley 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Yehuda Lindell , "David McGrew \(mcgrew\)" , "cfrg@ietf.org" 
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 01:46:57 -0000

On 25 February 2017 at 06:57, Adam Langley  wrote:
> Yes, it appears that the IETF processing doesn't handle UTF-8 :(

Yet... https://tools.ietf.org/html/rfc7997 is on a slow path to being
usable.  Maybe this time next year if we're all very good and eat our
greens.


From nobody Tue Feb 28 05:25:35 2017
Return-Path: 
X-Original-To: cfrg@ietf.org
Delivered-To: cfrg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC73129602; Tue, 28 Feb 2017 05:25:22 -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.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148828832247.30665.1938517213721291830.idtracker@ietfa.amsl.com>
Date: Tue, 28 Feb 2017 05:25:22 -0800
Archived-At: 
Cc: cfrg@ietf.org
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
List-Id: Crypto Forum Research Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2017 13:25:22 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : Re-keying Mechanisms for Symmetric Keys
        Authors         : Stanislav Smyshlyaev
                          Russ Housley
                          Mihir Bellare
                          Evgeny Alekseev
                          Ekaterina Smyshlyaeva
	Filename        : draft-irtf-cfrg-re-keying-00.txt
	Pages           : 36
	Date            : 2017-02-27

Abstract:
   This specification contains a description of a variety of methods to
   increase the lifetime of symmetric keys.  It provides external and
   internal re-keying mechanisms that can be used with such modes of
   operations as CTR, GCM, CBC, CFB, OFB and OMAC.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-00


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/