IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 27 May 2014 14:11 UTC

Return-Path: <ekr@rtfm.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 425BF1A034E for <tls@ietfa.amsl.com>; Tue, 27 May 2014 07:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DY8ZUsfsHNsj for <tls@ietfa.amsl.com>; Tue, 27 May 2014 07:11:27 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695D51A0137 for <tls@ietf.org>; Tue, 27 May 2014 07:11:27 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id cc10so1814560wib.4 for <tls@ietf.org>; Tue, 27 May 2014 07:11:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vSaImjdpx4OytSdwqwfj9J6U5Mp7gEpav2cSjMd+RT4=; b=hCgIzfh+zmBWotH/ldfWMHY6Tv1nzz+tdpIOClG/FW/UsmC2GvBMpT/ZYOliAxrzpm ytkFJjcVo/NRDFcktmfdSnQMI1+zsfgiwZhDx6jznVq2lvQA7cZ7fGHYkJLiT+a80nyI 4t5YTwKzeOYE+PPfrMBwbQDlc7tBJivhViLyLgBx9ZF0tDCxf1DLaakcWDsOrkUb+mzk grkfDxs+bFc+E6+tU3UrNdfijs2zGAQCoK5qyyUA/WGgj51CuKkJjfhby4gCHehiqeZu vTifAvijR2p9p981G/cEWVoS5GIWMBA/dSqjq8RO71gDj4vTB3CFyN+zSGN743XPSNML Ruvw==
X-Gm-Message-State: ALoCoQkZFyXk0l4PLe+wmwR6W18wgVeHn+VHppy8dQu+B8JsOt0m6Fm0xMKSVPzNxql/ejv2NiuT
X-Received: by 10.180.93.234 with SMTP id cx10mr23156683wib.18.1401199880699; Tue, 27 May 2014 07:11:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Tue, 27 May 2014 07:10:40 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0cmO5=AfrMN3+6ewAZPZ34XRd4JKti397XQhfyp5pYFqdg@mail.gmail.com>
References: <5383F02F.4050706@nthpermutation.com> <CFAA0E43.15C3B%uri@ll.mit.edu> <CABcZeBNJkq6us9=1HM28jwNbBDYak=4NiE5QXetJoLZxjSXQ2w@mail.gmail.com> <CACsn0cmO5=AfrMN3+6ewAZPZ34XRd4JKti397XQhfyp5pYFqdg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 27 May 2014 07:10:40 -0700
Message-ID: <CABcZeBNT6k6P7mEVBaJE3yXMrM-JsseVd2gZa4AtyTZMAM=qSA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="f46d04388e17261c0304fa62456a"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1NHAIg91lfXhEcEqkfsH8U4Q2HM
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:11:35 -0000

On Tue, May 27, 2014 at 7:00 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> 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.


Yes, that is one way of doing what i was suggesting.

-Ekr

v2.23.0 | Report a Bug | By Email