Re: [TLS] Using RSA PSS in TLS

Rob Stradling <rob.stradling@comodo.com> Mon, 14 October 2013 11:20 UTC

Return-Path: <rob.stradling@comodo.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 0D2FD11E8185 for <tls@ietfa.amsl.com>; Mon, 14 Oct 2013 04:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OCdskul-LEE for <tls@ietfa.amsl.com>; Mon, 14 Oct 2013 04:19:49 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mmmail.mcr.colo.comodoca.net [91.209.196.71]) by ietfa.amsl.com (Postfix) with ESMTP id E399D11E8182 for <tls@ietf.org>; Mon, 14 Oct 2013 04:19:27 -0700 (PDT)
Received: (qmail 12232 invoked from network); 14 Oct 2013 11:19:12 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 14 Oct 2013 11:19:12 -0000
Received: (qmail 24625 invoked by uid 1000); 14 Oct 2013 11:19:12 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 14 Oct 2013 12:19:12 +0100
Message-ID: <525BD330.6080100@comodo.com>
Date: Mon, 14 Oct 2013 12:19:12 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Santosh Chokhani <SChokhani@cygnacom.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com>
In-Reply-To: <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 14 Oct 2013 11:20:14 -0000

On 14/10/13 12:08, Santosh Chokhani wrote:
> Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI in the Server certificate would indicate it is RSA 1.5 or PSS and you do not need additional cipher suites.

But, when the server is deciding which of its 1 or more certs to send, 
how can it tell whether or not the client supports PSS?

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann
> Sent: Monday, October 14, 2013 6:59 AM
> To: <tls@ietf.org>
> Subject: Re: [TLS] Using RSA PSS in TLS
>
> =?UTF-8?B?SGFubm8gQsO2Y2s=?= <hanno@hboeck.de> writes:
>
>> legacy compatibility is exactly the point. Implementations must be
>> prepared to communicate to servers / clients that do not support the new version.
>
> Never underestimate that amount of weight that carries.  There was an attempt, some years ago, to mandate RSA-PSS for certificates.  It met with pretty much universal rejection, to the extent that people would probably ignore the requirement even if it was made a MUST in the spec (at the time it was described as "X9.42 all over again", a reference to another MUST that everyone ignored), and as a result was dropped.
>
> The problem with -PSS is that it doesn't real fix anything in -1.5 (I know it's *theoretically* better, but unless you do -1.5 really badly there's no practical weakness that would encourage an upgrade).  Counting against that is the near-insurmountable cost of a changeover (everyone has to redeploy global crypto infrastructure from scratch).
>
> Peter.
> _______________________________________________
> 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
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online