IETF Logo Mail Archive

Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD

Andy Lutomirski <luto@amacapital.net> Tue, 27 May 2014 19:17 UTC

Return-Path: <luto@amacapital.net>
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 47F111A06FD for <tls@ietfa.amsl.com>; Tue, 27 May 2014 12:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1vnduz-ffrFJ for <tls@ietfa.amsl.com>; Tue, 27 May 2014 12:17:48 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4434E1A0698 for <tls@ietf.org>; Tue, 27 May 2014 12:17:44 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id rq2so9766568pbb.17 for <tls@ietf.org>; Tue, 27 May 2014 12:17:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GVLxeMdrbq8hNI/ygugoY4BWwTwhDiRam/JBvuWzGj4=; b=cHQU2cvfxOUtntxKqLFnGyaZu4Lz4+1GHeGgo0LIVw0Mmx/QerjE0orMpdIQ0Qa08B Kbbdd3j7WmuHLJzm8JhN6thdEu8u0081eXeFpoPRim9ygCwxTgSkqQ0GBdAkez0DPyv+ UZVkHOjbnAuaiuU6rk9Kbq8NZvMKySe2aWP1nLG/oN6E1I2jgMbEeIhsWmK3zQFlr7XS NoeCYDc7nItmsvJoQTSe/LsrS9VsiD07XOz34/ZGfe5gNuQ1ysyII65qjHCbYAgHBmIC QoTAjh1xc4zYiyTsB15ZZHAym+OTW3uGAi0BSyQqLqhLR6onIuE4IKBH2Afm3R1pddHN DpOQ==
X-Gm-Message-State: ALoCoQlF/iZrKVWLdY828M57nTsiYed41WffWQNcIkp0M1lY6zhWehtZI2Np8ilKQfvmi2e4IydL
X-Received: by 10.68.134.69 with SMTP id pi5mr32665769pbb.126.1401218260949; Tue, 27 May 2014 12:17:40 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id fu12sm77169874pad.42.2014.05.27.12.17.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 12:17:39 -0700 (PDT)
From: Andy Lutomirski <luto@amacapital.net>
X-Google-Original-From: Andy Lutomirski <luto@mit.edu>
Message-ID: <5384E4D2.2010302@mit.edu>
Date: Tue, 27 May 2014 12:17:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>, Alyssa Rowan <akr@akr.io>, "tls@ietf.org" <tls@ietf.org>
References: <5383F02F.4050706@nthpermutation.com> <CFAA0E43.15C3B%uri@ll.mit.edu> <f16c4cb2-3ee8-443f-adbc-4e6fab36f707@email.android.com> <CFAA11DB.15C49%uri@ll.mit.edu>
In-Reply-To: <CFAA11DB.15C49%uri@ll.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EUvNX39yz9MDT3wBtf_udkE8E6w
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 19:17:52 -0000

On 05/27/2014 06:59 AM, Blumenthal, Uri - 0558 - MITLL wrote:
>>> What would be the consequences of this decision [removing static RSA]
>>> for embedded servers
>>> That may not have a good source of randomness to meaningfully engage in
>>> [EC]DH[E]?
>>
>> If they don't have any source of randomness, they are going to have
>> problems generating any keys, random nonces or IVs, period!
> 
> Respectfully disagree.
> 
> Keys: manufacturer can generate random key pairs for such devices and burn
> them in.

Which means that, if the device is ever a TLS client using an TLS
1.1-style RSA key transport, then the device is completely insecure: the
supposedly secret part of the pre-master secret will always be the same!

If the device really has no source of randomness, I think it's still
much better off using a static DHE secret.

--Andy

v2.23.0 | Report a Bug | By Email