Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

Eric Rescorla <ekr@rtfm.com> Sat, 25 March 2017 11:41 UTC

Return-Path: <ekr@rtfm.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 E84C5128656 for <tls@ietfa.amsl.com>; Sat, 25 Mar 2017 04:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 QhNzG2P88zsp for <tls@ietfa.amsl.com>; Sat, 25 Mar 2017 04:41:00 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 26EDE12741D for <tls@ietf.org>; Sat, 25 Mar 2017 04:41:00 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id d191so7517084ywe.2 for <tls@ietf.org>; Sat, 25 Mar 2017 04:41:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zV3j7x1CRXtuE+li0/gjqGFhiqg8UQ1n7COXKMJA25g=; b=zvkICbeWB8jIZ3YEJkqO+8V4FPKxs6iuVZCaDynHJyZiN5RzesKJeZ1UvUvZnHNTPG I+G608n+LJq5JsedlcuvrDcT33peOMgQSmMgdKNVZGmV0Lk3YS09i3T3Mxw2mx9Y8qVE R6eCa6rAK+9Ch4Uj7VWp8T1bll4xQWeYCjaa0PRCMI3H+cfESstucNuFX4ijnmQX03+B WADTctLLNJmIvROT0sUQmXmsz7nCbZoYLTUcwQ71mgSCax9qvMQiPhHXvJEFCvniRdUE qbnM0zBx5C35E22hEmvA61Nv/uc6IG0+eWZEXqEiXno7T9tsL5R8WWrvx62rUG6mZW0Z RfGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zV3j7x1CRXtuE+li0/gjqGFhiqg8UQ1n7COXKMJA25g=; b=DWqOBC7oEIXYECN26nho5uU+YUAGllmI5a9S1iLitgLerPV118A6A+GQyTNpwzIYTr flfczFa93Mr7NDOF7kaw8KLeIs4zQ2LO033nLpz5B3JsuP5dTzLi8dy0MDIDayCLaO81 MZs/OV2u7E7d7pMno/+g1aoPt5nrk/2RINxXZgtlkAvtw+I8ahcOFTemO6f0sL31JVjP 3oq+lyrn6RMzhkpUgz5heExiJeHrR75CSL/1wPJRGv6k9fS+1tCr/Ckl0r3ciWHhUjmD HsjtL9lbKx3JaZWD69byoj/9dz+IVM5EY9wjG3qeaRH6MIv38YSkwxnccRRroiQHjhm/ cRZw==
X-Gm-Message-State: AFeK/H0DkmFoKQrGs0c2SlB2mstridermNTpHKaUzt0GCqdo2/cWcTKY2MCiiynQCwjQ8iYA7IF3iH76aNyzQA==
X-Received: by 10.129.108.214 with SMTP id h205mr9587853ywc.71.1490442059338; Sat, 25 Mar 2017 04:40:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Sat, 25 Mar 2017 04:40:18 -0700 (PDT)
In-Reply-To: <02c701d2a515$f9f8bcd0$edea3670$@augustcellars.com>
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> <CAF8qwaB8+o20QP71=zuCJ2EXt9EGFuLcn4s6es=gjnOccZE9fQ@mail.gmail.com> <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> <CABkgnnXfw45-R-Tvf2cZQGb4a5mas2yZRXT4q3ArRyTMSF9x2Q@mail.gmail.com> <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com> <949EBD4E-613B-4B36-BD93-FDE3E4D4926F@vigilsec.com> <CAF8qwaA5ntF8iN99=tQyFt7dqucvcKNw9avgVRGJRmGu-3UswA@mail.gmail.com> <CABcZeBNXu==kGd63OdF07WEqcFiD0qd0aL=KQqKY23Y75XfewA@mail.gmail.com> <141723AB-B4E4-4233-8C35-C720E4A7FE0C@vigilsec.com> <CABcZeBNU23_ZM2JRz9aDyzuhcQ-ubzw5LU8Dkd=jPg1svhvukw@mail.gmail.com> <02c701d2a515$f9f8bcd0$edea3670$@augustcellars.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 25 Mar 2017 04:40:18 -0700
Message-ID: <CABcZeBPLHvSgr9DteHwJz_zdCMy6A2U2U+=q6MfmSWTaSYZGbg@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Russ Housley <housley@vigilsec.com>, IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e81dc816d01054b8c95af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zHdpZGOXPprBWPm4hWhJdXEUBKI>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 25 Mar 2017 11:41:02 -0000

