Re: [TLS] Potential New Handshake Flows for TLS 1.3

Michael D'Errico <mike-list@pobox.com> Tue, 05 November 2013 23:58 UTC

Return-Path: <mike-list@pobox.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B9F11E8125 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 15:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHDFv67X65L6 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 15:58:23 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97511E811A for <tls@ietf.org>; Tue, 5 Nov 2013 15:58:23 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1E0C4D7C5; Tue, 5 Nov 2013 18:58:21 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=8fD12Lrr5zPL tQJmhgicNx4bD10=; b=vqxC/e4KxFKc8uTGFprWAvVdZAR9ilmgFAT6qURJinmj xjA7OPwR9i8hRJpnxvc5mJDeiNdBdAx8dmyZuqqDCd56/uu8NBUkEWv0163ejXKk Ik6X6FGpMUU4BUL9QDvN/cDWIjI1q5hOChRcIT+w72+LhQu3oU4zY9o2AN9JdK8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iaENhm yZ/GzFeyYmmkE1ImEz/mUfPTkkrLoXWae20DRkgR+oWjH973jM+RnhwtAtjvmHqz Zn+iqoc0PHNIJLgI8TGr1Q76gkyvwd9JfFtPIyyuUheydE7+IjVOimc6N3YiH8JT lq+0MJ3A4pHjFxwJWzlb0GUVgIRCgGJX0UGeg=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 16496D7C4; Tue, 5 Nov 2013 18:58:21 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 73FE1D7C3; Tue, 5 Nov 2013 18:58:20 -0500 (EST)
Message-ID: <52798619.8030305@pobox.com>
Date: Tue, 05 Nov 2013 15:58:17 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
In-Reply-To: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 25DAED70-4676-11E3-A5BB-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Nov 2013 23:58:28 -0000

Eric Rescorla wrote:
> I've just submitted a document on potentially new reduced RT/more
> private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
> to err on the side of getting some of the ideas out for discussion
> so we could figure out which avenues we want to pursue. This draft
> borrows (steals) liberally from a bunch of prior work too numerous
> to name here.

In the handshake of Figure 7, an active attacker can obtain the 3rd
ClientHello since the ServerKeyExchange is not signed.

I would like to see some DH parameters standardized to simplify
things (no need for the client to validate) and to remove the need
to transmit them.

Since the idea of server state is being thrown around, perhaps the
server can simply send a key to the client (after Finished) to be
used to make the next handshake private.  New PreSharedKeyRequest
and response messages (not necessarily Handshake messages) could be
defined for this if necessary.

Mike