IETF Logo Mail Archive

Re: [TLS] RSA-PSS in TLS 1.3

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 07 March 2016 17:21 UTC

Return-Path: <sfluhrer@cisco.com>
X-Original-To: tls@ietfc.amsl.com
Delivered-To: tls@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B77E71CD60B for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 09:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.621
X-Spam-Level:
X-Spam-Status: No, score=-12.621 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly3LLxtGqR4C for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 09:21:47 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 40F671CD609 for <tls@ietf.org>; Mon, 7 Mar 2016 09:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11244; q=dns/txt; s=iport; t=1457371307; x=1458580907; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p+szWQKYKJQZvT+9nUoUcMrweeI4M5CmLdeAPxlddFY=; b=Tb/z18+imsJPgJkvW+ilCMxkNyVmopZkxanfYOpZaqCqahwmHFeyQirU fuXCPmVxNkTHq0PMigaNClCZJFJMfbRCGSMdvVIW5BxJOwBYJuhy8mwYO 5Bxo632yUK/vCvXduhlRV+EJ6Jz3I4Up+v3fbtJoMl5M5c54LRnd0q7E4 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArAgBXuN1W/40NJK1cgm5MUm0GujoBDYFphg8CHIEOOBQBAQEBAQEBZCeEQQEBAQQjCkwQAgEIDgMEAQEoAwICAh8RFAkIAgQOBQiIBwMSr3GKMw2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGF4Q9gj2CEyCCSoE6BYg3jnMBi3eBbo8BhwyHSAEeAQFCg2RqiD9+AQEB
X-IronPort-AV: E=Sophos;i="5.22,552,1449532800"; d="scan'208,217";a="246699308"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 17:21:45 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u27HLjjf031766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 17:21:45 GMT
Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 11:21:38 -0600
Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 11:21:32 -0600
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Tony Arcieri <bascule@gmail.com>
Thread-Topic: [TLS] RSA-PSS in TLS 1.3
Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AAChgSqAAAfIBWD///NnAIAAWx/g
Date: Mon, 07 Mar 2016 17:21:32 +0000
Message-ID: <d7bbbb10fa7a42368717ee47a45c07d6@XCH-RCD-006.cisco.com>
References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> <CAHOTMVKMPuaakquEz=s7pRDGEHpXT9qsRVkNMv_kaz5Zx31skQ@mail.gmail.com>
In-Reply-To: <CAHOTMVKMPuaakquEz=s7pRDGEHpXT9qsRVkNMv_kaz5Zx31skQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.61]
Content-Type: multipart/alternative; boundary="_000_d7bbbb10fa7a42368717ee47a45c07d6XCHRCD006ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ak9buaNWpKeHUQASMQYC7sA5gMs>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 07 Mar 2016 17:21:48 -0000

From: Tony Arcieri [mailto:bascule@gmail.com]
Sent: Monday, March 07, 2016 11:40 AM
To: Scott Fluhrer (sfluhrer)
Cc: Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>> wrote:
Defenses against the first type of attack (passive evesdropping by someone who will build a QC sometime in the future) are something that this WG should address; even if the PKI people don't have an answer, we would at least be secure from someone recording the traffic and decrypting it later

I think it would make sense to wait for the CFRG to weigh in on post-quantum crypto. Moving to a poorly studied post-quantum key exchange algorithm exclusively runs the risk that when it does receive wider scrutiny new attacks will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for the CFRG than the TLS WG.


I’m sorry that I wasn’t clearer; I agree that *now* isn’t the time to define a postquantum ciphersuite/named group; we’re not ready yet (and this WG probably isn’t the right group to define it).  However, I believe that we will need to do at some point; my guess is that it’ll be sooner rather than later.  What (IMHO) this WG should be doing now is making sure that there isn’t something in TLS 1.3 that’ll make it harder to transition to postquantum crypto when we do have a concrete proposal.

One thing that proposed QR key exchanges have is that they don’t have the full flexibility that (EC)DH have; either they aren’t secure with static key shares, or we can’t use the same key share as both an ‘initiator’ and a ‘responder’ key share.  This would indicate to me that we need to make sure that TLS 1.3 should be engineered to use (EC)DH as only a simple, ephemeral-only key exchange – yes, it has more flexibility than that, however taking advantage of such flexibility might cause us problems in the future

v2.23.0 | Report a Bug | By Email