Re: [TLS] TLS ExtensionType Registry

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 12 August 2016 09:02 UTC

Return-Path: <ilariliusvaara@welho.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 045E812B019 for <tls@ietfa.amsl.com>; Fri, 12 Aug 2016 02:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
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 s8d9p6Fy0V-8 for <tls@ietfa.amsl.com>; Fri, 12 Aug 2016 02:02:42 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A703812B013 for <tls@ietf.org>; Fri, 12 Aug 2016 02:02:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5703AF82A; Fri, 12 Aug 2016 12:02:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fO5YRJNEPKJY; Fri, 12 Aug 2016 12:02:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0C46D21C; Fri, 12 Aug 2016 12:02:40 +0300 (EEST)
Date: Fri, 12 Aug 2016 12:02:32 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160812090231.76bskgj4wkoymvyh@LK-Perkele-V2.elisa-laajakaista.fi>
References: <f5bbef49-6c37-8118-731d-9581ed7db877@gmx.net> <20160811190929.bowe75bhjeks6bqf@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnUugwSOvMGQ+eAipkVOGcFHVxoQqJcFEDoEME7s-ggnCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnUugwSOvMGQ+eAipkVOGcFHVxoQqJcFEDoEME7s-ggnCg@mail.gmail.com>
User-Agent: Mutt/1.6.2-neo (2016-07-23)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q-T_cMWJq2YKEomeIp0SYJc1Kuo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS ExtensionType Registry
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Aug 2016 09:02:45 -0000

On Fri, Aug 12, 2016 at 04:39:51PM +1000, Martin Thomson wrote:
> On 12 August 2016 at 05:09, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > Actually, the server_name could be made into 'client', since the only
> > thing server sends about server_name is an ACK, meaning it has taken it
> > into "consideration" (in some vague way).
> 
> I disagree.  If it can be encrypted, then it should be.  (I don't
> believe that we ack this in NSS, so it's moot there.)

Well, I was more like "do we need this at all?".

> >> The max_fragment_length extension is sent in the initial ClientHello but
> >> is not as essential as the server_name extension. Still, in most cases
> >> there is no security context established at the time of sending the
> >> ClientHello (at least not in the full handshake when ECDHE is used).
> >
> > I think max_fragement_length should be made into 'clear', given what
> > it is used for.
> 
> I disagree.  The client doesn't need to use this value until it has
> read all of the server's first flight, so it can be encrypted.  The
> server can still act on the client's value until that time.  (I know
> that you might make an argument that it could appear in
> HelloRetryRequest to force the client to cut its second ClientHello
> smaller, but that's really tricky to get right, and I think that
> servers should just be prepared to swallow an entire ClientHello.)

Actually, the client can just abort if it observes server generating
larger fragments than it requested, so it doesn't really need the
ACK for anything (and if it could handle full 16k fragments, it
presumably wouldn't use the extension).


-Ilari