Re: [TLS] Distinguishing between external/resumption PSKs

Christian Huitema <huitema@huitema.net> Thu, 19 September 2019 18:06 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 1D8951208FC for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 11:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XbLBEW7M1WB7 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 11:06:35 -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 BB6E31208F6 for <tls@ietf.org>; Thu, 19 Sep 2019 11:06:33 -0700 (PDT)
Received: from xse21.mail2web.com ([66.113.196.21] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iB0p5-000Eeu-5r for tls@ietf.org; Thu, 19 Sep 2019 20:06:32 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46Z4Y11ShRzC4G for <tls@ietf.org>; Thu, 19 Sep 2019 11:06:29 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iB0p3-0003cd-2x for tls@ietf.org; Thu, 19 Sep 2019 11:06:29 -0700
Received: (qmail 5937 invoked from network); 19 Sep 2019 18:06:28 -0000
Received: from unknown (HELO [192.168.200.64]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <rlb@ipv.sx>; 19 Sep 2019 18:06:27 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-5B8E8267-514A-49BF-8660-7958A8A1DCD6
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <CAL02cgSuFGNd26TS8bNbjhh+YEYVbAH5TQBneeLNyouZemAZXw@mail.gmail.com>
Date: Thu, 19 Sep 2019 08:06:26 -1000
Cc: Jonathan Hoyland <jonathan.hoyland@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <DDFDB072-63F6-4B52-9F64-56772910515D@huitema.net>
References: <CY4PR1101MB227834A5DF828F000C6D1144DB890@CY4PR1101MB2278.namprd11.prod.outlook.com> <CACykbs2qp0EDa3pGfFpQY6rgruJD1f-6mZ_B5KF8kBkrXD9caw@mail.gmail.com> <CY4PR1101MB227871FEF520A88CF65BADF6DB890@CY4PR1101MB2278.namprd11.prod.outlook.com> <CACykbs3aQxM3kxa3khOYbj8naXfcaPmSOKY01nAsuAyfEWYkzg@mail.gmail.com> <CAL02cgT73q0iOj=7fMsneQwjAFFDnSYM92MhV0adSfU2qOCurQ@mail.gmail.com> <CACykbs2=e9LvnvvU=zOWuzqeU4aYXOA3SPWBwQGyPcW6QjrSkA@mail.gmail.com> <CAL02cgSuFGNd26TS8bNbjhh+YEYVbAH5TQBneeLNyouZemAZXw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Originating-IP: 66.113.196.21
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.21/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.21/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.03)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVxsm/g6tRdL1d WtUlu3ssxkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4YhuIxvMGVc8vf5bGATYT86gyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+c10h9aHNaslh2Yjb8ceaq51aOsarGPChhedL2Py5oHk46jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbuhdxf5Dwg9wMBX5ckCo48ayVGvgdM/14NhEhsQ0jllqEE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd5csd6/DQyP1F2MXqSxFa+Qssn+Puh2ckHiEuoZTp5PTAAtQTt0r0FTdGiRgJhd7K30 lSfuxANzRU5MAZzTOSGB0ajS6cTcaeWUSBYMfWz8jPKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6QpmdmUsCyezkPbvOzctiMpxMPnetLBJMh51NiRRoHICmsZSQ3fzvEUQXznOE5tahmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50u0oTVM0O5kGWaUP9pclsYh08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kMF5iJIdAeIH9NvJQoE1kj7Z-eM>
Subject: Re: [TLS] Distinguishing between external/resumption PSKs
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: Thu, 19 Sep 2019 18:06:38 -0000

There is also a privacy angle. From a privacy point of view, it is very nice that PSK cannot be distinguished from session resumption.

-- Christian Huitema 

> On Sep 19, 2019, at 5:57 AM, Richard Barnes <rlb@ipv.sx>; wrote:
> 
> As nice as that requirement would be, I'm not sure it's really compatible with the way people want to build software.  For example, OpenSSL right now gets external PSKs by calling out to an external callback.  Given that degree of separation, proactively assuring no collisions would be hard.
> 
>> On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland <jonathan.hoyland@gmail.com>; wrote:
>> Ah yes, Richard is right, the PSK IDs do not have a defined structure. 
>> 
>> Having two different PSKs attached to a single PSK_ID should be banned if it isn't already. 
>> 
>> Regards,
>> 
>> Jonathan
>> 
>>> On Thu, 19 Sep 2019 at 16:26, Richard Barnes <rlb@ipv.sx>; wrote:
>>>> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <jonathan.hoyland@gmail.com>; wrote:
>>> 
>>>> That's how I would interpret the spec yes. 
>>>> You could argue that there's a distinguishing attack where the attacker measures the response time on PSKs to determine if it was an OOB PSK or a resumption, but I think you could do equally well just by looking at the PSK lengths, because resumption PSKs have a defined structure. 
>>> 
>>> I don't think that's quite right.  The PSKs resulting from NewSessionTicket have a defined structure, but the PSK *IDs* do not; they're specified by the server.  AFAICT, existing server stacks generate their own PSK IDs for resumption PSKs, so from the application's perspective, the structure of the resumption PSKs is unknown (or at best, specific to the TLS library in use).
>>> 
>>> If I understand correctly, the worst case here would be:
>>> 
>>> 1. The server application wants to have some behavior change based on the use of an external PSK (not resumption)
>>> 2. The server TLS stack is configured with external and resumption PSKs with the same PSK ID
>>> 3. The client sends a ClientHello using the resumption PSK
>>> 4. The server TLS stack attempts to verify the binder with the resumption PSK and succeeds
>>> 5. The server application gets a session that is authenticated with the PSK ID and notes that the PSK ID matches one of its external PSKs
>>> 6. The server application improperly does the external PSK behavior when in fact resumption has happened
>>> 
>>> I might be missing something, but I don't see anything in the spec that would prevent this situation from arising.  So it's up to the application to choose its PSK IDs in such a way that they don't collide with resumption PSK IDs.  But the fact that resumption PSK IDs are implementation-specific mean that this is tough to do with any generality, unless you're willing to rely on long pseudorandom strings not colliding with each other.
>>> 
>>> Maybe the answer is just that TLS stacks that handle their own resumption caches need to signal to applications when that cache has been used vs. an external PSK.
>>> 
>>> --Richard
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Jonathan
>>>> 
>>>>> On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) <ofriel@cisco.com>; wrote:
>>>>> 
>>>>> 
>>>>> > -----Original Message-----
>>>>> > From: Jonathan Hoyland <jonathan.hoyland@gmail.com>;
>>>>> > Sent: 19 September 2019 14:32
>>>>> > To: Owen Friel (ofriel) <ofriel@cisco.com>;
>>>>> > Cc: Martin Thomson <mt@lowentropy.net>;; tls@ietf.org
>>>>> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>>>> > 
>>>>> > Hi Owen,
>>>>> > 
>>>>> > If I understand your question correctly the distinguishing is done implicitly
>>>>> > (not explicitly) through the key schedule.
>>>>> > If the client and server do not agree on whether the PSK is a resumption or
>>>>> > an OOB PSK then the `binder_key` will not match, and the handshake will fail.
>>>>> > 
>>>>> > See pp. 93-94 of the spec.
>>>>> 
>>>>> And we only even get that far on the off chance that an ext PskIdentity.identity is exactly the same as a res PskIdentity.identity. e.g. a client presents an ext PskIdentity.identity, the server somehow thinks it’s a res PskIdentity.identity, and then handshaking will fail, not only because the actual raw PSK is likely different but the binders will not match due to different labels.
>>>>> 
>>>>> But my question was before we even get that far - its an internal server implementation decision how it determines whether the presented PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB table vs. a res cache first to find a PskIdentity.identity match. And say it fails to find an ext match then it tries to find a res match, and if it finds a match, then it knows what binder label to use.
>>>>> 
>>>>> 
>>>>> > 
>>>>> > Does that answer your question?
>>>>> > 
>>>>> > Regards,
>>>>> > 
>>>>> > Jonathan
>>>>> > 
>>>>> > On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <mailto:ofriel@cisco.com>
>>>>> > wrote:
>>>>> > 
>>>>> > > -----Original Message-----
>>>>> > > From: TLS <mailto:tls-bounces@ietf.org> On Behalf Of Martin Thomson
>>>>> > > Sent: 04 September 2019 02:46
>>>>> > > To: mailto:tls@ietf.org
>>>>> > > Subject: Re: [TLS] Binder key labels for imported PSKs
>>>>> > >
>>>>> > >
>>>>> > > When we built the ext/res distinction, there was a clear problem
>>>>> > expressed.
>>>>> > > We had the potential for both to be used by the same servers at the same
>>>>> > > time (though not for the same connection) and distinguishing between
>>>>> > them
>>>>> > > was important
>>>>> > 
>>>>> > Martin, maybe I am missing something in the threads on this. Is there
>>>>> > anything explicit planned in ClientHello PreSharedKeyExtension or
>>>>> > PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
>>>>> > it up to server implementation and how the server handles the opaque
>>>>> > PskIdentity.identity? e.g. ImportedIdentity.external_identity fields could be
>>>>> > stored in one DB table, and (ignoring https://tools.ietf...org/html/draft-ietf-
>>>>> > tls-external-psk-importer-00#section-9 for now) the server on receipt of a
>>>>> > ClientHello searches for PskIdentity.identity in its
>>>>> > ImportedIdentity.external_identity table and if that lookup fails, then try to
>>>>> > parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order of
>>>>> > those two operations is of course implementation specific too.
>>>>> > 
>>>>> > 
>>>>> > _______________________________________________
>>>>> > TLS mailing list
>>>>> > mailto: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