From tmarkmann@googlemail.com Sun Jul 21 13:22: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 346FC21E8091 for ; Sun, 21 Jul 2013 13:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Ia6t6I94YmV5 for ; Sun, 21 Jul 2013 13:22:37 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0721E804D for ; Sun, 21 Jul 2013 13:22:31 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id jg1so2219542bkc.34 for ; Sun, 21 Jul 2013 13:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=content-type:mime-version:subject:x-mailer:date:message-id:from:to :cc; bh=cCQ4jPcR4il5mqBHw0keRgsbE8nzol8vpQOhGzIKnW4=; b=K4S0/huuz2NGTcx+/PlCZ1pqmxZgE58UOZ6Txfk/u9iELbYYMY4kLa7E+czQEQhd3+ JdKOaewvpJzSuK0PVuWEnQk5IObm/x3ItQNqji+Cnf+ur/lFTrMR07UaN8IkJFR1ki35 /Qv9PkvC1n2xGGjT55WQP2u9bJAgu5ohgjznpMX9ugpT0viq6OSU/6bbEXizGb4KgsMK QU8TQsQMhsEqbWTIJeAbDMDVYJv/bpZC6phZrBILlBVkeP86ZIkTjRkyUyy1/CRiYbBm ApcBFn/v4WFKOWm12xEi9m21k/1AK2YhtaFgXhWD+lZw6TfjkXoZH/UkS0y+O9GUoto3 coEQ== X-Received: by 10.204.230.145 with SMTP id jm17mr3496342bkb.125.1374438150822; Sun, 21 Jul 2013 13:22:30 -0700 (PDT) Received: from ruediger.fritz.box (port-9350.pppoe.wtnet.de. [84.46.36.170]) by mx.google.com with ESMTPSA id cy5sm6081162bkb.1.2013.07.21.13.22.29 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Sun, 21 Jul 2013 13:22:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="===============0051014757==" MIME-Version: 1.0 X-Mailer: Inky (TM) v1.0.51DD.C559 ("Epoch") Date: Sun, 21 Jul 2013 20:22:29 -0000 Message-Id: From: Tobias Markmann To: Cc: Subject: [POSH] Feedback on 'draft-miller-posh-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: Sun, 21 Jul 2013 20:22:41 -0000 --===============0051014757== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Matt and Peter, So I've given draft-miller-posh-00 a read and have the following feedback on the document. All in all the draft is well-written and, apart from the issues mentioned, easily understandable with less deployment requirements compared to secure DNS. Below you'll find my comments for each section. 1. Introduction --------------- > 1. A TLS client retrieves 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 [JOSE-JWK] defined within the > JOSE WG. Why are JSON Web Keys used over more common formats like Base64-encoded DER, for which parsers are readily available in all TLS libraries? The 'x5c' field in the JWK set seems to be Base64ed DER; still with JSON around it. Presenting the reasoning behind this choice would make the document easier to grasp in its context. 3. Obtaining Verification Materials ------------------------------------ > For example, if the application protocol is XMPP then the "{service}" is > either "_xmpp-client" for XMPP client-to-server connections, and > the "{protocol}" is "_tcp"; thus if an XMPP client were to use > POSH to verify an XMPP server for the domain "im.example.com", > the HTTPS GET request would be as follows: The lone *either* suggests you also want to mention the S2S scenario here, though it seems to be missing. The following sounds more complete: ...either "_xmpp-client" for XMPP client-to-server connections or "_xmpp-server" for XMPP server-to-server connections... 3.1. Source Domain Possesses PKIX Certificate ---------------------------------------------- > In order for the TLS client to verify > the identity of the TLS server, it MUST ensure that the PKIX > certificate presented by the TLS server during the TLS negotiation > matches the certificate that it obtained via POSH. How to perform that matching/equality check? Comparing the X.509 fingerprints should be enough, right? A paragraph or reference to a section on how to perform the matching would make it more clear. 3.2.2. Redirect Depth ---------------------- > To protect against circular references, clients MUST NOT follow an > infinite number of redirects. It is RECOMMENDED that clients follow > no more than 10 redirects, although applications or implementations > can require that fewer redirects be followed. These are basically the same precautions RFC 2616 mandates in section 10.3. I suggest simply referring to [RFC 2616, Section 10.3] instead of duplicating text or describing the same with different words. If we want to set additional precautions these should be emphasised. 6. Caching Results ------------------- While this section already recommends HTTPS servers to add headers preventing any client side caching, I think this issue should be more highlighted. Long caching deplays roll-over or other changes related to the secure delegation setup. Cheers, Tobi --===============0051014757== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Matt and Peter,

=A0

=A0

So I've given draft-miller-posh-00 a read and have the following feedback= on the
document.
=A0
All in all the draft is well-written and, apart from the issues mentioned= ,=A0
easily understandable with less deployment requirements compared to secur= e
DNS.
=A0
Below you'll find my comments for each section.
=A0
1. Introduction
---------------
=A0 =A0 > 1. =A0A TLS client retrieves the material to be used in chec= king the
=A0 =A0 > =A0 =A0 =A0 TLS server's identity by requesting it from a we= ll-known HTTPS
=A0 =A0 > =A0 =A0 =A0 URI, where the response contains one or more cer= tificates
=A0 =A0 > =A0 =A0 =A0 formatted as a JSON Web Key set [JOSE-JWK] defin= ed within the
=A0 =A0 > =A0 =A0 =A0 JOSE WG.
=A0
Why are JSON Web Keys used over more common formats like Base64-encoded D= ER,
for which=A0parsers are readily available in all TLS libraries? The 'x5c'= field in the JWK
set seems to be Base64ed DER; still with JSON around it. Presenting the r= easoning=A0
behind=A0this choice would make the document easier to grasp in its conte= xt.
=A0
3. =A0Obtaining Verification Materials
------------------------------------
=A0 =A0 > For example, if the application protocol is XMPP then the "{= service}" is
=A0 =A0 > either "_xmpp-client" for XMPP client-to-server connections,= and
=A0 =A0 > the "{protocol}" is "_tcp"; thus if an XMPP client were to u= se
=A0 =A0 > POSH to verify an XMPP server for the domain "im.example.com= ",
=A0 =A0 > the HTTPS GET request would be as follows:
=A0
The lone *either* suggests you also want to mention the S2S scenario here= ,=A0
though it seems to be missing. The following sounds more complete:
=A0
=A0 =A0 ...either "_xmpp-client" for XMPP client-to-server connections or=
=A0 =A0 "_xmpp-server" for XMPP server-to-server connections...
=A0
3.1. =A0Source Domain Possesses PKIX Certificate
----------------------------------------------
=A0 =A0 > In order for the TLS client to verify
=A0 =A0 > the identity of the TLS server, it MUST ensure that the PKIX=
=A0 =A0 > certificate presented by the TLS server during the TLS negot= iation
=A0 =A0 > matches the certificate that it obtained via POSH.
=A0
=A0 =A0 How to perform that matching/equality check? Comparing the X.509 = fingerprints
=A0 =A0 should be enough, right? A paragraph or reference to a section on= how to perform
=A0 =A0 the matching would make it more clear.
=A0
3.2.2. =A0Redirect Depth
----------------------
=A0 =A0 > To protect against circular references, clients MUST NOT fol= low an
=A0 =A0 > infinite number of redirects. =A0It is RECOMMENDED that clie= nts follow
=A0 =A0 > no more than 10 redirects, although applications or implemen= tations
=A0 =A0 > can require that fewer redirects be followed.
=A0
=A0 =A0 These are basically the same precautions RFC 2616 mandates in sec= tion 10.3.
=A0 =A0 I suggest simply referring to [RFC 2616, Section 10.3] instead of= duplicating
=A0 =A0 text or describing the same with different words. If we want to s= et additional
=A0 =A0 precautions these should be emphasised.
=A0
6. =A0Caching Results
-------------------
=A0 =A0 While this section already recommends HTTPS servers to add header= s preventing
=A0 =A0 any client side caching, I think this issue should be more highli= ghted. Long
=A0 =A0 caching deplays roll-over or other changes related to the secure = delegation
=A0 =A0 setup.

=A0

Cheers,

Tobi

=A0