On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> EKR – I think that is the wrong answer because of the resume case.
>

Why? It seems like for Russ'a application, you would inject the static PSK
initially
and then it would be implicitly part of any resumption so no need to
reinject it
to obtain PQ safety.

-Ekr

However, I would expect that the external PSK would be appended or
> otherwise munge into the computed secret (assuming DH) and would be
> consumed as part of that processing.  No additional slot needed.
>
>
>
> jim
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, March 24, 2017 12:19 PM
> *To:* Russ Housley <housley@vigilsec.com>
> *Cc:* IETF TLS <tls@ietf.org>
> *Subject:* Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
>
>
>
> Why would the external PSK not just go into he PSK slot.
>
>
>
> -Ekr
>
>
>
>
>
> On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley <housley@vigilsec.com>
> wrote:
>
>
> > I agree with David here. Specifically, I think.
> >
> > - The base specification should continue to forbid certificates in
> combination with PSK
> > - We should at some point contemplate an extension that allows the use
> of certificates in combination with PSK
> > - The base spec should be factored in such a way as to make that
> extension easy.
>
>
> While I agree that we do not want to delay the TLS 1.3 specification to
> sort this out; however, I do not think we have provided the hook to make
> this future extension easy.   Looking at the key schedule in -19, I think
> we can provide the hook without being disruptive.  My goal is to minimize
> the pain to implementing the extension in the future by putting a
> straightforward hook in today:
>
>                  0
>                  |
>                  v
>    PSK ->  HKDF-Extract = Early Secret
>                  |
>                  +-----> Derive-Secret(.,
>                  |                     "external psk binder key" |
>                  |                     "resumption psk binder key",
>                  |                     "")
>                  |                     = binder_key
>                  |
>                  +-----> Derive-Secret(., "client early traffic secret",
>                  |                     ClientHello)
>                  |                     = client_early_traffic_secret
>                  |
>                  +-----> Derive-Secret(., "early exporter master secret",
>                  |                     ClientHello)
>                  |                     = early_exporter_secret
>                  v
>            Derive-Secret(., "derived secret", "")
>                  |
>                  v
> (EC)DHE -> HKDF-Extract = Handshake Secret
>                  |
>                  +-----> Derive-Secret(., "client handshake traffic
> secret",
>                  |                     ClientHello...ServerHello)
>                  |                     = client_handshake_traffic_secret
>                  |
>                  +-----> Derive-Secret(., "server handshake traffic
> secret",
>                  |                     ClientHello...ServerHello)
>                  |                     = server_handshake_traffic_secret
>                  v
>            Derive-Secret(., "derived secret", "")
>                  |
>                  v
> ExtPSK OR 0 -> HKDF-Extract = Master Secret
>                  |
>                  +-----> Derive-Secret(., "client application traffic
> secret",
>                  |                     ClientHello...Server Finished)
>                  |                     = client_traffic_secret_0
>                  |
>                  +-----> Derive-Secret(., "server application traffic
> secret",
>                  |                     ClientHello...Server Finished)
>                  |                     = server_traffic_secret_0
>                  |
>                  +-----> Derive-Secret(., "exporter master secret",
>                  |                     ClientHello...Server Finished)
>                  |                     = exporter_secret
>                  |
>                  +-----> Derive-Secret(., "resumption master secret",
>                                        ClientHello...Client Finished)
>                                        = resumption_master_secret
>
>
> The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret
> computation.
>
> The Section 4.1.1 can call out this place for the future specification:
>
> OLD:
>
>    -  When authenticating via a certificate, the server will send the
>       Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
>       messages.  In TLS 1.3 as defined by this document, either a PSK or
>       a certificate is always used, but not both.  Future documents may
>       define how to use them together.
>
> NEW:
>
>    -  When authenticating via a certificate, the server will send the
>       Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
>       messages.  In TLS 1.3 as defined by this document, either a PSK or
>       a certificate is always used, but not both.  So, the ExtPSK is not
>       used in the key schedule (Section 7.1).  Future documents may
>       define how to use them together and tell how the ExtPSK is
>       handled in the key schedule.
>
> Russ
>
>
>