Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 20 July 2018 07:29 UTC

Return-Path: <nmav@redhat.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 06FF1131068 for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 00:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 afkotToZW4Wv for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 00:29:07 -0700 (PDT)
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 960C51310E1 for <tls@ietf.org>; Fri, 20 Jul 2018 00:29:07 -0700 (PDT)
Received: by mail-wm0-f50.google.com with SMTP id l2-v6so3516817wme.1 for <tls@ietf.org>; Fri, 20 Jul 2018 00:29:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=7zSLFQTfyhYONit3/Nw6hXjjSDpHI1b6uBkU0rLk6/w=; b=WRArBYKN1kJtmxX0T7JT/KJUdnnMooYSOhJIQB9q3jK1vXqt3M2M6EFrP27g1KY08W ZPxj3eJKiXrn7Vhwgrlt8nZqgnPI0iw+rpRyfnwTpsogBKiwU4xaMbWT10BLAxwH/8kC /E3KL8AKgPrLYO7zjvK1Lp+NTSCxFq9TJ7/BEe8HbcBVkd8XQMYuenMKUvo97C3K7VWO d+fyuQlVktpR8Z5c920CkarNrZdmXCtWOfaIz9IOj8J30cOjUUFulsIxemGYyOKDZvnD YmxlIhfx7dMtnHWzqulSrdaVswNMqh36AbT3B9pdJPDzlm23/xsS1c78+GwGqXgTgGD9 e5SA==
X-Gm-Message-State: AOUpUlHugPL7zBn0nipYpN8XeXzwaLJbWCaF5nQTBV32x5m4XP3ATy5g BsxR9hfpPwulOj/HaJqclAerTvxIZLs=
X-Google-Smtp-Source: AAOMgpdlQujSBWlc6beH+UHfOFQaG+L5+8nLwrWTHXuBO7GpUR8xTA0Sgkra/bQHlz0w8b2Vf/YQvQ==
X-Received: by 2002:a1c:dc89:: with SMTP id t131-v6mr826518wmg.50.1532071745759; Fri, 20 Jul 2018 00:29:05 -0700 (PDT)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id t9-v6sm981229wra.62.2018.07.20.00.29.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 00:29:04 -0700 (PDT)
Message-ID: <ce4cb23be8939e57574062e17c4f204f7145d020.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, tls@ietf.org
Date: Fri, 20 Jul 2018 09:29:03 +0200
In-Reply-To: <20180719230009.GD14551@akamai.com>
References: <20180719230009.GD14551@akamai.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.3 (3.28.3-1.fc28)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FEAc3N1V9f2jUfzuyuFiiI0Q7z8>
Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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, 20 Jul 2018 07:29:18 -0000

On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> Hi all,
> 
> As I mentioned at the mic today, there is a question that has been
> raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> directly in the TLS 1.3 key ladder.  At a high level, the reason why
> one
> might want to restrict this is that the security proofs for TLS 1.3
> rely
> on the pre-shared key being only used with a single key-derivation
> function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
> key-derivation function, so formally the proofs do not hold.  We
> don't
> currently know of a specifc attack against such reuse, of course, but
> perhaps it is prudent to restrict our usage to adhere to the verified
> scenarios.
> 
> This is somewhat timely, as if we do want to introduce a restriction,
> it
> would ideally be in the form of some text in the TLS 1.3
> specification,
> which is very nearly done.
> 
> It would be good to hear more opinions on this question, particularly
> from those who have worked on the formal verification directly.
> 
> If I can attempt to summarize some discussion that occurred in the
> mic
> line today, Hannes was surprised that we would care, likening this
> case
> to the regular version negotiation, where we are happy to use the
> same
> certificate to sign messages for both TLS 1.2 and 1.3.  David
> Benjamin
> points out that we explicitly go to the trouble of putting 64 bytes
> of
> 0x20 padding at the front of the content that gets signed for
> CertificateVerify, to enforce separation between the TLS versions.
> 
> My own personal opinion is that we should enforce a domain separation
> between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal
> PSKs"
> proposal seems like a potential mechanism by which to do so without
> doubling the provisioning needs.

I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. 
There is no inherent difference between the two keys types. I could
have deployed TLS with PKI or TLS with PSK. I should be able to upgrade
protocols the same way.

If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should
PSK keys. The current document specifically allows that re-use, and if
you fear that the current document did not take cross-protocol attacks
in mind during design, then let's fix that instead.

regards,
Nikos