Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

Christopher Wood <caw@heapingbits.net> Wed, 19 August 2020 14:28 UTC

Return-Path: <caw@heapingbits.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 248C03A0B03 for <tls@ietfa.amsl.com>; Wed, 19 Aug 2020 07:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=7GIU0KZf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C51aNpqL
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 0UiL87MPo3nM for <tls@ietfa.amsl.com>; Wed, 19 Aug 2020 07:28:39 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8A13A09FA for <tls@ietf.org>; Wed, 19 Aug 2020 07:28:39 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5591CCC9 for <tls@ietf.org>; Wed, 19 Aug 2020 10:28:37 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 19 Aug 2020 10:28:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=fdI+j MyWdGvRrQIU4god+bvVSIE9Y6zcoLAZq/zDEjM=; b=7GIU0KZfB6Dp64mI1nTKh qs/Ck9bhm2kGABqzJwgy6kAApdCrr5UKyw8cjfZmN6lEs23IaUYiAjl+0m+dBsI5 24RPnMnmkCjT5o3CqAY1AioIuXvK2Dx/qHnbg6Z8aLksZQII5RUOJATGs8xoC0WW Jrm4pvhUMgJfBX4FIAyysbvmCj4UQWnqserI8gi9kQlZkXM9tdMGd7GKoPgUkNXM 5JxEiYv3cwmQtvrZkbX1wvcVtlc2zGSqDfY59QjH97Hy4uzUI5HVRDuGTzkSKw49 4U3sJXvTM18g5UctFrUCFYnLVj+ADXxhsUTLICgROuEgUTXqhr4SrKoODdWcL+tN Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=fdI+jMyWdGvRrQIU4god+bvVSIE9Y6zcoLAZq/zDE jM=; b=C51aNpqLtn4qJDLs9H7wwtFMocfjhALl9AigmWT75Hji3aKgMJBJnF5Cl R9cuy+Vo55kItPkuU8GfHaoGCEcFAFFhJooUWS0lx+nPiiowCwe7H+4E720l/4zW zhmg6pz2ButO+iYsEiFfalnCWuwULQ2I6ZjoY2Qd3Rsn7DThBpczgiCfyQAn53HV 7WnCt1vp5uFWqZjiE6uURGThjuVEDTAoXOO101S+kxb+QjGVBrl9kmDahSaarFw9 kCqplQLbSUDrYDk6iEuVjvwjGzHSr0kAC6U7p8sSUZ8lyZ4h5tVFlp0joJXp0K6P 4uqYfzzYzmukX5unAY5TvwQ3pkyNw==
X-ME-Sender: <xms:FDc9X8ilE6PklLbm4CikKbF_Gb8qnJoNbPepqf9wiw5JS7I0icSEcQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtkedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepffekhfdute fhleelueetleekvdefheelfedvfeeigeegjeetvefhgeffjefftedtnecuffhomhgrihhn pehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv th
X-ME-Proxy: <xmx:FDc9X1BipaJcLaTqcSe_HTFvILbwdy1oHSIaaWZ2UrJIRt2_IvDfZg> <xmx:FDc9X0EU38-eVb7nDx8K4DYhH16utJPd0T5Arztq4aqPvf0zMBaX-w> <xmx:FDc9X9Rx_TyhxuY5UxZUt4pvvm8d9ltAcQqfsBqHJgNVkrkB-j-7cw> <xmx:FDc9X9jlrkGS9vBbfG4xhW7Vl-JkOq1a3_hxKGldcoaXCLQXdZq4bw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90C493C00A1; Wed, 19 Aug 2020 10:28:36 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-191-gef79d59-fm-20200818.001-gef79d590
Mime-Version: 1.0
Message-Id: <948d472d-5abb-4806-90da-877dc3420eaa@www.fastmail.com>
In-Reply-To: <c3d2ff8c-762a-399b-40c2-59ddbfe387ae@ericsson.com>
References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> <ab10fa75-f30e-d0e2-2c29-6ec0f51bb4da@ericsson.com> <006401d653af$7b029f80$7107de80$@augustcellars.com> <4f52e8f0-eb0b-d6c6-e8bd-3f6fc0b3541e@ericsson.com> <010201d65536$6554f5b0$2ffee110$@augustcellars.com> <c3d2ff8c-762a-399b-40c2-59ddbfe387ae@ericsson.com>
Date: Wed, 19 Aug 2020 07:28:16 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PK39yZg4PtcoGeK0J1FXd7jFaHo>
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00
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: Wed, 19 Aug 2020 14:28:41 -0000

On Thu, Jul 9, 2020, at 3:08 AM, Mohit Sethi M wrote:
> Top posting so that others on the list can chime in. 
> 
> While discussing the privacy implications of external PSK identities, 
> Jim Schaad in his email below recommends that we could describe 
> techniques for importing external PSK identities (that may be typed in 
> by the user). He suggests that we could consider using a construct 
> based on one way hash functions so that the typed-in external PSK 
> identity (presumably with not so good privacy properties) are never 
> sent on the wire. 

