[TLS] 1rtt thoughts

Michael StJohns <msj@nthpermutation.com> Mon, 14 July 2014 17:16 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 40A911A0AE6 for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 10:16:39 -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 BKQNHOytbVz5 for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 10:16:37 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3221A0AE3 for <tls@ietf.org>; Mon, 14 Jul 2014 10:16:37 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id dc16so3436927qab.22 for <tls@ietf.org>; Mon, 14 Jul 2014 10:16:35 -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=y/ZcXGqou0USA4MezQFuDFnv3qCqz4FwY2KwEYitMCk=; b=ecriEfYmhP2Ps/S2MzVERKuExgAe5M+mfrm+NUCzfRDHrIaE+cDsi403ZeRSJ9ikZP qXMk7/swY+QRG6Abfx8Y2ukrcoVrRbwt7B2ECRpHKiTpQLSd1L7Defd1Im6pUrRpf1Ep zle+tfKhk/+oZCWydxOtVYidCbLlTq0ZtjMN5PU4lLk+TtkMy0VEQ/fCw5zg5PODjneU TEBOjLMWtDGeWZoNg3bBMfLu9297t+TgGUHrxqzlwR0tCrvH07/TibtGhj3ZfuoJFCX3 uje8ifrrftPN3zL6tlSKnA7mt2PARAvtHlnoiThqwGKX/UE3T/3hwrnylYho6oz1f2tA Xssg==
X-Gm-Message-State: ALoCoQnPOiqIHwFo+7FtMmNZ17E4XSHnDLhLSiHeZmD901Q1v7jDHU27gAJ3RoEQU2FgOkbzVkCh
X-Received: by 10.229.38.1 with SMTP id z1mr27198941qcd.18.1405358195315; Mon, 14 Jul 2014 10:16:35 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:d81:350c:1e85:a7c? ([2601:a:2a00:390:d81:350c:1e85:a7c]) by mx.google.com with ESMTPSA id j1sm21343741qaa.11.2014.07.14.10.16.34 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 10:16:34 -0700 (PDT)
Message-ID: <53C41080.9050204@nthpermutation.com>
Date: Mon, 14 Jul 2014 13:16:48 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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/UipCH2vlHe0S3HtE6OEXkxmlmmM
Subject: [TLS] 1rtt thoughts
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: Mon, 14 Jul 2014 17:16:39 -0000

The current 1rtt draft uses a ClientHello with a ClientKeyExchange 
embedded in an EarlyData extension of the hello to get around the 
problem of pre-TLS1.3 handshake message ordering.   That solves the 
problem mostly, but at the cost of yet another tweak to message formats 
and slightly more complexity in processing.

Instead, how about simply sending the ClientKeyExchange first and then 
the ClientHello (same TCP/UDP send call, just a different record 
order)?  A TLS1.2 server receiving things in this order discards the 
ClientKeyExchange with an out of sequence error, and then starts the 
handshake normally with the receipt of the ClientHello.   The TLS1.3 
client detects the error report and resends the ClientKeyExchange in the 
appropriate TLS1.2 order.

For Finished message processing, the ClientKeyExchange record is 
included in the hash/mac in its normal location, regardless of when it 
was received.

Mike