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

Eric Rescorla <ekr@rtfm.com> Fri, 20 July 2018 09:39 UTC

Return-Path: <ekr@rtfm.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 E172C131136 for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 02:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 9xF5hegb73hZ for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 02:39:15 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 34EF5131133 for <tls@ietf.org>; Fri, 20 Jul 2018 02:39:15 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id j143-v6so1359442lfj.12 for <tls@ietf.org>; Fri, 20 Jul 2018 02:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PmmUGZctUBvo8ygUu+cLZJWGJGv7xIyAn+vAmTxad6c=; b=MsCFQ7uNW2zewhvwUOHjHfQQ2SddMu4ePWDWDzOCdkNBWjJrl85PZbcXDXzTnC+XPA sz6FXC8l3Ojb0NSoq2fAlonNmz2IPgMMkdYcNKbTbcCKg/kJquRrccjXJaxj/f22RnDA cbdsezdXAt8eAby1GWp2l7Hjh5e0Dn4n0/k4NSc3Kd/ryoiqRvKVaIV5kP1NlZRSdj7S DnsIikis4ikkLBU9DG4tWAp5Qxtj8OCNC/U9RejHR3iDjFb95rLKw1s+qDGgfAwGfbLe 9GOrnsPP91YtH7okl1ry7dQI8JoiC476ZMFMZQ31dadPKBi7UYp0wj00zQUDvNe4DPbh qDng==
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=PmmUGZctUBvo8ygUu+cLZJWGJGv7xIyAn+vAmTxad6c=; b=VaBB6NFB6WVx18j9uwER6fZ9eiDbh9LOsdq0YOfx+FGYQQ+N+bBFwElPhGAEWhfaLF 1mp9nBpQx6pb09HSxJA8UEox6a7Uck3UlMFAADZ5DKIrE1axpAJCIq2HjF+WBgtSy0Iw /wd7VFbOYPDjhwMv3vwMu9nVO1COaPYmKSV9shRuIcACw15jVQnU0032MkccpsXo8CYe AWvF+G3jqBI0FNcQsyGg79TjL5bQ9dbkXRQqIHmdOErd9Ioc/f0aHVqSZB7xGU7GKWs6 EEuI9o65Tub+bBsRYDh7HtxDuSY2bnyiqpR45EYyzzXW3wMMGr8GmNHhLA2E2cvLMmOI tdyA==
X-Gm-Message-State: AOUpUlEYWKNxgfaNP0h6FJYHot0HqBIWJcysRmFZ5RizP4mTnsIBfobi l0uMq66YlO/ZDdZDFMrI0YHKL1WiCGWP50hjCeZJcg==
X-Google-Smtp-Source: AAOMgpckZrzdNKKz0rnO2LknBJ4LME7Y65WBY5qVXNWkxh6ttayea+UEGwy0qqNRQd/YX3e5GA3k+e5HD3B6XpYIam0=
X-Received: by 2002:a19:6308:: with SMTP id x8-v6mr968982lfb.104.1532079553429; Fri, 20 Jul 2018 02:39:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 02:38:32 -0700 (PDT)
In-Reply-To: <ce4cb23be8939e57574062e17c4f204f7145d020.camel@redhat.com>
References: <20180719230009.GD14551@akamai.com> <ce4cb23be8939e57574062e17c4f204f7145d020.camel@redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 20 Jul 2018 02:38:32 -0700
Message-ID: <CABcZeBN4tdHZ_fzqqEJNR46BP5bxiy6gWa17xxhfj9YXVAR0rw@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008cd74405716b11a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/59bBS1zB_dIDcOW5PaToUhugrYw>
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 09:39:18 -0000

On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> 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.
>

The issue is not cross-protocol attacks; it's the reuse of PSKs with
different KDFs, which we don't have any analysis for and which the TLS 1.3
document prohibits.

-Ekr


> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>