Re: [TLS] RSA-PSS in TLS 1.3

Russ Housley <housley@vigilsec.com> Wed, 06 July 2016 17:27 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 271E212D1CB for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 10:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 IgkKoHkQRLg5 for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 10:27:29 -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 F07A312D5A8 for <tls@ietf.org>; Wed, 6 Jul 2016 10:27:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C7D0A300541 for <tls@ietf.org>; Wed, 6 Jul 2016 13:27:24 -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 UzdN--VviXiG for <tls@ietf.org>; Wed, 6 Jul 2016 13:27:23 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 63BD23004EE for <tls@ietf.org>; Wed, 6 Jul 2016 13:27:23 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_306D9E5B-C87B-421D-8246-746F1E4D1CBF"
Message-Id: <65544CC0-B59E-430B-A3C0-08F105CBFCFA@vigilsec.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Wed, 06 Jul 2016 13:27:28 -0400
References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> <CAOgPGoDq0r9CJETzmBvJTk+NNkCj1B=rwbtnD_e5-=VaRRdf=g@mail.gmail.com>
To: IETF TLS <tls@ietf.org>
In-Reply-To: <CAOgPGoDq0r9CJETzmBvJTk+NNkCj1B=rwbtnD_e5-=VaRRdf=g@mail.gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i28_jUoVMAlleyrI33V5So-NpSg>
Subject: Re: [TLS] RSA-PSS in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Jul 2016 17:27:32 -0000

I support a MUST for RSA_PSS for certificate verify, and it does seem like a good idea to be algorithm agile.

Russ


On Jul 6, 2016, at 1:23 PM, Joseph Salowey <joe@salowey.net> wrote:

> I don't think we ever call consensus on this topic.  It looks like there is rough consensus to move forward with RSA-PSS as the MUST implement algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.   During the discussion it also seemed that it is realistic that we may want to add additional types in the future.  We may want better separation of signature types of certificates and certificate verify.  
> 
> Cheers,
> 
> J&S
> 
> On Wed, Mar 9, 2016 at 2:05 AM, Hubert Kario <hkario@redhat.com> wrote:
> On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote:
> > On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > > No, I said that we have no reason to believe that quantum computers
> > > won't follow exponential increase in number of qbits they can
> > > handle,
> > > with the highest increase not exceeding doubling every year, but
> > > more
> > > likely doubling every two years (as every other technological
> > > development did till now).
> >
> > There's reason to be skeptical of such analogies.  Moore's law was
> > neither a theorem nor a law of nature.  It was an observation about
> > progress in feature-size shrink of silicon transistors.  It is far
> > from clear that evolution of silicon fabrication is a relevant model.
> 
> That's why I'm not saying that it will be exactly like Moore's law.
> 
> My point is, that processes which have super-exponential growth are the
> exception, not the rule (if they exist at all). And you would be hard
> pressed to find any process in history that experienced exponential
> growth over a long time span and be at the same time vastly faster than
> the Moore's law.
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls