RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard
"Stefan Santesson" <stefans@microsoft.com> Tue, 28 February 2006 18:15 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9O2-0008Mb-LX; Tue, 28 Feb 2006 13:15:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9O0-0008MH-Qf; Tue, 28 Feb 2006 13:15:48 -0500
Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9Nz-0004iv-E8; Tue, 28 Feb 2006 13:15:48 -0500
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 18:15:46 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard
Date: Tue, 28 Feb 2006 18:15:44 -0000
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404445A1E@EUR-MSG-11.europe.corp.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard
Thread-Index: AcY8hy33bKM9A901Q3m64GWpANS26wABaHDg
From: Stefan Santesson <stefans@microsoft.com>
To: Russ Housley <housley@vigilsec.com>, EKR <ekr@networkresonance.com>
X-OriginalArrivalTime: 28 Feb 2006 18:15:46.0234 (UTC) FILETIME=[FEADE9A0:01C63C92]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
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
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
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. 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. 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. Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: den 28 februari 2006 17:19 To: EKR Cc: Stefan Santesson; Ari Medvinsky; ietf@ietf.org; tls@ietf.org Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Eric: > > I can see many situations where the information in this is not > > sensitive. In fact, in the primary use case, the use mapping > > information is not sensitive. An enterprise PKI is used in this > > situation, and the TLS extension is used to map the subject name in > > the certificate to the host account name. > >But then we're left with the performance rationale that the user has >some semi-infinite number of mappings that makes it impossible to send >all of them and too hard to figure out which one. In light of the fact >that in the original -01 proposal there wasn't even any negotiation >for which type of UME data should be sent, is there any evidence that >this is going to be an important/common case? This requires a crystal ball.... Apparently yours is different than mine, as the negotiation that you reference above was added to resolve comments from my AD review. We all know that there is not going to be a single name form that is useful in all situations. We also know that you cannot put every useful name form into the certificate. In fact, the appropriate value can change within the normal lifetime of a certificate, so putting it in the certificate will result in high revocation rates. This is the reason that I believe this TLS extension will be useful in environments beyond the one that was considered by the Microsoft authors. Your perspective may differ .... Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Stefan Santesson
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Eric Rescorla
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Russ Housley
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Eric Rescorla
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Russ Housley
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Stefan Santesson
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Eric Rescorla
- Re: [TLS] Re: Last Call: 'TLS User Mapping Extens… Wan-Teh Chang