IETF Logo Mail Archive

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

Michael StJohns <msj@nthpermutation.com> Tue, 27 May 2014 17:43 UTC

Return-Path: <msj@nthpermutation.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 9C51F1A0527 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 10:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pfhOaA_8m64S for <tls@ietfa.amsl.com>; Tue, 27 May 2014 10:43:48 -0700 (PDT)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5D41A0502 for <tls@ietf.org>; Tue, 27 May 2014 10:43:48 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id jt11so9675455pbb.13 for <tls@ietf.org>; Tue, 27 May 2014 10:43:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0oxgzjJu0CwlW/GB2/8mMaonOAXFhhMrZDBnCWtnRwQ=; b=DOEWP9Ma+OPXskQdeYnUS/QaKXE38LzA+5fst/ACQ0rTY8MqWIEvzPq24G62bkk1mN AaZwFNozIw3E2UE4uMu2k3o5ym/aDVTPyO/LHdHThilqmOJxM5yWekbAfULVUaJMCTao fGOR9AKowZdzMNH38fMFKDRrhwKrQ4cZhayrqb7w7Wzyh6mvvLss2uBEc2nLf+R5/3ht Res93VbGEX0Uu1GhmjRNrW0XDJkzPppGLveXvFD88OAJyyyDIs0c01uBktl9zR2XSBUB 3wpAEGjSuEhAffCmaWZDCip3HQ+l3owKrsYOBtmDH/mVfPHO2U0JV9QV/gJYXPp1/CHn 6P3w==
X-Gm-Message-State: ALoCoQm9JGxbIj5w81IZhATeUZ/kWg10KJjgF9lix2OTBH9QMk8YrU3vDdF0Qa3B/rXhXXV47T3g
X-Received: by 10.68.200.133 with SMTP id js5mr39033146pbc.138.1401212625404; Tue, 27 May 2014 10:43:45 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id pr4sm24327835pbb.53.2014.05.27.10.43.44 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 10:43:44 -0700 (PDT)
Message-ID: <5384CED8.6030700@nthpermutation.com>
Date: Tue, 27 May 2014 13:43:52 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <5383F02F.4050706@nthpermutation.com> <CFAA0E43.15C3B%uri@ll.mit.edu> <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pJdPrhBwSIzGoGnJBK_WsrJI2UU
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 17:43:49 -0000

On 5/27/2014 11:18 AM, Dan Brown wrote:
> 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.

One of the London decisions (which EKR clarified earlier in the thread) 
is the removal of key transport (e.g. RSA static encryption) as a key 
exchange mechanism for TLS1.3.  That removes the need to generate a 
pre_master_secret as the product of only one side.

Mike

v2.23.0 | Report a Bug | By Email