From synp71@live.com Sun Dec 1 09:49:46 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053A31ADEC0 for ; Sun, 1 Dec 2013 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_1Wghjlavoe for ; Sun, 1 Dec 2013 09:49:43 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5739E1ADE87 for ; Sun, 1 Dec 2013 09:49:23 -0800 (PST) Received: from BLU0-SMTP404 ([65.55.116.8]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 09:49:21 -0800 X-TMN: [d5KpoX0mrQJCCsX27R8C48o5x+fyqO1r] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([80.179.9.115]) by BLU0-SMTP404.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 09:49:15 -0800 Date: Sun, 1 Dec 2013 19:49:19 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Trevor Perrin References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060000060009020205060001" X-OriginalArrivalTime: 01 Dec 2013 17:49:18.0048 (UTC) FILETIME=[A851B600:01CEEEBD] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 17:49:46 -0000 --------------ms060000060009020205060001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 29/11/13 10:24 PM, Trevor Perrin wrote: > On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: >> To summarize, although there has been much discussion since version -0= 6, >> most of it did not result in massive changes to the document, so IMO w= e >> don't need another WGLC. > > * Weren't we going to discuss the relationship of preloaded to > dynamic pins? See email [1]. > > * The rationale in thread [2] for "strict" seems different from the > rationale in previous list discussions [3]. Ryan now argues that > "strict" is not needed. I think that's worth considering. > > * I had feedback on an earlier draft which is still relevant [4], see= below. > > [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html > [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html > [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html > [hat off] Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot=20 down and easily convinced me. The "strict" directive has come up in=20 discussion at httpbis as well. There's all kinds of talk about adding a=20 "trusted proxy" (a proxy that can see the plaintext). These are used=20 today by performing a MitM attack on the client (with the grudging=20 cooperation of the user or the administrator of her computer. The server = does not have any way to ask the browser to not cooperate with the=20 MitM. A "strict" PKP is one great way to convey that policy, and I=20 don't think we should give up on it. This is especially useful now that = a lot of the content sites (Facebook, Google, Twitter) are becoming=20 HTTPS-only, and pretty much every firewall around can now do the MitM=20 thing. Unless there's some good reasons to leave this off, I think we should=20 leave this one in the spec just as it is. Unless we're afraid people=20 might use it ([4]). [/hat off] Yoav [4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1461.html= --------------ms060000060009020205060001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAxMTc0OTE5WjAjBgkqhkiG9w0BCQQxFgQUiZyXzkhq0r1GmvTA3Zww+ebW2gMwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAKfpUwfQlIqnzAElaNABxeTyG3aWz96mXBHYdX+qYYqZOiF+ +LZY5KStBnq7bwqfSMnIupI/roAIWGOWkHrZC3YSiGD6EYO+LmC3ovxt4oV3rw/iy1nqS0IB Hm5XFIJl0iicfO/FnoOkBkzujaF3Bv8QpFv7UyZysjVNNUOv+rQoPj5YQMszSAQrYehrLdrM yCOP1J/M3HFmFnWJ3nZVjdMbLyyb/K6nL+J1BwJEGvuXlFjSAHMsQwznzNBrJD+hrkPZ7FTq SruKN3WXH1sltNcOsqXLsbnkKjIWArko+K1/qyXpv++Rw31aojU2yza5JxKJDzxHrOdQ4WTc eBes0dsAAAAAAAA= --------------ms060000060009020205060001-- From synp71@live.com Sun Dec 1 09:54:25 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B01ADF5C for ; Sun, 1 Dec 2013 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aW_0twowbMF for ; Sun, 1 Dec 2013 09:54:22 -0800 (PST) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7321ADFE4 for ; Sun, 1 Dec 2013 09:54:21 -0800 (PST) Received: from BLU0-SMTP380 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 09:54:20 -0800 X-TMN: [onVfexT6SZuY9osnO86j8KicZS/X6jJZ] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([80.179.9.115]) by BLU0-SMTP380.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 09:54:13 -0800 Date: Sun, 1 Dec 2013 19:53:41 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Trevor Perrin References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040205080008080304020508" X-OriginalArrivalTime: 01 Dec 2013 17:54:14.0837 (UTC) FILETIME=[59381E50:01CEEEBE] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 17:54:25 -0000 --------------ms040205080008080304020508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 29/11/13 10:24 PM, Trevor Perrin wrote: > On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: >> To summarize, although there has been much discussion since version -0= 6, >> most of it did not result in massive changes to the document, so IMO w= e >> don't need another WGLC. > > * Weren't we going to discuss the relationship of preloaded to > dynamic pins? See email [1]. > > * The rationale in thread [2] for "strict" seems different from the > rationale in previous list discussions [3]. Ryan now argues that > "strict" is not needed. I think that's worth considering. > > * I had feedback on an earlier draft which is still relevant [4], see= below. > > [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html > [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html > [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html > [hat off] Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot=20 down and easily convinced me. The "strict" directive has come up in=20 discussion at httpbis as well. There's all kinds of talk about adding a=20 "trusted proxy" (a proxy that can see the plaintext). These are used=20 today by performing a MitM attack on the client (with the grudging=20 cooperation of the user or the administrator of her computer. The server = does not have any way to ask the browser to not cooperate with the=20 MitM. A "strict" PKP is one great way to convey that policy, and I=20 don't think we should give up on it. This is especially useful now that = a lot of the content sites (Facebook, Google, Twitter) are becoming=20 HTTPS-only, and pretty much every firewall around can now do the MitM=20 thing. Unless there's some good reasons to leave this off, I think we should=20 leave this one in the spec just as it is. Unless we're afraid people=20 might use it ([4]). [/hat off] Yoav [4] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1461.html= --------------ms040205080008080304020508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAxMTc1MzQxWjAjBgkqhkiG9w0BCQQxFgQUzFm56saaJJ/G0lxPuM15mrVzvK0wbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBADBwYyt7Y+dCQGkPUySRgrHO7HLZLqU/gLB36hUJtfs53ZsE h7kaS/6iytlgcIMjAiIR6Tjck1UxX1xVLpo5ooKVLxCi7e4AyNyUhcug3oTKABMv0FvmiMMd m0lU7+qqJzOaZrQSXff9DjglIUvOq6wLXT9hJo+M1CMCTfa1cQokk2zSKcotSorxZ7bedESo zEsXEsqMQZSJaAhQMNoyi7JTBEnCYNi369aPjqLnejMv+At0hIA0NKTIey7NN6nG5MQulLES cbXvylsx73K86dtD6cPvDZiatTYOLYJUKVb0KHx0VKbgEjGtNUv+1XkysfZaz265JS/4l3/k /rK6cSAAAAAAAAA= --------------ms040205080008080304020508-- From hannes.tschofenig@gmx.net Sun Dec 1 09:58:18 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C991ADFB6 for ; Sun, 1 Dec 2013 09:58: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTr4DQIuqef3 for ; Sun, 1 Dec 2013 09:58:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id EC8421AE00A for ; Sun, 1 Dec 2013 09:58:13 -0800 (PST) Received: from masham-mac.lan ([2.102.217.110]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LtEtL-1VbNxB2iHj-012suX for ; Sun, 01 Dec 2013 18:58:11 +0100 Message-ID: <529B78AF.6020303@gmx.net> Date: Sun, 01 Dec 2013 17:58:07 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Yoav Nir References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7m7E5kRL35F11ONw5c+SEEmi45RY9o+XWMNbzo7hHzeZs8ZhVa6 ig0tpyT17R5CplQ5preXJGxxQNZsB/2XNNwsf610mRVhbHd2KYhHBHz1fi14PGd2HsVZnBv QGNa4ZJVRaSXkvufzlLg77mzKQwLK01C32he1DcDXMQzq1lU2DHBaOAPrq+wFC4XkrocHvz hn22yb7od/XvhdoVEoGSQ== Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 17:58:18 -0000 Am 01.12.13 17:49, schrieb Yoav Nir: > pretty much every firewall around can now do the MitM thing For those cases where the system administrator in an enterprise network installs a fake cert in your trust anchor store. For BYOD and other cases this is not possible since it would be indistingushable from an attack*. Ciao Hannes *: Some people may even argue that the practices of some enterprise networks are attacks but luckily there are also other companies around. From synp71@live.com Sun Dec 1 13:02:30 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585E01AE14B for ; Sun, 1 Dec 2013 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvXf-u9y2AfE for ; Sun, 1 Dec 2013 13:02:29 -0800 (PST) Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1961E1AE13F for ; Sun, 1 Dec 2013 13:02:29 -0800 (PST) Received: from BLU0-SMTP450 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 13:02:27 -0800 X-TMN: [JrQWU7Ql7PdwUD/SmKQayBfcMUF/nScf] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP450.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 13:02:25 -0800 Date: Sun, 1 Dec 2013 23:02:23 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <529B78AF.6020303@gmx.net> In-Reply-To: <529B78AF.6020303@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010005020203060307090602" X-OriginalArrivalTime: 01 Dec 2013 21:02:25.0755 (UTC) FILETIME=[A3217AB0:01CEEED8] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:02:30 -0000 --------------ms010005020203060307090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 1/12/13 7:58 PM, Hannes Tschofenig wrote: > Am 01.12.13 17:49, schrieb Yoav Nir: >> pretty much every firewall around can now do the MitM thing > > For those cases where the system administrator in an enterprise=20 > network installs a fake cert in your trust anchor store. For BYOD and=20 > other cases this is not possible since it would be indistingushable=20 > from an attack*. When you bring your own device (like I do), you get tired of clicking=20 through red screens, so you finally download the MitM CA cert, and=20 install it yourself in your trust anchor store. You do it anyway if=20 you've decided to use Firefox. The point is, that whether you do or you don't, the server has no say in = the matter without the "strict" directive. Yoav --------------ms010005020203060307090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAxMjEwMjIzWjAjBgkqhkiG9w0BCQQxFgQUJ5pRV2voCfdakKnys1Hypk6tuIcwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAJxSZRf+hhwjlbW5CM6TACizL0WO7fdSMYvdazHAIXs8nmmi X4XTXKUP8TsAUwMuxiggYElzePZ5xUqs0b+9pvvFg3e4I/h3BK1pOCezvwE48qzsNznWmAhy foEGgVo6Cl4FdxfgdRjgI1lCaPVhQ4ZEaJaObxMfXEMLqy55LY2PTHeyBX/O19MyW/lRKYMV KgVluZemruAR6qBFzvWTLet7C4jzE34Mr7HR8Q+frhR8iJ1oxcA7QI6purZAwG5NvyznfUU7 KYvuP1+4I8givvDrBYx/E9zQ5RshFevfjgk+awiabgtvezqboxqalJb2cVfiqs3B/mmLdwJo ve7HwjAAAAAAAAA= --------------ms010005020203060307090602-- From trevp@trevp.net Sun Dec 1 16:25:08 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027401AE212 for ; Sun, 1 Dec 2013 16:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4wA-nubfSh3 for ; Sun, 1 Dec 2013 16:25:05 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 558F21AE1C0 for ; Sun, 1 Dec 2013 16:25:05 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id z12so11031341wgg.3 for ; Sun, 01 Dec 2013 16:25:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z0E4zN7ZpHPxizCDFFG9fzcq6P9Mzz+SyIQacF4IDLs=; b=PMDsJ+1D/DBLQXPBkxNFlqVR+595cQEZajVkFTwA0mQtNPP1kt++Yd4o/oVrgKMhsS NrkmPUOpu91cZVPrtf5KicxxZFBN4CthGUr1nHz+chfirm5VF0POKnyypDmiHcYhSyny NM6fo3nFsDNDnEYeIp0tswzsPfQrB/vUSCrgaN/JBWzcFJ7YJM0CIQkpqjQomPbt5FCG aJNYxQnXD5kYDEwIXK0XcwerwADE+WN34x0P9WzDZw0sFNAwlQTJQg8giVdlV/BXxOPy 9xy+I6fw4QfG8VCYHKn7pWvX0UYZy5A2jbIxthhWpGTKqhFXtd4Ge78I3e69UOm6ZTUA u1xA== X-Gm-Message-State: ALoCoQmthv4R9opOweztTA7Kcn5riKTlHtSvX0RuouhpeBQHyEjLOrz9ezDmB4guyoYOoVn9EYlD MIME-Version: 1.0 X-Received: by 10.180.160.239 with SMTP id xn15mr15642058wib.17.1385943902813; Sun, 01 Dec 2013 16:25:02 -0800 (PST) Received: by 10.216.214.134 with HTTP; Sun, 1 Dec 2013 16:25:02 -0800 (PST) X-Originating-IP: [166.137.178.246] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Sun, 1 Dec 2013 16:25:02 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 00:25:08 -0000 On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir wrote: > On 29/11/13 10:24 PM, Trevor Perrin wrote: >> >> On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: >>> >>> To summarize, although there has been much discussion since version -06, >>> most of it did not result in massive changes to the document, so IMO we >>> don't need another WGLC. >> >> >> * Weren't we going to discuss the relationship of preloaded to >> dynamic pins? See email [1]. >> >> * The rationale in thread [2] for "strict" seems different from the >> rationale in previous list discussions [3]. Ryan now argues that >> "strict" is not needed. I think that's worth considering. >> >> * I had feedback on an earlier draft which is still relevant [4], see >> below. >> >> [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html >> [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html >> [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html >> > [hat off] > Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot down > and easily convinced me. The "strict" directive has come up in discussion at > httpbis as well. There's all kinds of talk about adding a "trusted proxy" (a > proxy that can see the plaintext). These are used today by performing a MitM > attack on the client (with the grudging cooperation of the user or the > administrator of her computer. The server does not have any way to ask the > browser to not cooperate with the MitM. A "strict" PKP is one great way to > convey that policy The browser has already decided to cooperate with the MITM. I side with Chris and Ryan: it's pointless for the site to try to win a policy arms race here. The question remains whether "strict" is necessary for the "pinning to local trust anchor" case. Ryan argues that it's not, and describes a way for the browser to handle this without "strict": http://www.ietf.org/mail-archive/web/websec/current/msg01947.htm That proposal makes sense to me, and avoids the complexity of an additional directive. So I support removing "strict", and adding text for this "pinning to local trust anchor" case. Trevor From synp71@live.com Sun Dec 1 21:10:02 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B479A1AE3F9 for ; Sun, 1 Dec 2013 21:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IJjGQ3EQymh for ; Sun, 1 Dec 2013 21:10:00 -0800 (PST) Received: from blu0-omc1-s33.blu0.hotmail.com (blu0-omc1-s33.blu0.hotmail.com [65.55.116.44]) by ietfa.amsl.com (Postfix) with ESMTP id 512B21AE3DF for ; Sun, 1 Dec 2013 21:10:00 -0800 (PST) Received: from BLU0-SMTP77 ([65.55.116.8]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 21:09:58 -0800 X-TMN: [5FCGpEr6RvrxfTXNl7GNDCBQDkXrH7bb] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP77.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 21:09:56 -0800 Date: Mon, 2 Dec 2013 07:09:53 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Trevor Perrin References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060106060708050800050207" X-OriginalArrivalTime: 02 Dec 2013 05:09:56.0554 (UTC) FILETIME=[BDF732A0:01CEEF1C] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 05:10:02 -0000 --------------ms060106060708050800050207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2/12/13 2:25 AM, Trevor Perrin wrote: > On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir wrote: >> On 29/11/13 10:24 PM, Trevor Perrin wrote: >>> On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: >>>> To summarize, although there has been much discussion since version = -06, >>>> most of it did not result in massive changes to the document, so IMO= we >>>> don't need another WGLC. >>> >>> * Weren't we going to discuss the relationship of preloaded to >>> dynamic pins? See email [1]. >>> >>> * The rationale in thread [2] for "strict" seems different from th= e >>> rationale in previous list discussions [3]. Ryan now argues that >>> "strict" is not needed. I think that's worth considering. >>> >>> * I had feedback on an earlier draft which is still relevant [4], = see >>> below. >>> >>> [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html= >>> [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html= >>> [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html= >>> >> [hat off] >> Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot d= own >> and easily convinced me. The "strict" directive has come up in discuss= ion at >> httpbis as well. There's all kinds of talk about adding a "trusted pro= xy" (a >> proxy that can see the plaintext). These are used today by performing = a MitM >> attack on the client (with the grudging cooperation of the user or the= >> administrator of her computer. The server does not have any way to ask= the >> browser to not cooperate with the MitM. A "strict" PKP is one great w= ay to >> convey that policy > The browser has already decided to cooperate with the MITM. I side > with Chris and Ryan: it's pointless for the site to try to win a > policy arms race here. > > The question remains whether "strict" is necessary for the "pinning to > local trust anchor" case. Ryan argues that it's not, and describes a > way for the browser to handle this without "strict": > > http://www.ietf.org/mail-archive/web/websec/current/msg01947.html > > That proposal makes sense to me, and avoids the complexity of an > additional directive. So I support removing "strict", and adding text > for this "pinning to local trust anchor" case. > The proposal there is for pins that chain to a well-known CA can be=20 overridden, but pins that chain to local CAs cannot. This means that=20 public sites, such as banks, social media and corporate portals (one=20 type of "SSL VPN") cannot opt out of this local policy override. With vendor hat on, we have been asked by customers whether we could=20 prevent traffic to SSL VPNs (which we provide) from being decrypted.=20 Currently, the only options we can give them are to deploy client=20 certificates or to use IPsec VPNs. The above proposal adds one other way = - to deploy a corporate CA. All three defeat the purpose of SSL VPNs=20 that is that they can be used from pretty much any device. A "strict"=20 directive and enforcing browser version (yes, I know it can be spoofed - = none of this is secure against a malicious client) can get us close enoug= h. Yoav --------------ms060106060708050800050207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAyMDUwOTUzWjAjBgkqhkiG9w0BCQQxFgQUFXzfNa82zyTWjw1iro5hHOc1atcwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAE+9ouI7oadVt9bCJUKMcB/dvxxZzhFccc0i6/DXmaBDZPaq Xt9ZiZI/dcT4xC1bFGfF3pBn3dVFf3Ewo7X2NQSAZFvn6Rp8oF8Knb2g5TKy8b4oSv4bo9Hq rQOpDAFhd9IlDMYX2SU60r8pjkcbp3yYMWf6oRjz9XKL19y29s7kZpfMxnfanyuJHe8BMbrR lwk2jzZs0oAhf9EGtaB+u8XbVpi+McXeQkoGnhD2DK5IWI0wgz5uBiIDr3vzaHaF7xTLB/KR WmnGY0OorQMDhXqW2xpLVwGc7NimeP5Sa8TQGnI3vX8AfymzHf/QHOfd9xrYuT7g9DQCIwRB cWUHBScAAAAAAAA= --------------ms060106060708050800050207-- From trevp@trevp.net Sun Dec 1 22:10:31 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA301AE269 for ; Sun, 1 Dec 2013 22:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkqIctve3B1R for ; Sun, 1 Dec 2013 22:10:29 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD6931AE2BE for ; Sun, 1 Dec 2013 22:10:28 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so4224136wid.11 for ; Sun, 01 Dec 2013 22:10:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=91w3pMjjXGsWdVzlOFcZpJmKGPZ6+ioZpt9LNXKN2xU=; b=SgoeOmzZ5ew/A//cDVkJZmy9nyZJ6YCll7S4/OuFOQ6FHTumGjbB5zbxZ+b4Sb9EKk tGiFcXU0MX8To5RVX1IcBeQUC3HgiJlqIBIMksvHpEQh7Ez9ohUnbL/jnT1ZJMcAMHvR pZrXXkecYdjQX0oHHmyuyf8r5aUxyZphRTVfJdRavnZi2tkSjEvB7tXYjnVXMP301+qu ipXUUcyyEq2P/ycN9rAUd0o57NzqaEAVISwvmC2upMheqr526e1t2tdC6iWXceR5xSxk ypVgY3ncW6YWeexKP1Awo8mybZH3pKzYXwFkYv4tX3mRkP8NsObfjZq0T7w008FughfQ PLdw== X-Gm-Message-State: ALoCoQlxgupIDa06LkNHXLe7seWisjQJPmuEUJwWojMa6zpjAeLlP4o1GTXIepOn1TDwE8Q3wCAm MIME-Version: 1.0 X-Received: by 10.180.89.193 with SMTP id bq1mr7208097wib.22.1385964626118; Sun, 01 Dec 2013 22:10:26 -0800 (PST) Received: by 10.216.214.134 with HTTP; Sun, 1 Dec 2013 22:10:26 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Sun, 1 Dec 2013 22:10:26 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:10:32 -0000 On Sun, Dec 1, 2013 at 9:09 PM, Yoav Nir wrote: >> >> The question remains whether "strict" is necessary for the "pinning to >> local trust anchor" case. Ryan argues that it's not, and describes a >> way for the browser to handle this without "strict": >> >> http://www.ietf.org/mail-archive/web/websec/current/msg01947.html >> >> >> That proposal makes sense to me, and avoids the complexity of an >> additional directive. So I support removing "strict", and adding text >> for this "pinning to local trust anchor" case. >> > The proposal there is for pins that chain to a well-known CA can be > overridden, but pins that chain to local CAs cannot. This means that public > sites, such as banks, social media and corporate portals (one type of "SSL > VPN") cannot opt out of this local policy override. > > With vendor hat on, we have been asked by customers whether we could prevent > traffic to SSL VPNs (which we provide) from being decrypted. Currently, the > only options we can give them are to deploy client certificates or to use > IPsec VPNs. The above proposal adds one other way - to deploy a corporate > CA. All three defeat the purpose of SSL VPNs that is that they can be used > from pretty much any device. A "strict" directive and enforcing browser > version (yes, I know it can be spoofed - none of this is secure against a > malicious client) can get us close enough. It's unclear what you're describing. Is it something like this? - - Company A provides an SSL VPN to its employees, but is unwilling to customize the user's software (e.g. install a trust root) - Company B requires everyone working onsite to send all traffic through a MITM proxy, and *is* willing to customize the user's software (e.g. install a trust root) - An employee of Company A is working onsite at Company B, using her company A laptop, yet subject to B's IT policies (which doesn't make sense, but let's soldier on...) - Company A would like to prevent the user from accessing A's SSL VPN through B's MITM proxy Is this where you think "strict" is useful? Company A would assert a "strict" pin for its SSL VPN? I think it's useless here. If "strict" was in the spec, many sites would undoubtedly enable it, causing these sites to (hypothetically) not to work through B's MITM. But B would "fix" this by configuring user browsers to ignore strictness (or even worse, requiring users to disable pinning, or use a browser without it). You can't win a policy fight with someone who controls the machine. It's pointless to try. Trevor From synp71@live.com Sun Dec 1 22:50:29 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF91AE436 for ; Sun, 1 Dec 2013 22:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iI-i5LTKxDw for ; Sun, 1 Dec 2013 22:50:27 -0800 (PST) Received: from blu0-omc1-s36.blu0.hotmail.com (blu0-omc1-s36.blu0.hotmail.com [65.55.116.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9126C1AE430 for ; Sun, 1 Dec 2013 22:50:27 -0800 (PST) Received: from BLU0-SMTP94 ([65.55.116.9]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 22:50:25 -0800 X-TMN: [ziqucRlU9Cd+WNgpKvxwbBBTI8uuyTq/] X-Originating-Email: [synp71@live.com] Message-ID: Received: from [192.168.1.101] ([84.109.50.18]) by BLU0-SMTP94.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Dec 2013 22:50:22 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Yoav Nir In-Reply-To: Date: Mon, 2 Dec 2013 08:50:17 +0200 Content-Transfer-Encoding: quoted-printable References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> To: Trevor Perrin X-Mailer: Apple Mail (2.1510) X-OriginalArrivalTime: 02 Dec 2013 06:50:24.0348 (UTC) FILETIME=[C6CF91C0:01CEEF2A] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:50:29 -0000 On Dec 2, 2013, at 8:10 AM, Trevor Perrin wrote: > On Sun, Dec 1, 2013 at 9:09 PM, Yoav Nir wrote: >>>=20 >>> The question remains whether "strict" is necessary for the "pinning = to >>> local trust anchor" case. Ryan argues that it's not, and describes = a >>> way for the browser to handle this without "strict": >>>=20 >>> http://www.ietf.org/mail-archive/web/websec/current/msg01947.html >>>=20 >>>=20 >>> That proposal makes sense to me, and avoids the complexity of an >>> additional directive. So I support removing "strict", and adding = text >>> for this "pinning to local trust anchor" case. >>>=20 >> The proposal there is for pins that chain to a well-known CA can be >> overridden, but pins that chain to local CAs cannot. This means that = public >> sites, such as banks, social media and corporate portals (one type of = "SSL >> VPN") cannot opt out of this local policy override. >>=20 >> With vendor hat on, we have been asked by customers whether we could = prevent >> traffic to SSL VPNs (which we provide) from being decrypted. = Currently, the >> only options we can give them are to deploy client certificates or to = use >> IPsec VPNs. The above proposal adds one other way - to deploy a = corporate >> CA. All three defeat the purpose of SSL VPNs that is that they can be = used >> from pretty much any device. A "strict" directive and enforcing = browser >> version (yes, I know it can be spoofed - none of this is secure = against a >> malicious client) can get us close enough. >=20 >=20 > It's unclear what you're describing. >=20 > Is it something like this? - > - Company A provides an SSL VPN to its employees, but is unwilling to > customize the user's software (e.g. install a trust root) Yes. Maybe this is because the employee is using some weird device like = a Mac, or a Windows Phone, or a box running Ubuntu - things the IT = department has no idea how to handle. In other cases, we've seen SSL = VPNs deployed to customers or partners. > - Company B requires everyone working onsite to send all traffic > through a MITM proxy, and *is* willing to customize the user's > software (e.g. install a trust root) Either that, or they can keep clicking through warning screens. > - An employee of Company A is working onsite at Company B, using her > company A laptop, yet subject to B's IT policies (which doesn't make > sense, but let's soldier on=85) Sure it makes sense. The transparent proxy goes with the Wifi. > - Company A would like to prevent the user from accessing A's SSL VPN > through B's MITM proxy *Any* MitM proxy. > Is this where you think "strict" is useful? Company A would assert a > "strict" pin for its SSL VPN? >=20 > I think it's useless here. If "strict" was in the spec, many sites > would undoubtedly enable it, causing these sites to (hypothetically) > not to work through B's MITM. But B would "fix" this by configuring > user browsers to ignore strictness (or even worse, requiring users to > disable pinning, or use a browser without it). I don't think many would enable it. I don't think even banks would, and = I'm pretty sure social media, and web-based mail wouldn't. It's a niche = of web sites that would enable it. > You can't win a policy fight with someone who controls the machine. > It's pointless to try. Agreed. But the use case is against someone who does not control the = machine. Yoav From trevp@trevp.net Mon Dec 2 00:04:19 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C341AE36D for ; Mon, 2 Dec 2013 00:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxHkO0ivb6BR for ; Mon, 2 Dec 2013 00:04:18 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B67721AE355 for ; Mon, 2 Dec 2013 00:04:17 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so4327342wid.17 for ; Mon, 02 Dec 2013 00:04:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ShQYO1TfjZvpVKU3JCvRHxcoQudS4hvwAbqP77eTeRY=; b=d/1ZS2Mu7Q/BxPW02aiAjy7awySw7cNfpJ9n/m1bQ+DCtGP3U9wGmq1qPA0JWhigAl 3iKFZS8JDodzOtzoQpyFxUnbrLUgStZzlKohXjGEhenDCdWGvh7/VMQ7w0Z0RBRW6I7x fBcYq69XvHOF4qB1xyqmK4tTpeS7PLjoHA09zLKKcB92ht4XfZiwqyxVQfLQIu36LgO8 rp8N4yocNKD2dboEcoARuingDGiKim8QyDcbBioPKIbrF4lBTVC2z9tcOw0fvj5tADD7 Mahif/HuXM4jSCqCMTlsoXgifnD4U2BXfrp/SAiXtbOUBk7YZhjvQzO8qmA9VPmURLBU zaDA== X-Gm-Message-State: ALoCoQlsope3QwrlYfw6Rtm/Zpa18H8fuiGZKj1uQWduK3qDpHFaPDn7zN5L3UGni1xKWkHWBuCe MIME-Version: 1.0 X-Received: by 10.180.7.136 with SMTP id j8mr16788690wia.17.1385971454922; Mon, 02 Dec 2013 00:04:14 -0800 (PST) Received: by 10.216.214.134 with HTTP; Mon, 2 Dec 2013 00:04:14 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Mon, 2 Dec 2013 00:04:14 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:04:19 -0000 On Sun, Dec 1, 2013 at 10:50 PM, Yoav Nir wrote: > > On Dec 2, 2013, at 8:10 AM, Trevor Perrin wrote: >> >> It's unclear what you're describing. >> >> Is it something like this? - >> - Company A provides an SSL VPN to its employees, but is unwilling to >> customize the user's software (e.g. install a trust root) > > Yes. Maybe this is because the employee is using some weird device like a= Mac, or a Windows Phone, or a box running Ubuntu - things the IT departmen= t has no idea how to handle. In other cases, we've seen SSL VPNs deployed t= o customers or partners. > >> - Company B requires everyone working onsite to send all traffic >> through a MITM proxy, and *is* willing to customize the user's >> software (e.g. install a trust root) > > Either that, or they can keep clicking through warning screens. Completely different case - in that case, the browser is going to be screaming murder on *every* HTTPS access, and "strict" makes no difference. >> - An employee of Company A is working onsite at Company B, using her >> company A laptop, yet subject to B's IT policies (which doesn't make >> sense, but let's soldier on=85) > > Sure it makes sense. The transparent proxy goes with the Wifi. What doesn't make sense is that company A's VPN is being accessed through machines under the IT control of company B, yet A is trying to enforce its IT policy on these machines. >> - Company A would like to prevent the user from accessing A's SSL VPN >> through B's MITM proxy > > *Any* MitM proxy. > >> Is this where you think "strict" is useful? Company A would assert a >> "strict" pin for its SSL VPN? >> >> I think it's useless here. If "strict" was in the spec, many sites >> would undoubtedly enable it, causing these sites to (hypothetically) >> not to work through B's MITM. But B would "fix" this by configuring >> user browsers to ignore strictness (or even worse, requiring users to >> disable pinning, or use a browser without it). > > I don't think many would enable it. I don't think even banks would, and I= 'm pretty sure social media, and web-based mail wouldn't. It's a niche of w= eb sites that would enable it. As soon as one major website chooses to use this then MITM products break. As soon as those products break, they'll be "fixed" by instructing customers how to bypass strict pinning (or all of pinning). At that point, "strict" becomes worthless spec clutter. >> You can't win a policy fight with someone who controls the machine. >> It's pointless to try. > > Agreed. But the use case is against someone who does not control the mach= ine. No, it's about trying to override "local client policy". Someone who controls that policy controls the machine. It's silly to think an HTTP header is going to override that control. Trevor From brian@briansmith.org Mon Dec 2 00:09:47 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A041AE459 for ; Mon, 2 Dec 2013 00:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R13-Mvom2Hiy for ; Mon, 2 Dec 2013 00:09:45 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id E603D1AE457 for ; Mon, 2 Dec 2013 00:09:44 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id j5so4083084qaq.12 for ; Mon, 02 Dec 2013 00:09:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BMCSwQhdfsnVh1FBu43XZ5dubaIkubstFhsXVt3NRk0=; b=ECJtjpskh0IVhm3Kk+lVfBRNWtfZxP3Sun/LtfQGE9oi0BuNqFHvvqWb8qSKuFVRDF BPfUlA8SZFGyVV7Dp8HES9tj7ZnxJ5qY+ZxpSorOX0GJpyZ62oO+AZP44u4v9JrdREva n5/v8n6NzjEhvzHjTXUIlUVyZXrh/0DOrxkorCqclyzEwHRrWYi1xEslohsYI17jQHno uQaUBydXcwiEvXOrDo4GWgMFLKJsUKPgCdaSZGFIr/CDAldqgHXYcxA9dUO0cClv44wb roFW09r8MYk/udKrgcd0BDysqnRcCgzMkBOLeed4GO6GzJcHqCeIofjVFAcMLl2EKNXS tj0A== X-Gm-Message-State: ALoCoQmUlTt+XstLIWdhwfx74fuLXepreH+O3TM/i6Pna7byzyDQH7BJ2v9vlz+cFuw8Y8UgRmY+ MIME-Version: 1.0 X-Received: by 10.224.66.5 with SMTP id l5mr113493152qai.31.1385971780960; Mon, 02 Dec 2013 00:09:40 -0800 (PST) Received: by 10.224.40.11 with HTTP; Mon, 2 Dec 2013 00:09:40 -0800 (PST) X-Originating-IP: [98.150.241.154] In-Reply-To: <0293e6287211dfed80b38b0c367a6b9c.squirrel@webmail.dreamhost.com> References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> <0293e6287211dfed80b38b0c367a6b9c.squirrel@webmail.dreamhost.com> Date: Mon, 2 Dec 2013 00:09:40 -0800 Message-ID: From: Brian Smith To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:09:47 -0000 Ryan Sleevi wrote: > Trevor Perrin wrote: >> Ryan Sleevi wrote: >> > Trevor Perrin wrote: >> >> * Section 2.6 mandates "When a UA connects to a Pinned Host, if the >> >> TLS connection has errors, the UA MUST terminate the connection >> >> without allowing the user to proceed". HSTS allows the server to >> >> specify this, so it seems unnecessary and inflexible to mandate it >> >> here. It's also unclear whether a "report-only" pin counts as a >> >> "Pinned Host". >> > >> > This is a feature, not a bug. >> > >> > PKP is useful without mandating HSTS. However, the security advantages >> > of PKP can be undermined, much the way HSTS's can, if the UA allows >> > users bypass. >> >> I think it's a mistake to mandate UI here. "Users clicking through >> legitimate security errors" is one risk. "Users being denied access >> to legitimate sites due to pinning failures" is another. >> >> It's hard to know how to balance these. We should allow UAs latitude. >> I suggest changing the text from MUST to SHOULD, at minimum. > > Thanks for your feedback. I'd like to hear from others in the WG if that > view is shared. To this point, we haven't heard any concerns about the > MUST, and the security properties are seemingly well understood. > > Certainly, no UA vendor has asked or proposed such latitude. But then > again, we're all individuals here. I do fail to understand your > distinction between "legitimate security errors" and "pinning failures". I > would certainly count the latter amongst the former, and so I fail to see > how the risks differ, beyond being a superset/subset. I think it would be difficult for any UA to commit to implement this as written. For example, False Start intolerance is an error, but fallback when False Start intolerance is detected doesn't seem like something that should be prevented by pinning. (Especially if such intolerance can only be detected sporadically.) I suggest that the specific types of errors that UAs MUST terminate the connection for be enumerated (expired certificate, revoked certificate, receipt of any fatal alert in the TLS 1.0, TLS 1.1, and/or TLS 1.2 specifications, etc.). Then, leave the rest as SHOULD. Or, just make it SHOULD. >> >> * Why is SHA1 supported? If the reason is size, why not remove it >> >> but allow the server to pin to a truncated hash (e.g. pin to the first >> >> 16 or 20 bytes of SHA256) > In short, I don't feel like it's a compelling reason not to include SHA-1 > at this time (but am happy to see if the WG, ADs, or CFRG feel otherwise), > but I would definitely have concern over the complexity of some truncation > schemes. Example concerns with the proposal include: Is it arbitrary or is > it fixed? If it's fixed, is the criteria size of the hash? Speed of the > hash? Some other criteria? I agree that SHA1 doesn't need to be supported and shouldn't be a MUST-support feature. Let's be nice to our future selves and save them the pain of having to decide what to do about SHA1 in 2017 or whenever. In general, I think that new standards at IETF should avoid making SHA-1 mandatory when there are no legacy compatibility concerns to deal with. I also agree that the complexity of specifying a truncation scheme is concerning, and I would avoid doing anything with truncation. If the examples in the draft are anything to go by, the difference in length of a SHA256 hash vs a SHA1 hash is not a huge concern, relative to the verbosity. > Firefox, which has supported HSTS and is working on (shipping?) HPKP > support, is likewise on a similar update trajectory and a similar > situation where users and sites face much more pressing concerns than > HPKP. Firefox isn't shipping any HPKP implementation, though we are interested in shipping some implementation key pinning, and we've done some incomplete work on an implementation of HPKP. Because we are (I am very) concerned about what a footgun HPKP could be, our rollout of an implementation is likely to be very conservative. For example, I doubt that we would support the "strict" directive initially, and I would not be surprised if we never supporting it. (I definitely support the removal of "strict" from this version of the spec.) > I would think that it would be much better addressed that, as we progress > through WGLC, IF we find we need to make backwards incompatible changes, > we can assess the risks then, rather than act on hypothetical concerns in > the present. This is a draft that has three authors, all from Google, and the only major UA implementation (AFAICT) is also Google-authored. Without a second, independent implementation, it will be very difficult to determine which changes need to be made to the draft spec. I think a good litmus test for determining when HPKP may be suitable to advance would be having https://www.google.com and other major websites send a non-report-only HPKP header to UAs that are not based on Chromium. See [1] for some evidence of why I think that is likely to be quite a ways off. [1] https://groups.google.com/d/msg/mozilla.dev.security/Cfi30mFNxd4/TMmkI2nmWlwJ Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) From brian@briansmith.org Mon Dec 2 00:23:59 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E811AE45B for ; Mon, 2 Dec 2013 00:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnF27MEcURzW for ; Mon, 2 Dec 2013 00:23:58 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2191AE459 for ; Mon, 2 Dec 2013 00:23:58 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id o15so4070127qap.4 for ; Mon, 02 Dec 2013 00:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rCsCMHBlpHSYgOfeORtQS5PMv1b3vWlEBp2LKEjEFXs=; b=NUBWLiWkG7tmajEA6jFufdCu0nLJuVl88euvJOW3gw72xjL87vlUpDipXeZEvmA2+/ kh4ij4qOb4G7rTbktc7DrMAzIcTk8iMEcjym2xnGyVU84neaN/3y1lcwKN0B/qJd61Bh qMgYBdcLNixt+/100lSWd0Lk7OFPTYUsWAvR+5/wd/91bAYj6F9nz+zBQFRaJXECaX55 h2XVtD+ldBp+rVRn+nPIU7wJxF0uOk3sOGsvBY35GM+ZguItiexYuiyJGORBMqbbb5oE BZkTf7viSzpyEKFtY4F9Nhws0RvojTxfcJOY0jP+gjNdmDyiWVix/9q7akPPxrd+Vrvs 3bXw== X-Gm-Message-State: ALoCoQn4tAfBWh5JcP3LCrovYQ6Ia3ZP6YIBD9f+qK2PVE3MsOFYJzs4MArV9RPPk8GNJfs5ctRk MIME-Version: 1.0 X-Received: by 10.229.137.135 with SMTP id w7mr110890571qct.14.1385972635949; Mon, 02 Dec 2013 00:23:55 -0800 (PST) Received: by 10.224.40.11 with HTTP; Mon, 2 Dec 2013 00:23:55 -0800 (PST) X-Originating-IP: [98.150.241.154] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Mon, 2 Dec 2013 00:23:55 -0800 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:24:00 -0000 On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir wrote: > Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot down > and easily convinced me. The "strict" directive has come up in discussion at > httpbis as well. There's all kinds of talk about adding a "trusted proxy" (a > proxy that can see the plaintext). How to help end-users deal with "trusted proxies" and how to differentiate, if at all, benign MitMs from malicious ones, are issues for which there is no widespread consensus amongst UA vendors. When Firefox first started out, the fact that Firefox didn't use the system's enterprise, sysadmin-enforced networking and trust settings was considered a major feature by many Firefox users, and many Firefox users still see it that way. I understand the idea that the owner of the computer and/or the network (i.e. often the end-user's employer) has some rights regarding how their property is used. However, many people at Mozilla, myself included, think that ultimately the rights of the end-user trump the rights of the property owner, though we acknowledge that an adversarial property owner is often a very difficult attacker for the end-user to thwart. How we ensure that both the rights of the property owner and the rights of the end user (when different) are met is still very much an open issue. At least until there is a strong consensus regarding trusted proxies, I don't think specifications like HPKP should add features to differentiate benign MitM from malicious ones. In the case of HPKP, the important thing is that the specification gives UAs enough flexibility to decide how to deal with this on their own. Ultimately, if the spec includes "strict," UAs are only going to implement whatever mandated behavior is specified for "strict" if it makes sense for their constituents, regardless of MUST or SHOULD. IMO, that is a very good indication that, if "strict" survives at all, then it should not have any MUST-level requirements for its processing. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) From brian@briansmith.org Mon Dec 2 00:45:35 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4D11AE191 for ; Mon, 2 Dec 2013 00:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC968239ayJs for ; Mon, 2 Dec 2013 00:45:34 -0800 (PST) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id E222B1AE138 for ; Mon, 2 Dec 2013 00:45:33 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so10764936qec.23 for ; Mon, 02 Dec 2013 00:45:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qbtucB0FCLBzKMbJKiPnmuhRxRIFDSSZFKtl92sin5U=; b=RitfjAxm9bnec/Ur0cVvo6fd3WLpEZ91eaeJY0TBuDDb78Z5+OthGSkrkddpZFhbxT 8JoxThi/tYpODL0GfXHU4lBxrlY7S55KMjqZsTly6C6bhKB5Ftt8YVeARs3im75/Yfw/ GyaQcVkXUX027PU9Z7pqvC62sNVCm1mweHbXxiKiSm5XnBZrXSOJbS75x+D0Q2ca15fV o2CJYkoE4KpftD7y90V62mCBGh7LzMnauDMQ0kOELxOsGZKhoQAo2UNTSgT9YAZ4uIOC RFslZT5wP1qqQ7crZmomxXyxjs4rN8esIBUo4bphZc9wEwTOdqstfhI5vaLmLiY0MSk9 rXUg== X-Gm-Message-State: ALoCoQktBT0IT3ClKx5/OFE+u2QZtUSDV1nZj8q9+f4W5eIejg35JmH+XHG4Eantkpldg9AQ/mpl MIME-Version: 1.0 X-Received: by 10.49.13.135 with SMTP id h7mr17073910qec.73.1385973931561; Mon, 02 Dec 2013 00:45:31 -0800 (PST) Received: by 10.224.40.11 with HTTP; Mon, 2 Dec 2013 00:45:31 -0800 (PST) X-Originating-IP: [98.150.241.154] Date: Mon, 2 Dec 2013 00:45:31 -0800 Message-ID: From: Brian Smith To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Subject: [websec] HPKP: Storing unknown directives and effective pin date X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:45:35 -0000 See http://tools.ietf.org/html/draft-ietf-websec-key-pinning-09#section-2.3.2: > [...] the UA MUST note this host as a Known Pinned Host, caching > the Pinned Host's domain name and noting along with it the time of the > observation (also known as the Effective Pin Date), the value of the > max-age directive, whether or not the includeSubDomains or strict > directives are asserted, the value of the report-uri directive (if present), > and any other metadata from optional or future PKP header directives. In order to maximize the number of entries that can be stored in a limited amount of storage space, we (Mozilla) want to store HSTS/HPKP/etc. information in as compact of a form as possible. With that in mind: 1. Why must a UA store the effective pin date and the max-age directive, instead of storing just the calculated expiration time = effective pin date + max-age? I think that a UA can do a good enough job at making sure it uses the latest available pin data without needing to store the two separate items. 2. The requirement to store "future PKP header directives" seems to mean that a UA must store directives that it doesn't understand, presumably with the intention that it will process those stored directives if/when it starts understanding them. This requirement is unreasonable because it means that a UA may need to store huge HPKP headers full of directives that it will never process. This limits our options for efficiently encoding the stored information and also makes it unnecessarily difficult for us to calculate storage costs for this feature. In general, it seems to me that if it is safe for a UA to ignore a directive when it is first received, then it will be safe for the UA to ignore that directive until it receives a new HPKP header in some future response. If this is not the case, then I recommend changing the draft so that it would be safe. Regardless, I think the draft should be changed so that implementations are not required to store directives that they do not understand. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) From synp71@live.com Mon Dec 2 09:29:48 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858731AD7C5 for ; Mon, 2 Dec 2013 09:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_1aq7y5HmFz for ; Mon, 2 Dec 2013 09:29:47 -0800 (PST) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB7281ACCDF for ; Mon, 2 Dec 2013 09:29:46 -0800 (PST) Received: from BLU0-SMTP76 ([65.55.116.8]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 09:29:44 -0800 X-TMN: [tjLMX4uctMMI04qMvPKTtMxTVtvG6odd] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP76.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 09:29:42 -0800 Date: Mon, 2 Dec 2013 19:29:40 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: IETF WebSec WG References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040109010709010005080004" X-OriginalArrivalTime: 02 Dec 2013 17:29:42.0576 (UTC) FILETIME=[1618AB00:01CEEF84] Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:29:48 -0000 --------------ms040109010709010005080004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi It seems like I'm the only one left who likes the "strict" directive,=20 and I don't even like it much, except as a stop-gap measure until we can = get proper proxy visibility (discussed in httpbis) So let's make this a consensus call. If anyone (other than me) feels=20 that "strict" is useful, please speak up now. Let's make it three options= : A. Keep "strict", Explanation required B. Drop "strict" - not interested in local policy C. Drop "strict", and adopt the rule that local policy can override a=20 regular CA pin, but not a local CA pin. I think if we drop "strict", the choice between B and C will ultimately=20 fall to the UA, because while Chrome might ship with a list of=20 "standard" root CAs, wget does not. But we should still make a=20 recommendation. Please send your preferences by Wednesday, December 11th. Thanks Yoav [with chair hat on] --------------ms040109010709010005080004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAyMTcyOTQwWjAjBgkqhkiG9w0BCQQxFgQUc/aef7dOjhGAtITRaWMOIxxsrEEwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBACAyXpNB82j2LdBo0LyISy6nvNlqXX7AFyPEyj7QnFH4xSrE hilcJAE3kQnFpZz8IZfdL5MORX6HFvhw40bTLJXadXcCWUetoyEE08Vk0oFg/erfB9X0i/rB 6dmkqjtTpnJ/k2sCRyirTFHzzJ/r/o+h04YdcJHIjaBexmY1S9O6TJNgRPLi5uUnIG9gyNFn vBXex6/0AZxy+jnAbltMMnWiALOc0cSxOzdGzH+qVeING0iiUzC23AdxvByEDDXLEvsyt8L3 xYtHP4XCPS3Gl4YVWOdGzpZUEWdQ9LjMXteS8VJR8Eqg3PfzhC2VKIJiMB19oxtAVqjTNciC cHzHFlIAAAAAAAA= --------------ms040109010709010005080004-- From palmer@google.com Mon Dec 2 16:24:21 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879011ADFBF for ; Mon, 2 Dec 2013 16:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KANBxvodCyS for ; Mon, 2 Dec 2013 16:24:20 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 73DF71ADFCE for ; Mon, 2 Dec 2013 16:24:20 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id qd12so22735503ieb.15 for ; Mon, 02 Dec 2013 16:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=46o+tTmNDYMlzuRx7N9V4mWlMiE2E5/mdipBec4P+6g=; b=EjVub3hD3hoqNDdiDFCJl62ujJMlAjXbQC3kAFjruiH34T+ly4sWfNk0/fjOCqB2Vc Xai2eWRuftDbnsFiiyxmSi04zjOL6oZ2zNN5Fsauf97e8kwpZP4+lT4pDm/eEsYLJ/C+ xKwFgXMjMsc9AAAjIOq1ZzLQc8/FJ8rH1kreADiL5/d/VLB6AZFEXtC47e1LxXY5NFcC anzvNSzGpKZDlZYnpBjPieA/Kikn5++ng+sULIFuM3T27dSIM7whp3FGKnqisLzQlfcO o644ukQ8RwRQ8ovvhs51PAGdWH9udJrBR7KPKm5daSLNGu4agg30YXhbtSsnPbab0I92 n4bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=46o+tTmNDYMlzuRx7N9V4mWlMiE2E5/mdipBec4P+6g=; b=RCviYOKlfBSFNXhEeCD1hcWN3Ao2Nq83xAzz6qZTEg3uCiF6n3xZjXJmZvYDNFf/a1 7wTvXqX+JtXp03Y3dBmxg8em4CjoDBmq+zNwbC1k/ev3PTqDyPCCpoCRPG5pP6mzw3jn Z8WK+rIQGfy8krDp23/nP88bVxgTj8lmHNX4WJO1otYfEvqjBA7bYuHFNR2/K0uX2oDZ Zs5hO8e+7b82Qitv3KPhkti5tCB3dmBCaCvczgKJyIo3/h0vAGtTgB9B34jA2UeqrAYT fo5eeHMcXGjvrJ/fpzf2kcivJIQJiESeonuJ2xI16PXejSJc2HN/BkTgJ14YXjneNv9p 1UmA== X-Gm-Message-State: ALoCoQlyqnIB7kJ4l9jbuizU8PBWGn82S4kA4hovbnbGq+v3O/LGdoPafO1oH6Ps1mx0bQPY5Fo5DSY6FhBoYJccJy4eNAPGqSYLtkznmuE4EGJI6hPZYi0h2VvB4UVsz/6gB8XxO3sBB8CXkU4bdTa9XCIEarlPrOb6iQHC+Itav5li+4m3S6YriHW+BElsDOuMNqpF+Ozs MIME-Version: 1.0 X-Received: by 10.50.117.103 with SMTP id kd7mr69994igb.4.1386030257827; Mon, 02 Dec 2013 16:24:17 -0800 (PST) Received: by 10.64.226.69 with HTTP; Mon, 2 Dec 2013 16:24:17 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Mon, 2 Dec 2013 16:24:17 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:24:21 -0000 Hi all, Thanks for the discussion. We are going to roll another version of the draft to clarify the confusing things. Also, my semi-off-the-cuff thoughts on some of the issues: Strict: I support what Yoav calls option (B): Drop "strict" - not interested in local policy. (It has only been a source of confusion. Let's keep things simple.) SHA-1: Let's just get rid of it. SHA-256 only; MUST implement; no truncation. (Maximum simplicity.) Non-overridable failure mode on pin validation failure: To make HPKP less of a footgun, I support saying that UAs SHOULD disallow user override, or SHOULD provide some way of telling the user that pin validation failure happened. But no longer MUST. From synp71@live.com Tue Dec 3 14:52:16 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144AF1AE19F for ; Tue, 3 Dec 2013 14:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8XUIsepBtey for ; Tue, 3 Dec 2013 14:52:15 -0800 (PST) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by ietfa.amsl.com (Postfix) with ESMTP id B47451ADED9 for ; Tue, 3 Dec 2013 14:52:14 -0800 (PST) Received: from BLU0-SMTP241 ([65.55.116.8]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 14:52:12 -0800 X-TMN: [2xDa/gfnKA6DVVzXWcF34ycpzi7JZdkH] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP241.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 14:52:10 -0800 Date: Wed, 4 Dec 2013 00:52:06 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tobias Gondrom , palmer@google.com References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <529E4285.30407@gondrom.org> In-Reply-To: <529E4285.30407@gondrom.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000508000100060103040303" X-OriginalArrivalTime: 03 Dec 2013 22:52:10.0667 (UTC) FILETIME=[4CDECFB0:01CEF07A] Cc: websec@ietf.org Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:52:16 -0000 --------------ms000508000100060103040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/12/13 10:43 PM, Tobias Gondrom wrote: > regarding: SHA-1/SHA-256: please consider that we should have hash > agility whenever possible. There will be SHA-3 and future ones.... > > Hi Tobias. I agree with Chris that we should not specify weak algorithms in new=20 specs. If we had a bunch of deployed HPKP headers with SHA-1, that would = be different. Having just SHA2-256 as MTI is fine, while leaving the door open for=20 other algorithms. SHA2-384 and SHA2-512 and even SHA2-512/256 are pretty = easy. SHA-3 is different, because for efficiency, NIST intends to use=20 different tuning parameters for different uses. So we might end up with=20 one SHA3-256 for MACs in TLS and IPsec, and a totally different SHA3-256 = in certificate signatures, and yet a third one used for HASH-DRBG. That=20 means you can't just label something "pin-sha3-256" and expect all=20 implementations to inter-operate. You'd need to write an RFC "The SHA-3=20 algorithm and its use in key pinning", where you'd specify the=20 parameters for SHA3 in this context. But really, SHA2-256 is an excellent MTI - it performs OK, it's=20 considered secure against second pre-image, and there are no current=20 indications that compromise is coming. If somebody wants to later do this, they can create the directive=20 registry then. Yoav --------------ms000508000100060103040303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjAzMjI1MjA2WjAjBgkqhkiG9w0BCQQxFgQU8AIFF07b2UfCdaQtKfpHn4Kh16QwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAIkRmlwZZcHcJPXLBFHsngpVTHfA94PG+NJ8t2vbYJBD08Pl uBegle1Y4m558ItYBCeLH3VUhrSr2AkqfZ8RTCL/DYyCIjqbwkPSkODll9nCYN/u/UgbQCgl dN8cD8xxZ7tKTtLYET9N/1/LlKXfb2J+nkVMWB3DI5qB53TlY3fauRSi9Gwl/gE6yoDsMaIT LoZxCpghQ+AqgbYt3AKoCNU+aie0apyjh+mSVGs+R235Z40bMDFNXint4CmzCVBIWXlDZ2CW kW3aeRqK6MXiBE3ENz042F+5RskevejZaxxFwk3wxlx7sD/usyOmDwliNfSVWvkKAU1GHvSe e7GdZYQAAAAAAAA= --------------ms000508000100060103040303-- From jbonneau@gmail.com Tue Dec 3 16:27:16 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A271ADF79 for ; Tue, 3 Dec 2013 16:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqVMYqNWRGKo for ; Tue, 3 Dec 2013 16:27:14 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 521B21ADD02 for ; Tue, 3 Dec 2013 16:27:14 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so11049644veb.2 for ; Tue, 03 Dec 2013 16:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dvxdv02ic+lOZUOBx/QeEuJ0AvTGyrm76/RX8LE8xn8=; b=HKFMWTuI2BZpviiqY1hqVGlswMITulK6WFka9iuBOs2TcgZ737Sltdkt6pTz+d6k1m QighjP3uTykcNrKZGiclYX07nabUwHm4jKMDP6FENxx5S4R/rOtxkZ8cPhOfpZLmA1en KVduSwJsKRxSSDlMDG6TlVnGwUaVnDkgIZmhhuh8H50z72NZAlN1zDzAzhtNjOB+eh4R vNx93q2mkWjndIrshofv0vAhR2qBliHiO0unfAAJLJaiod/hsCnFmNNe+NHixytP0lsO h41vgX1dcr2xsP7nysmpIRTGi+6OCmaIpeJOzuhGt8ajC/5ZIwALbZa12QsuuMjLABdn /4/A== X-Received: by 10.58.67.9 with SMTP id j9mr57357734vet.3.1386116831343; Tue, 03 Dec 2013 16:27:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.241.198 with HTTP; Tue, 3 Dec 2013 16:26:51 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <529E4285.30407@gondrom.org> From: Joseph Bonneau Date: Tue, 3 Dec 2013 16:26:51 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b339e0759a85304ecaa797e Cc: "" Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 00:27:16 -0000 --047d7b339e0759a85304ecaa797e Content-Type: text/plain; charset=UTF-8 > SHA-3 is different, because for efficiency, NIST intends to use different > tuning parameters for different uses. So we might end up with one SHA3-256 > for MACs in TLS and IPsec, and a totally different SHA3-256 in certificate > signatures, and yet a third one used for HASH-DRBG. That means you can't > just label something "pin-sha3-256" and expect all implementations to > inter-operate. You'd need to write an RFC "The SHA-3 algorithm and its use > in key pinning", where you'd specify the parameters for SHA3 in this > context. > This discussion is premature of course, but there will certainly be standard forms of SHA3 with short standard names hiding all of the current discussion of output sizes and capacities that are currently being discussed for the final SHA-3 spec. There will be some string like SHA3-256-X which everybody in the world will agree on the meaning of, we just don't know what yet. --047d7b339e0759a85304ecaa797e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
SHA-3 is different, because for efficiency, NIST intends to use different t= uning parameters for different uses. So we might end up with one SHA3-256 f= or MACs in TLS and IPsec, and a totally different SHA3-256 in certificate s= ignatures, and yet a third one used for HASH-DRBG. That means you can't= just label something "pin-sha3-256" and expect all implementatio= ns to inter-operate. You'd need to write an RFC "The SHA-3 algorit= hm and its use in key pinning", where you'd specify the parameters= for SHA3 in this context.

This discussion is premature of course, bu= t there will certainly be standard forms of SHA3 with short standard names = hiding all of the current discussion of output sizes and capacities that ar= e currently being discussed for the final SHA-3 spec. There will be some st= ring like SHA3-256-X which everybody in the world will agree on the meaning= of, we just don't know what yet.
--047d7b339e0759a85304ecaa797e-- From hillbrad@gmail.com Tue Dec 3 18:37:05 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF11ADFAD for ; Tue, 3 Dec 2013 18:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARPTRF5GOIkT for ; Tue, 3 Dec 2013 18:37:03 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 371C11ADF96 for ; Tue, 3 Dec 2013 18:37:03 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id ii20so6222357qab.8 for ; Tue, 03 Dec 2013 18:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GluEoiOOJKV1SRDIL0v33u12ZJ/4FWTLnQDAPdfbGys=; b=NEmm3ZpgN0jJnPacTT0e7otawgmlBOt8WqRp0LoHyQKMvAD3957SfDNT994m+i1QuU bINYVdYKOMcCpU7tN17ue0Inq2gMMa8+4LNF/oVL6Xqfdp+FedWvGUyrXwHB4/iGcPn3 /JLMas07kYFXR4IfzqNCce6P9cbGEBoDpNfNBDlApR4NhBVJoMQFhx2WXhmNyRm8PRIf RaBJjHXIoqw4tq8HHTVsfRE1+3EygaEThIM286pUA1PRR5Pu8dNtQR3quZ3hw+HXujae lCJM2KdahajBGCSHDoaMK3KYIlM/pH2DsBS8ltYPRgKve0qLqq2OrRLZdGc1PXN/m73v LoAA== MIME-Version: 1.0 X-Received: by 10.49.41.104 with SMTP id e8mr131922478qel.1.1386124620109; Tue, 03 Dec 2013 18:37:00 -0800 (PST) Received: by 10.229.82.193 with HTTP; Tue, 3 Dec 2013 18:37:00 -0800 (PST) Date: Tue, 3 Dec 2013 18:37:00 -0800 Message-ID: From: Brad Hill To: websec@ietf.org Content-Type: multipart/alternative; boundary=047d7bea38ae989b6604ecac49ec X-Mailman-Approved-At: Wed, 04 Dec 2013 09:37:48 -0800 Subject: [websec] Future of frame options in Content Security Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 02:39:12 -0000 --047d7bea38ae989b6604ecac49ec Content-Type: text/plain; charset=ISO-8859-1 Websec folks, Last year, this group agreed to abandon plans for a "Frame-Options" header (minus the X-) and move that functionality over into Content Security Policy. (it currently resides in the UI Security Directives, latest editors' draft at: https://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html ) In that group, we have decided to remove the "check top only" behavior and go forward with a model that always requires a full ancestor walk. In light of that, there is a suggestion to rename the directive from 'frame-options' to 'frame-ancestors'. We have no objections over in WebAppSec to this change (it's actually what early implementations by Mozilla used) but we wanted to check over here. Are there any strong objections to naming the new directive 'frame-ancestors'? I'll watch for replies here, but as always, feel free to join in on public-webappsec@w3.org, too. Thanks, Brad Hill WebAppSec WG co-chair --047d7bea38ae989b6604ecac49ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Websec folks,

=A0 Last year, this group= agreed to abandon plans for a "Frame-Options" header (minus the = X-) and move that functionality over into Content Security Policy. =A0(it c= urrently resides in the UI Security Directives, latest editors' draft a= t:=A0https://dvcs.w3.org/hg/user-interface-safety/raw= -file/tip/user-interface-safety.html)

=A0 In that group, we have decided to remove the "= check top only" behavior and go forward with a model that always requi= res a full ancestor walk. =A0In light of that, there is a suggestion to ren= ame the directive from 'frame-options' to 'frame-ancestors'= . =A0We have no objections over in WebAppSec to this change (it's actua= lly what early implementations by =A0Mozilla used) but we wanted to check o= ver here. =A0

=A0 Are there any strong objections to naming the new d= irective 'frame-ancestors'?

=A0 I'll w= atch for replies here, but as always, feel free to join in on public-webappsec@w3.org, too.

Thanks,

Brad Hill
We= bAppSec WG co-chair

--047d7bea38ae989b6604ecac49ec-- From skyper@thc.org Sat Dec 7 06:24:41 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCCF1AE331 for ; Sat, 7 Dec 2013 06:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx3a7xoKgwzi for ; Sat, 7 Dec 2013 06:24:39 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8D1AE31F for ; Sat, 7 Dec 2013 06:24:39 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so3369037iec.2 for ; Sat, 07 Dec 2013 06:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=XNv1pKjJ92SfnruQMraPEHQpBCe43DGULZoyJGlbsTU=; b=eto5Fyc9lucQz2INCdKBSfvwcAk2BWKKtDFtOkNk/N3PleRLGCFtE/pYM/sFz4m4uD uU6lAxrgDTP++w7CNx9Gl1mz9W02fjc1PmYhFWpqSfmQMV4vIlx88UYPWCgYuG3ohO9Q QWe/m2tHktdUl1ez9bOOPG//6h65ym5rLJJmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XNv1pKjJ92SfnruQMraPEHQpBCe43DGULZoyJGlbsTU=; b=l61+27nijekMe1vG0ZlJ1O414rmWtC9nTbfqlKHgYaLhmkq13oo96YRN54Ik3etWtP t4HM8i67iAjXomfj7ZBAkZ+S6s2OMwS6qrt5PFAejc3Pd2hjVYW3L2ZYqc59SW4lvN+/ 3MrQ0f2mm3H39lDJmCS9cM5NfKQcUMgeVkKSpkn066wpvoHPEwmekpXRrIwd+nvpclhf QX6Bb1x9L7b7cvKii7e5wOb9uIefjAHSNbsUVt3L5FEV/CrT5k7mggO7yE3EgkZtRpcr kD8oN03UZsAFZBJ/IxQu6UQrLofWeozJb3XkPnbk/1+NOoGCZ9GYsdUXwFR0V3W1cEFW Cd4Q== X-Gm-Message-State: ALoCoQn78yFSvy4eK07BwZgw7ktO+EvaS/6M9LidcZ7BnPV79IrTlDaeBkoixW4ctAEfGe+hs8wo MIME-Version: 1.0 X-Received: by 10.43.103.133 with SMTP id di5mr7266352icc.38.1386426275503; Sat, 07 Dec 2013 06:24:35 -0800 (PST) Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 06:24:35 -0800 (PST) X-Originating-IP: [87.106.82.87] Date: Sat, 7 Dec 2013 14:24:35 +0000 Message-ID: From: Ralf Skyper Kaiser To: websec@ietf.org Content-Type: multipart/alternative; boundary=bcaec5171c59a8bf2e04ecf2857f Subject: [websec] On pinning of the TLS version X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 14:24:41 -0000 --bcaec5171c59a8bf2e04ecf2857f Content-Type: text/plain; charset=ISO-8859-1 Hi, The TLS-WG is discussing a method to prevent a fallback attack in TLS. [1] "Sad as it is, in order to work on public Internet all browsers implement TLS fallback: in the event of a handshake failure they will retry the connection with a lesser SSL/TLS version." The proposed solution is complex and requires protocol changes. A different solution is to pin the TLS version to the host. Once the TLS version is pinned any downgrade attack to a lower TLS version would fail. This feature could be optional or mandatory to be configured on the host. Please discuss. Opinions welcome. regards, ralf [1] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html --bcaec5171c59a8bf2e04ecf2857f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The TLS-WG is discussing a method to = prevent a fallback attack in TLS. [1]

"Sad as it is, in order t= o work on public Internet all browsers
implement TLS fallback: in the ev= ent of a handshake failure they will
retry the connection with a lesser SSL/TLS version."

The propos= ed solution is complex and requires protocol changes.

A different so= lution is to pin the TLS version to the host. Once the TLS version is
pinned any downgrade attack to a lower TLS version would fail.

This = feature could be optional or mandatory to be configured on the host.
Please discuss. Opinions welcome.


regards,

ralf

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10676.h= tml

--bcaec5171c59a8bf2e04ecf2857f-- From skyper@thc.org Sat Dec 7 06:31:35 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC21AE34E for ; Sat, 7 Dec 2013 06:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XwLwc6mwtSi for ; Sat, 7 Dec 2013 06:31:34 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E4ABF1AE346 for ; Sat, 7 Dec 2013 06:31:33 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id qd12so3371816ieb.15 for ; Sat, 07 Dec 2013 06:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=kG27HNGSvUsNizY17hMmBdOfy7HlMZvxZYxBhA+30eE=; b=DWT8vAHDXfaO6SQRdQje3zhd0fzaxxUDzLXNVSL0weunN0IeKNxFiQW2cJpLk/gMzY mtF+/FdV6m3hy9khrIazjpGg3ArrpRtPnWzsVLNRlF+vknj9VDl+TfGkqI7mRTnqvxGt 4JCGFjIvPvYXmXuRGv8i7bvsXnwZZCLfIM1+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kG27HNGSvUsNizY17hMmBdOfy7HlMZvxZYxBhA+30eE=; b=Eqbh3/3LQWRdFVaY/QuGnjNVI0WWYFgWU38S9zq8snUOTixg7kVvShin89Pyij3rNn LmPcElgkp487J9ZEW57kIsBPyh+YfWjF6yFPAJ65XtoTXEEMiUI21VqFwzz+QqleQcG1 L3aHz+5jEQpiPylTS2KjOiW4uGRbejw+7q10bjuxBoTop6Ib3VCthQVvBmGer9rktcA3 TGBHqYOu7Tb57qLb9niMDC5HDAfeqcxmLtqk3P881ZCnURLffvE3DW2d9WxCqXdC+GHQ JdWJvdud5VjlNraWo8SDOYn5kE0q1f2zX/RdNSJaXAOb4Ck/HIYAVFr2WBxaO3pAHmrx zzFQ== X-Gm-Message-State: ALoCoQm+WqhSy9pQaw+dMK/y7lO5PGBMaPnP5pRKFTDmWpPUlZlV9rjsJxYY+3H20Lb+trZoTpsp MIME-Version: 1.0 X-Received: by 10.42.47.201 with SMTP id p9mr7251484icf.4.1386426689690; Sat, 07 Dec 2013 06:31:29 -0800 (PST) Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 06:31:29 -0800 (PST) X-Originating-IP: [87.106.82.87] Date: Sat, 7 Dec 2013 14:31:29 +0000 Message-ID: From: Ralf Skyper Kaiser To: websec@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6149b258c11204ecf29e37 Subject: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 14:31:35 -0000 --90e6ba6149b258c11204ecf29e37 Content-Type: text/plain; charset=ISO-8859-1 Hi, To let old browsers connect to a host most hosts will support weak or broken ciphers for the forseable future. A feature to pin the CIPHER SUITE would be desirable. It would allow a client to learn a set of 'strong' ciphers available on client and host side. Any downgrade attack to a weaker cipher would fail. This feature could be optional or mandatory to be configured on the host. Please discuss. Opinions welcome. regards, ralf --90e6ba6149b258c11204ecf29e37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

To let old browsers connect to a host= most hosts will support
weak or broken ciphers for the forseable future= .

A feature to pin the CIPHER SUITE would be desirable.

It wo= uld allow a client to learn a set of 'strong' ciphers available
on client and host side. Any downgrade attack to a weaker cipher
would f= ail.

This feature could be optional or mandatory to be configured on= the host.

Please discuss. Opinions welcome.

regards,

ralf
--90e6ba6149b258c11204ecf29e37-- From skyper@thc.org Sat Dec 7 07:01:25 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ACC1AE35F for ; Sat, 7 Dec 2013 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pue8ypWMn0tJ for ; Sat, 7 Dec 2013 07:01:23 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7201AE35D for ; Sat, 7 Dec 2013 07:01:23 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so3207735iej.26 for ; Sat, 07 Dec 2013 07:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YnNWQ0XRqImrNLuE2EBoRyWW1oE29HKKsFwciLcOKAw=; b=Esc5lcVnOOYA8iVul9TYWh2HpPoYpeEd5cKr/8Q0FMWUxTQRJe5EbgKcyYWalGUxe7 KPCPzr25Bfahi/mJIVOLHNiaTUYcchqOIQ96tbpNR9LXcev1FM0fqEcNXCXtwlXIDK/t znTFO4NHk17io/kliKhZL0FeAaIxWVNwIXCFA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YnNWQ0XRqImrNLuE2EBoRyWW1oE29HKKsFwciLcOKAw=; b=PyR4nRGZryyss6iZUth9mDmucfuIRf1v6Uke98UFdRe78EvPo/Ecj6oPs8CaU+oh3N HXJKteMc7MAKIRzKCDaRtRNqnzq+TW/wrL8uc/qGj3OacxgJ+ZXFTqHYwY7ARi7pQuJM 1qQXGo8EUbgYQiONwIybSv7lF0eARJCDbDy2Fljy0D/AjrjyxceCKNA+1MNGeJfqx9f4 UBp9xHTYY+b0MBansWLEXn79NHeZzsmLn1QpxzA+Cb4/Dez/9z63jje/2StHrpVoWiVd Coco8jqBHLJC9Uz7/AL0n3Jmhy6CXC7KlVLdifma/WX+RlegulbPNyQzHx5kE7X0wvKO 7j6Q== X-Gm-Message-State: ALoCoQmRvUFIskiE0iNKx4taujAdAAnk97zxI6jJYcdHvDhUsKi/1/kJPwWZvz92RAnhC1citcLT MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr8085352igg.23.1386428479091; Sat, 07 Dec 2013 07:01:19 -0800 (PST) Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 07:01:19 -0800 (PST) X-Originating-IP: [203.118.14.76] In-Reply-To: <52A33662.1040903@gondrom.org> References: <52A33662.1040903@gondrom.org> Date: Sat, 7 Dec 2013 15:01:19 +0000 Message-ID: From: Ralf Skyper Kaiser To: Tobias Gondrom Content-Type: multipart/alternative; boundary=047d7bdc10ec00d70c04ecf3092b Cc: websec@ietf.org Subject: Re: [websec] On pinning of the TLS version X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 15:01:25 -0000 --047d7bdc10ec00d70c04ecf3092b Content-Type: text/plain; charset=ISO-8859-1 Hi, You are right that this could be solved by just disabling SSLv2, v3 and TLS 1.0 and only supporting STRONG ciphers. Unfortunately is this is not practical for most hosts. Server/hosts will support weak ciphers and weak TLS versions for the foreseeable future to allow old browsers (which do not support better TLS/cipher-suites) to connect. That's the sad reality of the Internet and TLS roll-out. regards ralf On Sat, Dec 7, 2013 at 2:53 PM, Tobias Gondrom wrote: > Hi Ralf, > > thanks for posting this here. > > To pin a host to a TLS version would indeed be fairly easy. > But a small question: I thought "downgrading attacks" would have been > addressed by configuring the server/host to only accept certain strong > ciphers for the TLS/SSL connection. And basically to configure the web > server to no longer support/accept weak ciphers. Wouldn't we want to do > this also with the TLS version? > > Am I missing something? > > All the best, Tobias > > > > > On 07/12/13 14:24, Ralf Skyper Kaiser wrote: > > Hi, > > The TLS-WG is discussing a method to prevent a fallback attack in TLS. [1] > > "Sad as it is, in order to work on public Internet all browsers > implement TLS fallback: in the event of a handshake failure they will > retry the connection with a lesser SSL/TLS version." > > The proposed solution is complex and requires protocol changes. > > A different solution is to pin the TLS version to the host. Once the TLS > version is > pinned any downgrade attack to a lower TLS version would fail. > > This feature could be optional or mandatory to be configured on the host. > > Please discuss. Opinions welcome. > > > regards, > > ralf > > [1] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html > > > > _______________________________________________ > websec mailing listwebsec@ietf.orghttps://www.ietf.org/mailman/listinfo/websec > > > --047d7bdc10ec00d70c04ecf3092b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

You are right that th= is could be solved by just disabling SSLv2, v3 and TLS 1.0 and only support= ing STRONG
ciphers. Unfortunately is this is not practical for most host= s.

Server/hosts will support weak ciphers and weak TLS versions for = the foreseeable future to allow old
browsers (which do not support bette= r TLS/cipher-suites) to connect. That's the sad reality of the Internet=
and TLS roll-out.


regards

ralf
=


On Sat,= Dec 7, 2013 at 2:53 PM, Tobias Gondrom <tobias.gondrom@gondrom.o= rg> wrote:
=20 =20 =20
Hi Ralf,

thanks for posting this here.

To pin a host to a TLS version would indeed be fairly easy.
But a small question: I thought "downgrading attacks" would= have been addressed by configuring the server/host to only accept certain strong ciphers for the TLS/SSL connection. And basically to configure the web server to no longer support/accept weak ciphers. Wouldn't we want to do this also with the TLS version? <= br>
Am I missing something?

All the best, Tobias




On 07/12/13 14:24, Ralf Skyper Kaiser wrote:
Hi,

The TLS-WG is discussing a method to prevent a fallback attack in TLS. [1]

"Sad as it is, in order to work on public Internet all browsers
implement TLS fallback: in the event of a handshake failure they will
retry the connection with a lesser SSL/TLS version."

The proposed solution is complex and requires protocol changes.

A different solution is to pin the TLS version to the host. Once the TLS version is
pinned any downgrade attack to a lower TLS version would fail.

This feature could be optional or mandatory to be configured on the host.

Please discuss. Opinions welcome.


regards,

ralf

[1] http://www.ietf.org/mail-archive/web/tls/curr= ent/msg10676.html



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


--047d7bdc10ec00d70c04ecf3092b-- From skyper@thc.org Sat Dec 7 07:06:41 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB46A1AE36D for ; Sat, 7 Dec 2013 07:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTJv29A9Eu7r for ; Sat, 7 Dec 2013 07:06:40 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA01AE368 for ; Sat, 7 Dec 2013 07:06:40 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so3398526iec.33 for ; Sat, 07 Dec 2013 07:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=prAEAra0kDdjvJU+a5E9VZWjVEPVl4cjHfDDWVaXzy4=; b=RTHU5RqT/jhBMf/aeejccxt393xHX8lCUzONjH0/fMh8Zyk6kmxMZ8tzDnHG2/0+p2 lWayf93zjQ6BWFZSZ5KXUjEuYkkYIaVkO7TGN2UdoKboAsC6c7dqDSf8gxI3hJBwUAZZ EkZniAhylovvXu1/tUh62jXOSRZrI44Ig+Hjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=prAEAra0kDdjvJU+a5E9VZWjVEPVl4cjHfDDWVaXzy4=; b=jIL4F/m0zf31qcmYv4iVFWcXQkKIFHXGa+maeVpVHmHcbG9mAJr7ZU+p/yLVky8Jnf jZQvWL0eAVCvo5tMTiO4j7ay00hTp+gKcuAsPldeobUjORDsncWgRbTJUm0wCXpv4ciP TruIRxLFQDXUjulaYJX6rugbqLgXr7WBk6Debh7PDMwTFiDXyCF7KVqFJaX4+ILzQXHN HOTplhDXpeOKV/r4bQDLU1LFzoycy8Tb10newjCtksUT8W12/WM32jOhtIWXhQCzDpNz wWpbOWIkF2Iz5F0F683f5cp05qU+yHQ2WEWAaDlg5oBSTjzg/n4dVFktE1w1UQJiZdf9 8PBQ== X-Gm-Message-State: ALoCoQkqnukGB+rl2hGrdrdcy5RCxkN0V2/dcAMIcfTBdehlBmQ2ZPthobfcnPNk764dA70LPmy2 MIME-Version: 1.0 X-Received: by 10.50.23.103 with SMTP id l7mr8089402igf.3.1386428796446; Sat, 07 Dec 2013 07:06:36 -0800 (PST) Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 07:06:36 -0800 (PST) X-Originating-IP: [203.118.14.76] In-Reply-To: <52A3383F.603@gondrom.org> References: <52A3383F.603@gondrom.org> Date: Sat, 7 Dec 2013 15:06:36 +0000 Message-ID: From: Ralf Skyper Kaiser To: Tobias Gondrom Content-Type: multipart/alternative; boundary=089e0158aabaeba03604ecf31b97 Cc: websec@ietf.org Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 15:06:41 -0000 --089e0158aabaeba03604ecf31b97 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Dec 7, 2013 at 3:01 PM, Tobias Gondrom wrote: > Hi Ralf, > > trying to understand what functionality you are seeking. > Should this be: > a) only a pinned "announcement" of the supported cipher suites on the > server or > b) "enforced" on the server? > That is open for discussion. My personal preference is that server announces a set of 'STRONG' ciphers to the client. The client will fail to connect on future connections if none of the announced ciphers is no longer available (downgrade attack under way). > > In case of b) would this mean that the server fails any insecure cipher > connection attempts. > > Best regards, Tobias > > > Ps.: btw. on a personal note: I found that the underlying paradigm we had > in browser web servers of "weak encryption would be better than no > encryption" from back in the day of weak algorithms due to export > regulations in the US is part of or even the root of the problem. IMHO this > allows the downgrading attacks. In my view we should on server side shift > to a paradigm of "either strong encryption or no encryption at all". > I'm with you on this one. The big corporates who value their customers (including the 5% still using SSLv2/v3) are not. Currently the 95% of users are taking a security hit to let the 5% of all users still connect to the websites. It will be like this for the foreseeable future :/ regards, ralf --089e0158aabaeba03604ecf31b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Sat, Dec 7, 2013 at 3:01 PM, Tobias Gondrom <tobias= .gondrom@gondrom.org> wrote:
=20 =20 =20
Hi Ralf,

trying to understand what functionality you are seeking.
Should this be:
a) only a pinned "announcement" of the supported cipher sui= tes on the server or
b) "enforced" on the server?
<= div>
That is open for discussion. My personal preference is t= hat server announces a set of 'STRONG' ciphers
to the client. Th= e client will fail to connect on future connections if none of the announce= d ciphers is no
longer available (downgrade attack under way).

=A0

In case of b) would this mean that the server fails any insecure cipher connection attempts.

Best regards, Tobias


Ps.: btw. on a personal note: I found that the underlying paradigm we had in browser web servers of "weak encryption would be bette= r than no encryption" from back in the day of weak algorithms due = to export regulations in the US is part of or even the root of the problem. IMHO this allows the downgrading attacks. In my view we should on server side shift to a paradigm of "either strong encryption or no encryption at all".

I'm with you on this one. The big corporates who = value their customers (including the 5% still using SSLv2/v3) are not. Curr= ently the 95% of users are taking a security hit to let the 5% of all users= still connect to the websites. It will be like this for the foreseeable fu= ture :/

regards,

ralf
--089e0158aabaeba03604ecf31b97-- From skyper@thc.org Sat Dec 7 08:43:56 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7579D1AE3A1 for ; Sat, 7 Dec 2013 08:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78bxULx4QkYm for ; Sat, 7 Dec 2013 08:43:55 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E68BD1AE084 for ; Sat, 7 Dec 2013 08:43:54 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so3486615iec.37 for ; Sat, 07 Dec 2013 08:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j6I3XIl0BS1/yxzBuzfgYGzze7PJInj0/nR7wCAnP0o=; b=SadKZYoVhek7IL/JJM3SqEKPFNsiUXM0f8TmETMEAGBIh9+pFTBhZQllJ3wtFT/QGJ 3mkFDLBoI6qHwfSCPFrfPLSSKTLdLRcJxke4kj3VHA7wlrB5X4VUPF8ME1TPZ5aATnqT GzOlOeD1aUGTBD9R3WmhaW0m/+90FcnJbg/88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j6I3XIl0BS1/yxzBuzfgYGzze7PJInj0/nR7wCAnP0o=; b=GIbhQegANvNJJc9NJJiIH55kW/FgpkNXxVgwyp3kkalcJlKP4QfRSi8qTr2bxQgAcS IZ47oTZXMhjaD5hjpjK6YCYaI9DJ71TmydVKlh4YD3edKlSr0yjsK/UYi+7yS6B8dvJp hvMSZGbVff+BSlMjS3QwYuzibOSI4oNtdrBYt4U1NwLI0buGEBwd6tUdmxjXk81TN4/L ahih/6CKxFX2bTeRERKVLbte5rhDD4geZon5hAlIZ0uAr2z8852Tb3oxgFd3a1N484xJ MGMgPo60tfGM+itv/LaQN3kZOf7ppY+O0WV5mfL21cv+oc4sHlMcSCxq8vXRGfkbAUXd cEsQ== X-Gm-Message-State: ALoCoQlxLlltDeNJ1cm9E4WfhG5RtzVP+l0xDaErOP4U1e9w2Ge+SO+00r2LsuwZBapYXG6rr/Xi MIME-Version: 1.0 X-Received: by 10.42.118.14 with SMTP id v14mr306832icq.73.1386434629570; Sat, 07 Dec 2013 08:43:49 -0800 (PST) Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 08:43:49 -0800 (PST) X-Originating-IP: [213.52.184.7] In-Reply-To: <52A33D0B.7050102@gondrom.org> References: <52A3383F.603@gondrom.org> <52A33D0B.7050102@gondrom.org> Date: Sat, 7 Dec 2013 16:43:49 +0000 Message-ID: From: Ralf Skyper Kaiser To: Tobias Gondrom Content-Type: multipart/alternative; boundary=90e6ba613ea299bdcd04ecf47719 Cc: websec@ietf.org Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 16:43:56 -0000 --90e6ba613ea299bdcd04ecf47719 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 7, 2013 at 3:21 PM, Tobias Gondrom wrote: > On 07/12/13 15:06, Ralf Skyper Kaiser wrote: > > Hi, > That is open for discussion. My personal preference is that server > announces a set of 'STRONG' ciphers > to the client. The client will fail to connect on future connections if > none of the announced ciphers is no > longer available (downgrade attack under way). > > > [...] > > Maybe one question: as the browser already has the information about all > cipher suites offered in a TLS connection and could possible cache this > information from previous connections already without pinning. Would > pinning this via an http header or file add much value over this? > > What do you think? > > My feeling is that the server should announce to the client that CIPHER-SUITE-pinning is supported. The client should only pin the cipher suite if it has been announced by the server (similar to certificate pinning). Using the cache to determine which cipher to use might not be sufficient. The ServerHello only contains 1 cipher that the server picked from the ClientHello. In this case the server admin would have no chance to upgrade to a stronger cipher. Instead the server should send a list of 'preferred strong ciphers' to the client. If the client (TLS connection) is not using any of these ciphers then the connection should fail. If the client uses one of these ciphers then the client should pin the 'preferred strong cipher' list. The pinned list should be updated on every successful connection. For future communication the client should fail the connection if the negotiated TLS cipher is not part of the pinned ' preferred strong cipher' list. This would allow the server admin to add new and stronger ciphers to the list and slowly remove old or broken ciphers. regards, ralf --90e6ba613ea299bdcd04ecf47719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Dec 7, 2013 at 3:21 PM, Tobias Gondrom &l= t;tobias.go= ndrom@gondrom.org> wrote:
=20 =20 =20
On 07/12/13 15:06, Ralf Skyper Kaiser wrote:
Hi,
That is open for discussion. My personal= preference is that server announces a set of 'STRONG' ciphers
to the client. The client will fail to connect on future connections if none of the announced ciphers is no
longer available (downgrade attack under way).

[...]
=A0

Maybe one question: as the browser already has the information about all cipher suites offered in a TLS connection and could possible cache this information from previous connections already without pinning. Would pinning this via an http header or file add much value over this?

What do you think?


My feeling is that the serve= r should announce to the client that CIPHER-SUITE-pinning is supported. The= client should only pin the cipher suite if it has been announced by the se= rver (similar to certificate pinning).

Using the cache to determine which cipher to use might not b= e sufficient. The ServerHello only contains 1 cipher that the server picked= from the ClientHello. In this case the server admin would have no chance t= o upgrade to a stronger cipher.

Instead the server should send a list of 'preferred stro= ng ciphers' to the client. If the client (TLS connection) is not using = any of these ciphers then the connection should fail.

If the client = uses one of these ciphers then the client should pin the 'preferred str= ong cipher' list. The pinned list should be updated on every successful= connection.

For future communication the client should fail the connection if the n= egotiated TLS cipher is not part of the pinned ' preferred strong ciphe= r' list.

This would allow= the server admin to add new and stronger ciphers to the list and slowly re= move old or broken ciphers.

regards,

ralf

--90e6ba613ea299bdcd04ecf47719-- From agl@google.com Sat Dec 7 08:49:07 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDB91AE3AC for ; Sat, 7 Dec 2013 08:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNhQki5Gghdf for ; Sat, 7 Dec 2013 08:49:06 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7D61AE3A1 for ; Sat, 7 Dec 2013 08:49:06 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id jx11so2117065veb.6 for ; Sat, 07 Dec 2013 08:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bSmuTN7DCbSiuhYwE0QfneUVlJSqx5Dru4SmtBZKRAM=; b=cTAHcRpvyNrUV8y1VWTyVssQxXsesqihGBCEFqaZjinop/3VaIRgD0oarIlUNZX9Xb IxWVDu7luoW9apzEAxtUq4+CuoMFOcSjtnsogURcOxKA1hCX3sXYwJqIdUCYbRmPbz11 nubKihjEkDWCtBGdTIJYtsvzvkxsmR2LhE8xqooSgCCRfZ7Rg0ORORVVIr8ObPi6pXo+ hgXLD3wRix0B/nwwqBlqk9pbECLKVHus5vVGxdrTw3SxEgemTPJ1vsvsWAADoSImlGM9 lM8NMdi8YrCDaDAU8S2y5HBCyHddTUDlQi+/jL7nBRYZ/ZVnjlKMK57blTgdV3mc1y/Z YUyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bSmuTN7DCbSiuhYwE0QfneUVlJSqx5Dru4SmtBZKRAM=; b=kpUaOwLLcj0nmbkfx05kp/eXnbLl2sfvtCkFDHtSkgotOXItnqUhUcxM0wcnejHqr+ Bjg+XwcheKOhGbW5E1WRI7coGoowqvNT0n81mNDsiJ2BHpu43XDUhFFnPkuiZ/MswrM9 sMJiY9egPQ9FhlpP+FDCdie3IGjPZPsEGSLGEGQFKhV20kalDbUV18I1X6+lLG18hGEz mOpuox2cgExmkFnPgJvnyRnEBSeo3zn4da2qHpNDGDob3q9TaxML0nuvlbmFRWinW2vv qj2sQWodYraCmjB1eU3QyTqDk9HQzqL6vhhu62kjqusH/bFN+wOEFuKGxuobS0cq/U9O vTkw== X-Gm-Message-State: ALoCoQleqMjPYwDCmQ8xWsnBBd0Zrkxzo+rMzGwNiQ0ba6P2XUfygrDuaLHXNDSqSbhaOG8ihFdGJmF0wfb9exFX5gtiOkzhzTRFe9pYNaLwO6XTT+LviNosIcYduZavgLdsxm0JurW408wdyEgrbJ+7M0Ch+Q7baP76Xw/n13DHz6CaWGEIsoU3D9yj+NllQWmjs3hIg+JZ X-Received: by 10.52.50.177 with SMTP id d17mr5032168vdo.23.1386434941715; Sat, 07 Dec 2013 08:49:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Sat, 7 Dec 2013 08:48:40 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Sat, 7 Dec 2013 11:48:40 -0500 Message-ID: To: Ralf Skyper Kaiser Content-Type: text/plain; charset=UTF-8 Cc: "websec@ietf.org" Subject: Re: [websec] On pinning of the TLS version X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 16:49:07 -0000 On Sat, Dec 7, 2013 at 9:24 AM, Ralf Skyper Kaiser wrote: > Please discuss. Opinions welcome. The point of the message that you cited as [1] was that we tried TLS version pinning and it proved to be undeployable because of buggy MITM proxies. Hence, part of the motivation for adding TLS_FALLBACK_SCSV. Cheers AGL From agl@google.com Sat Dec 7 09:55:10 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39A71AE2FE for ; Sat, 7 Dec 2013 09:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.119 X-Spam-Level: ** X-Spam-Status: No, score=2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FSL_HELO_FAKE=3.499, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HH75tz6rBQu for ; Sat, 7 Dec 2013 09:55:09 -0800 (PST) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9C61ADF99 for ; Sat, 7 Dec 2013 09:55:09 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so1609307qeb.34 for ; Sat, 07 Dec 2013 09:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mXpa97fjIw1KLt1PVJUkUul/wA1kwaPvGTPq+LxuAJ0=; b=ffeylOnRct8Qs43dC2b30vRH4xuajkAH4JxXsjWyj9b37WnapbWYh28lYF3YXrercp 2kufAl5FFgjf5Te6D8ncgBHjOs4VQ503Kyi1x6ZzvseYdUbexgRZ4PDnmfCH/j+gDHZ0 TdVBVVB8BHqDdzO/TYDCkXvw3g7SZ6iXct1eAkVHhYoEEiybsD0l7/geXgEnFpzmWrVs Pgy772eSW5t4KQV+DCIY7RZKJKfSlBjxdSwXnFVMViTOWTyErHItKlLT88b1EkEm1n9B CTNJlMZU8/+a4XkbLxsUADmKOx8VaBafxQ13GGukhTLhqktuo7mRNcRU7qCMqGj+TwBr o30w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=mXpa97fjIw1KLt1PVJUkUul/wA1kwaPvGTPq+LxuAJ0=; b=PnLaP19W+Ob8YWpkOOnKMlj3oHHGDkiCvcSoiYUQBcEcMyn2E+KAt2EmMxBTIlmws9 vzn5TlD2GH4LFzbsAfQIkuSAzlXI0d/oMQ7Hz2x7xLNUkASNI5JnBB+9VFlMwV/gttEI 0r3bJUCRyrlQvj8TA+rth6erdfqSvZsfV00tTbprGbEYm7BukfidaC/P7AqihzazJThv i6xJP9YFxq7CNr70YxloLpmqmEOw1L8KfZJ4zdebq5QmKbkeZnPUHx5Y4a9F8Vj6j3R0 R5J7UwhG0rPo9GuJ6i0VALj8XJagFmyzHyuvsTmwQ4O+W1A2Q9FpTx10tjoJcjwj2ART Vi6g== X-Gm-Message-State: ALoCoQn01vR+i9mqCqQrhHpQkTbhqAD2tafFq1/oXQyjuIsBNxcTaPlUilWMAFJfpxigeoBsMWguoU5h3oKDYym5AmkFiG0kSAq9RcVnopOMTgiBK3TbNFEOAFSqGXeZO9xclv6HqpZOJPhomqrx0e5smGY6iSrQz3aqXgW04Y+j+FTgan5+DyxoGM88scRJMrwsJWJmzOi7YlkNDRr2OXmj7TfDyQ/KfA== X-Received: by 10.224.75.9 with SMTP id w9mr18696264qaj.68.1386438904723; Sat, 07 Dec 2013 09:55:04 -0800 (PST) Received: from gmail.com ([2620:0:1003:1016:2e41:38ff:fea6:f3d7]) by mx.google.com with ESMTPSA id lc1sm9232305qeb.5.2013.12.07.09.55.04 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 07 Dec 2013 09:55:04 -0800 (PST) Date: Sat, 7 Dec 2013 12:55:02 -0500 From: Adam Langley To: websec@ietf.org Message-ID: <20131207175502.GC6068@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 17:55:10 -0000 On Sat, Dec 07, 2013 at 02:31:29PM +0000, Ralf Skyper Kaiser wrote: > To let old browsers connect to a host most hosts will support > weak or broken ciphers for the forseable future. > > A feature to pin the CIPHER SUITE would be desirable. What attacks do you believe will be prevented by this? TLS has cipher suite negotiation so weak ciphersuites will only be used if it's the best that the client and server support. TLS negotiation can be somewhat subverted by version fallback, as implemented in browsers, because certain cipher suites depend on a minimal TLS version. (I.e. AES-GCM needs 1.2 and ECDHE suites need 1.0.) However the solution to that is to solve fallback issues. We've tried just requiring certain TLS versions for servers that we know support it and that didn't work because there are lots of buggy MITM boxes. So I'm trying an SCSV now: https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 Cheers AGL From agl@google.com Sat Dec 7 13:17:35 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE41AE3E5 for ; Sat, 7 Dec 2013 13:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjTa5F078yhO for ; Sat, 7 Dec 2013 13:17:34 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 385801AE100 for ; Sat, 7 Dec 2013 13:17:33 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jw12so2247638veb.24 for ; Sat, 07 Dec 2013 13:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EUuJHa8kOBzM4Vh5t17bQgLOyKmQ++scgC38FnLsXh0=; b=KF6FG/KzYZSGonmI39xPzkPUAc/8+dN6q7U5pMnqWM2dhFDvKctb5flYFZhlM5glEg j13bEvgKkCDCo/gG5r79ARCdE3qOvU0RlY5dllmB1QuKAUMl2f1L0JsFBCNe+JVk3+RS GnoY607hqhPOIJB5sjNVdnJap3v2KOfAbtwLncE1vnHOUONoVB7r9Q12sYlNB7bvnSLz RKwcHRY85XSbTOSthlbO4ux1lnONdhrzsW7H/fNvCsTIr2jU3E5kzOBa0mkYmX8Ot820 BODTUWLfFRAltHradTGSgBugVk3T3HIsHPCsuAETf1++nd8JtJSh7V1jTODtFGcDUKqh dmoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EUuJHa8kOBzM4Vh5t17bQgLOyKmQ++scgC38FnLsXh0=; b=TGiR47lQQ1CbPZPwOlGwbjBIV6HriH9ExApIivYBVz5/NPRlJeaaBadtJCi5GuQiWa hRWB1kmlCaEVRc9fnJw8g2gSOhp4/FLET1uGIJOn8ThkCU8gHAySTEqDjfLR+y1bAyZH sKOFcnpob9+lrF1CEq0awhLot4+J2pcXcarE8nVxHk5zOsf4EeLIebNSMUvOsWY92z2W koH3sK9ij9pWVuX9iY1UMiCXcJcDnnctnlKO6kAiG0IRXvJ4+zd21P0HascH8R7gwVIM j63AqQACpg8EvEhlseUcBb2dI+nWJyhw0V7kNdLTtrzpkdt7pGpr2Ix09QZydg9ECdvg kVcA== X-Gm-Message-State: ALoCoQngIDzI3kAl3YSnucqYHq05ieiNeQ41iMvZe2VOy9qtGnqnWOntromS88gPxLSbfnirzO459WbQRw/97AXWgdJwJZr2R/kuuyAtfEedemU811n8n+7jm1SMUq/VNEHTA+GUMhuirjsd+2Fj1CURGWAVjdO4NdS65M2/Tgtqjvm8eGnS2CTyfKQeuIqhxOHiRU32P/8Q X-Received: by 10.52.113.97 with SMTP id ix1mr5378023vdb.9.1386451049672; Sat, 07 Dec 2013 13:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Sat, 7 Dec 2013 13:17:09 -0800 (PST) In-Reply-To: <52A38EC5.2@gondrom.org> References: <20131207175502.GC6068@gmail.com> <52A38EC5.2@gondrom.org> From: Adam Langley Date: Sat, 7 Dec 2013 16:17:09 -0500 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Cc: "websec@ietf.org" Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 21:17:35 -0000 On Sat, Dec 7, 2013 at 4:10 PM, Tobias Gondrom wrote: > I am not sure that the main mechanism of the ID of merely "the client > indicating that the current connection attempt is only a fallback" is > sufficient to protect against downgrading. It could help a little, but > is potentially limited, as evil MitM boxes can potentially strip out > parameters from the requests. > E.g. Moxie's SSL strip tool does already strip out various http headers, > secure cookie flags, etc. > Having said that, I can still see that scsv could be useful. > Just my 5cents, Tobias An SSL MITM (i.e. one with a valid certificate for the site in question) can certainly still implement downgrade. But, if it has a certificate for the site in question, then it can do anything it wants really. A MITM without a valid certificate can tweak the ClientHello, but the hash of the handshake is verified by the Finished messages and so any changes will be discovered. SSL strip certainly still works in the same way that it always has: by avoiding TLS completely. But we already have HSTS to address that. Cheers AGL From tobias.gondrom@gondrom.org Thu Dec 12 05:14:02 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD391AE2B7 for ; Thu, 12 Dec 2013 05:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.597 X-Spam-Level: X-Spam-Status: No, score=-98.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bAsZDh1oK22 for ; Thu, 12 Dec 2013 05:14:01 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8CA1AE2A5 for ; Thu, 12 Dec 2013 05:14:00 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=29Utbhydoj6l2aOz5CTAQOhSyiZlJ35yIrkok6fEZv1PaOXYO5GTV8FtPB/NhWHZ6YMpCCgbXtXDCndD60pDih6z3iJgQ7YKAKwkwSrvNDPhumb1cLfa4trxQljTMGfBncgQw+4dpW+WO0pSMYzvHKK8ah3anWvo6uyKjEyhIes=; h=X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network Received: from [192.168.1.100] (2e40a8f0.skybroadband.com [46.64.168.240]) by www.gondrom.org (Postfix) with ESMTPSA id 7BDCA15390058; Sat, 7 Dec 2013 22:10:29 +0100 (CET) Message-ID: <52A38EC5.2@gondrom.org> Date: Sat, 07 Dec 2013 21:10:29 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: agl@google.com, websec@ietf.org X-Priority: 4 (Low) References: <20131207175502.GC6068@gmail.com> In-Reply-To: <20131207175502.GC6068@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:14:02 -0000 On 07/12/13 17:55, Adam Langley wrote: > On Sat, Dec 07, 2013 at 02:31:29PM +0000, Ralf Skyper Kaiser wrote: >> To let old browsers connect to a host most hosts will support >> weak or broken ciphers for the forseable future. >> >> A feature to pin the CIPHER SUITE would be desirable. > What attacks do you believe will be prevented by this? TLS has cipher > suite negotiation so weak ciphersuites will only be used if it's the > best that the client and server support. > > TLS negotiation can be somewhat subverted by version fallback, as > implemented in browsers, because certain cipher suites depend on a > minimal TLS version. (I.e. AES-GCM needs 1.2 and ECDHE suites need 1.0.) > > However the solution to that is to solve fallback issues. We've tried > just requiring certain TLS versions for servers that we know support it > and that didn't work because there are lots of buggy MITM boxes. So I'm > trying an SCSV now: > https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 Hm, just a quick thought: I am not sure that the main mechanism of the ID of merely "the client indicating that the current connection attempt is only a fallback" is sufficient to protect against downgrading. It could help a little, but is potentially limited, as evil MitM boxes can potentially strip out parameters from the requests. E.g. Moxie's SSL strip tool does already strip out various http headers, secure cookie flags, etc. Having said that, I can still see that scsv could be useful. Just my 5cents, Tobias Ps.: IMHO the benefit of pinning would be that once you have the pin, your browser is resistant to downgrading as it _knows_ that stronger versions/algorithms are in fact available. It might actually even be worthwhile considering to have both scsv and pinning in tandem. > > Cheers > > AGL > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Thu Dec 12 05:14:02 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7781AE2A5 for ; Thu, 12 Dec 2013 05:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.596 X-Spam-Level: X-Spam-Status: No, score=-98.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDEKSO99AhoE for ; Thu, 12 Dec 2013 05:14:01 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 97F211ACCE7 for ; Thu, 12 Dec 2013 05:14:00 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=DqTCusSKUbdd/5s8m7+pL8odVfL1K6saQExK+xKYMwIO17h/Q4aEk4hMPCDL2Pv2UzML3FbetJ+b5PfsU4h5k2dNo5oFsbUE8jMw/snNPhVX/fFRyGoKKMz1ZHXuQs6B0JQYY6xqdahVTt6FBhmtiNaFtI44/Bb4C/XBuK0fSA0=; h=X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network Received: from [192.168.1.100] (2e40a8f0.skybroadband.com [46.64.168.240]) by www.gondrom.org (Postfix) with ESMTPSA id F2AFA1539005C; Sat, 7 Dec 2013 16:21:47 +0100 (CET) Message-ID: <52A33D0B.7050102@gondrom.org> Date: Sat, 07 Dec 2013 15:21:47 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: skyper@thc.org References: <52A3383F.603@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070407020008000608000405" Cc: websec@ietf.org Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:14:03 -0000 This is a multi-part message in MIME format. --------------070407020008000608000405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/12/13 15:06, Ralf Skyper Kaiser wrote: > Hi, > > > On Sat, Dec 7, 2013 at 3:01 PM, Tobias Gondrom > > wrote: > > Hi Ralf, > > trying to understand what functionality you are seeking. > Should this be: > a) only a pinned "announcement" of the supported cipher suites on > the server or > b) "enforced" on the server? > > > That is open for discussion. My personal preference is that server > announces a set of 'STRONG' ciphers > to the client. The client will fail to connect on future connections > if none of the announced ciphers is no > longer available (downgrade attack under way). I see your point. Like a "soft migration" patter for strong clients, while keeping old browsers accessible. I understand that this would only be enforced on the client and not on the server (noting your comment at the end). So, it is worth noting that this would still have some residual risks with all the old browsers and expired pins (which may be acceptable). Pinning this information in the browser could indeed help against a number of attack vectors in face of corporations unwilling to shut down the old algorithms / versions. As mentioned the procedure of pinning itself could be achieved relatively easy. Maybe one question: as the browser already has the information about all cipher suites offered in a TLS connection and could possible cache this information from previous connections already without pinning. Would pinning this via an http header or file add much value over this? What do you think? Cheers, Tobias > > > > > In case of b) would this mean that the server fails any insecure > cipher connection attempts. > > Best regards, Tobias > > > Ps.: btw. on a personal note: I found that the underlying paradigm > we had in browser web servers of "weak encryption would be better > than no encryption" from back in the day of weak algorithms due to > export regulations in the US is part of or even the root of the > problem. IMHO this allows the downgrading attacks. In my view we > should on server side shift to a paradigm of "either strong > encryption or no encryption at all". > > > I'm with you on this one. The big corporates who value their customers > (including the 5% still using SSLv2/v3) are not. Currently the 95% of > users are taking a security hit to let the 5% of all users still > connect to the websites. It will be like this for the foreseeable > future :/ > > regards, > > ralf > --------------070407020008000608000405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/12/13 15:06, Ralf Skyper Kaiser wrote:
Hi,


On Sat, Dec 7, 2013 at 3:01 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
Hi Ralf,

trying to understand what functionality you are seeking.
Should this be:
a) only a pinned "announcement" of the supported cipher suites on the server or
b) "enforced" on the server?

That is open for discussion. My personal preference is that server announces a set of 'STRONG' ciphers
to the client. The client will fail to connect on future connections if none of the announced ciphers is no
longer available (downgrade attack under way).

I see your point. Like a "soft migration" patter for strong clients, while keeping old browsers accessible.
I understand that this would only be enforced on the client and not on the server (noting your comment at the end). So, it is worth noting that this would still have some residual risks with all the old browsers and expired pins (which may be acceptable).
Pinning this information in the browser could indeed help against a number of attack vectors in face of corporations unwilling to shut down the old algorithms / versions. 
As mentioned the procedure of pinning itself could be achieved relatively easy.

Maybe one question: as the browser already has the information about all cipher suites offered in a TLS connection and could possible cache this information from previous connections already without pinning. Would pinning this via an http header or file add much value over this?

What do you think?

Cheers, Tobias




 

In case of b) would this mean that the server fails any insecure cipher connection attempts.

Best regards, Tobias


Ps.: btw. on a personal note: I found that the underlying paradigm we had in browser web servers of "weak encryption would be better than no encryption" from back in the day of weak algorithms due to export regulations in the US is part of or even the root of the problem. IMHO this allows the downgrading attacks. In my view we should on server side shift to a paradigm of "either strong encryption or no encryption at all".

I'm with you on this one. The big corporates who value their customers (including the 5% still using SSLv2/v3) are not. Currently the 95% of users are taking a security hit to let the 5% of all users still connect to the websites. It will be like this for the foreseeable future :/

regards,

ralf


--------------070407020008000608000405-- From tobias.gondrom@gondrom.org Thu Dec 12 05:29:02 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494591AE2B5 for ; Thu, 12 Dec 2013 05:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.661 X-Spam-Level: X-Spam-Status: No, score=-100.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYln0Z3MlQCN for ; Thu, 12 Dec 2013 05:29:00 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 651381AE281 for ; Thu, 12 Dec 2013 05:29:00 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BCOJ7i1w7YMDP+GVuv+DwCfyy9Nnn7Jvcl0B4XK3xFLP1vNfpn9zt17J6SvmizGrVcR8pqHXeKcx5W+L7373Q649Se1wuo+ykf5xveYJD6osrwKJamLzfBGC8fgzsW4kD/kEOiifbAHbyKKbwoKbSOJJWc9XZ7ra/UhUycsLsTw=; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:X-Forwarded-Message-Id:Content-Type; Received: from [192.168.1.100] (2e40a8f0.skybroadband.com [46.64.168.240]) by www.gondrom.org (Postfix) with ESMTPSA id EC3231539005F for ; Tue, 10 Dec 2013 20:19:31 +0100 (CET) Message-ID: <52A76943.5000706@gondrom.org> Date: Tue, 10 Dec 2013 19:19:31 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <529E4285.30407@gondrom.org> In-Reply-To: <529E4285.30407@gondrom.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <529E4285.30407@gondrom.org> Content-Type: multipart/alternative; boundary="------------070605030306060701050707" Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:29:02 -0000 This is a multi-part message in MIME format. --------------070605030306060701050707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, re-send, as I just received an error message from the websec-mailing-list mail-server on not delivering this email on Dec-3. Best regards, Tobias -------- Original Message -------- Subject: Re: [websec] HPKP: The strict directive and TLS proxies Date: Tue, 03 Dec 2013 20:43:49 +0000 From: Tobias Gondrom To: palmer@google.com, synp71@live.com CC: websec@ietf.org Hi Chris, Yes, please roll the updates into a new version and post it as soon as possible. Please remember version-numbers are cheap, so rather update often. Plus, I would really like to give the doc in its final state another good read before we go to IESG. regarding: SHA-1/SHA-256: please consider that we should have hash agility whenever possible. There will be SHA-3 and future ones.... Best regards, Tobias On 03/12/13 00:24, Chris Palmer wrote: > Hi all, > > Thanks for the discussion. We are going to roll another version of the > draft to clarify the confusing things. Also, my semi-off-the-cuff > thoughts on some of the issues: > > Strict: I support what Yoav calls option (B): Drop "strict" - not > interested in local policy. (It has only been a source of confusion. > Let's keep things simple.) > > SHA-1: Let's just get rid of it. SHA-256 only; MUST implement; no > truncation. (Maximum simplicity.) > > Non-overridable failure mode on pin validation failure: To make HPKP > less of a footgun, I support saying that UAs SHOULD disallow user > override, or SHOULD provide some way of telling the user that pin > validation failure happened. But no longer MUST. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------070605030306060701050707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,
re-send, as I just received an error message from the websec-mailing-list mail-server on not delivering this email on Dec-3. 
Best regards, Tobias


-------- Original Message --------
Subject: Re: [websec] HPKP: The strict directive and TLS proxies
Date: Tue, 03 Dec 2013 20:43:49 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
To: palmer@google.com, synp71@live.com
CC: websec@ietf.org 


Hi Chris,

<hat=WG chair>
Yes, please roll the updates into a new version and post it as soon as
possible.
Please remember version-numbers are cheap, so rather update often.
Plus, I would really like to give the doc in its final state another
good read before we go to IESG.
</hat>


regarding: SHA-1/SHA-256: please consider that we should have hash
agility whenever possible. There will be SHA-3 and future ones....

Best regards, Tobias




On 03/12/13 00:24, Chris Palmer wrote:
> Hi all,
>
> Thanks for the discussion. We are going to roll another version of the
> draft to clarify the confusing things. Also, my semi-off-the-cuff
> thoughts on some of the issues:
>
> Strict: I support what Yoav calls option (B): Drop "strict" - not
> interested in local policy. (It has only been a source of confusion.
> Let's keep things simple.)
>
> SHA-1: Let's just get rid of it. SHA-256 only; MUST implement; no
> truncation. (Maximum simplicity.)
>
> Non-overridable failure mode on pin validation failure: To make HPKP
> less of a footgun, I support saying that UAs SHOULD disallow user
> override, or SHOULD provide some way of telling the user that pin
> validation failure happened. But no longer MUST.
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec


--------------070605030306060701050707-- From tobias.gondrom@gondrom.org Thu Dec 12 05:59:06 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2751AE2ED for ; Thu, 12 Dec 2013 05:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.596 X-Spam-Level: X-Spam-Status: No, score=-98.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OksvXpp5qok for ; Thu, 12 Dec 2013 05:59:01 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id CE4F71AE2E8 for ; Thu, 12 Dec 2013 05:59:00 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=PmZO2vWQ7BLV//VfgS3x9TBSVR8bb6UHzzgY7NYZdtDzVeqmqQz+8OHGKfVGzqBWSNBcETsh/HB96fDCHbJmOyCMSmRelGvPq6NZ2A9k0ItnNDYc+FqOu1Epfqjwxmz6sRt513sFIUHktAC3WftO2zze9PR/VKx/wHp/zYS6VRk=; h=X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network Received: from [192.168.1.100] (2e40a8f0.skybroadband.com [46.64.168.240]) by www.gondrom.org (Postfix) with ESMTPSA id B432515390056; Sat, 7 Dec 2013 15:53:22 +0100 (CET) Message-ID: <52A33662.1040903@gondrom.org> Date: Sat, 07 Dec 2013 14:53:22 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: skyper@thc.org, websec@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070405080402010401020707" Subject: Re: [websec] On pinning of the TLS version X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:59:06 -0000 This is a multi-part message in MIME format. --------------070405080402010401020707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Ralf, thanks for posting this here. To pin a host to a TLS version would indeed be fairly easy. But a small question: I thought "downgrading attacks" would have been addressed by configuring the server/host to only accept certain strong ciphers for the TLS/SSL connection. And basically to configure the web server to no longer support/accept weak ciphers. Wouldn't we want to do this also with the TLS version? Am I missing something? All the best, Tobias On 07/12/13 14:24, Ralf Skyper Kaiser wrote: > Hi, > > The TLS-WG is discussing a method to prevent a fallback attack in TLS. [1] > > "Sad as it is, in order to work on public Internet all browsers > implement TLS fallback: in the event of a handshake failure they will > retry the connection with a lesser SSL/TLS version." > > The proposed solution is complex and requires protocol changes. > > A different solution is to pin the TLS version to the host. Once the > TLS version is > pinned any downgrade attack to a lower TLS version would fail. > > This feature could be optional or mandatory to be configured on the host. > > Please discuss. Opinions welcome. > > > regards, > > ralf > > [1] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------070405080402010401020707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ralf,

thanks for posting this here.

To pin a host to a TLS version would indeed be fairly easy.
But a small question: I thought "downgrading attacks" would have been addressed by configuring the server/host to only accept certain strong ciphers for the TLS/SSL connection. And basically to configure the web server to no longer support/accept weak ciphers. Wouldn't we want to do this also with the TLS version?

Am I missing something?

All the best, Tobias



On 07/12/13 14:24, Ralf Skyper Kaiser wrote:
Hi,

The TLS-WG is discussing a method to prevent a fallback attack in TLS. [1]

"Sad as it is, in order to work on public Internet all browsers
implement TLS fallback: in the event of a handshake failure they will
retry the connection with a lesser SSL/TLS version."

The proposed solution is complex and requires protocol changes.

A different solution is to pin the TLS version to the host. Once the TLS version is
pinned any downgrade attack to a lower TLS version would fail.

This feature could be optional or mandatory to be configured on the host.

Please discuss. Opinions welcome.


regards,

ralf

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html



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

--------------070405080402010401020707-- From tobias.gondrom@gondrom.org Thu Dec 12 06:04:03 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A9C1AE300 for ; Thu, 12 Dec 2013 06:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amvotH1iYGsT for ; Thu, 12 Dec 2013 06:04:01 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 043A01AE2ED for ; Thu, 12 Dec 2013 06:04:01 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=wlZlqyZbLvwpR+/EBInvnwcPOH8vl02EW+bzo7iQfJNPDpQ+07FHhrSqdYhpzw3T20CikR1tqX6/Xgn9BuzKfSD4KEBtyEGieR6o7knGCWYhwSdy6K9E5stb21ndz7w3ZS13I/xuRaoxTA3VMrNppa2AAel2b17tCXMh6HFjhGw=; h=X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network Received: from [192.168.1.100] (2e40a8f0.skybroadband.com [46.64.168.240]) by www.gondrom.org (Postfix) with ESMTPSA id 2A34B1539005B; Sat, 7 Dec 2013 16:01:20 +0100 (CET) Message-ID: <52A3383F.603@gondrom.org> Date: Sat, 07 Dec 2013 15:01:19 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: skyper@thc.org, websec@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070609040300030507080409" Subject: Re: [websec] On CIPHER-SUITE pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 14:04:03 -0000 This is a multi-part message in MIME format. --------------070609040300030507080409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Ralf, trying to understand what functionality you are seeking. Should this be: a) only a pinned "announcement" of the supported cipher suites on the server or b) "enforced" on the server? In case of b) would this mean that the server fails any insecure cipher connection attempts. Best regards, Tobias Ps.: btw. on a personal note: I found that the underlying paradigm we had in browser web servers of "weak encryption would be better than no encryption" from back in the day of weak algorithms due to export regulations in the US is part of or even the root of the problem. IMHO this allows the downgrading attacks. In my view we should on server side shift to a paradigm of "either strong encryption or no encryption at all". On 07/12/13 14:31, Ralf Skyper Kaiser wrote: > Hi, > > To let old browsers connect to a host most hosts will support > weak or broken ciphers for the forseable future. > > A feature to pin the CIPHER SUITE would be desirable. > > It would allow a client to learn a set of 'strong' ciphers available > on client and host side. Any downgrade attack to a weaker cipher > would fail. > > This feature could be optional or mandatory to be configured on the host. > > Please discuss. Opinions welcome. > > regards, > > ralf > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------070609040300030507080409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ralf,

trying to understand what functionality you are seeking.
Should this be:
a) only a pinned "announcement" of the supported cipher suites on the server or
b) "enforced" on the server?

In case of b) would this mean that the server fails any insecure cipher connection attempts.

Best regards, Tobias


Ps.: btw. on a personal note: I found that the underlying paradigm we had in browser web servers of "weak encryption would be better than no encryption" from back in the day of weak algorithms due to export regulations in the US is part of or even the root of the problem. IMHO this allows the downgrading attacks. In my view we should on server side shift to a paradigm of "either strong encryption or no encryption at all".


On 07/12/13 14:31, Ralf Skyper Kaiser wrote:
Hi,

To let old browsers connect to a host most hosts will support
weak or broken ciphers for the forseable future.

A feature to pin the CIPHER SUITE would be desirable.

It would allow a client to learn a set of 'strong' ciphers available
on client and host side. Any downgrade attack to a weaker cipher
would fail.

This feature could be optional or mandatory to be configured on the host.

Please discuss. Opinions welcome.

regards,

ralf


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

--------------070609040300030507080409--