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

Eric Rescorla <ekr@rtfm.com> Fri, 24 March 2017 17:19 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 1E5AA12978B for <tls@ietfa.amsl.com>; Fri, 24 Mar 2017 10:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] 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 dafZU9nJ2zgy for <tls@ietfa.amsl.com>; Fri, 24 Mar 2017 10:19:51 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D15E312948E for <tls@ietf.org>; Fri, 24 Mar 2017 10:19:50 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id p77so6414059ywg.1 for <tls@ietf.org>; Fri, 24 Mar 2017 10:19:50 -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=miKdI+8PLQq1z7kiSZiutf8v5GoYA0vw7iNKv7Z4Cco=; b=n9T+kIItB6sj0eSTLFHGbTtG5/tUCZYWapv7qXEwTOSdElELY9T/L71wqK45fr5Ttc j9pZtZSt/izvEEcnSiV7M5KKK0LN6OD1FDjnbEV2VBRRh7OkeQ7Aq1JFrGupHrenxwAy /ddrKHXAws4ccjiODD58HJpn9pRLT7HuNHzj719v9AsosdgkwA2+rTyH+hmvc8reyJ7z fksPiJ/8YQtjPhv/ZEWhJD7kpzkHxgPGVMC/CjAbgJBEefrVycaDZOYE+c6nB9TveQem uucBYhwghwQtXXGkblkhMkJ+YXYuZg5iqNdksck2fuLIT1y+iAdJ7qzufsiDAq9kMnag +61g==
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=miKdI+8PLQq1z7kiSZiutf8v5GoYA0vw7iNKv7Z4Cco=; b=AIalzWqOuUobEPbzB8M33qACqlNYPRo+Z/tS5zy4PJUJocSDC9uUmoFNumWFPvI4Cc AiIsFl7YRU5HBEQlxjEXvJ4mf6LVv6VXlhconGpEIaqxY9j4om+Ur8+Bn7Z9iZ67eo+H r5H3vmT8c96KEtbBXccWnM5vNRO3KgdV1niIGcxDIFF7GRj9KHPU7MrLdI8LAlvcBfMd UDJUnFlHMDgru8X5777w1hwt7N98lNVBDcNREmVM0o6de6g6f5F2iZKR1DzSWBKUhqGQ XLk7p0kuAWW8fbXaoGVb3Ztwib2nucxoWS+3rg4Dt+3zvotb5LGM+LNL1sxd+ziRF2gN FqXA==
X-Gm-Message-State: AFeK/H05geH2bi/omKBZPXjmxJpsx6F6vSpfPSTtD7YbGRKMh1rdSGpKY3WrmC3m41j35ciMKcKCFQN+M7gkcQ==
X-Received: by 10.37.53.138 with SMTP id c132mr6555781yba.105.1490375990006; Fri, 24 Mar 2017 10:19:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Fri, 24 Mar 2017 10:19:09 -0700 (PDT)
In-Reply-To: <141723AB-B4E4-4233-8C35-C720E4A7FE0C@vigilsec.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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 24 Mar 2017 10:19:09 -0700
Message-ID: <CABcZeBNU23_ZM2JRz9aDyzuhcQ-ubzw5LU8Dkd=jPg1svhvukw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114bbb32776fa1054b7d33bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Gp2lb8sBHUMZSCOxWQsie0C1SwA>
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: Fri, 24 Mar 2017 17:19:53 -0000

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