Re: [TLS] Distinguishing between external/resumption PSKs

Jonathan Hoyland <jonathan.hoyland@gmail.com> Thu, 19 September 2019 15:43 UTC

Return-Path: <jonathan.hoyland@gmail.com>
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 8701512022A for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 08:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 KNAGkgseIW4y for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 08:43:44 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 C80A6120130 for <tls@ietf.org>; Thu, 19 Sep 2019 08:43:43 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id l2so2588043vsr.8 for <tls@ietf.org>; Thu, 19 Sep 2019 08:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=68jVcUJq9UdE2y0hHSpXBplgovAcdpsDWPwOJ9zY1jg=; b=ky5yrVp8WnVtPk+h+D7izeJH8Ht9ucOMxRO1ve6PDP8YUV6umTZy13Vqw4GTb2iK18 55sooWWJTop4wOQh7rSPw4TmiSDMEBJ3Pl3At7ajPyKE0mxVb3/1ah1fFm/3lKuYdO4z vlABsRKowMG0AnbErxfdbwv39H6x8qKmgKKUyksiAG+pe+Ov22dnJZFIbQP55rGjiIB8 h9G0bnkWG25O0OhrykZ50B85yz4r1WMv6w3C5YiSeXQ42L6MUr2vJC4F3VMETzN5Ube7 Lr/ad+HpdH5kg1+OffbNxquQA512IB+1LAj+AZEBU8JPG1/x3OI1gk+QDxU+KlynNvKd Q6Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=68jVcUJq9UdE2y0hHSpXBplgovAcdpsDWPwOJ9zY1jg=; b=F7ovBSd2zhPlFX9dllgnyo6mkLgdKueJdc4KNQfpgh94uDEofj43ptT5jHoJBHvsDl KMSpTk69ohtoRl14TY0rMU5HApJfKFf31ZRUNrVer9da+sYzlp1HVqrV7qPfuRwNldbH hQJ7w3vATDPAIoBEO42DAQyIZvjnt6ahIzQdkQ8xCGiYqNma9kmUKfVk7/C6MfVOE1gE AIfuLMVr6i5AD/nshA2A2xaq1DJijUaAN+Zoq9FFIBKqYbS8vKSZxQYClR4omfmyFBdf i07VxNy1AKFxe4En39qlAfAfiPwlgemQSGtCF26h8oRkm1VW9/BQuUEHRygpeS/Tnxm+ tb5Q==
X-Gm-Message-State: APjAAAXphcPd6k36Dkgpi5SFYAG8u1EWjegPzIa4JJcaAFyOH54kJzx4 1DhSQyMPwoRQX3rR/H5YLJFg45Svlk3dlY/W9ic=
X-Google-Smtp-Source: APXvYqyuCsbUWsJB7Pr1a606Mxn936MHldQgH1kyXlS1vhCuWEwdgfnJY9UF67W3uxfFntHaZeCXmjMMgMNfKMbglWg=
X-Received: by 2002:a67:e447:: with SMTP id n7mr5787320vsm.66.1568907822710; Thu, 19 Sep 2019 08:43:42 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAL02cgT73q0iOj=7fMsneQwjAFFDnSYM92MhV0adSfU2qOCurQ@mail.gmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Thu, 19 Sep 2019 16:43:31 +0100
Message-ID: <CACykbs2=e9LvnvvU=zOWuzqeU4aYXOA3SPWBwQGyPcW6QjrSkA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: "Owen Friel (ofriel)" <ofriel@cisco.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007545410592e9d1b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0>
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 15:43:47 -0000

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-
>>> <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
>>
>