=A0
--===============0051014757==-- From mamille2@cisco.com Mon Jul 22 16:14:30 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 D684711E818C for ; Mon, 22 Jul 2013 16:14:30 -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 TLzG8PZwD0CF for ; Mon, 22 Jul 2013 16:14:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA20711E818A for ; Mon, 22 Jul 2013 16:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10858; q=dns/txt; s=iport; t=1374534865; x=1375744465; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cu9YbeQstkPMOFze1XcpC8ydIXShFPfxfUPHykrR4B4=; b=B4ULBlScZd9yrkEKeY0OdUUq13TZgEYt/eF19Flyln0qN/Tx9w6T4Bxf TU2ot6MMUpp4WdppwwFwqZ2dO810GqylWjgZldb0Yah3D5AeNG9halxcC 9SpXTNtUMvh+7rF9MhO9LOW7C1ekY6JOb8+9bLOiD9htMJton5Te59Y/Y 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFABK87VGtJXG8/2dsb2JhbABSCYMDNVDAMoEWFnSCJAEBAQMBeQULAgEIDhQkAjAlAgQOBQgGh3ADCQavbw2IXo0qgTGBCjEHCYMHbgOQEIEtgkmVJIMSgio X-IronPort-AV: E=Sophos;i="4.89,722,1367971200"; d="p7s'?scan'208";a="238068608" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jul 2013 23:14:24 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6MNEOl0005085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 23:14:24 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 18:14:23 -0500 From: "Matt Miller (mamille2)" To: Tobias Markmann Thread-Topic: [POSH] Feedback on 'draft-miller-posh-00' Thread-Index: AQHOhlAQOFQqAPn8+U2qt5mY/MGXs5lxqZiA Date: Mon, 22 Jul 2013 23:14:23 +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.129.24.90] Content-Type: multipart/signed; boundary="Apple-Mail=_0560B68E-64C1-4A80-A4E2-6071CB91A0DB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [POSH] Feedback on 'draft-miller-posh-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: Mon, 22 Jul 2013 23:14:31 -0000 --Apple-Mail=_0560B68E-64C1-4A80-A4E2-6071CB91A0DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Tobi, Thanks for the feedback! More comments inline... On Jul 21, 2013, at 2:22 PM, Tobias Markmann = wrote: >=20 > Hi Matt and Peter, >=20 >=20 > So I've given draft-miller-posh-00 a read and have the following > feedback on the > document. >=20 > All in all the draft is well-written and, apart from the issues > mentioned, > easily understandable with less deployment requirements compared to > secure > DNS. >=20 > Below you'll find my comments for each section. >=20 > 1. Introduction > --------------- >> 1. A TLS client retrieves 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 [JOSE-JWK] defined within the >> JOSE WG. >=20 > Why are JSON Web Keys used over more common formats like > Base64-encoded DER, > for which parsers are readily available in all TLS libraries? The > 'x5c' field in the JWK > set seems to be Base64ed DER; still with JSON around it. Presenting > the reasoning > behind this choice would make the document easier to grasp in its > context. >=20 The rationale is to certificate roll-over and alternate certificates. = The roll-over case is for operators to be able to obtain a renewed = certificate, and gradually update all of their front-end servers (all = identified by the same hostname) to the new certificate without = compromising the verification process. The alternate use case is to = allow for the front-end servers to be identified by different hostnames, = but for the same service. Section 7 discusses how to do that, but doesn't explain these = rationales. I'll make a note to add these rationales to the document. > 3. Obtaining Verification Materials > ------------------------------------ >> For example, if the application protocol is XMPP then the > "{service}" is >> either "_xmpp-client" for XMPP client-to-server connections, and >> the "{protocol}" is "_tcp"; thus if an XMPP client were to use >> POSH to verify an XMPP server for the domain "im.example.com", >> the HTTPS GET request would be as follows: >=20 > The lone *either* suggests you also want to mention the S2S scenario > here, > though it seems to be missing. The following sounds more complete: >=20 > ...either "_xmpp-client" for XMPP client-to-server connections or > "_xmpp-server" for XMPP server-to-server connections... >=20 Actually, the intent was to discuss the process using a single protocol; = Section 2. Terminology explains that (or attempts to). That "either" is = a typo, and we'll remove it with the next revision. > 3.1. Source Domain Possesses PKIX Certificate > ---------------------------------------------- >> In order for the TLS client to verify >> the identity of the TLS server, it MUST ensure that the PKIX >> certificate presented by the TLS server during the TLS negotiation >> matches the certificate that it obtained via POSH. >=20 > How to perform that matching/equality check? Comparing the X.509 > fingerprints > should be enough, right? A paragraph or reference to a section on how > to perform > the matching would make it more clear. >=20 Good point. we'll add that with the next revision. > 3.2.2. Redirect Depth > ---------------------- >> To protect against circular references, clients MUST NOT follow an >> infinite number of redirects. It is RECOMMENDED that clients follow >> no more than 10 redirects, although applications or implementations >> can require that fewer redirects be followed. >=20 > These are basically the same precautions RFC 2616 mandates in section > 10.3. > I suggest simply referring to [RFC 2616, Section 10.3] instead of > duplicating > text or describing the same with different words. If we want to set > additional > precautions these should be emphasised. >=20 "Mandate" might be too strong a word for what RFC2616 =A7 10.3 says (-: However, it does have recommendations, as we ought to reference those = unless there's a good reason to have our own. We'll see about changing = the existing section to mostly reference this section in RFC2616. > 6. Caching Results > ------------------- > While this section already recommends HTTPS servers to add headers > preventing > any client side caching, I think this issue should be more > highlighted. Long > caching deplays roll-over or other changes related to the secure > delegation > setup. >=20 I don't disagree, but I'm not sure what we ought to do to highlight it = more. Do you have any specific suggestions? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_0560B68E-64C1-4A80-A4E2-6071CB91A0DB 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 oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MjIyMzE0 MjNaMCMGCSqGSIb3DQEJBDEWBBQmQhDM31tf76X+7OVpzxtdB85A3TCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAIEm DyB0AjABW0fGEr607y1j9UB+Y3YVNVeVK1V5qwPbWLee/YzxYo2cloYIxLy/65b1Tkr0tpbc3RER NCvmS0tcqm8JaTLU/PeZNOOK1SsLkt4apPrEqv32QBlfPSqXpePxFKTjo75xCHhyaBmAj3rKnp9V 3n7xKGm71DNmJ+kNE7cLtXUxiywKVVDivUeGxVfOh/pztYG5jpzsZaCoSaGCMCnoB/19o1Q/9NTN Sx/9Zvg3tYSoX/xNXRN9kt6nKnfa9eXUmGz1o/5VsBWN7By4tQeC6CW2HP5uTGP/8egKocm1rZD+ n0rYDTg0R7mObox1WcQrgxO+j8J6l92qQP4AAAAAAAA= --Apple-Mail=_0560B68E-64C1-4A80-A4E2-6071CB91A0DB-- From alexey.melnikov@isode.com Wed Jul 24 14:08:10 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 7FC5621F9DD0 for ; Wed, 24 Jul 2013 14:08:09 -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 s2KBKhz8vAGi for ; Wed, 24 Jul 2013 14:08:04 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 678E821F9D87 for ; Wed, 24 Jul 2013 14:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1374700069; d=isode.com; s=selector; i=@isode.com; bh=LWYAZDS5mn6LHjmaZtN4jJeFrlkMTJQWlsR+iprhfZs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IFXuWcD/vOJC3yEdTl1tY/Cey7Q6bdCqYwKkWKFXf8eUcOIK4QncqK5z39a3h9IgT5jCcW lcmZyvZ0z9jryvfEMfIyi0vtPPPHAYRx2M+B5YfB8r2NOyNzyuelnyQ4Hh2cg9T+Cqglv4 uAAs6gzc/WWRCbuuYePvdUOdGBPHZAQ=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 24 Jul 2013 22:07:49 +0100 Message-ID: <51F04223.4090803@isode.com> Date: Wed, 24 Jul 2013 22:07:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: posh@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 24 Jul 2013 14:43:07 -0700 Cc: Kathleen Moriarty Subject: [POSH] Proposed agenda for the BOF 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, 24 Jul 2013 21:08:10 -0000 Hi, Below is the proposed agenda for the BOF. Please let Kathleen and me know if you have any comments. * Intro (5 minutes) - Chairs a. Note Well b. Logistics c. Progress to date d. Goals for the meeting e. Agenda bashing * Problem statement, certificate checking in XMPP (10 minutes) - Matt Miller * Certificate checking in SIP (10 minutes) - Olle Johansson * Certificate checking in SMTP (10 minutes) - John Levine * Charter Discussion (15 minutes) - moderated by Chairs http://www.ietf.org/mail-archive/web/posh/current/msg00001.html a. Problem statement b. Objectives c. Deliverables d. Milestones * Questions to be answered (10 minutes) - moderated by Chairs a. Is there a problem that needs solving? b. Is the problem well defined and understood? c. Is there agreement on what a WG would need to deliver? d. Are there people willing to do the work? i. Writing drafts / code ii. Reviewing drafts / code iii. Implementing / testing / characterizing / other e. Would a WG have a reasonable probability of success? Thank you, Alexey From mamille2@cisco.com Wed Jul 24 16:14:11 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 90EF411E812E for ; Wed, 24 Jul 2013 16:14:11 -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 f9vaH2Md0RBA for ; Wed, 24 Jul 2013 16:14:06 -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 19F9A11E812D for ; Wed, 24 Jul 2013 16:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6277; q=dns/txt; s=iport; t=1374707646; x=1375917246; h=from:to:subject:date:message-id:mime-version; bh=349YafZeYUKt0/Pl8nm7k5Hgxb9E+NbXUCRqojZZ07I=; b=WXtCVKMQmgyH379batFouc/hn5vkGfDI0ass4iDM0SaP62p1h4djurKi MSoeHV4qQD7FHQ/GO1H5YJaV++TIpPoupfNa8N4J8dWGOum3fM4nGG6XQ vQZdC7tAxzbe9spxxMEom4SteZ17lnMRoXizfjUfxFUG9wITPVKdNQDay 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAEJf8FGtJXG+/2dsb2JhbABbFoJwNVCCQrslgRYWdIImAQICgQsBKiYwJwQTCAaIAgyZM6BLj0yDSm4DkBKBLZdtgxSCKg X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="p7s'?scan'208";a="239071768" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2013 23:14:03 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6ONE2Qc018609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 23:14:02 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 18:13:51 -0500 From: "Matt Miller (mamille2)" To: "" Thread-Topic: Draft Slides -- "Problem statement, certificate checking in XMPP" Thread-Index: AQHOiMN1QeYjiZTwN0ipApNKJ53ehg== Date: Wed, 24 Jul 2013 23:13:50 +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=_0597BBC7-20F8-4F1C-AC57-BC67CC8B594D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [POSH] Draft Slides -- "Problem statement, certificate checking in XMPP" 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, 24 Jul 2013 23:14:11 -0000 --Apple-Mail=_0597BBC7-20F8-4F1C-AC57-BC67CC8B594D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Here is a first draft of my slides for the POSH BoF. Feedback welcome! < http://outer-planes.net/%7Elinuxwolf/ietf/ietf87-poshbof-xmpp.pdf > - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_0597BBC7-20F8-4F1C-AC57-BC67CC8B594D 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 oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MjQyMzEz NTFaMCMGCSqGSIb3DQEJBDEWBBQ8KL9XI/cDBMCMzVQOeZ+trs6/SDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAEyx 59YfxhlZcSOUGXzaswCq2TW+ngJ7q/CmlfbpM2X5hMO4ipNkcCzbshj43WcIS5OEmQ7PixjpMopW ad/xKOOmE5NbcPyboo4mDWrVevBrGf+kL2zjOugjuoDtgqmwKNFmQSnjIxKlG99ARDURgvVKd+Ed xx0PVbHCoaqzN8mZtQu1y0yM/WEAn4vMGRkX1bI5flcjeHwf4gmNW+5pT0J6i+q36WzCa+PsNBzB jOEKu0UgCl/JA5/nRgcB21kEm3hm1CO9qZ0AjxRq3ZHXI7sd8ymzuGT+jQ5s987XkKM7wxUMMahI Jd4DtvI17mxOQDsrXJzlTOAsOd4V3LCk90cAAAAAAAA= --Apple-Mail=_0597BBC7-20F8-4F1C-AC57-BC67CC8B594D-- From jesse.thompson@doit.wisc.edu Thu Jul 25 14:51:57 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 C377821F933B for ; Thu, 25 Jul 2013 14:51:52 -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 f+icyjaBE4yE for ; Thu, 25 Jul 2013 14:51:48 -0700 (PDT) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by ietfa.amsl.com (Postfix) with ESMTP id CE91D21F9287 for ; Thu, 25 Jul 2013 14:51:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MQI00K00I1PAJ00@smtpauth4.wiscmail.wisc.edu> for posh@ietf.org; Thu, 25 Jul 2013 16:51:27 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.25.214228, SenderIP=0.0.0.0 Received: from [127.0.0.1] (boson.doit.wisc.edu [128.104.17.84]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MQI00MB8I1R4N40@smtpauth4.wiscmail.wisc.edu>; Thu, 25 Jul 2013 16:51:27 -0500 (CDT) Message-id: <51F19DDD.5020505@doit.wisc.edu> Date: Thu, 25 Jul 2013 16:51:25 -0500 From: Jesse Thompson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "Matt Miller (mamille2)" References: In-reply-to: Cc: "" Subject: Re: [POSH] Draft Slides -- "Problem statement, certificate checking in XMPP" 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: Thu, 25 Jul 2013 21:51:57 -0000 I like it... wish I could attend. I think that you might need to sell the "No longer acceptable: Users starting to care ... Operators starting to care" by providing some examples of why they care, and why others should care. Jesse On Wednesday, July 24, 2013 6:13:50 PM, Matt Miller (mamille2) wrote: > Here is a first draft of my slides for the POSH BoF. Feedback welcome! > > < http://outer-planes.net/%7Elinuxwolf/ietf/ietf87-poshbof-xmpp.pdf > > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > > _______________________________________________ > posh mailing list > posh@ietf.org > https://www.ietf.org/mailman/listinfo/posh From michael@voip.co.uk Fri Jul 26 02:54:39 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 3F50F21F8BCE for ; Fri, 26 Jul 2013 02:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 xFV0XLb9rObh for ; Fri, 26 Jul 2013 02:54:33 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with SMTP id 1D39C21F9005 for ; Fri, 26 Jul 2013 02:54:31 -0700 (PDT) Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUfJHVnHA6lQFKpH06AyNtwlnmykukj7F@postini.com; Fri, 26 Jul 2013 02:54:32 PDT Received: by mail-wi0-f179.google.com with SMTP id hj3so629960wib.6 for ; Fri, 26 Jul 2013 02:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=X+v+ijBHChbPjcPEVSNgfm1lfZDD4lH2B2EqLgShFRA=; b=JsEiYkEvZiSfRMhQup3HGmeulFtfcqKMnTb3ZQOQtjgGux1S5gwyNqDnud78UxY/1o FDGi9WqT1WVUyWsEJnwuhImgAWB/5K6Wy1bqs6OqhQqH9PUhFMw67MnMLy1BeWmlkhEF qXvpwg1Pj1WnWpcirfUpWnRv5UJz3/6t+28wMMorUYyDuD+PfHq3zdWWXjSHj90hXneY +MLl1bsXooob6tmXwEpXNxT8kujDzOatjpSvJ/aKHCoFtn0czZFxcbZyWcoVKlgM1PzD g7vKxAQyxaKYgjGXsUYUyVvnVT7oZuQim5oHcKoaxrx8f1E7WsLs4NqvBUAfBj6DHcKy UjLg== X-Received: by 10.194.240.201 with SMTP id wc9mr34147416wjc.1.1374832469447; Fri, 26 Jul 2013 02:54:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.201 with SMTP id wc9mr34147412wjc.1.1374832469348; Fri, 26 Jul 2013 02:54:29 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Fri, 26 Jul 2013 02:54:29 -0700 (PDT) Date: Fri, 26 Jul 2013 10:54:29 +0100 Message-ID: From: Michael Procter To: posh@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkz0XksVp/0anUN7yvGRrM1VcJwol+nvQ3DJyHEN+C9nKD7QGUiJP9toOYAx2dpP4NnGWu9MGwQpdUtbgNu2LDTQLj1V2aQ9cCgnvumG4xw1evV8Sul5XNWchRaMh0CQvazbo65 Subject: [POSH] Comments/questions on draft-miller-posh-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: Fri, 26 Jul 2013 09:54:39 -0000 I read draft-miller-posh-00 with interest, and have a couple of questions about the expected usage. In section 5, you discuss the relative timing of POSH operations and the application TLS handshake, requiring the POSH operations to be complete before the application handshake completes. At the end of the paragraph, you mention that all the POSH operations may in fact be completed before the application handshake begins. That sounds reasonable, provided you know in advance that the POSH part is required. Is that inferred from DNS if the target hostname is not in the original service domain or some other heuristic? It seems fair to me to only require the POSH part if the certificate presented is invalid for reasons such as subjectAltName mismatch, which precludes starting the POSH operations before the application handshake. Similarly, I can't see anything obviously wrong with letting the application handshake complete, then performing the POSH operations before deciding the application connection is not suitable and should be terminated before being used. Is the MUST in this section mandating the order of operations necessary for some other reason? In section 6, you state that ideally, caching of the certificate obtained via POSH should be based on the expiration time of the certificate. I think this might be a little too trusting, as it ties delegation validity to certificate expiry. If I trust hosting.example.net to host my service today, that doesn't mean I will continue to trust them until their certificate expires. HTTP cache-control headers might be a useful way of indicating a short term trust though. Regards, Michael From mamille2@cisco.com Sat Jul 27 02:59:32 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 941F521F9DED for ; Sat, 27 Jul 2013 02:59:32 -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 kCxRn5E0D0Ol for ; Sat, 27 Jul 2013 02:59:20 -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 E74AB21F9DA3 for ; Sat, 27 Jul 2013 02:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6740; q=dns/txt; s=iport; t=1374919160; x=1376128760; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2uZ06kz8+cTsLt+rKa2NUp2JIDPLF0hP9D9yej9lFKU=; b=E7yrkfm8o/A4v9TvazUXQXVG+fYpaz5OcJT+5dFB+JWYY40zgtlbmzjU vSzbwKKmxz616NuR5jJFEVYVDDMcqwQFw+yxGudGhK7qFtQbcM/IGbyAo F5H8I4NicHArPN+glQX3EjEGYVVsKt2YZnajFSPypuZ8c85Ho2dOKyUT7 4=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAICZ81GtJV2Y/2dsb2JhbABaDoJ4gQWCSLsUgRYWdIIkAQEBAwF5BQsCAQgiJAIwJQIEDgUIBod8BrhDj0wxB4MWbwOQEoEtl2yCVj6CKg X-IronPort-AV: E=Sophos;i="4.89,756,1367971200"; d="p7s'?scan'208";a="240213628" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2013 09:59:19 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6R9xJul006358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 09:59:19 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 04:59:18 -0500 From: "Matt Miller (mamille2)" To: Jesse Thompson Thread-Topic: [POSH] Draft Slides -- "Problem statement, certificate checking in XMPP" Thread-Index: AQHOiYEitkX0vcWSiU22Z7ly2gYW+Zl4oLiA Date: Sat, 27 Jul 2013 09:59:18 +0000 Message-ID: References: <51F19DDD.5020505@doit.wisc.edu> In-Reply-To: <51F19DDD.5020505@doit.wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.165] Content-Type: multipart/signed; boundary="Apple-Mail=_C79341E6-4A2A-4DDE-86FC-497D0D7988B9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [POSH] Draft Slides -- "Problem statement, certificate checking in XMPP" 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: Sat, 27 Jul 2013 09:59:32 -0000 --Apple-Mail=_C79341E6-4A2A-4DDE-86FC-497D0D7988B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 25, 2013, at 11:51 PM, Jesse Thompson = wrote: > I like it... wish I could attend. >=20 > I think that you might need to sell the "No longer acceptable: Users = starting to care ... Operators starting to care" by providing some = examples of why they care, and why others should care. >=20 > Jesse I'll be sure to talk about them in the room. I can see about adding = them to this slide, but I personally rather have a discussion than = merely reading the slides! (-: If you have specific examples you've heard, I'd be happy to add them. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_C79341E6-4A2A-4DDE-86FC-497D0D7988B9 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 oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MjcwOTU5 MThaMCMGCSqGSIb3DQEJBDEWBBTFxmAoOnxfEa3SDgCfS9dtQYeEIDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAE9Z VSABmne5LFvFBYuEPifuEes42e3GydZ3Az8lw3A/6wAMAU0JUFil2ceJ6d9fL2UbcZIcm5iyJbRa m/mBR+tAFLQeJMssuup+IWHZOAA51wPIESQqMLX0XssP9n0VgVB+wpmDwGy13l86EiAWRBUKz/nQ h2tSJDplOEe030KJuRSC0dSgPWkARNMTP1XmPSVB1JycUBIVT/dxQyzNZANVHPKKApqw8V5DbNnL LcYVo6xpAEL3WdVefAH3MsDdlzdaDVRKHnB89kuOF4gr3ctvN7fbe8Scm+p088jXrefMXaKqf/0z TWX3NAmN+jredjFYTlbpG259wLUQSorkSdgAAAAAAAA= --Apple-Mail=_C79341E6-4A2A-4DDE-86FC-497D0D7988B9-- From stpeter@stpeter.im Sun Jul 28 07:32:30 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 A752521F9DA1 for ; Sun, 28 Jul 2013 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SARE_RMML_Stock1=0.21, 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 9TDsvaNlphFc for ; Sun, 28 Jul 2013 07:32:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1C21F9DA3 for ; Sun, 28 Jul 2013 07:32:26 -0700 (PDT) Received: from ergon.local (unknown [193.43.158.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AA87CE8319; Sun, 28 Jul 2013 08:34:30 -0600 (MDT) Message-ID: <51F401CE.9080803@stpeter.im> Date: Sat, 27 Jul 2013 19:22:22 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Procter References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: posh@ietf.org Subject: Re: [POSH] Comments/questions on draft-miller-posh-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: Sun, 28 Jul 2013 14:32:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/26/13 11:54 AM, Michael Procter wrote: > I read draft-miller-posh-00 with interest, and have a couple of > questions about the expected usage. Hi Michael, thank you for the review, and sorry about the slightly delayed reply (travel, pre-IETF workshops, etc.). > In section 5, you discuss the relative timing of POSH operations > and the application TLS handshake, requiring the POSH operations to > be complete before the application handshake completes. At the end > of the paragraph, you mention that all the POSH operations may in > fact be completed before the application handshake begins. That > sounds reasonable, provided you know in advance that the POSH part > is required. Well, it's pretty clear that you'll need to complete the POSH operations before the TLS negotiation ends. :-) IMHO you don't really need to know in advance that a POSH retrieval will be necessary, thus I don't think that we need some sort of discovery mechanism (in fact, Matt and I discussed that since XMPP has a way to advertise features and authentication methods and such before STARTTLS, but we decided it wasn't needed). For instance, the TLS client could attempt the negotiation, realize that it's not able to tie the TLS server's end entity certificate back to a trusted root, then try the POSH path. Alternatively, the TLS client could take a "happy eyeballs" approach and retrieve all possible verification materials (PKIX, DANE, POSH) in parallel before attempting the application-layer connection. > Is that inferred from DNS if the target hostname is not in the > original service domain or some other heuristic? It seems fair to > me to only require the POSH part if the certificate presented is > invalid for reasons such as subjectAltName mismatch, which > precludes starting the POSH operations before the application > handshake. I think this text is purely informational, since it doesn't have any impact on the protocol (TLS negotiation) operations themselves. > Similarly, I can't see anything obviously wrong with letting the > application handshake complete, then performing the POSH > operations before deciding the application connection is not > suitable and should be terminated before being used. Is the MUST > in this section mandating the order of operations necessary for > some other reason? As mentioned above, the MUST here is perhaps a bit silly because it's so obvious. I think there is a better way to word it... OLD POSH processes MUST be complete before the end of the TLS handshake for the application protocol, so that the TLS client can perform verification of reference identifiers. NEW Clearly, POSH processes need to be completed before the end of the TLS handshake for the application protocol, so that the TLS client can perform verification of reference identifiers. > In section 6, you state that ideally, caching of the certificate > obtained via POSH should be based on the expiration time of the > certificate. I think this might be a little too trusting, as it > ties delegation validity to certificate expiry. If I trust > hosting.example.net to host my service today, that doesn't mean I > will continue to trust them until their certificate expires. HTTP > cache-control headers might be a useful way of indicating a short > term trust though. You make a very good point. I think this needs to be worded more carefully, because caching of the certificate itself doesn't necessarily apply a long-lived decision or policy to expect the TLS server for that domain to present that certificate (e.g., as you say the hosted domain could certainly re-delegate to a new service before the old service's certificate has expired). Matt and I will chat about a better way to express this guideline (or define separate guidelines for certificate expiry and delegation expiry). Thanks again, 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/ iQIcBAEBAgAGBQJR9AHOAAoJEOoGpJErxa2p8RkQAI2ddhxQ3dqTiYK0RzM2O34b 9a35xhDKi38uMwZ1dJChNmWtULwVQ7N87pL7V4k94/1XE7BJwi28hcj63KxnWwlE mEAFzq0TcwWWl15zYD4J6fZXJN+glp/SCHLGULRC3Ue/zPCCofNTh1TD1mmoG7Cq 4IooLD6Cv4sLffFh0neCj0vkTKGh6HW3KbX/32qbL8mEK3cdUcQCpmDtTt/I8TXQ aP79eXBphoqBZSN4325ULKXA0pOjvEHELpETPf3GmYJIunc0D2djssaal6Ll05Gl tDSJUyry4OwTviPVwW1lZqYqFQ5sQLYzXxytKW84DZt+os9OzTmyczDsD/6UutBJ Drk1Pypx29OMzHDPvRNImatGvV6DFGtrONpB/VgHS/NOgZUdT480bvDftImtXDcV R1ribE5wRNW0qh7jMtiV9DaLeBZQdwcPYW0ISjGWqX0Tiisrdl1/KQZsiv4t8FYu yQQN/kROSu3dUZ7Xkr6Yld7L38kKeXitIu6sETelkTEXdgE5SLxvELdcVBSAwrCn YEz7xwvis2I4r3y9MdVrrRPDw1EAens/dujxyJusrwhV9vukElbdVcSyGs9irWyS UbJiBem490nJYqCJppT1Dc5FOS6beQsr+nhxtRXAFb4znCmkZ56a0El0CGnBaxFE NXS7PwyyhyEhYyRqxzFa =b0dw -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Sun Jul 28 12:10: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 6443C21F9E13 for ; Sun, 28 Jul 2013 12:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, 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 dbwcinlaE7I7 for ; Sun, 28 Jul 2013 12:09:54 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7D21F9E46 for ; Sun, 28 Jul 2013 12:09:53 -0700 (PDT) Received: from [10.0.0.23] (f052136037.adsl.alicedsl.de [78.52.136.37]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6SJ9jmO025244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 21:09:47 +0200 Message-ID: <51F56C79.3020503@goodadvice.pages.de> Date: Sun, 28 Jul 2013 21:09:45 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: posh@ietf.org References: <51F401CE.9080803@stpeter.im> In-Reply-To: <51F401CE.9080803@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [POSH] Comments/questions on draft-miller-posh-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: Sun, 28 Jul 2013 19:10:00 -0000 Am 27.07.2013 19:22, schrieb Peter Saint-Andre: >> Similarly, I can't see anything obviously wrong with letting the >> application handshake complete, then performing the POSH >> operations before deciding the application connection is not >> suitable and should be terminated before being used. Is the MUST >> in this section mandating the order of operations necessary for >> some other reason? > > As mentioned above, the MUST here is perhaps a bit silly because it's > so obvious. I think there is a better way to word it... It isn't. In server-to-server XMPP what is typically done is to let the tls handshake succeed and only offer sasl external if the peer certificate is "valid". The same could be done for POSH... after the handshake is complete, look at the verification result. If it is valid, send stream features including external; if not, do the POSH dance. That would typically be done in the application, not the TLS lib. Doing an asynchronous https request inside the verification is not something I would expect to be trivial. From kathleen.moriarty@emc.com Mon Jul 29 01:30:29 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 DF56C21F9EB2 for ; Mon, 29 Jul 2013 01:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, WEIRD_PORT=0.001] 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 s6w40d6WlURV for ; Mon, 29 Jul 2013 01:30:26 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9173021F9E99 for ; Mon, 29 Jul 2013 01:29:38 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6T8Ta81016720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jul 2013 04:29:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 29 Jul 2013 04:29:25 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6T8TPCc019373 for ; Mon, 29 Jul 2013 04:29:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Mon, 29 Jul 2013 04:29:24 -0400 From: "Moriarty, Kathleen" To: "posh@ietf.org" Date: Mon, 29 Jul 2013 04:29:24 -0400 Thread-Topic: POSH BoF Monday 16:20-17:20 (UTC +2) Thread-Index: AQHOjDW66Id1YoJhNUy9xVGQDXsLKw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [POSH] POSH BoF Monday 16:20-17:20 (UTC +2) 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: Mon, 29 Jul 2013 08:30:30 -0000 Hello, This a friendly reminder that the POSH BoF will take place today, Monday Ju= ly 29, 2013 at 16:20-17:20 UTC+2 in Charlottenburg 2/3. The meeting agenda= , materials, and information for remote access and other tools can be found= in the links provided below. We will need volunteers to assist with meeting minutes and the jabber room.= Please let us know in advance if you can assist. Agenda: http://tools.ietf.org/agenda/87/ For us that would be: Agenda: http://tools.ietf.org/agenda/87/agenda-87-posh.html Audio Stream: http://ietf87streaming.dnsalias.net/ietf/ietf873.m3u Jabber room: xmpp:posh@jabber.ietf.org?join Presentations: https://datatracker.ietf.org/meeting/87/materials.html#wg-posh Notes: http://etherpad.tools.ietf.org:9001/p/notes-ietf-87-posh?useMonospaceFont= =3Dtrue&showChat=3Dfalse Meetecho http://www.meetecho.com/ietf87/posh Thank you! Kathleen & Alexey= From michael@voip.co.uk Mon Jul 29 03:25:50 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 1F1E321F9EB3 for ; Mon, 29 Jul 2013 03:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 7RQS9oMlQ3E7 for ; Mon, 29 Jul 2013 03:25:44 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id DFD3C21F9981 for ; Mon, 29 Jul 2013 03:25:43 -0700 (PDT) Received: from mail-wg0-f43.google.com ([74.125.82.43]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUfZDGzq2RlGU0kS5FkUlrcYfdFtkxbMB@postini.com; Mon, 29 Jul 2013 03:25:44 PDT Received: by mail-wg0-f43.google.com with SMTP id z12so4637670wgg.34 for ; Mon, 29 Jul 2013 03:25:30 -0700 (PDT) X-Google-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:x-gm-message-state; bh=YaiFohOZnXzxVWDL3moM4Ab9mpt+peLzZWKEBgq9TLk=; b=FWNPxdNWokRTPQoRf9M0a7trek+hstLSbagFwXSMx8w8kOFYAwNUsnYrG7QY2ER+mw SYcFYrurhh/zps+SkFa4Yc7+NAtkRhA4dr+p8j34HG7sJXFIpcq8Fdr+OcPRY/ZbhEmy 7EEiCEWHpLJzsaToZtOBeL/ZtaWuk+g5ZPhjEQvXLOejXjVCN1z5BJRk42dfI3LVhMZp rr8PgsSLKZ+Ne/Nm/q27z5nqOGc+cV0OKRvGoG8PJnEbcuqqYdpwYr89LYH4yabpFnX9 zC41YhTUsZwZtIXI6Mk8iG55w/rKWk9+xyuon0BVC7mq8wWW31GsgAgBqpCXk1n06WvJ YZDQ== X-Received: by 10.180.160.240 with SMTP id xn16mr6581599wib.62.1375093530620; Mon, 29 Jul 2013 03:25:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.240 with SMTP id xn16mr6581591wib.62.1375093530559; Mon, 29 Jul 2013 03:25:30 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Mon, 29 Jul 2013 03:25:30 -0700 (PDT) In-Reply-To: <51F56C79.3020503@goodadvice.pages.de> References: <51F401CE.9080803@stpeter.im> <51F56C79.3020503@goodadvice.pages.de> Date: Mon, 29 Jul 2013 11:25:30 +0100 Message-ID: From: Michael Procter To: Philipp Hancke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmEuJzwWJDAlF1KZ17M2X8xSFfij3vXZa98NOFaNRI5ds6Zg/Npf3IQ7lKYCNOt6+WyVAif9RxuABvLaQHwQnSS3Q0aaaAScCAv6j+EdjInfsEc0c6MVAn862OHz3EoAaGGUNeP Cc: posh@ietf.org Subject: Re: [POSH] Comments/questions on draft-miller-posh-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: Mon, 29 Jul 2013 10:25:50 -0000 On 28 July 2013 20:09, Philipp Hancke wrote: > Am 27.07.2013 19:22, schrieb Peter Saint-Andre: > >>> Similarly, I can't see anything obviously wrong with letting the >>> application handshake complete, then performing the POSH >>> operations before deciding the application connection is not >>> suitable and should be terminated before being used. Is the MUST >>> in this section mandating the order of operations necessary for >>> some other reason? >> >> >> As mentioned above, the MUST here is perhaps a bit silly because it's >> so obvious. I think there is a better way to word it... > > > It isn't. In server-to-server XMPP what is typically done is to let the tls > handshake succeed and only offer sasl external if the peer certificate is > "valid". The same could be done for POSH... after the handshake is complete, > look at the verification result. If it is valid, send stream features > including external; if not, do the POSH dance. Thanks, Philipp. That is the sort of scenario I was thinking about, which is why I questioned the MUST. Doing the POSH lookup after the TLS handshake seems fine, as long as the application doesn't try to use the not-yet-verified connection until POSH completes. I can't think of a protocol reason why the TLS handshake must be held off until POSH completes, unless you wish to withold a client cert until the server is trusted. That obviously doesn't apply if you aren't doing mutual auth. Regards, Michael From michael@voip.co.uk Mon Jul 29 03:35: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 5AE2821F9DB2 for ; Mon, 29 Jul 2013 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 K9oZWpsfTzRy for ; Mon, 29 Jul 2013 03:35:00 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with SMTP id BC9B121F9D7B for ; Mon, 29 Jul 2013 03:34:59 -0700 (PDT) Received: from mail-wi0-f178.google.com ([209.85.212.178]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUfZFU3Rhy8Gbfy5QsIc3+oR6gMjeX5J4@postini.com; Mon, 29 Jul 2013 03:34:59 PDT Received: by mail-wi0-f178.google.com with SMTP id j17so2308525wiw.17 for ; Mon, 29 Jul 2013 03:34:58 -0700 (PDT) X-Google-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:x-gm-message-state; bh=YaiFohOZnXzxVWDL3moM4Ab9mpt+peLzZWKEBgq9TLk=; b=peBkj0wGhlUP4dGboCX8h6RGLf0BrrC4/JmIKFAzs11HI0RRnLU4Frv8ZUwn3EyWOg cxD4Dbgg4f1YrTrEWs34VeD9QYRnIOAm9Rn9SCDDfBnz6wJUqBHZR3u0wS3n9eAvcN9/ /4Di9OyWOOffFMhcGiyYSxzWsRN1/MTZQVm2XHadLh43MVoFgjTmv7zibwi2qHWHc7ji CZO4akS059pQFMgc0e4Qh5Vs111vNmcOLOSIKsPV4p5u+ria3eBKuJBj0azWdxjNRT5O rcmXxGMayk4I8pbpp3Q4CSa2nraJkmpnQfVs5VYI1eRZwIgmapiycIyezXsenXaIBjGi EkOw== X-Received: by 10.180.38.45 with SMTP id d13mr6610615wik.62.1375094098208; Mon, 29 Jul 2013 03:34:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.38.45 with SMTP id d13mr6610554wik.62.1375094096951; Mon, 29 Jul 2013 03:34:56 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Mon, 29 Jul 2013 03:34:56 -0700 (PDT) In-Reply-To: <51F56C79.3020503@goodadvice.pages.de> References: <51F401CE.9080803@stpeter.im> <51F56C79.3020503@goodadvice.pages.de> Date: Mon, 29 Jul 2013 11:34:56 +0100 Message-ID: From: Michael Procter To: Philipp Hancke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnCcX0pmrKldRyl4v3RL4vuXnOoe5Vq6hMvo9z3oMrm5tUQRTBafm017rpNSZEHsmbPDO75JVKJl2G7fymXyLdpKaPR8ODWi0v8MXarwjQopd8wd5nus0awbzriBg7lvvKOYwB Cc: posh@ietf.org Subject: Re: [POSH] Comments/questions on draft-miller-posh-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: Mon, 29 Jul 2013 10:35:00 -0000 On 28 July 2013 20:09, Philipp Hancke wrote: > Am 27.07.2013 19:22, schrieb Peter Saint-Andre: > >>> Similarly, I can't see anything obviously wrong with letting the >>> application handshake complete, then performing the POSH >>> operations before deciding the application connection is not >>> suitable and should be terminated before being used. Is the MUST >>> in this section mandating the order of operations necessary for >>> some other reason? >> >> >> As mentioned above, the MUST here is perhaps a bit silly because it's >> so obvious. I think there is a better way to word it... > > > It isn't. In server-to-server XMPP what is typically done is to let the tls > handshake succeed and only offer sasl external if the peer certificate is > "valid". The same could be done for POSH... after the handshake is complete, > look at the verification result. If it is valid, send stream features > including external; if not, do the POSH dance. Thanks, Philipp. That is the sort of scenario I was thinking about, which is why I questioned the MUST. Doing the POSH lookup after the TLS handshake seems fine, as long as the application doesn't try to use the not-yet-verified connection until POSH completes. I can't think of a protocol reason why the TLS handshake must be held off until POSH completes, unless you wish to withold a client cert until the server is trusted. That obviously doesn't apply if you aren't doing mutual auth. Regards, Michael From michael@voip.co.uk Mon Jul 29 03:42:04 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 6D30421F9F59 for ; Mon, 29 Jul 2013 03:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 F+fN7h26wcHW for ; Mon, 29 Jul 2013 03:42:04 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id DA1BE21F994B for ; Mon, 29 Jul 2013 03:42:03 -0700 (PDT) Received: from mail-wg0-f54.google.com ([74.125.82.54]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUfZG+wJ7ptviMnJ2YRcYtU2tjmh2oGaI@postini.com; Mon, 29 Jul 2013 03:42:04 PDT Received: by mail-wg0-f54.google.com with SMTP id n11so1618353wgh.33 for ; Mon, 29 Jul 2013 03:42:02 -0700 (PDT) X-Google-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:x-gm-message-state; bh=YaiFohOZnXzxVWDL3moM4Ab9mpt+peLzZWKEBgq9TLk=; b=S5MKyBcnEpACu4Fg0e1KpZOA5T7kvxj0/w1AEORh/axYjLwu70AEIv+uD8nrq34VX7 Viblc0iLW6AmHPIHYTlvp0OtALbJ108mkyv+/OK5LuMi2aJBNNm4E6em/nTsyemLkkDF zHYap5JG+fCnBZs3Y8hIyengZ0rDmQFk9bkuwzaRXNHkMEn85Vf/iB1p7aSFfdeM5LsP 5N/GT4YGvmrxcrJbAyf9jihMbVEL4p7IBl+PgexoVC76aoUSyctUl5Z7ex+1SX3pVNwg ObipDb4q/s+n7juOuzRL9SJDDlZZwndnHSUODgQnqoj3+KaDpdg1qh9wflZObJkZLSAj 712Q== X-Received: by 10.194.157.198 with SMTP id wo6mr42974215wjb.60.1375094522445; Mon, 29 Jul 2013 03:42:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.198 with SMTP id wo6mr42974212wjb.60.1375094522391; Mon, 29 Jul 2013 03:42:02 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Mon, 29 Jul 2013 03:42:02 -0700 (PDT) In-Reply-To: <51F56C79.3020503@goodadvice.pages.de> References: <51F401CE.9080803@stpeter.im> <51F56C79.3020503@goodadvice.pages.de> Date: Mon, 29 Jul 2013 11:42:02 +0100 Message-ID: From: Michael Procter To: Philipp Hancke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmUvxcZJ5oJ5qXz+70j6OW84kLkc04e5ZeToUoQNBxKiS384Ugug3LmF5+m+1kR6ak3fY0QkEyJT8pA4LbxH8bJXiHcpMDBQEykoInrefyn8LA/lTBddodQd4BbrO5KM9rjriLw Cc: posh@ietf.org Subject: Re: [POSH] Comments/questions on draft-miller-posh-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: Mon, 29 Jul 2013 10:42:04 -0000 On 28 July 2013 20:09, Philipp Hancke wrote: > Am 27.07.2013 19:22, schrieb Peter Saint-Andre: > >>> Similarly, I can't see anything obviously wrong with letting the >>> application handshake complete, then performing the POSH >>> operations before deciding the application connection is not >>> suitable and should be terminated before being used. Is the MUST >>> in this section mandating the order of operations necessary for >>> some other reason? >> >> >> As mentioned above, the MUST here is perhaps a bit silly because it's >> so obvious. I think there is a better way to word it... > > > It isn't. In server-to-server XMPP what is typically done is to let the tls > handshake succeed and only offer sasl external if the peer certificate is > "valid". The same could be done for POSH... after the handshake is complete, > look at the verification result. If it is valid, send stream features > including external; if not, do the POSH dance. Thanks, Philipp. That is the sort of scenario I was thinking about, which is why I questioned the MUST. Doing the POSH lookup after the TLS handshake seems fine, as long as the application doesn't try to use the not-yet-verified connection until POSH completes. I can't think of a protocol reason why the TLS handshake must be held off until POSH completes, unless you wish to withold a client cert until the server is trusted. That obviously doesn't apply if you aren't doing mutual auth. Regards, Michael From stefan.winter@restena.lu Mon Jul 29 08:26: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 5C7B621F9DA5 for ; Mon, 29 Jul 2013 08:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=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 QbE0O32oGZY2 for ; Mon, 29 Jul 2013 08:26:28 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id B15EC21F994C for ; Mon, 29 Jul 2013 08:26:18 -0700 (PDT) Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 44C79EA801 for ; Mon, 29 Jul 2013 17:26:11 +0200 (CEST) Received: from viper.local (unknown [158.64.15.193]) by smtp.restena.lu (Postfix) with ESMTPSA id 2CC33EA1F0 for ; Mon, 29 Jul 2013 17:26:11 +0200 (CEST) Message-ID: <51F689A6.3050805@restena.lu> Date: Mon, 29 Jul 2013 17:26:30 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: posh@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: [POSH] Another use case that suffers: RADIUS dynamic peer discovery 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: Mon, 29 Jul 2013 15:26:48 -0000 Hi, sitting in the POSH BoF, I would have had one other use case which suffers the same problems - but having had so many at the mike, I guess sending an email to the list is enough. This is about RADIUS and an almost-finished draft about "Dynamic Server Discovery". The short story is that a RADIUS client gets an email-style username from an end-user, uses DNS (NAPTR -> SRV/A/AAAA) to find a server and then tries to figure out: is that server authoritative for the _domain_ I got as input. The discovery process doesn't particularly care about the hostname, just like in the other use cases. And just like in those, you may operate a RADIUS proxy which deals with multiple domains, none of which are cert-wise under its control. Our problem is a little tougher to crack than those presented IMHO, because: - DNSSEC+DANE doesn't do the job entirely: RADIUS/TLS connections are always mutually authenticated, meaning there's a client cert validation happening - which DANE doesn't specify how to do. We could restrict to using DNSSEC+DANE for server authz+authn, and declare the client part out of scope though. - In the absence of DNSSEC, X.509 service names don't do the job either, because the discovery starts with NAPTR, and it may or may not traverse an SRV in the middle; and even if it does, the input to SRV lookup is untrusted (someone might have manipulated the preceding NAPTR already). Our solution (or what I currently think is the solution) is to have a new cert property that encodes the _domain name_ just for the specific AAA use case. We call our domains "NAI realms", so what I was trying to get from PKIX folks is a subjectAltName:nAIRealm property. This would contain the realm and only delegate trust for the NAI realm of a domain to the cert holder, not of the entire domain per se. I understand from the SIP presentation that this will hit the ground hard if you expect actual commercial CAs to issue certs with such a name, but that's less an issue… RADIUS is typically run for (closed-group) roaming consortia which can agree on their own CAs. And the certs are validated in a machine-to-machine manner from RADIUS clients to RADIUS servers, not by end-users. I don't have the name from PKIX yet, still being discussed. If POSH had a less intrusive way of solving this, do go ahead :-) I'll read the draft. Greetings, Stefan Winter From fippo@goodadvice.pages.de Wed Jul 31 00:51:06 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 AAB7D11E80AD; Wed, 31 Jul 2013 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 XVRgSfi9ikjl; Wed, 31 Jul 2013 00:50:51 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10021F9F13; Wed, 31 Jul 2013 00:50:51 -0700 (PDT) Received: from [130.129.18.133] (dhcp-1285.meeting.ietf.org [130.129.18.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6V7odNl006225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 09:50:49 +0200 Message-ID: <51F8C1CE.1010701@goodadvice.pages.de> Date: Wed, 31 Jul 2013 09:50:38 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: posh@ietf.org References: <51F401CE.9080803@stpeter.im> In-Reply-To: <51F401CE.9080803@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [POSH] Comments/questions on draft-miller-posh-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, 31 Jul 2013 07:51:07 -0000 Am 27.07.2013 19:22, schrieb Peter Saint-Andre: [...] >> Similarly, I can't see anything obviously wrong with letting the >> application handshake complete, then performing the POSH >> operations before deciding the application connection is not >> suitable and should be terminated before being used. Is the MUST >> in this section mandating the order of operations necessary for >> some other reason? > > As mentioned above, the MUST here is perhaps a bit silly because it's > so obvious. I think there is a better way to word it... While implementing this I found another reason why this MUST doesn't work. In XMPP we want DNA to have the ability to multiplex several domain pairs, with multiple remote domains. However, at the time of the TLS handshake we only know a single remote domain (taken from the stream's from). At any later time, the remote end may use this stuff to add another remote domain. This might trigger the POSH dance and clearly happens after the TLS handshake is done. I would suggest removing this MUST. From mamille2@cisco.com Wed Jul 31 01:19:47 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 2176E21F9ED8; Wed, 31 Jul 2013 01:19:38 -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 mKwdZ3dJ3Ze5; Wed, 31 Jul 2013 01:19:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D298221F9926; Wed, 31 Jul 2013 01:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8075; q=dns/txt; s=iport; t=1375258732; x=1376468332; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ce2D2l5ln2Ixo4YMdF+p0KNDSOmhs+500y8if15tgto=; b=HgwfOAXnObnw5jsqFR37bja+ODqc9d41RCGe1PqyFZvuM6M6WAyu6Ydq Mn3SINkHV3RGkAuWoqa5iaGrIQ1OYf6xH1BdlEqd6YrlK2Aspz0Wn6Z8G rGN0+QTaI4KzmZzE5Ng728enEWGqxcppIIoTSk0OgK06NPXnFZiMSi+sp Y=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFACLH+FGtJXHB/2dsb2JhbABbgwaBBb4cgRgWdIIkAQEBAwF5BQsCAQgOFCQCMCUCBA4FCAaHfAa4T49NFhsHgxhxA5ASgS2CSZUjgxSBaCMf X-IronPort-AV: E=Sophos;i="4.89,785,1367971200"; d="p7s'?scan'208";a="241677481" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 08:18:51 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6V8Ipet003705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 08:18:51 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 03:18:51 -0500 From: "Matt Miller (mamille2)" To: Philipp Hancke Thread-Topic: [POSH] Comments/questions on draft-miller-posh-00 Thread-Index: AQHOieYn3zcp/gJiFUS1gabrGyMGtpl5G7oAgAWplgCAAAfhAA== Date: Wed, 31 Jul 2013 08:18:50 +0000 Message-ID: References: <51F401CE.9080803@stpeter.im> <51F8C1CE.1010701@goodadvice.pages.de> In-Reply-To: <51F8C1CE.1010701@goodadvice.pages.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.77.137] Content-Type: multipart/signed; boundary="Apple-Mail=_3AB2945B-0B72-416B-B783-F10050DB8279"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , XMPP Working Group Subject: Re: [POSH] Comments/questions on draft-miller-posh-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, 31 Jul 2013 08:19:48 -0000 --Apple-Mail=_3AB2945B-0B72-416B-B783-F10050DB8279 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2013, at 9:50 AM, Philipp Hancke wrote: > Am 27.07.2013 19:22, schrieb Peter Saint-Andre: > [...] >>> Similarly, I can't see anything obviously wrong with letting the >>> application handshake complete, then performing the POSH >>> operations before deciding the application connection is not >>> suitable and should be terminated before being used. Is the MUST >>> in this section mandating the order of operations necessary for >>> some other reason? >>=20 >> As mentioned above, the MUST here is perhaps a bit silly because it's >> so obvious. I think there is a better way to word it... >=20 > While implementing this I found another reason why this MUST doesn't = work. >=20 > In XMPP we want DNA to have the ability to multiplex several domain = pairs, with multiple remote domains. >=20 > However, at the time of the TLS handshake we only know a single remote = domain (taken from the stream's from). >=20 > At any later time, the remote end may use this stuff to = add another remote domain. This might trigger the POSH dance and clearly = happens after the TLS handshake is done. >=20 > I would suggest removing this MUST. These are all good points. I will note that there is general queasiness with suspending disbelief = on a connection, accepting the TLS handshake but then actually verifying = (and potentially failing) the connection because of TLS failings; not = the least of which is the potential for abuse is very very great. This = also means that any error reporting that one might get from their TLS = implementations for better error reporting is lost. However, the multiplexing case is important for XMPP (not sure about = others). We need to allow for that to work. I'll confer with my co-author, and we'll try to come up with some text = that preserved the intent without being overly constricting. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_3AB2945B-0B72-416B-B783-F10050DB8279 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 oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MzEwODE4 NTBaMCMGCSqGSIb3DQEJBDEWBBTF/F2OFdZoc+EVBpUd9w2CmHN6kDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBADMC 1CKSVEB7W64wrm0qm1RQiRs6G/XCgu3L6y5ptCuqTpCA4An1spHklUFq79A0Z9ermYSJtlgGBGm7 lBJ9Va/d7h8ZjL/wy6AWwKvXEDW0L+wDiaP0YdJkVrAr7lo2dK0PmZMxq/1KrMi0Nu2e+tdrEL7h QrIcjFmN4OhCrqhinhu4UttMuK9AN+RGzt321s2NZe/rjCwLcvkmi/KG6rgpcfuDFFdeh3K3H6JR xgjFVQQxfXqWxn95WwutnNhWhwHXDcTyy4Lo4V+nNOYcrIRO+WMecpCyxZ7u/XN2/1kukCU3MKvP nMR7AQUblU66116nfAPeACyeAi9OcqVG6xMAAAAAAAA= --Apple-Mail=_3AB2945B-0B72-416B-B783-F10050DB8279-- From dave@cridland.net Wed Jul 31 02:09: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 BEB8111E8147 for ; Wed, 31 Jul 2013 02:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 BLY5TcxIJHSY for ; Wed, 31 Jul 2013 02:09:44 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 52CEC11E817E for ; Wed, 31 Jul 2013 02:01:34 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so302228lab.22 for ; Wed, 31 Jul 2013 02:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FWkkp9P/ywka76bKnBeAkdZiGAGloyWNgtHp6uwAGp0=; b=Bq9jtxZX50c0jsVIySUX/AIADjYZBIP8Yd+1YiX4+jFa/8bk78K0jq/Tas2P53gjCL N9CV5+zxX4XQTGfQ1cMJykdtByuXriKSa7bM+xJbp4wECKgct18svNwmrOWGBL5Yzdfp rdQinfLRgtlO8xM1iKWJfCUeD7hXqiAcogzr8= X-Google-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:x-gm-message-state; bh=FWkkp9P/ywka76bKnBeAkdZiGAGloyWNgtHp6uwAGp0=; b=bR3ptlug+C+TsT733fzSgUlqXZG2gEOSZdoZewrzXtaiU4WChbMWTKNSv9PpfEIaKI n4xlJdQOMXXrzNoUZ7jlrSa4TvLzqUvPhA/GEsRd4kynicVuDUaNS87eR1MARrDOAF/5 WgjMujnAkc+xzEEqnXvUXUJBIa7qmMlpd4NVhQaIENU0s1ti2pNnTmWd+XtABXtN3lXk sFqr3IXlhX1MUqE1ksdUxwMzD9+YXbjzNW+VM2RQ3hKErsjyvjwWadJ3I2BquJ1f0N+C 9KFwmkfRq303QjfhQ54nT29x1O72QJCL3lfFcFAUcn3zEfsqXsT4mPip1sF8i5StdFQZ 4EPQ== MIME-Version: 1.0 X-Received: by 10.112.185.36 with SMTP id ez4mr6704224lbc.81.1375261280888; Wed, 31 Jul 2013 02:01:20 -0700 (PDT) Received: by 10.114.184.137 with HTTP; Wed, 31 Jul 2013 02:01:20 -0700 (PDT) In-Reply-To: References: <51F401CE.9080803@stpeter.im> <51F8C1CE.1010701@goodadvice.pages.de> Date: Wed, 31 Jul 2013 10:01:20 +0100 Message-ID: From: Dave Cridland To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=001a11c3cc1c1ef7d604e2caf8e8 X-Gm-Message-State: ALoCoQm2tQfKRm+fda8Am4bCppWlaTFLTZyBLKjIsCpZ3jnHXeUdt5fsybl0sVBDutGc639NuLjE X-Mailman-Approved-At: Wed, 31 Jul 2013 03:36:24 -0700 Cc: Philipp Hancke , "" , XMPP Working Group Subject: Re: [POSH] [xmpp] Comments/questions on draft-miller-posh-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, 31 Jul 2013 09:09:46 -0000 --001a11c3cc1c1ef7d604e2caf8e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 9:18 AM, Matt Miller (mamille2) wrote: > I will note that there is general queasiness with suspending disbelief on > a connection, accepting the TLS handshake but then actually verifying (and > potentially failing) the connection because of TLS failings; not the least > of which is the potential for abuse is very very great. This also means > that any error reporting that one might get from their TLS implementations > for better error reporting is lost. > If there is queasiness here it's misplaced. The case for abuse here is predicated on the TLS handshake being the authorization, which it is not in any SASL based protocol. So in XMPP, we must already perform auth during the SASL exchange, and during the , too. If you have a protocol which conflates authentication and authorization, of course, then the situation is different. --001a11c3cc1c1ef7d604e2caf8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2013 at 9:18 AM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:
I will note that there is general queasiness= with suspending disbelief on a connection, accepting the TLS handshake but= then actually verifying =A0(and potentially failing) the connection becaus= e of TLS failings; not the least of which is the potential for abuse is ver= y very great. =A0This also means that any error reporting that one might ge= t from their TLS implementations for better error reporting is lost.

If there is queasiness here it's mispl= aced. The case for abuse here is predicated on the TLS handshake being the = authorization, which it is not in any SASL based protocol.

So in XMPP, we must already perform auth during the SASL exchang= e, and during the <db:result/>, too.

If you = have a protocol which conflates authentication and authorization, of course= , then the situation is different.
--001a11c3cc1c1ef7d604e2caf8e8-- From stpeter@stpeter.im Wed Jul 31 06:39:04 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 3752721F9FFC for ; Wed, 31 Jul 2013 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 OPGy8BFEp-eO for ; Wed, 31 Jul 2013 06:38:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A01BC21E804B for ; Wed, 31 Jul 2013 06:38:59 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D3D440046; Wed, 31 Jul 2013 07:41:12 -0600 (MDT) Message-ID: <51F9136F.7020609@stpeter.im> Date: Wed, 31 Jul 2013 15:38:55 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Cridland References: <51F401CE.9080803@stpeter.im> <51F8C1CE.1010701@goodadvice.pages.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Philipp Hancke , "" , "Matt Miller \(mamille2\)" Subject: Re: [POSH] [xmpp] Comments/questions on draft-miller-posh-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, 31 Jul 2013 13:39:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ removing xmpp@ietf.org since this is a general issue ] On 7/31/13 11:01 AM, Dave Cridland wrote: > On Wed, Jul 31, 2013 at 9:18 AM, Matt Miller (mamille2) > > wrote: > > I will note that there is general queasiness with suspending > disbelief on a connection, accepting the TLS handshake but then > actually verifying (and potentially failing) the connection > because of TLS failings; not the least of which is the potential > for abuse is very very great. This also means that any error > reporting that one might get from their TLS implementations for > better error reporting is lost. > > > If there is queasiness here it's misplaced. The case for abuse here > is predicated on the TLS handshake being the authorization, which > it is not in any SASL based protocol. > > So in XMPP, we must already perform auth during the SASL exchange, > and during the , too. > > If you have a protocol which conflates authentication and > authorization, of course, then the situation is different. I don't think we want POSH to be limited to SASL application protocols. 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/ iQIcBAEBAgAGBQJR+RNvAAoJEOoGpJErxa2p86cP/2EEGUrGmRUEyJpSefdN4/hx MwLJUrtiBvR7Cj0clHYPguJ4YVRFvFKLwDDJ4aXxup725PTSXx7bfj1KVRw4cYej 8EB9i8iiJXIEUnMYYAhMcNxIHCnUSIETl2xpBU/A346+KNNDud+pITWGDf7jzWtP bIDoN3tjqXna9u4wvrtmE3fLkNEPGvkO/2RkhdmTkcJYrCrf5Jj9CeJwGB9bXCsX Cp7f1npqYKqj9kDe2Gslszo0nz/2etmHXR4/8/PWiCGafN/IM+moDv19InKByX5B PkXiaV0YpWu/eEO6Ty43Af3dWxoat4xAMu854MDRqpTlyo4HgXZ0P4paUYV/czCA X6Mfg1pf/Cgw1QoqGfY5syaGmRjCB0UBoRrMsNyTExfUEzJPIjZMtoL9vE/Yxvvo OGQo/5sLvMOM+UboGR+iOg7rAESxVSkemiA8rD2YmKY5k2PCSDqPLNrloaG9js1n PtBwHxUxnsUZyTEw/UEW3EYVD4k5WAUcqfeCd+/HV7VekWgPn6EFzPVOI/2C7WQ8 rCwF+hXRIePCzR276lcu24ab9BA8zwigKoXcLCEgnLcQwc1MDTVfSInoCh5n2G9q W3GAOePyZkcSgZ5f8vovuyRz7eGYsHeSd4DKTK3fLLfCVoQzslOJoR1ihYmN3R1y e+YmIqBnKpCOJ9YzQYNq =Sjm8 -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Wed Jul 31 07:14:03 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 D8CBB11E81B8 for ; Wed, 31 Jul 2013 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 Xso4Y6u8PdF6 for ; Wed, 31 Jul 2013 07:13:58 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 896A111E81BE for ; Wed, 31 Jul 2013 07:13:57 -0700 (PDT) Received: from [130.129.18.133] (dhcp-1285.meeting.ietf.org [130.129.18.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6VEDlqW013800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 16:13:52 +0200 Message-ID: <51F91B9B.1090700@goodadvice.pages.de> Date: Wed, 31 Jul 2013 16:13:47 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <51F401CE.9080803@stpeter.im> <51F8C1CE.1010701@goodadvice.pages.de> <51F9136F.7020609@stpeter.im> In-Reply-To: <51F9136F.7020609@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Matt Miller \(mamille2\)" , "" , Dave Cridland Subject: Re: [POSH] [xmpp] Comments/questions on draft-miller-posh-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, 31 Jul 2013 14:14:04 -0000 Am 31.07.2013 15:38, schrieb Peter Saint-Andre: [...] > I don't think we want POSH to be limited to SASL application protocols. Nor do we want it to be limited to non-multi-tenant usecases.