Re: [TLS] TLS 1.3 comments

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 17 August 2015 19:07 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 72EFC1B2F36 for <tls@ietfa.amsl.com>; Mon, 17 Aug 2015 12:07:30 -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 rbsPxheZybTH for <tls@ietfa.amsl.com>; Mon, 17 Aug 2015 12:07:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF171B2F45 for <tls@ietf.org>; Mon, 17 Aug 2015 12:07:23 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78A66284D92; Mon, 17 Aug 2015 19:07:16 +0000 (UTC)
Date: Mon, 17 Aug 2015 19:07:16 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150817190716.GP24426@mournblade.imrryr.org>
References: <55D1B5CC.1050005@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55D1B5CC.1050005@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DBhBP1QjPefMqOk125fsIlVvlIE>
Subject: Re: [TLS] TLS 1.3 comments
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Mon, 17 Aug 2015 19:07:30 -0000

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:

>      * Server Configuration: how does the client know to whom the
>        configuration applies? For example if I connected to
>        "*.example.com" (a wildcard cert) and now I connect to
>        "srv.example.com", should I use the stored configuration?

Clients don't "connect to *.example.com", they connect to a specific
server, one of whose "presented identities" might be "*.example.com".

Since clients don't a priori know which certificates correspond to
which reference identities, they can't apply a configuration to
anything other than the exact peer for which it was obtained.

Section 6.2.2 speaks of "the server", and I think this needs to be
taken literally.  Not some set of servers, but "the server".  Of
course load-balancers might hide multiple servers behind a single
transport end-point, in which case the client may not be able to
distinguish between them, and it is then up to the server administrators
to ensure that any configurations are sufficiently "portable"
between the servers in the pool.

This is similar to the question of when to reuse cached sessions.
Postfix, for example, does not reuse a session established to one
IP address for a multi-homed host, to communicate with "the same"
host on another IP address (which might not in fact be the same
host).  [ Even further, Postfix avoids re-using sessions when the
SMTP conversation prior to STARTTLS shows a different server name
in the EHLO reply. ]

So I think the current language is largely fine, with "the server"
meaning whatever the client uses to identify a single peer as best
it can.

-- 
	Viktor.