Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard

Eric Rescorla <ekr@networkresonance.com> Tue, 28 February 2006 18:26 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9YV-0006IZ-D7; Tue, 28 Feb 2006 13:26:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9YT-0006IF-Rm; Tue, 28 Feb 2006 13:26:37 -0500
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9YR-00056p-E5; Tue, 28 Feb 2006 13:26:37 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 59A041E8C1B; Tue, 28 Feb 2006 10:26:34 -0800 (PST)
To: Stefan Santesson <stefans@microsoft.com>
Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard
References: <BF9309599A71984CAC5BAC5ECA62994404445A1E@EUR-MSG-11.europe.corp.microsoft.com>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Tue, 28 Feb 2006 10:26:34 -0800
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994404445A1E@EUR-MSG-11.europe.corp.microsoft.com> (Stefan Santesson's message of "Tue, 28 Feb 2006 18:15:44 -0000")
Message-ID: <86oe0rpcf9.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Ari Medvinsky <arimed@windows.microsoft.com>, ietf@ietf.org, tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

"Stefan Santesson" <stefans@microsoft.com> writes:

> Eric,
>
> In a general sense, name hints are IDs and IDs are not secrets and no
> security system should depend on them being secrets.
>
> However, there might be privacy concerns on where and when you want to
> send what ID info to whom. We may e.g. have an issue of aggregate
> knowledge. It is always good design to minimize the information sent and
> not broadcast them around. ID1 and ID2 might not be a privacy issue when
> sent separately to different servers but may be a privacy issue if they
> are always sent together.

As I noted in my original review, you already have all the information
you need about which server you're talking to prior to
initiating the connection, so you can triage the hint list at
that point. The only way in which your approach improves on this
(in the current system, as opposed to some hypothesized new
set of extensions) is to have the server indicate whether it's
willing to accept the extension or not--which, as I indicated
earlier, you can probe for.


> In the primary use case there is no reason to encrypt the UPN name hint
> but if such requirement would arise for another hint type, then the
> current model allows a new hint type to be defined which could carry
> encrypted information, e.g. encrypted to the public key of the server
> certificate.

And this kind if hackery is *exactly* what I'm concerned about.
TLS has a perfectly good story if you're interested in preserving
the confidentiality of data in the handshake. It's called
rehandshake. 


> On the name space issue;
> We are nowhere close to exhausting the name space (less than 5% used)
> for handshake messages. If we think we will do that in any reasonably
> foreseeable future, then we simply have to figure out a way to fix that
> problem before it becomes a blocking factor for protocol design. 
> There are ways to do that and maintaining backwards compatibility way
> before this becomes a problem.

It's not primarily an exhaustion issue--though I do worry about that
as well. It's an issue of cluttering up the primary TLS state machine
with things that aren't particularly generic and could be done better
in other ways.

At this point, I think we're just repeating ourselves.

-Ekr



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls