From stpeter@stpeter.im Tue Jun 4 16:25:48 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60CE21F994D for ; Tue, 4 Jun 2013 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VJOfU62bdIE for ; Tue, 4 Jun 2013 16:24:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB1A221F8459 for ; Tue, 4 Jun 2013 16:24:41 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D678741240; Tue, 4 Jun 2013 17:37:25 -0600 (MDT) Message-ID: <51AE771F.6080005@stpeter.im> Date: Tue, 04 Jun 2013 17:24:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: posh@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [POSH] PKIX Over Secure HTTP (POSH) X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:25:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Miller and I have been working on a specification for "PKIX Over Secure HTTP" (POSH), which aims to make it easier to ensure proper TLS server identity checking in multi-tenanted environments (where it's basically impossible right now): https://datatracker.ietf.org/doc/draft-miller-posh/ As the abstract says: This document defines two methods that make it easier to deploy certificates for proper server identity checking in application protocols. The first method enables a TLS client to obtain a TLS server's end-entity certificate over secure HTTP as an alternative to standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based Authentication of Named Entities (DANE). The second method enables a source domain to securely delegate an application to a derived domain using HTTPS redirects. We love PKIX (really!), we love DNSSEC, and we love DANE (which solves some of the same problems for some application protocols as POSH does). However, we want a technology that can be deployed more quickly than DANE in order to solve pressing operational security issues with standard PKIX in multi-tenanted environments. This effort emerged from the XMPP community, but we have heard from folks working on other application technologies that it might be useful for things like IMAP and SMTP, thus the more generalized version of POSH that we published today (superseding draft-miller-xmpp-posh-prooftype). We are planning to hold a BoF on this topic in Berlin, but in the meantime comments are very much welcome. Please post your feedback to the new posh@ietf.org list: https://www.ietf.org/mailman/listinfo/posh Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrncfAAoJEOoGpJErxa2p91QP/3PvNnKN00cNLGAygbGKNUIV lE+MZopE0BBlpSEaf7hEBFT8uBO+e9EX4bCnV+IjRBlDU3O7W+E9qSD4FuwqRBau 9lQ1ayBt/SgOi3gkhxvwh00KfID0HAGo+09UsbLuF08TNMdOhRmng+qSXPLHmB3A FKDmHZVv7hUVz2m82HpU7ebp7Bjf/HQFOVlqg8wiXvn2imRgyRPH/7AY5tyeVk1p my0YFMdq9B/1EHqTeWMpF2sEo7vQeO59Jz3+ZuMwpXIBEUktjsLKn0jNNXtluoIk QgNJOYOA3UXsJDjZWaPwQMp2bMteZPmbS8wB08BNBOS4Y9q5WfgEUkV2xLl5yqJF SDBXmHK8kxfHPZUeUKHTuVa4kNMnK537Y4FqWt+E4Mv+dC0L3hcxj2sH/nZwRA/L A1iU438y7o1jxFWWpvqf5ekFkz4bBMEk7ZEqDaQHvyfqcnswjC27ZATd6rb1yigA qZg+NCMX3n+RlU1X7k1yQmAebZFq9WzTMFfjPcnzlIg6LRqns1Iuf/Hv2wDtpxeZ Ei2ASdusWG4PJKEOH+hoq3+w3PJqWR0AGVdTB6aAcb6yv7IdPmVJHrBLtrKbRCcz czWvvC0mEGXeu/anlVs5flQSikrSpnVe/1reKSjU7XwoWSRGEI3JMI/zLgMctxg7 hc8WGnHPzPAmbtGqzH3/ =gEbl -----END PGP SIGNATURE----- From mamille2@cisco.com Wed Jun 5 14:01:41 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6385A21E805A for ; Wed, 5 Jun 2013 14:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCx+gBxnWsye for ; Wed, 5 Jun 2013 14:01:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1420221F8EAD for ; Wed, 5 Jun 2013 14:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8486; q=dns/txt; s=iport; t=1370466094; x=1371675694; h=from:to:subject:date:message-id:mime-version; bh=h36GJBPpug6BAA3pggwYQi+LgNXsJyGOK0ddGV23W7E=; b=YzmcAh0JeOATwOJ+FxoO8DdAWEzYuelVFVNO89tDOBVMXIwuFHh7OQpQ 5wM6oEtyrfLH3EN0qlnEXGLi4iQPfmSBV71gVHSfVN16fLeCDXcK7zh2e Ua4yl5GKuMvwwOI4eOXTWwD1NMhPegsLWQrvkxA9sxnzOY8gCE3dWy8Wg I=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAM2lr1GtJV2b/2dsb2JhbABRCYMJML8/fxZtB4IlAQSBCwEqJjAnBBMIBg2Hcp0foDSNcIEKgzJhA5AAgSyXU4MPgic X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="p7s'?scan'208";a="219280567" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2013 21:01:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55L1Wsg032022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Jun 2013 21:01:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 16:01:32 -0500 From: "Matt Miller (mamille2)" To: "posh@ietf.org" Thread-Topic: BoF Charter Proposal -00 Thread-Index: AQHOYi/an7FibGZFXkWrpUojCtcORg== Date: Wed, 5 Jun 2013 21:01:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.59] Content-Type: multipart/signed; boundary="Apple-Mail=_B027E243-519D-4982-B906-898B9C94CF9A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [POSH] BoF Charter Proposal -00 X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:01:41 -0000 --Apple-Mail=_B027E243-519D-4982-B906-898B9C94CF9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the charter proposal Peter and I submitted. Any feedback would = be greatly appreciated! - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN CHARTER PROPOSAL----- Charter Proposal: PKIX Over Secure HTTP (POSH) Problem Statement Channel encryption with TLS depends on proper checking of the server's identity, as specified in RFC 2818 or RFC 6125 for PKIX certificates.=20 However, in multi-tenanted environments it is effectively impossible for a hosting service to offer the correct certificates on behalf of a=20 hosted domain, since neither party wants the hosting service to hold the=20= hosted domain's private keys. As a result, typically the hosting service=20= offers its own certificate (say, for hosting.example.net), which means=20= that TLS clients and peer servers need to "just know" that the hosted=20 domain (say, foo.example.com) is hosted at the service.=20 This situation is clearly insecure. The use of DNSSEC and DANE has the potential to solve the problem, but that potential is most likely many years from being fully realized. Hosting services and hosted domains need a method that can be deployed more quickly to overcome the lack of secure delegation on the Internet today. For a more detailed description of the problem from the perspective of a particular application protocol (XMPP), see draft-ietf-xmpp-dna. Proposed Solution POSH (PKIX Over Secure HTTP) provides a way to solve the problem, involving two interconnected aspects: 1. TLS clients and peer servers retrieve the material to be used in checking the TLS server's identity by requesting it from a well-known HTTPS URI, where the response contains one or more certificates formatted as a JSON Web Key set defined within the JOSE WG. 2. If a hosted domain securely delegates an application to a hosting service, it redirects requests for the well-known HTTPS URI to an HTTPS URI at the hosting service. For a more detailed description of the proposed solution (at least for=20= XMPP), see draft-miller-xmpp-posh-prooftype. Deliverables The group would produce a specification for POSH, and might informally provide advice about how to use the POSH technique for particular=20 application protocols. Any additional work would require a recharter. Milestones To be determined. -----END CHARTER PROPOSAL-----= --Apple-Mail=_B027E243-519D-4982-B906-898B9C94CF9A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDUyMTAx MzFaMCMGCSqGSIb3DQEJBDEWBBRDYtlhTk+t6S4TwyW31mz8RiuorDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABME RVglSWfMTUkZnbavAu1745BpeZmiVs3aMj9zocSiU8qas+D1rOTifJ6KZCRRrDtttwM6q31/dIYx woKf8dENM7x1APiE3K79bHCtw3ojuSU9LwS2gbegOuhg5z7jA/Ns7SddsvaO2Z2Fw8butxGGOp75 NcNlLGcsHjTBtdazCDbhthpyU1IAkrN2foXwfKvFZ4oOVnKsY2QbxR9RpInaqTLXWJrMZ061Of3Y y6hH04n8a0JHuf23kLWI1dBkYC1sY7zx1z7qlBOSYeQvLGNhwt1VfF8ncKSCa8ekm/U8PksH1V4z v8q75ZjI5vzr49Jhhu4FC4GLvNH5aOV5g8cAAAAAAAA= --Apple-Mail=_B027E243-519D-4982-B906-898B9C94CF9A-- From ietf-secretariat@ietf.org Tue Jun 11 14:45:22 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CBB21F99FE; Tue, 11 Jun 2013 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei5GfydCoX4f; Tue, 11 Jun 2013 14:45:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A164B21F8F6E; Tue, 11 Jun 2013 14:45:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130611214521.13673.2687.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2013 14:45:21 -0700 Cc: posh@ietf.org, stpeter@stpeter.im Subject: [POSH] New Non-WG Mailing List: posh -- Discussion about PKIX Over Secure HTTP X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 21:45:22 -0000 A new IETF non-working group email list has been created. List address: posh@ietf.org Archive: http://www.ietf.org/mail-archive/web/posh/ To subscribe: https://www.ietf.org/mailman/listinfo/posh Purpose: Discussion about PKIX Over Secure HTTP, a method for secure = delegation of application services and retrieval of end-entity certificates= over = HTTPS. For additional information, please contact the list administrators. From stpeter@stpeter.im Fri Jun 21 08:39:13 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3021F9E97; Fri, 21 Jun 2013 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyaMSoHxsc+p; Fri, 21 Jun 2013 08:39:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93A21F9EAC; Fri, 21 Jun 2013 08:39:09 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42686412C3; Fri, 21 Jun 2013 09:39:13 -0600 (MDT) Message-ID: <51C4739A.3030508@stpeter.im> Date: Fri, 21 Jun 2013 09:39:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> In-Reply-To: <20130621142331.GJ29420@mournblade.imrryr.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Viktor Dukhovni , posh@ietf.org Subject: Re: [POSH] [dane] while we're waiting for DANE deployment... X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:39:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] On 6/21/13 8:23 AM, Viktor Dukhovni wrote: > On Thu, Jun 20, 2013 at 08:02:45PM -0600, Peter Saint-Andre wrote: > >> DANE is awesome and will solve many practical challenges with >> the existing PKI (e.g., the inability to securely offer proper >> certificates for hosted domains in multi-tenanted environments). > > Isn't this *supposed* to be solved via SNI? (I personally don't > believe SNI scales, but I'm willing to go along with the idea for > argument's sake now and then). The core problem in the PKI context is that BigCompany.com isn't going to hand over its private keys to ConvenientHostingService.com, and the hosting company doesn't want those keys anyway for liability purposes. > Is it no longer controversial to say that SNI does not solve the > multi-tenant problem? If so, then I'd like to more strongly > emphasise my comments on DANE and CNAMEs. If DANE clients chase > CNAME RRs (while keeping track of DNSSEC validation at each step), > then multi-tenant deployments can avoid SNI depedence, as the TLSA > RRs would only need to be published in one place by the service > operator. Otherwise, it is not clear how DANE addresses the > multi-tenant issue. With POSH we are trying to find an interim solution to PKI issues. I *think* (although I have not yet proved it out) that DANE solves those problems, too. But the PKI problems are pressing enough that we need to solve them as soon as possible. >> Unfortunately, DANE won't be widely deployed anytime soon. (As >> one example, we're still struggling with the lack of DNS SRV >> support among domain registrars for certain major TLDs, let alone >> DNSSEC support.) > > Is the main obstacle in your view lack registrar infrastructure to > support customer DNSSEC deployment, or lack of tools for customers > to manage DNSSEC zone signing? IMHO, probably both. But I will ask some folks on the operational side to find out more. >> https://datatracker.ietf.org/doc/draft-miller-posh/ >> >> As the abstract says: >> >> This document defines two methods that make it easier to deploy >> certificates for proper server identity checking in application >> protocols. The first method enables a TLS client to obtain a >> TLS server's end-entity certificate over secure HTTP as an >> alternative to standard Public Key Infrastructure using X.509 >> (PKIX) and DNS-Based Authentication of Named Entities (DANE). >> The second method enables a source domain to securely delegate an >> application to a derived domain using HTTPS redirects. > > This requires TLS clients to also also implement HTTPS, and to > able to do PKIX validation of HTTPS peers. Yes, but we figure that such code is very widely available. > Plus additional latency to fetch the certs via HTTPS with no local > cache (as with DNS). This certainly looks unappealing from an SMTP > perspective. A happy eyeballs approach should help with latency. >> Feedback from folks in the DANE community is very much welcome on >> the posh@ietf.org list: >> >> https://www.ietf.org/mailman/listinfo/posh > > I'll take a closer look when I get a chance, but I am skeptical. Your skepticism is appreciated. > New standards take a long time from inception to wide adoption. > Software released today takes ~2-5 years to be included by O/S > distributions (if bundled as with MTAs) or upgraded by a majority > of the user base. Browsers with their independent distribution > channels are the exception, not the rule. So I think that > deployment barriers today should not overly prejudice architectural > decisions for software that will only become mainstream in ~5 > years. That is a valid point, and one that we'll need to consider at the BoF in Berlin. Pete - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRxHOaAAoJEOoGpJErxa2p6Z4P/2R2v9k2v1pVq6oQx7/GzPH2 vab6rFlPLUrPq4JuSRyspCmJcy0fOxzK5er6Mc/cE/70icEqobBDx0z4Swd/yCRm HwKkSJQFQKUI47y2GbtDcaSW3MSC09Y+9qWdiv0gLy9jInVV782tzjKGMlCgupq1 gdOfuDEcSYXorlpI1pjWKD535pO8PRz32mwXR30i8Ov6noxFEou4wTrSnQPMdDm9 RX96v5nyOvOQ9Kw1RCAGWX3GavumNzi6qG8pJDSxNnP57MHeb4eTegMfT2qzPWTs h4PbhX+mp3DIGDirf3x6aF79zia4gcL885tN0qPEDJwqAuOJ84h0BGypotjUrge/ WqYkXzQOIPo7dm+KYEWjnUF5kyuYZ1k+7mk104LDJ+Tyjq8MulXH//huXnZeh6fe 1KJcVltlzpdsxN0fzXk3KxiejADxkSRDXHnvE4Gbd49Nqeb86ORW6SBxzqbUygT2 UQ1n44WLg3eYjAH5uDVpTQzL+DNwcWrrj5b2Vh44VeOR9auBtpNR/6xWe8Yi55Ug SYn5fQ8/kBBZZ57P9vvc1jGbEqsHvz560lnbzYWS+Wekf89MboKH0Jmo425GY252 uIZkr2koOI9OwS3RDIOWV5v/GsDUlUbmMt/y3G4RwFfCmpxUew4rSr4m7tdRylHA 19z4KBbbcsmh4v2HvF9K =Ygon -----END PGP SIGNATURE----- From guido@witmond.nl Fri Jun 21 09:51:23 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E210721F8C4C; Fri, 21 Jun 2013 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDy0i0iPe+3i; Fri, 21 Jun 2013 09:51:19 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96E11E81A5; Fri, 21 Jun 2013 09:51:04 -0700 (PDT) Received: from [10.1.2.6] (mail.wtmnd.nl [80.100.189.3]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5LGouI7009661; Fri, 21 Jun 2013 18:51:03 +0200 (CEST) (envelope-from guido@witmond.nl) Message-ID: <51C48470.6070007@witmond.nl> Date: Fri, 21 Jun 2013 18:50:56 +0200 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Peter Saint-Andre References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> <51C4739A.3030508@stpeter.im> In-Reply-To: <51C4739A.3030508@stpeter.im> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Fri, 21 Jun 2013 09:55:28 -0700 Cc: posh@ietf.org, dane@ietf.org Subject: Re: [POSH] [dane] while we're waiting for DANE deployment... X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:51:24 -0000 On 21-06-13 17:39, Peter Saint-Andre wrote: > [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] > > On 6/21/13 8:23 AM, Viktor Dukhovni wrote: > >> New standards take a long time from inception to wide adoption. >> Software released today takes ~2-5 years to be included by O/S >> distributions (if bundled as with MTAs) or upgraded by a majority >> of the user base. Browsers with their independent distribution >> channels are the exception, not the rule. So I think that >> deployment barriers today should not overly prejudice architectural >> decisions for software that will only become mainstream in ~5 >> years. > > That is a valid point, and one that we'll need to consider at the BoF > in Berlin. That's a good argument to work on browser plugins. Like the ridiculed Extended DNSSEC validator. Or the next version of CZ.nic's original plugin. Even if the only purpose of these tools is to raise awareness about DNSSEC/DANE, I believe it's worth it. My authentication protocol relies on DANE, so I made it into a browser proxy. [1] Regards, Guido. [1] http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html From jesse.thompson@doit.wisc.edu Tue Jun 25 21:09:00 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4521E8089 for ; Tue, 25 Jun 2013 21:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjE4cpkS83LJ for ; Tue, 25 Jun 2013 21:08:55 -0700 (PDT) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8B11E8193 for ; Tue, 25 Jun 2013 21:08:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MOZ00J00EXXZH00@smtpauth2.wiscmail.wisc.edu> for posh@ietf.org; Tue, 25 Jun 2013 23:08:53 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.6.26.35742, SenderIP=0.0.0.0 Received: from [192.168.1.129] (24-159-240-219.dhcp.mdsn.wi.charter.com [24.159.240.219]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MOZ00BX3FIS1910@smtpauth2.wiscmail.wisc.edu> for posh@ietf.org; Tue, 25 Jun 2013 23:08:52 -0500 (CDT) Message-id: <51CA695A.8080505@doit.wisc.edu> Date: Tue, 25 Jun 2013 23:08:58 -0500 From: Jesse Thompson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: posh@ietf.org References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> <51C4739A.3030508@stpeter.im> In-reply-to: <51C4739A.3030508@stpeter.im> Subject: Re: [POSH] [dane] while we're waiting for DANE deployment... X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 04:09:00 -0000 On 6/21/13 10:39 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] > > On 6/21/13 8:23 AM, Viktor Dukhovni wrote: >> On Thu, Jun 20, 2013 at 08:02:45PM -0600, Peter Saint-Andre wrote: >> >>> DANE is awesome and will solve many practical challenges with >>> the existing PKI (e.g., the inability to securely offer proper >>> certificates for hosted domains in multi-tenanted environments). >> >> Isn't this *supposed* to be solved via SNI? (I personally don't >> believe SNI scales, but I'm willing to go along with the idea for >> argument's sake now and then). > > The core problem in the PKI context is that BigCompany.com isn't going > to hand over its private keys to ConvenientHostingService.com, and the > hosting company doesn't want those keys anyway for liability purposes. +1 (especially in light of Prism) >>> Unfortunately, DANE won't be widely deployed anytime soon. (As >>> one example, we're still struggling with the lack of DNS SRV >>> support among domain registrars for certain major TLDs, let alone >>> DNSSEC support.) >> >> Is the main obstacle in your view lack registrar infrastructure to >> support customer DNSSEC deployment, or lack of tools for customers >> to manage DNSSEC zone signing? > > IMHO, probably both. But I will ask some folks on the operational side > to find out more. Talking with the network folks in my organization... little hope of DNSSEC any time soon. Jesse University of Wisconsin From mamille2@cisco.com Tue Jun 25 22:24:45 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA121E8099; Tue, 25 Jun 2013 22:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7KhHziNo5Jb; Tue, 25 Jun 2013 22:24:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A48BC21E808E; Tue, 25 Jun 2013 22:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9026; q=dns/txt; s=iport; t=1372224279; x=1373433879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4t30XmWGuypYRHoSKU0XwbG05+Gy3/VD54Oz0Bf9UCk=; b=Vuvnw8HeM28uSJw55ETarjrHbygZT3E87XTeddbkveCe1CE4yU9Z4Shf 7+C18SLP2QRx7F5UEVuEhwXhy/0rXnq7mEStlA+5qIyEYdumG0CFtNddJ +XbX3F/f8ErpqCW7Mn/6JMgI6tvIUJyA32ry8fE4cbhZpDZEM+oKCGlhy w=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABl6ylGtJXG+/2dsb2JhbABagwkxSb84gQgWdIIjAQEBAwF5BQsCAQgiJAIwJQIEAQ0FCAaHegYMumCPGTEHgwJhA5ADgSyCQoR7kByDEYIo X-IronPort-AV: E=Sophos;i="4.87,941,1363132800"; d="p7s'?scan'208";a="227486240" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 05:24:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5Q5OcpG015945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 05:24:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 00:24:38 -0500 From: "Matt Miller (mamille2)" To: Simon Tennant , "posh@ietf.org" Thread-Topic: [xmpp] About POSH Thread-Index: AQHObiE1Fi9LMklP/k+iidnwvGyvpZlAXkeAgAd0LoA= Date: Wed, 26 Jun 2013 05:24:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.113] Content-Type: multipart/signed; boundary="Apple-Mail=_7C544B37-9850-49C2-BAE9-03F9CDF6C6F2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: " Group" Subject: Re: [POSH] [xmpp] About POSH X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:24:46 -0000 --Apple-Mail=_7C544B37-9850-49C2-BAE9-03F9CDF6C6F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [including posh@ietf.org; will remove xmpp@ietf.org in subsequent = replies to this thread] On Jun 21, 2013, at 5:34 AM, Simon Tennant wrote: > What's unclear to me is the lookup order and which certification to = trust? > - should I trust DNSsec before POSH? >=20 I believe much of that is still in [XMPP-DNA], but we are recommending = that applications try to locate both as simultaneously as possible (a la = Happy Eyeballs). Otherwise, I think it comes down to what the application implementers = (and application deployers) believe will most quickly result in success. > Is there any versioning of the results. I presume this is v1.0. How = will > clients handle newer versions of the protocol? The content is JSON, and conforming to a [JWK] Set. I think it could be = extended to add a "version" or "poshVer" property if needed. Do you see any specific changes you think are likely and would require = versioning for interoperability? >=20 > Can any of this lookup reuse the the DNS-SD discovery protocol (the = TXT > record format and IANA registry)? > https://tools.ietf.org/html/rfc6763#page-19 I don't think that DNS-SD itself provides any real benefit here. This = is effectively reusing portions of the SRV query (including the registry = of service and protocol names), while reusing a highly popular data = encapsulation format for which parsers and generators are readily = available for just about every conceivable platform. >=20 > Of course my fear with anything webfinger-y, is that it supposes the = type > of people who look after the infrastructure can work with the people = that > look after content that goes onto the naked domain (which is usually > outsourced or run by an web agency). IMHO, a far more reliable = approach > would be to have a dedicated URL away from the root domain for this = content > (https://posh.example.com, for example). >=20 I fail to see how shifting the burden from one content distributor to = another is far more reliable. Presumably, if the source-domain owner = already contracted with one agency to host their HTTPS service and = another (or some collection of anothers) for their non-HTTPS services, = it stands to reason they would then most likely contract with said HTTPS = hosting agency for the "posh." + source-domain. In my opinion, requiring "posh." + source-domain actually makes this = less reliable because it requires implicit trust in DNS hierarchies = always reflecting the domain ownership a specific way, but without = actually easing the deployment burden. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [XMPP-DNA] Domain Name Associations (DNA) in the Extensible Messaging = and Presence Protocol (XMPP) < = http://tools.ietf.org/html/draft-ietf-xmpp-dna > [JWK] JSON Web Key (JWK) < = http://tools.ietf.org/html/draft-ietf-jose-json-web-key >= --Apple-Mail=_7C544B37-9850-49C2-BAE9-03F9CDF6C6F2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MjYwNTI0 MzhaMCMGCSqGSIb3DQEJBDEWBBT64zyvZxDZik9024xj9TLnHuVqzTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAClL mmkdBct5Of0JS52Vns0DoVfaI6h1eKbQn9XR1iKMhioOd3nKVCG9efUePE9M8hH3NKW1GJKBnt5W IFLgXUjLWyvfnF5b3OrNQ0HSde/PCarzTRl7tUA5mY4mtxRbFoy94yMV7mCV97qVGSrvy1M2iAV1 60XeshLwsEsy3/DkM+svuLoZptnLtZZeHhhSYxqUk/aXUhmCLLCblbeXWSnIsdznEAZRkpyeujIU /dY2O95SVBm/Q6rVmbmX6eMW90sHym9g1bsRJYCoTi+f0Ni/vu1etLoTm9YUnSx84q/XlXrh/9nI sRpbv2JsejDICmJyBYXw0shcv/A5Rn59REAAAAAAAAA= --Apple-Mail=_7C544B37-9850-49C2-BAE9-03F9CDF6C6F2-- From stpeter@stpeter.im Tue Jun 25 22:31:45 2013 Return-Path: X-Original-To: posh@ietfa.amsl.com Delivered-To: posh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EE21F8206 for ; Tue, 25 Jun 2013 22:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAaiEtKliHRQ for ; Tue, 25 Jun 2013 22:31:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 274FB21F9F19 for ; Tue, 25 Jun 2013 22:31:41 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D50C41101; Tue, 25 Jun 2013 23:32:00 -0600 (MDT) Message-ID: <51CA7CBB.1070001@stpeter.im> Date: Tue, 25 Jun 2013 23:31:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jesse Thompson References: <51C3B445.3050604@stpeter.im> <20130621142331.GJ29420@mournblade.imrryr.org> <51C4739A.3030508@stpeter.im> <51CA695A.8080505@doit.wisc.edu> In-Reply-To: <51CA695A.8080505@doit.wisc.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: posh@ietf.org Subject: Re: [POSH] [dane] while we're waiting for DANE deployment... X-BeenThere: posh@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion about PKIX Over Secure HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:31:46 -0000 On 6/25/13 10:08 PM, Jesse Thompson wrote: > On 6/21/13 10:39 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> [ + posh@ietf.org - I will drop dane@ietf.org if this thread continues ] >> >> On 6/21/13 8:23 AM, Viktor Dukhovni wrote: >>> On Thu, Jun 20, 2013 at 08:02:45PM -0600, Peter Saint-Andre wrote: >>> >>>> DANE is awesome and will solve many practical challenges with >>>> the existing PKI (e.g., the inability to securely offer proper >>>> certificates for hosted domains in multi-tenanted environments). >>> >>> Isn't this *supposed* to be solved via SNI? (I personally don't >>> believe SNI scales, but I'm willing to go along with the idea for >>> argument's sake now and then). >> >> The core problem in the PKI context is that BigCompany.com isn't going >> to hand over its private keys to ConvenientHostingService.com, and the >> hosting company doesn't want those keys anyway for liability purposes. > > +1 (especially in light of Prism) > > >>>> Unfortunately, DANE won't be widely deployed anytime soon. (As >>>> one example, we're still struggling with the lack of DNS SRV >>>> support among domain registrars for certain major TLDs, let alone >>>> DNSSEC support.) >>> >>> Is the main obstacle in your view lack registrar infrastructure to >>> support customer DNSSEC deployment, or lack of tools for customers >>> to manage DNSSEC zone signing? >> >> IMHO, probably both. But I will ask some folks on the operational side >> to find out more. > > Talking with the network folks in my organization... little hope of > DNSSEC any time soon. Unfortunately that's the experience of many many people. Thus the impetus some of us feel to work on POSH... Peter -- Peter Saint-Andre https://stpeter.im/