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

Benjamin Kaduk <bkaduk@akamai.com> Thu, 05 January 2017 01:33 UTC

Return-Path: <bkaduk@akamai.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 C10B21294AB for <tls@ietfa.amsl.com>; Wed, 4 Jan 2017 17:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 m5DZ9eXu3W9U for <tls@ietfa.amsl.com>; Wed, 4 Jan 2017 17:33:31 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 377E21293DC for <tls@ietf.org>; Wed, 4 Jan 2017 17:33:31 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BD12A433412; Thu, 5 Jan 2017 01:33:30 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A5F5C433404; Thu, 5 Jan 2017 01:33:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483580010; bh=CNuPihA6TNnd5lhsoV6x/D3EUkfhXu7mbWa8DUyk35I=; l=7770; h=To:References:Cc:From:Date:In-Reply-To:From; b=zg4C+FTlmrZd9gV1jm9kvO2ak6B9Plz67eGHc8l4ZV+NwlkYm1soBDdYrCcPjwRbP HQqC9KnVUyxrbEVbTW3InxBf7ToWdIh+ufIU3jq1saHnK5s0B6R0yl6jEKhEPRcQ8z PotwjNk0BrOqwNwKKPvfuEoV77b8vBpHHCTMx5U4=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 599FB1FC86; Thu, 5 Jan 2017 01:33:30 +0000 (GMT)
To: Russ Housley <housley@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> <0FDAC302-2E1E-4E31-B649-2E2E0B4EB690@vigilsec.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <62a479bc-895f-8b59-e37d-5854bfe1185c@akamai.com>
Date: Wed, 04 Jan 2017 19:33:30 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <0FDAC302-2E1E-4E31-B649-2E2E0B4EB690@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------025FC0AE98C810FD2D30B245"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Buv9gWgtZ3O6KRaxmr7kRqQ3HjI>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 05 Jan 2017 01:33:34 -0000

Hi Russ,

On 01/04/2017 03:17 PM, Russ Housley wrote:
> Ben:
>
>> I also had the sense that ekr noted that we didn't want to do this in
>> the core spec.
>> So, could you point me more clearly at what you would want to change
>> in the core spec that would allow doing the thing you want to see
>> done in a future document?  (Is it just removing "i.e., when a PSK is
>> not in use"?)
>>
>
> I am not looking to put the details in the core spec.  I think I said
> that in my first posting.  However, I do want to ensure that the
> identity associated with the external PSK and the certificate are both
> considered.  There needs to be a hook in the core spec for that to happen.
>

I understand that.

> I quotes the part of the core spec that seems to say otherwise.
>

What I don't understand is exactly which part or parts in combination of
the quoted text are saying otherwise, in your reading of it.  I offered
a potential part of the quoted text which might be leading you to that
interpretation (the "i.e., when a PSK is not in use" clause), and you
did not confirm or deny my guess.  So, I still don't understand what
seems problematic to you about the existing text -- to me, it says that
certain things must be done if certain other things are or are not done,
but does not seem to preclude certain things being done and certain
other things also being done. Maybe you could propose a patch that
provides the hook that you would like to see, so that I can understand
the issue with the current text?

-Ben

>
>>>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley <housley@vigilsec.com
>>>> <mailto:housley@vigilsec.com>> wrote:
>>>>
>>>>     I want to make sure that it is possible to mix PSK with (EC)DH
>>>>     as a protection against the discovery of a quantum computer.  I
>>>>     recognize that the WG does not want to tackle this topic in the
>>>>     base specification; however, the following text in Section
>>>>     4.1.1 makes this difficult to do so in a companion document:
>>>>
>>>>     >    The server indicates its selected parameters in the
>>>>     ServerHello as
>>>>     >    follows:
>>>>     >
>>>>     >    -  If PSK is being used then the server will send a
>>>>     "pre_shared_key"
>>>>     >       extension indicating the selected key.
>>>>     >
>>>>     >    -  If PSK is not being used, then (EC)DHE and
>>>>     certificate-based
>>>>     >       authentication are always used.
>>>>     >
>>>>     >    -  When (EC)DHE is in use, the server will also provide a
>>>>     "key_share"
>>>>     >       extension.
>>>>     >
>>>>     >    -  When authenticating via a certificate (i.e., when a PSK
>>>>     is not in
>>>>     >       use), the server will send the Certificate (Section
>>>>     4.4.1) and
>>>>     >       CertificateVerify (Section 4.4.2) messages.
>>>>
>
> Russ