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

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 28 Feb 2006 18:15:44 -0000

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:[email-masked]] 
Sent: den 28 februari 2006 17:19
To: EKR
Cc: Stefan Santesson; Ari Medvinsky; [email-masked]; [email-masked]
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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Feb 2006 10:26:34 -0800

> 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.

> encrypted information, e.g. encrypted to the public key of the server

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. 

> 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