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

Joseph Salowey <joe@salowey.net> Thu, 22 December 2016 22:29 UTC

Return-Path: <joe@salowey.net>
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 06D931295FB for <tls@ietfa.amsl.com>; Thu, 22 Dec 2016 14:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 RG1oyAWmFDik for <tls@ietfa.amsl.com>; Thu, 22 Dec 2016 14:29:01 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 5D51C1279EB for <tls@ietf.org>; Thu, 22 Dec 2016 14:29:01 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id h133so5019901ioe.3 for <tls@ietf.org>; Thu, 22 Dec 2016 14:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6U/pqsU5BnksqhapF2LSuHXIGh+wpD1qscY/OgjWJTg=; b=hcsMUSyhDilJKQqyXeZx+SMuLhyfHVQXmU/w7ZEgswAtxx/1i0fy7mK52/uayC9pQD 4bxd5oxnpqyz/9ell981iV2eVjRdOfKTwSWo2W683eFDOuueswz8ekLQuDTM9GKYoUyK zL02iVeUrgcBouW1vPMZd4oiXTaIR3brt6lz0FyiPbJWbgAnobcy4C9ku3bWhDqTGPM/ bKj2ZHcO+BkjOl/+Z9imm6JyotM7p4xID8z/nJxH6c8XJc8/dNxhDs4XHlIzsudDFJQ1 ydfSFPH0t1oBNnmwvTgOeX+sh39ZdR4rXt/sH+D42Asw08CsR9lpUUVsVqhppF2fwlqe pZxA==
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=6U/pqsU5BnksqhapF2LSuHXIGh+wpD1qscY/OgjWJTg=; b=IB60hoY3HMu4gSeX09J47TRG5zHcI/3eZ4YYtTvJdYvQsx6TYkChsppXUwyZcewjXa RYX2TFK0XdEUQq9A3vgLYrhXiuc9eMGEYEMJSXT4rZueGSN8foYZw2PUCLkpWgZttn2T 07fYBt5zRdi4gZozh+CVUKZ6rJKKRGGHniC9bX9hm3LQPrPh+qT6nDZV0xP1YrU2nkEc C0w+vh8a6aL72QkP4PExi/hhyCzgtkHeKdtKIH+Dvc7x5p8KYSZ+dfSsYTe/xguQ5sSg yayX0V1kGZL0szi5svdwGhjYSsXUE0M3j8iCnev1HLPbvOxyrHAkohMezcrwK07BGGj/ /KZg==
X-Gm-Message-State: AIkVDXK60LRHkB3uPug4SOE8mHNlTmDrmnZUSiDOz2nLqp/zSpFVOKuZ5Z0L6E3kbA+ntGYij5KWtiAWEPOLSQ==
X-Received: by 10.107.18.162 with SMTP id 34mr1910047ios.14.1482445740621; Thu, 22 Dec 2016 14:29:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.15.73 with HTTP; Thu, 22 Dec 2016 14:28:40 -0800 (PST)
In-Reply-To: <CAF8qwaB8+o20QP71=zuCJ2EXt9EGFuLcn4s6es=gjnOccZE9fQ@mail.gmail.com>
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> <CAF8qwaB8+o20QP71=zuCJ2EXt9EGFuLcn4s6es=gjnOccZE9fQ@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Thu, 22 Dec 2016 14:28:40 -0800
Message-ID: <CAOgPGoCwQ4j4ZPpoApc-9mpE-hfWNGa+41KUo4P2OS6gUrBu1g@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary="001a113f6216c4d6fc054446cb90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h_OIoyVe_TWVhX7SAQpiZUU_zlQ>
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, 22 Dec 2016 22:29:04 -0000

Does you implementation allow a PSK to be used along with certificate based
authentication?

On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin <davidben@chromium.org>
wrote:

> It's possible I'm misunderstanding your message here (I'm a little
> confused by the mention of combining normal certificate authentication with
> an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH.
> That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by
> the server by sending both pre_shared_key and key_share extensions. Perhaps
> the wording should be a bit clearer.
>
> Our stack does not even implement psk_ke. It always requires an (EC)DH
> operation in a TLS 1.3 handshake, whether using PSK or certificates.
>
> David
>
>
> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley <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.
>>
>> An Internal PSK offers no protection against the discovery of a quantum
>> computer.  I assume that an attacker can save the handshake that
>> established the Internal PSK, and then at some future date use the quantum
>> computer to discover the Internal PSK.  Therefore, protection against the
>> discovery of a quantum computer is only concerned with External PSK.
>>
>> I would like for the specification to permit normal certificate
>> authentication when someone is using an External PSK.  I am guessing that
>> the granularity of the name associated with the External PSK to be pretty
>> broad.  If this guess is correct, it would be appropriate for the name in
>> the certificate to be further restrict the one associated with the External
>> PSK.  Maybe the External PSK is associated with example.com, and then
>> the certificate that includes www.example.com would be acceptable
>> acceptable.  Then, I would expect any Internal PSK that is generated after
>> such an authentication would be associated with the more granular
>> certificate name.
>>
>> Maybe it is as simple as reorganizing these bullets like this:
>>
>>    - When only PSK is being used, …
>>
>>    - When only (EC)DHE is being used, …
>>
>>    - When PSK and (EC)DHE are both being used, …
>>
>> If others agree with this direction, I am willing to propose some text.
>>
>> Happy holidays,
>>    Russ
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>