This is being discussed here:

   https://github.com/tlswg/external-psk-design-team/issues/36

I think we ought to omit any particular recommendation, especially in the absence of analysis. What do others think?

Thanks,
Chris

> 
> --Mohit
> 
> On 7/8/20 5:45 PM, Jim Schaad wrote:
> >  
> 
> >  
> 
> > *From:* Mohit Sethi M <mohit.m.sethi@ericsson.com> 
> > *Sent:* Wednesday, July 8, 2020 1:03 AM
> > *To:* Jim Schaad <ietf@augustcellars.com>om>; Mohit Sethi M <mohit.m.sethi@ericsson.com>om>; draft-ietf-tls-external-psk-guidance@ietf.org
> > *Cc:* tls@ietf.org
> > *Subject:* Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00
> 
> >  
> 
> > Hi Jim,
> 
> > On 7/6/20 7:06 PM, Jim Schaad wrote:
> 
> >>   -----Original Message----- From: Mohit Sethi M <mohit.m.sethi@ericsson.com> Sent: Monday, July 6, 2020 3:10 AM To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-tls-external-psk- guidance@ietf.org Cc: tls@ietf.org Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00  Hi Jim,  Thanks for the review. A clarifying question in-line.  On 7/2/20 12:02 AM, Jim Schaad wrote: * In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs.  This was a complete surprise to me and I don't know if it was supposed to be one.  Are there mitigations that can be made?  * In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance.  * Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels.  I think you are referring to the PSK identity and not to the PSK.  As you know, the Network Access Identifiers (NAIs) used in EAP typically need the domain name suffix for roaming, federation, etc.  This is true, it is also true that EAP is very strong on saying that if you have a choice, always send an anonymous version of the NAI if you have to do it in the clear.  This means that the domain can be used for correlation, but you do not have the full identity for that purpose.  I think that the EMU group is going to need to look at what level of privacy protection it is going to desire when using a PSK, but in that case there is no need for having  a domain suffix as that information is provided elsewhere.   This might require keeping the TLS tunneling as an option to deal with passive attacks. 
> > You are absolutely right about the preference for using anonymous identities. draft-ietf-emu-eap-tls13 currently says the following about resumption: 
> 
> >>    It is RECOMMENDED to use a NAIs with the same realm in the resumption    and the original full authentication.  This requirement allows EAP    packets to be routable to the same destination as the original full    authentication.  If this recommendation is not followed, resumption    is likely to be impossible.  When NAI reuse can be done without    privacy implications, it is RECOMMENDED to use the same anonymous NAI    in the resumption, as was used in the original full authentication.    E.g. the NAI @realm can safely be reused, while the NAI    ZmxleG8=@realm cannot. 
> > This document and the ensuing discussion pertains only to external PSKs and external PSK identities. I think I incorrectly used the word "issue" in my previous email as a more correct choice would have been "agree/establish" (i.e. the server and client agree on an external PSK and an external PSK identity). RFC 8446 doesn't place any restrictions on external PSK identities (other than the fact that they are at least 1 byte). If we are going to discourage the use of domain names in external PSK identities, would that be sufficient? What prevents me from using an external PSK identity of the type: my_strong_secret_psk_with_amazon_server? 
> 
> > I am not sure if we should recommend randomized external PSK identities of a certain minimum length. Perhaps it might be better to add a disclaimer about the privacy loss from carelessly chosen external PSK identities? 
> 
> > [JLS] There are going to be three different cases for external PSK identities: The identity if factory provisioned and carried in a file to the server,  the identity is factory provisioned and read by the user from the device, and it is hand chosen.  The first two cases can definitely be randomized.  I don’t know that having a minimum length makes any difference.  This is not exactly a cryptographic property.  Another thing that might be done would be analogous to the PSK importer document and apply a one way hash from the typed in value to the value that is sent over the wire so on the wire it is just a random set of bytes.
> 
> > Jim
> 
> >  
> 
> > --Mohit
> 
> >>     I would like to understand the nature of the resulting privacy loss. Is it that a passive attacker can now easily determine the server which issued the PSK identity (and the server where it will eventually be used)?  While it I true that at least some of the privacy information has already been leaked in the PSK case, you know the address that is being talked to and the PSK identity that is passed.  If you look at using thigs like ESNI, doing this would appear to potentially give away the very information that is being hidden in that case.   The other problem with having domain based KIDs is that you could easily get some amount of correlation between the KIDs that are assigned in different domains.  You could end up with mohit.ietf and mohit.amazon and it would be quite reasonable to assume that both of those identities are going to be for the same entity, just in different domains.  Jim    --Mohit   * Section 7.1.2 - There seem to me to be three different places where collisions will occur.  The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys.  There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem.  * Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity.  Perhaps you should look to see if this does work and if it is safe.  Jim    _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 
> > 
> > _______________________________________________
> TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>