Re: [TLS] External PSK importers
Christian Huitema <huitema@huitema.net> Tue, 30 October 2018 19:02 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5BC130E4D for <tls@ietfa.amsl.com>; Tue, 30 Oct 2018 12:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji8DnesKXkt8 for <tls@ietfa.amsl.com>; Tue, 30 Oct 2018 12:02:38 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B1793130DFD for <tls@ietf.org>; Tue, 30 Oct 2018 12:02:37 -0700 (PDT)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx65.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gHZHe-0006BN-NH for tls@ietf.org; Tue, 30 Oct 2018 20:02:36 +0100
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1gHZHY-0006w3-DB for tls@ietf.org; Tue, 30 Oct 2018 15:02:32 -0400
Received: (qmail 12694 invoked from network); 30 Oct 2018 19:02:23 -0000
Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 30 Oct 2018 19:02:22 -0000
To: Russ Housley <housley@vigilsec.com>
Cc: IETF TLS <tls@ietf.org>
References: <D8741E2F-9D4B-4405-8A73-33CDD39F2857@apple.com> <CABkgnnXwPRdcwPATaWMpvCb8NdDLBbWEzu9RmxJb0iPwUL75Jg@mail.gmail.com> <1a5c2d42-4232-b7b1-27a0-97c2b033129c@huitema.net> <7DE67484-DF67-47CF-9934-CB44F61D1EA0@vigilsec.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <ebcbafaf-ec2c-24c9-e481-2112882ff9fd@huitema.net>
Date: Tue, 30 Oct 2018 12:02:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7DE67484-DF67-47CF-9934-CB44F61D1EA0@vigilsec.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.177
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.36)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5h0tWPG0hFaC5t1vpuAhB+5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxDxOulR1IrpZ94p+U7GOZIUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2cFBJ33PyTEulbj2AjstEIPvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtGgdQZXRisyliedf3wwG/i2qU6J8I9awOrPXuYGgz3WgHzKXU aRMqx/iV8P/ENaGyxxyuvB0jWb+i2PkgrNx3bPBWi14qeT2rPZ1/13TrXXs1uSg37woMz0RVvZDr sV8LYWIsgJuhzJxUTB9lxDN+Gp+9VMhAJkmEVg2pGJQCagDTBN5UXzuTNxOoOql1SHXYelGAATxC ZqJIDFYhDesXleccPtSRk0m/kQt358TQfZrY5Qx4fJOk03R5fJtf/Dv/2WNBsAy8Nv289m/zQuaH eERE5KNIYL4TOer9CexvGTH1Q9wOZPbbCAV5E1ncBg4FMv/GVRtkwgTXqRFVk6En6J28dFabfd7P HaYFsN2d6vI69TdE5SQ4dxJir0Y8rHr0CnFV4ppbCSIV+5MQOIhZDwZx+7akvXuW0uKgP4xcS0Yf /ZWJrKdeszZmTOPanuiaJuyN28CJzjT5weLgu0H3IAf6YE745piwblNU2qurWrnsn9mE+fGN0lc+ e/EYlJJDfMmwr0h6gpRCxy4/rMf5kU8byrGRBbWsaDFa8gBatH6LjIhcApHEq6VJj+GinOstdpOr kslJz3mJvCTcshirSG05iiatprOXw9FbZg9TYU/x3fBWJlKQxl5A/NUiEbAJT6hiIcrBPOkAxAXv 937MUfLd14/y82ebPziYNS9mrGeruXSJR3Z0Vju70hqF5YH+Tu89+T1gK4F4f0LxqBVlR4hU8Mt6 1NIE13FQzIlTV40=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6WmZbQ3WXw-vQ3rvRTOHd9msisM>
Subject: Re: [TLS] External PSK importers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 19:02:51 -0000
On 10/30/2018 4:07 AM, Russ Housley wrote: >> On Oct 30, 2018, at 2:26 AM, Christian Huitema <huitema@huitema.net> wrote: >> >> On 10/29/2018 9:56 PM, Martin Thomson wrote: >> >>> You should do something more concrete with the label parameter. Keep >>> in mind that both client and server need to agree on a use for this, >>> so my initial intuition to put the server identity might not work, but >>> it could be a start. The problem being that how the client identifies >>> the server might not be something it shares with the server. >> There is also a privacy issue with the external identifiers. For session >> tickets, this is solved by only using a given resume ticket once, but >> that's harder with external PSK. > Christian: > > Proclaiming that you have access to a particular external PSK may reveal that you as part of a group. I do not see a way to completely avoid this because the PSK is input to the key schedule at the very top. Thus, there is no key that could be used to encrypt it. You do have a shared secret, the PSK itself. In the DNS SD privacy proposal, we construct an obfuscated key identifier as base64(nonce|truncated(hash(nonce|PSK))). In the simplest form, the nonce is chosen randomly by the client, and the server has to try all available keys until it finds one that matches. We were worried about the compute cost of many trials, so we specified a "predictable nonce" set to a "rounded time" -- in our case, the most significant 24 bits of the 32 bit Unix time. The server would only have to compute the set of hashes and potential identifiers once per time interval. But that's of course a trade-off between obfuscation and compute costs. We were somewhat concerned about replay attacks, but that's a general problem with PSK. An attacker could repeat the client hello, and see whether the server's response provides information about the server identity. Hopefully, TLS 1.3 takes care of that. My point however is not to propose specific solutions, but rather to ensure that the documents that we produce acknowledges the privacy concerns with key identifiers. Once we agree that this is indeed an issue, we can debate the appropriate solution. -- Christian Huitema
- [TLS] External PSK importers Christopher Wood
- Re: [TLS] External PSK importers Martin Thomson
- Re: [TLS] External PSK importers Christian Huitema
- Re: [TLS] External PSK importers Russ Housley
- Re: [TLS] External PSK importers Christian Huitema