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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 08 May 2012 20:57 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 9C59D21F852B for <tls@ietfa.amsl.com>; Tue, 8 May 2012 13:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 O34MXlyQg3lH for <tls@ietfa.amsl.com>; Tue, 8 May 2012 13:57:43 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2D21F84FF for <tls@ietf.org>; Tue, 8 May 2012 13:57:42 -0700 (PDT)
Received: by eekd4 with SMTP id d4so869702eek.31 for <tls@ietf.org>; Tue, 08 May 2012 13:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=U63iMpK2sfWA6McHZJ9vXHc9DNcKDobo3CGMtJqmqgY=; b=X00aObczHT2aIlgwYmdU+D3mXULnhYCXSpb83EQ/I56m3eAGOz08XqcdkVSyJQpfTg 7UN4IjseC7p3QaCiSldctR9hL9CwC/+mfinUiNfATJQvtOBq5GblYym19BmnahP68PsH krUut9AcQjq4QuaaReNDlhbRd9haCREm0hgkj1cjehSgvtRN64H6ATtTElo6kToDkadp LHAcgokGKjinh7g3NKEo65rwOUyTIUx1SfEegcYAenU/+SmMMh/8MGmn4q2CmRnMH7s4 j/F0aJXJmADL9RroOqepidghsABoEiObZWzz3KdR3noJAc6/TRUWtNrbptcJNB06BLZX EjSQ==
Received: by 10.213.14.15 with SMTP id e15mr112542eba.8.1336510661989; Tue, 08 May 2012 13:57:41 -0700 (PDT)
Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id y54sm2057203eef.10.2012.05.08.13.57.40 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 13:57:41 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4FA988BF.3060509@gnutls.org>
Date: Tue, 08 May 2012 22:57:35 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3
MIME-Version: 1.0
To: Marsh Ray <marsh@extendedsubset.com>
References: <4FA401F7.5060003@extendedsubset.com> <4FA63814.8010405@gnutls.org> <4FA6A005.7010001@extendedsubset.com> <CAJU7zaK28dwFU3=+jGa4HREDfr18VLpq110TPJQWHW-AyrvOSA@mail.gmail.com> <4FA81966.8060604@extendedsubset.com>
In-Reply-To: <4FA81966.8060604@extendedsubset.com>
X-Enigmail-Version: 1.4
OpenPGP: id=96865171
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Tue, 08 May 2012 20:57:43 -0000

On 05/07/2012 08:50 PM, Marsh Ray wrote:

> On 05/07/2012 02:47 AM, Nikos Mavrogiannopoulos wrote:
>>
>> Even with the three levels supported (zero,
>> one, two), if a client advertises required zero, requested two, should
>> the server assume that he supports one? What if the client only
>> supports level two and zero?
> I think that EH level one is such a clear subset of level two that it
> doesn't make sense to implement level two but not level one.

In that case, it should be clearly forbidden by this draft not to
implement one if two is implemented, and pretty much mention that
only the options 0, 1, 2 will ever be available. Otherwise if 10
years from now sbd adds 3 which is independent of 1,2 it may make
sense to support 3 but not 2.

I'd prefer however if the draft is flexible to allow future updates.

> Would we ever define more levels such that implementation support for
> them could sensibly be non-contiguous? It doesn't seem too likely to me,
> but should the need arise we'd probably have a new extension ID anyway.


I don't know. The future is hard to predict, so it may be better to be
safe than sorry :)

regards,
Nikos