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
- [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 Benjamin Kaduk
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Ilari Liusvaara
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Nikos Mavrogiannopoulos
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Matt Caswell
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Nikos Mavrogiannopoulos
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… David Benjamin
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Ilari Liusvaara
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Jonathan Hoyland
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Matt Caswell
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Nikos Mavrogiannopoulos
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Karthikeyan Bhargavan
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Benjamin Kaduk
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Ilari Liusvaara
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Nikos Mavrogiannopoulos
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Ilari Liusvaara
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Karthikeyan Bhargavan
- Re: [TLS] on sharing PSKs between TLS 1.2 and TLS… Eric Rescorla