From nobody Wed Jun 22 14:39:32 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0588512DD38 for ; Wed, 22 Jun 2016 14:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncUeCFCS8wqH for ; Wed, 22 Jun 2016 14:39:28 -0700 (PDT) Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B6E12D991 for ; Wed, 22 Jun 2016 14:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding; bh=QDku8qyU6QCHf1+Amimch4CQdEGTN1HPas4xOomtoxA=; b=YtnxqDnLhcwkCXGy+pu3UAJ/hjhjO7PKopcrrdunfQYvQ8HCwRCRAmeywZOo809sd+B93OQY++zbZ zXgUYo6MVGD839UKexL7Eo7EUlxDeqUD/ncckkUFuLQypqhTc27j1PC67DUw6HPErOd6CkEtTAQBam ZToI14vCpTIq7KRQ= X-HalOne-Cookie: 5ca078c0160d77276743912f44628a3bc43f3df4 X-HalOne-ID: 9d8e55cf-38c1-11e6-9f37-b82a72d06996 Received: from smtp.dmfs.org (unknown [217.234.107.6]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Wed, 22 Jun 2016 21:38:10 +0000 (UTC) Received: from localhost.localdomain (p5DDABB85.dip0.t-ipconnect.de [93.218.187.133]) by smtp.dmfs.org (Postfix) with ESMTPSA id 987B52F5 for ; Wed, 22 Jun 2016 23:32:36 +0200 (CEST) Message-ID: <576B0541.7040708@dmfs.org> Date: Wed, 22 Jun 2016 23:38:09 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [websec] Service auto-configuration and certificate pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:39:31 -0000 Hi list, I'm currently working on an update of a draft that specifies a way for clients to configure themselves with a minimum of user-provided information. The current draft is available at https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 (it's a bit outdated, but we're working on it). This draft specifies a member to contain a server certificate, which presumably was meant to support some sort of certificate pinning. During my research on how to improve this I came across RFC 7469 and https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 I'd like to ask the members of this list whether they think that "bootstrapping" certificate pinning for individual services (like so: https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982) would be useful to have in a service configuration document or if they have any concerns or other comments about this. I'd also like to hear about opinions if this could be an acceptable solution for certificate pinning with non-HTTP based protocols, i.e. for protocols that don't have an in-band pinning mechanism the client would reload the service configuration document whenever the cached pinning information is outdated (i.e. seconds have passed since it was downloaded). Any comments (whether in response to this post or at GitHub) are very welcome. Regards, Marten Gajda -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Thu Jun 23 01:54:38 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10112DF80 for ; Thu, 23 Jun 2016 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_fC_6OPhy4R for ; Thu, 23 Jun 2016 01:54:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC78A12DF7D for ; Thu, 23 Jun 2016 01:54:34 -0700 (PDT) Received: from [194.53.161.129] by 3capp-gmx-bs77.server.lan (via HTTP); Thu, 23 Jun 2016 10:54:31 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Marten Gajda" Content-Type: text/html; charset=UTF-8 Date: Thu, 23 Jun 2016 10:54:31 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <576B0541.7040708@dmfs.org> References: <576B0541.7040708@dmfs.org> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:C1ux6Rdo7gBwk+JuFYwTukXOEUt/uJZSDoEI5bXffil pIRtYykjH94bi9mPqumz+2ovs2ibmAoEW6+7o5Izdho3j2xzGz 9hb3sLaZDmOrebsD1tqK8wCCYGDd1bmUFv3KHfpc/V8F7bzjzu V/K3GzF2LA9Q5UB5EGSPTlfuFNxVFGtK/zAEmvdoYc9YWPxS4W sjB/d7zUBR2YvSAfZUZ9EbmEpua14HYJUPEmn3HjmtrEy7ExfR irk6oUwXb6FMTPkUGMk+TQoIOsS3mTPs7B+qumyIXLc0VUI09p yZyFq4= X-UI-Out-Filterresults: notjunk:1;V01:K0:TJABIOueuYM=:VWv6zLsKP148XD0iBPQJAL wrVxVGQNyMvTsUmEJLy518L57+pIhLqIWqgMf88ZrPH9udThos4pVgF196KcTFToc2NatRr0a dYOSEXZcF3NZvQNF0tEfTE9JdNriWkJhqJY3WDybnqLzzuSghE9KweKYrpc7oNkBwkMyMVPzy nhuOaWDGBEAG02+lInBLyuglvKjsVKyJQQn+T8HSXhKYpDmV+2CQu5nuNgOygWFhMjy1tQcFh 7oju5pXPXydVBkwogZkFBRVbuQdVt1VL4N5I4Y4hbD3IKEg8ppkOu9CZEfSRZ30cMg6ACM/UK a2o4dZbkOov0J1CASZijQ++6LhN1yqTzwT5Yn8NoiI9uc8MYfChJep0yB5rQwqhWoOZshFh0q mOsiGc/1efAyPdfanfqsRGIwsV08dWmGspZuAcjINosVsfhlQ7RgFe0W2uxWElazTJvwFCFg5 H2kjZziZGw== Archived-At: Cc: "websec@ietf.org" Subject: Re: [websec] Service auto-configuration and certificate pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:54:37 -0000
Hello Marten,
 
it might be of interest to check out the 'Unbearable' group. they are working on pinning bearer certficates.
 
Regards
Dean Rogers
Gesendet: Mittwoch, 22. Juni 2016 um 23:38 Uhr
Von: "Marten Gajda" <marten@dmfs.org>
An: "websec@ietf.org" <websec@ietf.org>
Betreff: [websec] Service auto-configuration and certificate pinning
Hi list,

I'm currently working on an update of a draft that specifies a way for
clients to configure themselves with a minimum of user-provided
information. The current draft is available at
https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03
(it's a bit outdated, but we're working on it).
This draft specifies a member to contain a server certificate, which
presumably was meant to support some sort of certificate pinning.

During my research on how to improve this I came across RFC 7469 and
https://tools.ietf.org/html/draft-hallambaker-webseccaa-00

I'd like to ask the members of this list whether they think that
"bootstrapping" certificate pinning for individual services (like so:
https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982)
would be useful to have in a service configuration document or if they
have any concerns or other comments about this.

I'd also like to hear about opinions if this could be an acceptable
solution for certificate pinning with non-HTTP based protocols, i.e. for
protocols that don't have an in-band pinning mechanism the client would
reload the service configuration document whenever the cached pinning
information is outdated (i.e. <max-age> seconds have passed since it was
downloaded).

Any comments (whether in response to this post or at GitHub) are very
welcome.

Regards,

Marten Gajda

--
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
From nobody Thu Jun 23 02:20:01 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DEA12E12F for ; Thu, 23 Jun 2016 02:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wCl80i3cURp for ; Thu, 23 Jun 2016 02:19:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5C012E138 for ; Thu, 23 Jun 2016 02:14:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DBC1BE3E; Thu, 23 Jun 2016 10:14:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8ykTf0GpIgc; Thu, 23 Jun 2016 10:14:26 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C534FBE80; Thu, 23 Jun 2016 10:14:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466673243; bh=Xb2S64S+8ujYUy5cBjRzHF8HnGhU3Ik3/KQ64PLFkN4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DoPFqv7hDtMjnrsCLYS2M96j74KKW7uaiCavB1wxGSNFr+5+3wRSDdDR043HIaIoE CDotI+UitteSv+WSe7ceG09bnLlllNXAdENdm+xeNma9Hwum4hVGhzVgJIya/w3d3d kEhMv/9ectXH5WPebGGeSkmLGz+/KNUNyapdOKF0= To: D.Rogers@gmx.net, Marten Gajda References: <576B0541.7040708@dmfs.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <576BA85A.6000507@cs.tcd.ie> Date: Thu, 23 Jun 2016 10:14:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070109040907070609060309" Archived-At: Cc: "websec@ietf.org" Subject: Re: [websec] Service auto-configuration and certificate pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 09:20:00 -0000 This is a cryptographically signed message in MIME format. --------------ms070109040907070609060309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/06/16 09:54, D.Rogers@gmx.net wrote: > Hello Marten, > it might be of interest to check out the 'Unbearable' group. they are w= orking on=20 > pinning bearer certficates. For info: unbearable@ietf.org is the WG mailing list. The working group is more prosaically named tokbind. [1] :-) S. [1] https://tools.ietf.org/wg/tokbind > Regards > Dean Rogers > *Gesendet:* Mittwoch, 22. Juni 2016 um 23:38 Uhr > *Von:* "Marten Gajda" > *An:* "websec@ietf.org" > *Betreff:* [websec] Service auto-configuration and certificate pinning > Hi list, >=20 > I'm currently working on an update of a draft that specifies a way for > clients to configure themselves with a minimum of user-provided > information. The current draft is available at > https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03= > (it's a bit outdated, but we're working on it). > This draft specifies a member to contain a server certificate, which > presumably was meant to support some sort of certificate pinning. >=20 > During my research on how to improve this I came across RFC 7469 and > https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >=20 > I'd like to ask the members of this list whether they think that > "bootstrapping" certificate pinning for individual services (like so: > https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-22785= 7982) > would be useful to have in a service configuration document or if they > have any concerns or other comments about this. >=20 > I'd also like to hear about opinions if this could be an acceptable > solution for certificate pinning with non-HTTP based protocols, i.e. fo= r > protocols that don't have an in-band pinning mechanism the client would= > reload the service configuration document whenever the cached pinning > information is outdated (i.e. seconds have passed since it wa= s > downloaded). >=20 > Any comments (whether in response to this post or at GitHub) are very > welcome. >=20 > Regards, >=20 > Marten Gajda >=20 > -- > Marten Gajda > CEO >=20 > dmfs GmbH > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > GERMANY >=20 > phone: +49 177 4427167 > email: marten@dmfs.org >=20 > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 >=20 >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 --------------ms070109040907070609060309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjMw OTE0MDJaMC8GCSqGSIb3DQEJBDEiBCC2OkdogLCJxPtNtXI469HDMIkx3G4UkOnKMQN4wctS nTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCMbqTT2ah2adbQ3IN4XfVYzyrKnQT7qwDFEX8ZOuZC2T2uCw6eBBZ4 Pueso6dorhpqvzy59ED4iohWKNW1PGlBc3FHX5Zp8ucWJIKR7SW8xYU8FXY0VmnBZMBLGACO laO0WJ+9wNK5ULLF74ke7vRsQWEmnLEQ5yTN9lbKeLlMjg7GrOzmHz78mkG7v9nQq0ZLZAHP U/aLSkqSbiEbcVUU0EP2lhDbIKwKTDN0jNktC/Pd/A+Gqluk+R+ZT4kzzBZ06ifJZ/ung14w Zl7SL5MozB8spQCxfBDlJrnWMv0hOBSkPIo/MUBFSOPJQpTWTmhkDfrMIbvedHzlAGnCUOLI AAAAAAAA --------------ms070109040907070609060309-- From nobody Thu Jun 23 14:26:30 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF6512D684 for ; Thu, 23 Jun 2016 14:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tW-WrTH1pCA for ; Thu, 23 Jun 2016 14:26:27 -0700 (PDT) Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A4112D6A7 for ; Thu, 23 Jun 2016 14:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=FYq8CDoKw44QxSJQ83+bU91Eg3TDHW/KbTC6VXygrkc=; b=m59GgNkKzTDoLQ1p7a22+0Yjd6Eq/clBvsfVz8SBM6VoLI+ddP09WTY+B65ml3+JLsn6MnLTx2WpB a6NHKv9JTKLHKFI5vD8lKTw7sn5nru0i8L4iP2oFmI0fD3HRCyPz8+zO3UgpkC6RExbqz2uRe/maU+ WHlQ3UFBeHJKGdPY= X-HalOne-Cookie: 645bf10ea3a5c79e05c17d6107329d2a07d6becb X-HalOne-ID: 2232a7de-3989-11e6-9f37-b82a72d06996 Received: from smtp.dmfs.org (unknown [217.234.108.208]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 23 Jun 2016 21:26:22 +0000 (UTC) Received: from localhost.localdomain (p5DDABB85.dip0.t-ipconnect.de [93.218.187.133]) by smtp.dmfs.org (Postfix) with ESMTPSA id E0CF534C; Thu, 23 Jun 2016 23:20:43 +0200 (CEST) Message-ID: <576C53FD.20004@dmfs.org> Date: Thu, 23 Jun 2016 23:26:21 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , D.Rogers@gmx.net References: <576B0541.7040708@dmfs.org> <576BA85A.6000507@cs.tcd.ie> In-Reply-To: <576BA85A.6000507@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] Service auto-configuration and certificate pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 21:26:30 -0000 Thanks to the both of you. I'll have a closer look into that. On a first glance it looks indeed very interesting. Cheers, Marten Am 23.06.2016 um 11:14 schrieb Stephen Farrell: > > On 23/06/16 09:54, D.Rogers@gmx.net wrote: >> Hello Marten, >> it might be of interest to check out the 'Unbearable' group. they are working on >> pinning bearer certficates. > For info: unbearable@ietf.org is the WG mailing list. The working > group is more prosaically named tokbind. [1] :-) > > S. > > [1] https://tools.ietf.org/wg/tokbind > >> Regards >> Dean Rogers >> *Gesendet:* Mittwoch, 22. Juni 2016 um 23:38 Uhr >> *Von:* "Marten Gajda" >> *An:* "websec@ietf.org" >> *Betreff:* [websec] Service auto-configuration and certificate pinning >> Hi list, >> >> I'm currently working on an update of a draft that specifies a way for >> clients to configure themselves with a minimum of user-provided >> information. The current draft is available at >> https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >> (it's a bit outdated, but we're working on it). >> This draft specifies a member to contain a server certificate, which >> presumably was meant to support some sort of certificate pinning. >> >> During my research on how to improve this I came across RFC 7469 and >> https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> I'd like to ask the members of this list whether they think that >> "bootstrapping" certificate pinning for individual services (like so: >> https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982) >> would be useful to have in a service configuration document or if they >> have any concerns or other comments about this. >> >> I'd also like to hear about opinions if this could be an acceptable >> solution for certificate pinning with non-HTTP based protocols, i.e. for >> protocols that don't have an in-band pinning mechanism the client would >> reload the service configuration document whenever the cached pinning >> information is outdated (i.e. seconds have passed since it was >> downloaded). >> >> Any comments (whether in response to this post or at GitHub) are very >> welcome. >> >> Regards, >> >> Marten Gajda >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Fri Jun 24 22:46:04 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57012D5DE for ; Fri, 24 Jun 2016 22:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xd1Ydt8F_u6 for ; Fri, 24 Jun 2016 22:46:00 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CFB12D5AD for ; Fri, 24 Jun 2016 22:45:59 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r190so12238059wmr.0 for ; Fri, 24 Jun 2016 22:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Q/t9j8hLN4sH+H35ofwZNFqE9u8cwZACe/bO6RAcauA=; b=n41I7qnGGrUQHbn0c8D2zcH8vC0bruSCkcyr3XguJ5SDLAQO51gK2LNxvFBUjKIPw3 enQ5p57XWyjzIAbmPiNd6a3A27KhPBw8wbJoqHoj3Gx/XqNj0Lpz+EXe01HJc3DhcRhw RB6wJTIQdDgcDM8UNtcyXbl7+Zkr/WdTVRsc1J36RGTmqs+Aexvnv3G1SnASEnMLZrdq PfblNBVM6/2z7WCPQ3JWyrMmIU8SjjAaCE3KAJXYPmpjKznNypiXn0r1HxsO0ExAFdUW Sge54M5M3qRIQd1Xw7Is+19uBVMqGzX75Hro+IlEUNgykRlfwEI2EgMi9s2+XSZRc0be 88aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Q/t9j8hLN4sH+H35ofwZNFqE9u8cwZACe/bO6RAcauA=; b=Md4LdErew+nnlx44+Sk4vLkMV8BuRasGgQ0fGb9XZSq4K+XSjS1cfXPlLGTspfslkq jkeJD968S6wDjw3pdIhazRkpdk3N+Wkxs7jr9Q2W3O55mIX6AS5orEakCLtcL9WkAwmL O9W3eJwnY6TEkc05JLUcMQ1XoCXJgndnEB1QtuyuxZkdk+V4EyoGW/ib0M9kSQSaJoBF 6AS05vqamvq6BAdPrkgK7Skdg32urwVayIAeYEscesQLTrg1xYLaIcxh8JQVEaxQZIEa Hn2CAYxhNXP1wlfYlL9YGR4dHbg5A5ylS01fXDmELJK2fambhBXdZkT4pIxNaBGUxUkZ X7ww== X-Gm-Message-State: ALyK8tIhfNi4aQpA2ykOXKoADKxXqY+IhjR/JQsKOD/LqJSDA3UoQfyxhPXzBQqjZtnvwg== X-Received: by 10.194.23.7 with SMTP id i7mr7385135wjf.57.1466833557862; Fri, 24 Jun 2016 22:45:57 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.gmail.com with ESMTPSA id g195sm1633890wme.23.2016.06.24.22.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 22:45:56 -0700 (PDT) To: Marten Gajda , Stephen Farrell , "D.Rogers@gmx.net" References: <576B0541.7040708@dmfs.org> <576BA85A.6000507@cs.tcd.ie> <576C53FD.20004@dmfs.org> From: Yaron Sheffer Message-ID: <576E1A8A.1030902@gmail.com> Date: Sat, 25 Jun 2016 08:45:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <576C53FD.20004@dmfs.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] Service auto-configuration and certificate pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 05:46:02 -0000 As a totally different alternative for non-HTTP pinning, please take a look at https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/. I the meantime I have also prototyped an implementation by forking the "mint" TLS 1.3 code, https://github.com/yaronf/mint/blob/master/README-pinning.md Thanks, Yaron On 24/06/16 00:26, Marten Gajda wrote: > Thanks to the both of you. I'll have a closer look into that. On a first > glance it looks indeed very interesting. > > Cheers, > > Marten > > Am 23.06.2016 um 11:14 schrieb Stephen Farrell: >> On 23/06/16 09:54, D.Rogers@gmx.net wrote: >>> Hello Marten, >>> it might be of interest to check out the 'Unbearable' group. they are working on >>> pinning bearer certficates. >> For info: unbearable@ietf.org is the WG mailing list. The working >> group is more prosaically named tokbind. [1] :-) >> >> S. >> >> [1] https://tools.ietf.org/wg/tokbind >> >>> Regards >>> Dean Rogers >>> *Gesendet:* Mittwoch, 22. Juni 2016 um 23:38 Uhr >>> *Von:* "Marten Gajda" >>> *An:* "websec@ietf.org" >>> *Betreff:* [websec] Service auto-configuration and certificate pinning >>> Hi list, >>> >>> I'm currently working on an update of a draft that specifies a way for >>> clients to configure themselves with a minimum of user-provided >>> information. The current draft is available at >>> https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >>> (it's a bit outdated, but we're working on it). >>> This draft specifies a member to contain a server certificate, which >>> presumably was meant to support some sort of certificate pinning. >>> >>> During my research on how to improve this I came across RFC 7469 and >>> https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >>> >>> I'd like to ask the members of this list whether they think that >>> "bootstrapping" certificate pinning for individual services (like so: >>> https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982) >>> would be useful to have in a service configuration document or if they >>> have any concerns or other comments about this. >>> >>> I'd also like to hear about opinions if this could be an acceptable >>> solution for certificate pinning with non-HTTP based protocols, i.e. for >>> protocols that don't have an in-band pinning mechanism the client would >>> reload the service configuration document whenever the cached pinning >>> information is outdated (i.e. seconds have passed since it was >>> downloaded). >>> >>> Any comments (whether in response to this post or at GitHub) are very >>> welcome. >>> >>> Regards, >>> >>> Marten Gajda >>> >>> -- >>> Marten Gajda >>> CEO >>> >>> dmfs GmbH >>> Schandauer Straße 34 >>> 01309 Dresden >>> GERMANY >>> >>> phone: +49 177 4427167 >>> email: marten@dmfs.org >>> >>> Managing Director: Marten Gajda >>> Registered address: Dresden >>> Registered No.: AG Dresden HRB 34881 >>> VAT Reg. No.: DE303248743 >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >>> >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>>