[TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3

Rene Struik <rstruik.ext@gmail.com> Mon, 07 March 2016 19:48 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: tls@ietfc.amsl.com
Delivered-To: tls@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id 2DF9D1CDA2F for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 11:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.201
X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id Yu9pi-YirMd1 for <tls@ietfc.amsl.com>; Mon, 7 Mar 2016 11:48:50 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 6774C1CDA2A for <tls@ietf.org>; Mon, 7 Mar 2016 11:48:50 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id y89so105324238qge.2 for <tls@ietf.org>; Mon, 07 Mar 2016 11:48:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Z1R7xPkaWgpoOij1fOUiAOzcmbQGFjmnR3Q0ca1AZBc=; b=wV2aJ9vBqAXySrt8VHdmlSpqFIEtFZvh9aInYWDMTmzEzzrLR8nytRsK2pUqaVl4tD S+XcW6pAVgAXlThxH1ECqdV/z7Z7h1wM9BH4SQvcq7oQxMgV7YUcwhC/2uEyihSSY/XQ CYggw4JKIM0yzakKSsoK3sMlSfITvtUuAw+wtxFqN5Fy+TgcNtP2e+yIkYf9KPnjqbKH YG6tO1BN88dF0ox/WyDBAAGDHvFttS1Bx5rRMxu/InIVGMsPZ5XUyYFJQa0k0rtLlolH jrsYDWgqMSjZ599rBwgvrP+8a+i1CPm2fnJ9CIqlwbXNG3L6XIleX1/BKuuKVMfPVveC 6qbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Z1R7xPkaWgpoOij1fOUiAOzcmbQGFjmnR3Q0ca1AZBc=; b=FokkwebtrTAAb5Kx4jJvjL+JKPfTkLKUNrLTlvwPJs8nDrj5ilVqxW0bvj81gFaG1l 5oOJyX77uPa9xljcl/QIFayOi2+XMXHRgcmtlfKp9B616oF5fa8ns4VceFKrLhFYWilx RdKp0ArCv3+S92nbvgy168ZakENIsLpulVPM8V3LDmqZJSVyKWhtHNT5vDVUBbSJyBBF g56n9QgUcHBj/FJ4LZnot+dHt27Vs93crvOLsAuxQVR0tnMHXF5UY/FvcKM5zTA5XV/W 809bxKEqNc81x+wrz4oYsaRu88ACqYRMT+3fAiCOvomWYiWxBzNrsXd+kemHnIs+el5L BrlA==
X-Gm-Message-State: AD7BkJJvmowDMaUt5sAR0pMCVvpzrwvL2G/iHCucMLNS9WfWxRQBpU1C5FY4WDIc2aHLCA==
X-Received: by with SMTP id y32mr30422407qgd.42.1457380129495; Mon, 07 Mar 2016 11:48:49 -0800 (PST)
Received: from [] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. []) by smtp.gmail.com with ESMTPSA id v66sm8635116qhb.26.2016. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 11:48:48 -0800 (PST)
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, Tony Arcieri <bascule@gmail.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> <d7bbbb10fa7a42368717ee47a45c07d6@XCH-RCD-006.cisco.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <56DDDB1E.1090007@gmail.com>
Date: Mon, 7 Mar 2016 14:48:46 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <d7bbbb10fa7a42368717ee47a45c07d6@XCH-RCD-006.cisco.com>
Content-Type: multipart/alternative; boundary="------------010400030408050409000403"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lED7sD_b_v4PhOPUIjr-3rz6VIY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: 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 19:48:52 -0000

Hi Scott:

I think it is really premature to speculate on features PQ-secure 
algorithms can or cannot provide (*) and try and have this influence 
*current* TLS1.3 protocol design.  Should one wish to include PQ 
algorithms in a future update of TLS1.3, one can simply specify which 
protocol ingredients those updates relate to. As long as the current 
TLS1.3 specification has some facility for implementing algorithm 
agility, one can shy away from crystal ball gazing for now.

Best regards, Rene

(*) I am not sure everyone would concur with your speculation, but 
crypto conferences may be a better venue to discuss this than a TLS 
mailing list.

On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote:
> *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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363