Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Russ Housley <housley@vigilsec.com> Tue, 21 May 2019 13:54 UTC

Return-Path: <housley@vigilsec.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 0087F120043 for <tls@ietfa.amsl.com>; Tue, 21 May 2019 06:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 SIq5tJSPyxqD for <tls@ietfa.amsl.com>; Tue, 21 May 2019 06:54:16 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFF2120041 for <tls@ietf.org>; Tue, 21 May 2019 06:54:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1AFA5300ABC for <tls@ietf.org>; Tue, 21 May 2019 09:34:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2w6AsffgMDeF for <tls@ietf.org>; Tue, 21 May 2019 09:34:56 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6E88F3005AB; Tue, 21 May 2019 09:34:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <m28sv03b6y.fsf@localhost.localdomain>
Date: Tue, 21 May 2019 09:54:13 -0400
Cc: Joe Salowey <joe@salowey.net>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B76BDA6-5641-43A9-894F-2D70AEE9AC09@vigilsec.com>
References: <CAOgPGoBA8KykyHmLxqSEp51jyXO673Wb==O9KVx+U23k3h1=Tg@mail.gmail.com> <CAOgPGoDArfcX09bXVT58VgsyXspG76Cm9TNaBUmGgaqUB=ULUA@mail.gmail.com> <m28sv03b6y.fsf@localhost.localdomain>
To: Geoffrey Keating <geoffk@geoffk.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/b7RGEboewmY1JjpnH-JyW1pfRwI>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk
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: Tue, 21 May 2019 13:54:18 -0000

Geoffrey:
> 
> The last call has come and gone without any comment.  Please indicate if
>> you have reviewed the draft even if you do not have issues to raise so the
>> chairs can see who has reviewed it.  Also indicate if you have any plans to
>> implement the draft.
> 
> I looked at the draft.
> 
> My understanding of the draft (and I think it would have helped if it
> contained a diagram showing the resulting TLS handshake) is that it's
> specifying the existing psk_dhe_ke flow, to which it adds a
> certificate-based signature over the handshake, which it doesn't
> specify but works the same way as in RFC 8446 when there is no PSK.

I am pleased to add text that will make it more clear, but you are the first one to ask.

Please see slides 5 and 6 of the presentation at IETF 104:
https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls13-cert-with-extern-psk-00

> This is somewhat confusing because the draft is written as if it
> starts with a certificate-based TLS flow and somehow adds a PSK; it
> repeats all the RFC 8446 PSK machinery, but doesn't explain how the
> certificate interacts with it, and raises questions like "are there
> two DH operations or just one?".  I think the draft could have been a
> lot shorter.

One (EC)DH exchange.

I agree that there is a fair amount of context in the draft.  That was an attempt to avoid the confusion that you claim in the previous paragraph.

> Conversely, one area where the draft could have been longer would be to
> explain how exactly this produces quantum-resistance in the presence
> of a secret shared key.  It appears that it relies on the HKDF-Expand
> function being quantum-resistant.  That seems like an important thing
> to document, given that we don't have fully functional quantum
> cryptanalysis yet and so don't know exactly what might be
> quantum-resistant or not.

Hash functions are quantum-resistant.  Shor's algorithm means that you might want to use one that 2x longer than previously chosen.  The same is true for symmetric encryption algorithm keys.

I can add a paragraph to the security considerations that HKDF and the underlying hash function are assumed to be quantum-resistant.

> However, once you're past that, the resulting protocol seems quite
> simple (as an addition to psk_dhe_ke) and I have no objections to it.

Thanks.

Russ