IETF Logo Mail Archive

[TLS] draft-ray-tls-encrypted-handshake-00.txt

Marsh Ray <marsh@extendedsubset.com> Fri, 04 May 2012 16:21 UTC

Return-Path: <marsh@extendedsubset.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 C6DF221F85B8 for <tls@ietfa.amsl.com>; Fri, 4 May 2012 09:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 CrxBI1WJrCyP for <tls@ietfa.amsl.com>; Fri, 4 May 2012 09:21:10 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE521F8577 for <tls@ietf.org>; Fri, 4 May 2012 09:21:10 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1SQLFm-000OlY-6Y for tls@ietf.org; Fri, 04 May 2012 16:21:10 +0000
Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 62DEB6067 for <tls@ietf.org>; Fri, 4 May 2012 16:21:09 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/MIQgtE84A73Lfb+OXn7ixl8nMqRDOVak=
Message-ID: <4FA401F7.5060003@extendedsubset.com>
Date: Fri, 04 May 2012 11:21:11 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [TLS] draft-ray-tls-encrypted-handshake-00.txt
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: Fri, 04 May 2012 16:21:11 -0000

I would appreciate it if the participants of the TLS WG will give this 
draft a reading and serious consideration to taking it up as a work item:

------------------------------
http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/

A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been 
successfully submitted by Marsh Ray and posted to the IETF repository.

Filename:	 draft-ray-tls-encrypted-handshake
Revision:	 00
Title:		 Transport Layer Security (TLS) Encrypted Handshake Creation 
date:	 2012-05-04
WG ID:		 Individual Submission
Number of pages: 18
Abstract:
    This specification defines a Transport Layer Security (TLS) extension
    which allows endpoints to negotiate the use of encryption with
    forward secrecy at the beginning of the handshake.  Two levels of
    functionality are defined.  Implementations are free to support one
    or both levels, with the first level incurring no additional
    computational or round-trip overhead.  The TLS cryptographic
    calculations are unchanged.
------------------------------

This draft is motivated by the discussions in recent weeks, when some 
related issues came up in a similar context:

* AGL et al. have some particular requirements for the handshake when 
using the NP(N)/SPDY feature. They really need confidentiality in 
negotiating the next protocol but they cannot afford the overhead of 
even one extra round trip (let alone renegotiation). I would like for 
them to be able to implement NP(N) in an RFC-defined way.

* When coupled with the RFC 4680 'TLS Handshake Message for Supplemental 
Data' that Martin Rex pointed out, it provides a powerful and very 
general way of negotiating features under encryption. It could possible 
enable new features.

* Alternatively, we could view this as a round-trip-saving optimization 
for certain handshake operations that really do need encryption.

* It allows to encrypt the client certificate without renegotiation, 
magic cipher suite values, or a bunch of new protocol that isn't useful 
for anything else.

* I watched a fascinating presentation from the Tor project
https://www.youtube.com/watch?v=GwMr8Xl7JMQ
Unfortunately, they are having to minimize their dependence on TLS 
because it's so easy to DoS selectively. I don't know if this proposal 
will make TLS suitable for Tor again, but I do think it represents a 
shortcoming of the protocol which deserves fixing.

* There's simply no reason TLS needs to leak so much plaintext.

* I believe it may help a little with the issue Nikos Mavrogiannopoulos 
and I were discussing, where an attacker is able to trick the client 
into interpreting the server's signed key exchange parameters as the 
wrong type of structure.

* To the implementers in the group: don't be fooled, it's not as big a 
change as it looks! I just tried to be extra careful to describe it 
step-by-step in the spec. Did I mention it doesn't change the crypto 
calculations?

Thanks,

- Marsh

v2.23.0 | Report a Bug | By Email