Re: [TLS] Distinguishing between external/resumption PSKs

Jonathan Hoyland <jonathan.hoyland@gmail.com> Thu, 19 September 2019 14:25 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 3232F120127 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 07:25:45 -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 lNqa3Fs3Nt1V for <tls@ietfa.amsl.com>; Thu, 19 Sep 2019 07:25:42 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 D8C4E120090 for <tls@ietf.org>; Thu, 19 Sep 2019 07:25:36 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id b1so2371878vsr.10 for <tls@ietf.org>; Thu, 19 Sep 2019 07:25:36 -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=C/ugK2DTQfkgwQhnD+fX+WwY+aF2iIembIaZEajYFig=; b=oMQMwT1CrBFmZ7oyUq0xd0F9fAnxj7HMYzwUO39mLRJq+OZLc4e6SfkMAvrFRydSfs NmTmY148lgtIMM2jDUm46SnDGVovQervv31h+BhzH6/Vn94LlNFWXgVe9kWcxtGhkJLQ Vr3IxAiG+9AG9zpjWd/B6r7SZw/xs0bPVm7HreV+GYetB248P/+F/mWixQxfGoHqEAGH OQJ7HF34pXn3psKPVU4V+mbQGGL1e6lSXRGMIqxRCr2+nGtwAaegIfG8jYbBTbZ31OQ8 sGgcDTBV9YhZ8OT3J6b5lDKj9PB1s4XwnZE8jGCbHdqblZ6maH/7jBYaUzCCnpa5Pwpu P+Cw==
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=C/ugK2DTQfkgwQhnD+fX+WwY+aF2iIembIaZEajYFig=; b=KcEaoPL+5Ui9K1ZU8o80AJCTFqgqSvdtFHhooI1QqkTnKvFqGQILyqpuJU2eyB/lJK a41RxRbkFdKO81w0KxoK44NkYf8IiiGD/dL1Y5ha2ylAKXJEZN/wCQNn1+Wtz499bDBR U6lCfmtOiq/2umq/d8FnifPyW4ijLvUkwVGptKEhR+XN+fy+U8v40vlTovJjemvDVR52 NEmI8bq6c79bOVIukbVwP4Si2vef9ZsfjLQO1zCVxgg7/UtCkTYdcpRfINWuQfHOcnSu oFhs5YnYa6DnPp12mq2Nrp+PRqjdglfB+rpxdEi5crebVYzYt4fmx5jRkFqwobMgEpWN r3Mg==
X-Gm-Message-State: APjAAAXynVyPn24RMVIVn8t/PcMCzdDf688v5zr+fskDD8ZW4ZHDpX5/ kr0ZMTbxPIFoMJzGqKpSUhjei0zjPb1SaSCf1js=
X-Google-Smtp-Source: APXvYqwEJzj5aXitChq4eSDAotBY1CRZhRcbhKyTzwC4bMG9ZViWW3ORreZWzQS0zLhD6vm0u7YZnZztfZZ8H+KOTvc=
X-Received: by 2002:a67:e447:: with SMTP id n7mr5516075vsm.66.1568903135901; Thu, 19 Sep 2019 07:25:35 -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>
In-Reply-To: <CY4PR1101MB227871FEF520A88CF65BADF6DB890@CY4PR1101MB2278.namprd11.prod.outlook.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Thu, 19 Sep 2019 15:25:24 +0100
Message-ID: <CACykbs3aQxM3kxa3khOYbj8naXfcaPmSOKY01nAsuAyfEWYkzg@mail.gmail.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
Cc: Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a3e660592e8ba8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/haXhCy-Sc8nFGhvjaOWKfHAuH8Q>
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 14:25:45 -0000

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.

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
>