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

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 20 July 2018 11:39 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 8A9F9130EB1 for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 04:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 LxJq4Knx5hOU for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 04:39:44 -0700 (PDT)
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 B5B93130DE7 for <tls@ietf.org>; Fri, 20 Jul 2018 04:39:43 -0700 (PDT)
Received: by mail-wr1-f51.google.com with SMTP id s11-v6so10996007wra.13 for <tls@ietf.org>; Fri, 20 Jul 2018 04:39:43 -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:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=z3QPAKvWmudSsY0KwBndmtIvsBMVgTZMGhSL9ApjsJY=; b=NIGLoErOdOXRQHKlJgbobIaPwI5IQR4wfZqmEYGTuYK1sjByQ3EOe3GgOmfT789C55 5lzLWhWcaZ4q+jOYxVPdlBaLSGWMkLfY4RAgU4IwcA3LmKxetp7H/k/VUd5+xyk6OPhb HzqyYn+N+JCNXQKFrk6NIzlUt45GRa0GIgKH/adW1TZmfgov8bke2CfbNptfPVwfBbMm MxMaXHX2QIXFCbOPZW1sujCV1+/vpckUq3714PQz1uvh1+HuAOGanA4u3/ZKPV0nt7RN yad03GjYcVbj9IXQrHbcXFR3Y94zJfGtkSqcWlVP+fxOu341sGoupm2PyXdZWvlctEaV 03nA==
X-Gm-Message-State: AOUpUlGi0iKlfro0v0Z8G/wtQHcWhrZykwDljcpanmFD8HPFNGeE69yd NMjjdcHCYe8Qy7N3EqI/9wK4oA==
X-Google-Smtp-Source: AAOMgpfO917grIw5Zz1Pp2kScRffnMIHzPrluGS55Gm3J4sNn5r+R2JRlojHGt3SYU/5/WbSYP3mMg==
X-Received: by 2002:adf:a401:: with SMTP id d1-v6mr1222997wra.121.1532086782251; Fri, 20 Jul 2018 04:39:42 -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 73-v6sm1831278wmu.37.2018.07.20.04.39.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 04:39:41 -0700 (PDT)
Message-ID: <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Date: Fri, 20 Jul 2018 13:39:40 +0200
In-Reply-To: <CABcZeBN4tdHZ_fzqqEJNR46BP5bxiy6gWa17xxhfj9YXVAR0rw@mail.gmail.com>
References: <20180719230009.GD14551@akamai.com> <ce4cb23be8939e57574062e17c4f204f7145d020.camel@redhat.com> <CABcZeBN4tdHZ_fzqqEJNR46BP5bxiy6gWa17xxhfj9YXVAR0rw@mail.gmail.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/jORf5LpIMuPcjcWnoCS_My7ol6o>
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 11:39:47 -0000

On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > 
> > > 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

I understand, but as I have already mentioned that argument also
applies for RSA keys which can be used e.g., for RSA encryption under
TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used
with multiple hashes under TLS1.2 while only one under TLS1.3.
TLS 1.3 did not enforce protocol separation for that ugly scenario, so
I wouldn't expect the treatment of PSKs differently.

Said that, I want to clarify that I wouldn't necessarily object to an
improvement the situation for externally established PSKs. The issue I
see is that TLS1.3 already gives a "good enough" solution with re-using 
the key, and I'm afraid we're going to have interoperation issues if
some implementations move to universal psks and some do not, defeating
the purpose of a standard.

regards,
Nikos