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

Michael StJohns <msj@nthpermutation.com> Tue, 27 May 2014 01:53 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 2D43B1A02EC for <tls@ietfa.amsl.com>; Mon, 26 May 2014 18:53:51 -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 nSYssIaVqhF6 for <tls@ietfa.amsl.com>; Mon, 26 May 2014 18:53:48 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD06E1A02E5 for <tls@ietf.org>; Mon, 26 May 2014 18:53:48 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id rd3so8312843pab.35 for <tls@ietf.org>; Mon, 26 May 2014 18:53: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:content-type:content-transfer-encoding; bh=+mvHTuOGgXHHxRD0l5IvnxbvukCI863CKjwn03oPAL0=; b=P3bPrzP8b5e5kaRDyVxRsQXytrgML1ztpjuzZ9b8OlDoTtAf+AKPcEopa4omhV1eOL sAMNa7h0qKmE88CBtxB1yd63IEnb0kRztjz1QOYttQsthpD5/ETQfNfoeA+NTSWOzAoU HCoTHShJZOMj0mAaGAGrVLPHj+Nm6Qsp0E7ovE8MD0wGcw+1rmuci1rqyFdhQWGEOfqj fACBKGYcRS30m3Iw+q+cY4m0d2pJ1g8wYIXVI8IzYplE7w5wC52W1Okl/c/JT7aQp44P loOGsJKrWY9YeFvVZly6T8WKXiRspwAiNhGxEmBMeJG+6uS5gSQLhJkS3MCv9mf7Xth1 po2Q==
X-Gm-Message-State: ALoCoQnXsR5YiLWSeFIHZm2Sdomdc0ZYC+3hVLubV9VeR06rSiMWwFFA798YIyEcE3lHvhIHjctx
X-Received: by 10.66.162.103 with SMTP id xz7mr28072932pab.104.1401155625660; Mon, 26 May 2014 18:53: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 op3sm20376251pbc.40.2014.05.26.18.53.44 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 18:53:44 -0700 (PDT)
Message-ID: <5383F02F.4050706@nthpermutation.com>
Date: Mon, 26 May 2014 21:53:51 -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" <tls@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c2916PBttbx5BI_-EG2dMTMQ20U
Subject: [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 01:53:51 -0000

I went back and read the minutes of the London meeting about removing 
static RSA and wanted to clarify what that really meant. The minutes had 
EKR mentioning this in conjunction with DH which seems different that 
what I kept hearing at the interim meeting. 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?


Also in the London meeting it was agreed limit ciphertext to AEAD style 
processing - e.g. in the TLSCipherText record to remove "stream" and 
"block" as valid choices.  Does that result in the removal of sections 
6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3?  Does it also 
result in changing the output of the "key expansion" phase as only 
"client_write_key" and "server_write_key"s will be needed for AEAD?

Is there any desire to specify a AEAD general block cipher mode/mac 
construct with an integral key expansion function?  E.g. could something 
like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt 
be adapted to be a general model for TLS or is this out of scope for the 
TLS1.3 main document?

Mike