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

Watson Ladd <watsonbladd@gmail.com> Tue, 27 May 2014 14:00 UTC

Return-Path: <watsonbladd@gmail.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 459D51A034E for <tls@ietfa.amsl.com>; Tue, 27 May 2014 07:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 65C8-WUnD9Ah for <tls@ietfa.amsl.com>; Tue, 27 May 2014 07:00:52 -0700 (PDT)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED691A0354 for <tls@ietf.org>; Tue, 27 May 2014 07:00:52 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id a41so7476525yho.7 for <tls@ietf.org>; Tue, 27 May 2014 07:00:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1szYJS5qFGSBjg+QzkWaX5xVjYpeKhksVoqIux0//j4=; b=aY8FO8P5MLI7xU6oF1xKnLj7sHtUoyCNgRr27huTWFmm6IFCV9ib64brreNJFSV7vX LrEPij4Gf8WbcIgyRbKBvLIqAeAnM0i3oPgD6yWWJvejhY38ugVB7KBUJbSwoguk58rZ yUlpRIcjZIXh5Vwgp3DjRrNuAW3u5dbf/dqrzFVN52tiOywDXHLd+AodM14n+oUygwBD La59Z8LzuN9v9h61p00G5NVdp7RUad3lbfX5Qrqu9qU3qtgncVBpaeqoC2V+2vrWN9So dwEiJ6Bn46KtrLESe8V5eNZ8CorWBoMQm19jYSV7eWKYcofqtFjKyEDzhgGj/ZfD8E2m jyEw==
MIME-Version: 1.0
X-Received: by 10.236.120.66 with SMTP id o42mr46715640yhh.66.1401199249140; Tue, 27 May 2014 07:00:49 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 07:00:49 -0700 (PDT)
In-Reply-To: <CABcZeBNJkq6us9=1HM28jwNbBDYak=4NiE5QXetJoLZxjSXQ2w@mail.gmail.com>
References: <5383F02F.4050706@nthpermutation.com> <CFAA0E43.15C3B%uri@ll.mit.edu> <CABcZeBNJkq6us9=1HM28jwNbBDYak=4NiE5QXetJoLZxjSXQ2w@mail.gmail.com>
Date: Tue, 27 May 2014 07:00:49 -0700
Message-ID: <CACsn0cmO5=AfrMN3+6ewAZPZ34XRd4JKti397XQhfyp5pYFqdg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iQI1yCuiEfQhv9aJRg5l8dFCV0w
Cc: "tls@ietf.org" <tls@ietf.org>
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 14:00:55 -0000

On Tue, May 27, 2014 at 6:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL
> <uri@ll.mit.edu> wrote:
>>
>> >...... 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]?
>
>
> They will be in trouble. However, presumably if they have a place to store
> their private key, they can somehow store other random data there that
> they use to generate random values, no?

But then they can store an incrementing counter for use with AES with
a fixed key as a RNG. I don't see the problem here.
>
> -Ekr
>
>>
>> _______________________________________________
>> 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
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin