Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
Dan Brown <dbrown@certicom.com> Tue, 27 May 2014 15:18 UTC
Return-Path: <dbrown@certicom.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D64A1A00F9 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 08:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 Bg5H9M5VxBrk for <tls@ietfa.amsl.com>; Tue, 27 May 2014 08:18:30 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB41A034E for <tls@ietf.org>; Tue, 27 May 2014 08:18:27 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 May 2014 11:18:20 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Tue, 27 May 2014 11:18:19 -0400
From: Dan Brown <dbrown@certicom.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
Thread-Index: AQHPebG6jS62b94+bkCFOdj7VQoBAZtUfXPg
Date: Tue, 27 May 2014 15:18:19 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net>
References: <5383F02F.4050706@nthpermutation.com> <CFAA0E43.15C3B%uri@ll.mit.edu>
In-Reply-To: <CFAA0E43.15C3B%uri@ll.mit.edu>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_000F_01CF799D.5B4DDE90"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZfQe0Zobl7NQhi91ggYQo5ijqNE
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 27 May 2014 15:18:31 -0000
> -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Blumenthal, Uri - > 0558 - > MITLL > Sent: Tuesday, May 27, 2014 9:44 AM > > >...... Could someone confirm > >"removing static RSA" results in removing the use of RSA as a key > >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of > >TLS1.2 - basically removing this section and prohibiting "rsa" and > >"rsa_psk" as key exchange algorithms)? > > > >To go further and take this up from specific cryptography - will/should > >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key > >Agreement mechanisms for key exchange? > > What would be the consequences of this decision for embedded servers that > may not have a good source of randomness to meaningfully engage in > [EC]DH[E]? As noted elsewhere, if the server is authenticated (or at least has a long-term private key) and has a persistent state then it should be able to implement a good PRNG. Then it can do pretty good DHE, with forward secrecy, which is better than key transport. Otherwise, static [ECH]DH seems quite similar in security properties to key transport, from the server's side, for the following 2 reasons. If the server is completely stateless and lacks an entropy source, it will fail to achieve FS in its attempts at DH[E], but this is still as good as key transport. If the server is anonymous, (or at least lacks a long-term private key) and lacks a source of entropy, a persistent state does not seem to help, whether for DH or RSA key exchanged. --- A different question: what about very constrained clients? Is this even a fair question? For example, what if the client can be seeded with entropy but lacks a live entropy source and a persistent state (to implement a good PRNG)? Currently key transport require the client to generate a random pre_master_secret. A weak client could naively always generate the same PMS, which would be bad. It could derive the PMS from the server key public key, and perhaps the server random value, so that PMS is not common to two different servers, or sessions. This would make it similar to static DH. An even weaker client is one that is unseeded and entropy-lacking (and completely stateless, not that statefulness would help here). Such a client could apply deterministic encryption of messages using RSA. Note that this would no longer be key transport, but rather content encryption, so would require a major change to TLS. Also, this type of deterministic encryption lacks many of the important security benefits of probabilistic encryption. There have been research papers about deterministic encryption: the security is limited by the amount of entropy in the message being encrypted. Anyway, maybe this is the one situation in which RSA has an advantage over DH.
- [TLS] Clarifications and questions: TLS1.3 - Stat… Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Eric Rescorla
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Eric Rescorla
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Alyssa Rowan
- Re: [TLS] Clarifications and questions: TLS1.3 - … Eric Rescorla
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Watson Ladd
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Eric Rescorla
- Re: [TLS] Clarifications and questions: TLS1.3 - … Jakob Breier
- Re: [TLS] Clarifications and questions: TLS1.3 - … Dan Brown
- Re: [TLS] Clarifications and questions: TLS1.3 - … Jakob Breier
- Re: [TLS] Clarifications and questions: TLS1.3 - … Dan Brown
- Re: [TLS] Clarifications and questions: TLS1.3 - … Watson Ladd
- [TLS] IV Generation was: Clarifications and quest… Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Michael StJohns
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Clarifications and questions: TLS1.3 - … Alyssa Rowan
- Re: [TLS] Clarifications and questions: TLS1.3 - … Andy Lutomirski
- Re: [TLS] Clarifications and questions: TLS1.3 - … Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] IV Generation was: Clarifications and q… Martin Rex
- Re: [TLS] IV Generation was: Clarifications and q… Michael StJohns
- Re: [TLS] IV Generation was: Clarifications and q… Martin Rex
- Re: [TLS] IV Generation was: Clarifications and q… Michael StJohns
- Re: [TLS] IV Generation was: Clarifications and q… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] IV Generation was: Clarifications and q… Michael StJohns