Subject: Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Feb 2006 17:31:13 -0800

BACKGROUND
This document describes an extension to TLS which allows the client to
give the server a hint (the User Principal Name) about which directory
entry to look up in order to verify the client's identity.

This works as follows:
1. The client offers the extension (called UME) in the 
   ClientHello message. 
2. The server accepts the extension.
3. The client sends the new HandshakeType to the server
   before sending its Certificate message.

The packet flow looks like this (cut-and-pasted from the draft):

      Client                                               Server

      ClientHello
       /* with user_mapping ext */ -------->

                                                      ServerHello
                                      /* with user-mapping ext */
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone

-->   UserMappingDataList  
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

New handshake message marked by --> on the left.

This document was presented to the TLS WG in Vancouver and there was
only a very small amount of interest. The authors posted the -00 version
of their draft on January 10. Some minor comments were made by a single
WG member and these were addressed. The authors asked for a preliminary
code point assignment on January 14.  I provided a number of technical
comments (including suggesting an alternate approach, described below)
at that time, but was told that the implementation was already too far
along to be changed significantly.

Since the IETF would not have change control, this is an inappropriate
work item for the TLS WG and therefore the authors appear to have
decided on an Individual Submission. The reason for the intended status
of Proposed Standard is that this extension defines a new Handshake Type
and the TLS WG has decided that new Handshake Types require a Standards
Action (See S 7.4 of draft-ietf-tls-rfc2246-13, in RFC-Ed queue).

Contrary to the the Last Call announcement, the comments I raised
originally have not been addressed--except to be told they weren't
possible. For the reasons indicated below, I believe this document
should not be advanced to Proposed Standard as-is.

REVIEW COMMENTS
The obvious design here would simply be to place the information
in the UserMappingDataList (UMDL) message directly in the ClientHello
extension. The draft argues that this is bad for the following
reason:

   The reason the mapping data itself is not placed in the extension
   portion of the ClientHello is to prevent broadcasting this
   information to servers that don't understand the extension.
   Additionally, if new mapping information were to be considered
   confidential, the addition of a new handshake message allows the data
   to be encrypted using the servers public key.

   No other modifications to the protocol are required. The messages are
   detailed in the following sections.

This is unconvincing for a number of reasons. First, TLS handles the
case where an extension is not understood just fine. It's ignored. Since
the extension appears to be less than 100 bytes, there's no performance
issue.

The authors suggest that there is a security issue:

   As the client is the initiator of this TLS extension, it needs to
   determine when it is appropriate to send the User Mapping
   Information. It may not be prudent to broadcast this information to
   just any server at any time, as it can reveal network infrastructure
   the client and server are using.

      - The client SHOULD only send the UserMappingDataList handshake
        message if it is agreed upon in the Hello exchange, preventing
        the information from being sent to a server that doesn't
        understand the User Mapping Extension.

      - The client SHOULD further only send this information if the
        server belongs to a domain to which the client intends to
        authenticate using the UPN as identifier.

However, the second piece of information (the domain name of the server)
is generally available to the client prior to the connection initiation,
since it's used to look up the server's address. So, the client could
decide whether to send the UMDL data prior to handshake initiation.

One difference here is that the client now has the server's certificate
and that certificate could potentially contain some X.509 Extension that
indicated that the server was authorized to receive the UMDL
data. However, this is of very limited security value because in the
static RSA modes which are common with SSL/TLS, the server has not
proved possession of the corresponding private key at this point in the
handshake. Note that this draft does not describe any such extension.

An attacker who wished to impersonate the server in order to capture the
UMDL would be able to do so with a simple replay/cut-and-paste
attack. Moreover, because the UMDL is sent in the clear (the draft
claims that it could be encrypted but provides no facility for doing
so) any passive attacker can capture the UMDL by observing a single
handshake.	

At best this strategy stops the client from inadvertantly sending the
UMDL to a server which it *thinks* should support it (because it's
got the right domain name) but which actually doesn't (perhaps because
it's broken?). This seems to be of extremely limited value.

AN ALTERNATE DESIGN
There is an alternate design which has superior security properties
and does not involve defining a new HandshakeType. 

1. Do an ordinary TLS handshake without offering UME.
2. Initiate a TLS rehandshake and send the UMDL in an extension
   in the ClientHello.

Because the second TLS handshake is conducted over the TLS session
established in step (1), the entire UMDL extension exchange is
protected. A passive attacker cannot capture the UMDL data and an active
attacker cannot impersonate the server and force the transmission of the
UMDL. 

This approach has two (modest) drawbwacks.

1. It is slower because it requires two handshakes.
2. The client may have to authenticate twice (this is a special
   case of (1)).

The second case can be easily ameliorated by having the client send an
extension (empty UME?) in the first handshake as a signal that it wants
to do UMDL and that the server should hold off on demanding client
authentication until the rehandshake happens.

The performance issue is quite modest with modern servers.  Indeed, it's
quite common for web servers to do a first handshake without cert-based
client auth and then rehandshake with client auth if the client asks for
a sensitive page.

Note: there is an alternate design in which you do a client auth in the
first handshake and then do a resumption in the second one but do
UME. This is rather faster, both in terms of computation and round trips
but is technically precluded by S 2.3 of RFC3546 which requires ignoring
extensions if you do a resume. One could imagine relaxing this
restriction but that hasn't been done yet.

Note also that if the client isn't worried about the sensitivity of the
UMDL, then it can simply offer the UME extension with a UMDL in the
first handshake and skip the second handshake.

Another (hacky) approach would be for the client to probe the server
with an initial ClientHello (and no UME) and then abort the handshake
and restart if it decides that it likes the server and wants to do
UME. This would have equivalent security properties to this draft at the
cost of a single round trip.

SUMMARY
The technique described in this document appears to be of limited
usefulness. In particular, the lack of confidentiality for the
UMDL is a big limitation in extending it to other applications
than the one envisioned by Microsoft. There are alternate designs
which don't have those limitations and don't involve allocating a
new HandshakeType value. This document should not advance as a
Proposed Standard.

-Ekr

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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 18 Feb 2006 22:32:13 -0500

In message <[email-masked]>, Eric Rescor
la writes:

>of Proposed Standard 

Do we have a process issue here?  Can we have a Proposed Standard
without the IETF having change control?  (2026 speaks of change control 
only in the context of a WG.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Russ Housley <[email-masked]>
Date: Sun, 19 Feb 2006 14:27:06 -0500

Steve & Eric:

The document that is in Last Call gives the IETF complete change 
control.  There is no process issue.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Feb 2006 15:23:59 -0800

Folks,

 > client auth and then rehandshake with client auth if the client asks for

This raised a flag with me.  Within the Internet protocol context I have always 
seen significant concern for reducing the number of exchanges, because 
additional exchanges (hand-shakes) can -- and often do -- have painful 
round-trip latencies.  (Server capacity can be a concern, of course, but not for 
this issue.)

For all of the massive improvements in the Internet's infrastructure, my 
impression is that round-trip delays can still be problematic.

To this end, the high chatter rate of http seems less a basis for encouraging 
other protocols to  chatter more, than a case of remarkable good luck... unless 
you happen to be on a path that has high latencies frequently, or experience too 
many of these extra handshakes.

Is it true that we no longer need to worry about regularly adding extra 
round-trips to popular protocols that operate over the open Internet?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Russ Allbery <[email-masked]>
Date: Sun, 19 Feb 2006 15:37:22 -0800

> round-trips to popular protocols that operate over the open Internet?

It was certainly a significant issue that was much-discussed in the
working group when we were working on the new NNTP standards.  People
maintaining major commercial NNTP services said that excessive round trips
were a performance concern for them.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 19 Feb 2006 18:48:32 -0500

>round-trips to popular protocols that operate over the open Internet?

A lot depends on the expected operational environment.  All the massive 
improvements in Internet infrastructure haven't done much for the speed 
of light.

For protocols whose *usual* -- not exclusive -- operational environment 
is on a LAN or within an campus, round trips don't matter that much.  
For things that might be cross-US or intercontinental, things *can't* 
get too much better.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 Feb 2006 09:13:22 +0000

On Sun Feb 19 23:23:59 2006, Dave Crocker wrote:
> This raised a flag with me.  Within the Internet protocol context I 
> have always seen significant concern for reducing the number of 
> exchanges, because additional exchanges (hand-shakes) can -- and 
> often do -- have painful round-trip latencies.  (Server capacity 
> can be a concern, of course, but not for this issue.)
> 
> 
Well, for those of us looking at Lemonade, etc, I think we're still 
very concerned about every round-trip. Server capacity, too, is a 
very real problem, and, while I admit to not having looked at this 
specification yet, given what I've read thus far, I'm assuming this 
has some applicability to email protocols as well as HTTP, which 
would affect Lemonade.

> For all of the massive improvements in the Internet's 
> infrastructure, my impression is that round-trip delays can still 
> be problematic.

Yes, I believe it has something to do with the difficulty of changing 
the speed of light. Probably requires standards action on a bunch of 
normative references, or there's a global upgrade problem.

> Is it true that we no longer need to worry about regularly adding 
> extra round-trips to popular protocols that operate over the open 
> Internet?

No.

As far as I'm aware, there is no protocol in existence which 
somebody, somewhere, does not actively use over a mobile phone link, 
or a slow analogue modem, and this is especially true of TLS enabled 
protocols such as HTTP, email protocols, etc.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Feb 2006 10:34:27 +0100

Sharing personal experience:

As a Norway-based user, I do worry about anything that adds extra round 
trips to my queries to US-based websites. The user experience seen from 
California is really quite different from the user experience here in 
Norway - about 200 ms * number of round trips different, in fact. Extra 
RTTs add up REAL fast here.

                  Harald

---

From: Peter Dambier <[email-masked]>
Date: Mon, 20 Feb 2006 12:28:32 +0100

Dave Cridland wrote:
>> > The performance issue is quite modest with modern servers.

as long as you are living in the same rack with them. If you are connected
via UMTS it is a different thing.

>> > Indeed, it's
>> > client auth and then rehandshake with client auth if the client asks 
>> > for sensitive page.

Indeed there are some webservers around that take so long until my
browser times out.

>> exchanges, because additional exchanges (hand-shakes) can -- and often 
>> do -- have painful round-trip latencies.  (Server capacity can be a 
>> concern, of course, but not for this issue.)
>>
>>
> Well, for those of us looking at Lemonade, etc, I think we're still very 
> concerned about every round-trip. Server capacity, too, is a very real 
> problem, and, while I admit to not having looked at this specification 
> yet, given what I've read thus far, I'm assuming this has some 
> applicability to email protocols as well as HTTP, which would affect 
> Lemonade.
> 
> 
>> For all of the massive improvements in the Internet's infrastructure, 
>> my impression is that round-trip delays can still be problematic.
> 
> 

A typical traceroute for me and many, many, many customers of major
german ISPs

  1  echnaton.peter-dambier.de (192.168.48.228)  4.594 ms   5.464 ms   6.267 ms
  2  DARX41-erx (217.0.116.49)  96.478 ms   101.004 ms   111.541 ms
  3  sepia (217.0.67.102)  115.774 ms   123.485 ms   131.139 ms
  4  62.154.15.2  147.919 ms   155.120 ms   162.845 ms
  5  gb-10-0-0.saams.nl.easynet.net (195.69.144.137)  171.365 ms   178.635 ms   187.107 ms
  6  213.201.252.10  267.804 ms   270.174 ms   272.507 ms
  7  Scylla (213.201.229.65)  269.246 ms   272.058 ms   274.653 ms
  8  Charybdis (84.22.96.250)  98.668 ms   107.666 ms   111.906 ms
  9  Bifroest (84.22.96.246)  124.170 ms   128.057 ms   138.825 ms
10  tourelle (84.22.100.150)  148.487 ms   158.490 ms   163.288 ms

Except for (192.168.48.228) 4.594 ms (my old 486-SLC/2 router, 66 MHz) all are
fast modern machines. That DARX41-erx (217.0.116.49) 96.478 ms is a top model.

So 300 msec forward + 300 msec backward will become 1.2 seconds.
Vaja con dios VoIP.

> 
> No.
> 
> As far as I'm aware, there is no protocol in existence which somebody, 
> somewhere, does not actively use over a mobile phone link, or a slow 
> analogue modem, and this is especially true of TLS enabled protocols 
> such as HTTP, email protocols, etc.
> 
> Dave.

Peter

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Feb 2006 07:15:23 -0800

Dave Cridland <[email-masked]> writes:

>> often do -- have painful round-trip latencies.  (Server capacity can
>> be a concern, of course, but not for this issue.)
>>
> very concerned about every round-trip. Server capacity, too, is a very
> real problem, and, while I admit to not having looked at this
> has some applicability to email protocols as well as HTTP, which would
> affect Lemonade.

Well, I'm not claiming that latency isn't a factor in protocol
performance. What I'm claiming is that it's not clear that latency
in the initial connection setup handshake (in this case the TLS
one) is a major factor in protocol performance. Recall that the
way that TLS works is that you do an initial handshake to establish
the keys and then you send data of the negotiated channel. What
we're discussing is whether it's OK for this to take a few extra
round-trips at the setup of the first connection (and not necessarily
afterwards because of TLS session caching). So, we're not talking
about adding messages to every activity of the higher level protocol.

So, what I'm arguing is that except for applications where initial
connection setup is a large fraction of the cost of the entire
connection, I think it's not worth optimizing the initial connection
setup very much. And until you've profiled the protocols in 
question it's hard to know which case you're in.

> such as HTTP, email protocols, etc.

Well, I hear what you're saying, but when I check my mail over my
cell phone, it's pretty clear that the time isn't going to TLS
connection setup.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Feb 2006 11:06:38 -0500

> about adding messages to every activity of the higher level protocol.

True, but this presumes a lot about how TLS is used.  For instance, if 
you're using it with HTTP to load a web page that downloads not only a 
root HTML file but lots of other files for frames, images, applets, 
etc., then you're going to incur that connection setup overhead for 
every one of those objects.  And because (partially for this reason) 
with HTTP it's fairly normal for a browser to open multiple connections 
to a server site, all of those delays won't be serialized, but they'll 
still impact the total time to download the page.

Now maybe this specific example illustrates a flaw in the design of HTTP 
and/or HTML, but the extra setup overhead of TLS (and this new 
extension) does impact its versatility.

Also I chose HTTP/HTML because most people are familiar with it.  There 
are other, more obscure, applications involving lots of hosts that need 
to open up secure and sometimes brief connections with one another.

So while the extra setup delays of TLS might not matter much in some 
applications, they definitely matter in others.

Keith

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 Feb 2006 16:20:25 +0000

> question it's hard to know which case you're in.
I'll have to disagree almost totally.

I think you always basically know what case you're in, because the 
connection setup time is wasted time that's not achieving anything 
useful, it's just staring-at-the-screen time. For a purely 
non-interactive protocol that a real human will never be waiting for 
results from, I suppose you could ignore any setup RTT cost, but I 
struggle to think of an example for this.

For IMAP, where connection setup time is, in principle, a very small 
part of the total session time, it seems odd you're advocating that 
nobody should worry about adding round-trips when there's been 
substantial effort in reducing round-trips in precisely this area. 
Witness the way that the CAPABILITY command has been deprecated into 
a CAPABILITY response code, or the SASL-IR proposal, or RECONNECT - 
the list just goes on.

Moreover, this phase of "reading your mail" is one where the user is 
definitely watching, and essentially nothing useful is happening. You 
absolutely know this is a good place to optimize.

> somebody,

Nope, but I'll bet that the time you spend waiting, rather than 
reading, is almost entirely round-trip latency, and not actual useful 
octets coming through the ether - silent noise and not shifting bits.

Dave.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Feb 2006 08:29:06 -0800

>> very concerned about every round-trip. 
 >
> one) is a major factor in protocol performance. 

Eric,

I did understand you meant start-up chatter, rather than data chatter.

But latency is latency.  There are situations in which an isolated bad latency 
effect is tolerable to a session, and others where it is not.  When that chatter 
is repeated for every session of a popular protocol, it usually raises a flag 
about design choice. As your response notes, it might well have a small 
statistical impact on the total session, but that does not automatically make it 
acceptable.

By way of historical contrast, the addition of an options mechanism to SMTP was 
very, very carefully designed to add no extra round-trips, due to the email 
infrastructure experiences with this issue as a problem.  And my note 
acknowledged the obvious alternate view that http represents, since it just 
chatters away, especially at startup.

That's why I raised the question.

I note a pattern of responses to my question; it show that there still IS a 
concern.  More interesting is that the concern applies to a variety of scenarios.

While the IETF list is not the right venue for considering this protocol design 
point to its conclusion, I was looking for an indication of whether my concern 
was out-dated or whether there was an inconsistent view within the protocol 
design community.

Based on the brief set of responses, so far, my sense is that the latter holds. 
  Since this is a potentially fundamental protocol design point, it would be 
good to develop some community consensus about it.

I'll add one specific comment, reacting to Steve Bellovin's noting LAN vs. WAN 
"operational environment" distinction.  It has been my experience and my 
understanding that the IETF does not design upper-level (transport and above) 
protocols to be sensitive to that LAN vs. WAN distinction.

As I understand it, when TCP/IP was first put over Ethernet, this was a point of 
very significant debate.  There was a strong lobby for optimizing things for the 
faster, lower-latency Ethernet environment.

My own assessment of the decision to avoid the temptation to have protocols be 
"tuned" in that way is that it was a spectacularly good decision. First, it 
makes the protocol world vastly simpler.  Second, it makes the operational world 
vastly simpler.

Folks can study the OSI TP0, TP1, TP2, TP3, TP4 alternative approach, by way of 
seeing the way things could have been.  None of those transports interoperated 
with each other.

d/
-- 

Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Feb 2006 08:43:27 -0800

Keith Moore <[email-masked]> writes:

> with HTTP it's fairly normal for a browser to open multiple
> connections to a server site, all of those delays won't be serialized,
> but they'll still impact the total time to download the page.
>
> Now maybe this specific example illustrates a flaw in the design of
> HTTP and/or HTML, but the extra setup overhead of TLS (and this new
> Also I chose HTTP/HTML because most people are familiar with it.
> There are other, more obscure, applications involving lots of hosts
> that need to open up secure and sometimes brief connections with one
> another.
>

TLS incorporates a "session resumption" feature that is specifically
designed to let you avoid a new handshake for each connection you
make (that's what the "not necessarily afterwards" above meant.)
So, the full TLS cost is only paid for the first connection to
a given server. 

-Ekr

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Feb 2006 17:10:24 +0000

On Mon, 20 Feb 2006, Dave Cridland wrote:
>
> For IMAP, where connection setup time is, in principle, a very small part of
> the total session time, it seems odd you're advocating that nobody should
> worry about adding round-trips when there's been substantial effort in
> reducing round-trips in precisely this area. Witness the way that the
> CAPABILITY command has been deprecated into a CAPABILITY response code, or the
> SASL-IR proposal, or RECONNECT - the list just goes on.

A good way of saving a couple of RTTs is to use imaps rather than
imap+STARTTLS. It's a pity that the equivalent for message submission
has been rescinded, despite the fact that it's still widely used.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 20 Feb 2006 12:33:05 -0500

In message <[email-masked]>, Dave Crocker writes:

>As I understand it, when TCP/IP was first put over Ethernet, this
>was a point of very significant debate.  There was a strong lobby
>for optimizing things for the faster, lower-latency Ethernet
>environment.
>
>My own assessment of the decision to avoid the temptation to have
>protocols be "tuned" in that way is that it was a spectacularly
>good decision. First, it makes the protocol world vastly simpler.
>Second, it makes the operational world vastly simpler.
>
>Folks can study the OSI TP0, TP1, TP2, TP3, TP4 alternative approach,
>by way of seeing the way things could have been.  None of those
>transports interoperated with each other.

Dave, I tried to phrase my comment carefully. I wrote:

because I'm very well aware that there is no hard and fast boundary.
Indeed, I occasionally refer to what I call "Bellovin's Laws of Networking":

	1. Networks interconnect

	2. Networks *always* interconnect, even if you don't think they will

	3. Networks interconnect at the edges, not the center

That said, there are protocols whose usual patterns are in one camp
or the other, sometimes for fundamental reasons.  X11 and NFS will
always be better-used locally, because the people and applications are
expecting low-latency responses.  HTTP is generally a WAN protocol,
because statistically most of the Web isn't at your site.

It's acceptable, to me, to make an *engineering tradeoff* about how a
protocol design is balanced, if there's a natural operational environment.
What's not acceptable is to design it so that it *only* runs in one
environment or the other.

It's also worth noting that the counterexamples you cite are transport
protocols.  When something tends to live underneath many disparate
protocols, you're less free to make such choices, because you don't
know what the upper layers will be.  This obviously applies to TCP;
less obviously, it applies to TLS and (unfortunately) HTTP.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Feb 2006 11:21:21 -0800

Steve,

> Dave, I tried to phrase my comment carefully. I wrote:

1. You succeeded.

2. For my own part, I had no doubt that your model of the world had something 
like the rules you listed.

3. My reason for citing your note was that the issue of expected usage 
environment is, I think, exactly what drives many people's design models and 
exactly what, I think, can be a strategic danger.

In other words, I view this issue as specifically what should be discussed as an 
essentially architectural topic, looking for consensus, guidelines, or the like.

> environment or the other.

Over time, my experience has caused me to believe that protocols designed for 
the high vagaries of a WAN can usually be adapted to run well over a LAN. In 
considerable contrast, protocols designed for the high bandwidth and low 
latencies of a LAN are difficult or impossible to make work well over the 
vagaries of a WAN.

So while I agree with your basic view of engineering tradeoffs, I think that the 
topic is filled with dragons.

Worse, I believe that, as a community, we don't have much basis for considering 
the tradeoffs well.  That is, as a community, I think we tend to lock ourselves 
into designing for only one expected environment and fail to incorporate your 
listed rules properly.

Indeed, that is what prompted my starting this thread.  I think concern for 
protocol chatter is not high enough (ie, not as high as it used to be.)

d/

-- 

Dave Crocker

---

From: <[email-masked]>
Date: Tue, 21 Feb 2006 15:28:15 +0200

My personal comments about draft-santesson-tls-ume-01:

The draft defines an extension to TLS that allows the client to send
"user mapping" information to the TLS server. The server uses this
information to fetch authentication/authorization-related information
from a directory server.

The draft is quite similar to draft-housley-tls-authz-extns, which
allows sending X.509 attribute certificates and SAML assertions in
TLS. The main difference seems to be that we only send a pointer to
the authorization information (a bit like IKEv2, which supports
sending an URL of the certificate instead of the cert itself).  From a
purely technical point of view, it would probably make sense to merge
these drafts.  The tls-authz-extns draft does some details better:
e.g., the information is sent encrypted, and only after the server has
been authenticated.

The solution is also quite similar to the "client_certificate_url"
extension defined in RFC 3546 (the "User Principal Name" could be
considered as one type of certificate URL). Here even the placement
of the handshake messages is identical to tls-ume. Unfortunately,
it seems that sending both CertificateURL and Certificate handshake
messages is not allowed, complicating the situation.

However, it might be that process and timing issues make mergers
infeasible.  Also, the authors of draft-santesson-tls-ume seem to 
be unwilling to make changes to the protocol.

About the technical details: In general, the solution seems to work,
and does not contain any serious flaws. I don't count sending the user
mapping information unencrypted as a serious flaw -- this information
is sent only when a client certificate is also sent, and the client
certificate is not encrypted either (unless the double-handshake hack
is used, in which case the user mapping information would be
encrypted, too).

It's probably not the most elegant design possible (see e.g. Eric
Rescorla's review).

However, I think we should clearly "distinguish between 'it won't
work' and 'it could/should work better'" (as Dave Crocker well put it
in one email). The document solves a real (but maybe not extremely
large or important) problem, and the solution works. That's better
than many documents these days...

Given these, I think this would be an excellent document for
Informational, especially if the title was changed to "Microsoft TLS
User Mapping Extension" to indicate that it's a proprietary extension
where the IETF community had no chance to change anything.  I also
think vendors should be encouraged to publish their extensions, even
if they are not perfect.

However, due to the IANA allocation rules in 2246bis, this draft is
being last called for standards track, and this is slightly more
problematic.

One observation is that the TLS allocation rules are quite strict, and
not always totally logical. "Specification Required" is sufficient to
get a ClientCertificateType number, and "IETF Consensus" gets you an
ExtensionType number. But many extensions (including this one, and
also some of the extensions in 3546bis) also require a handshake
message number, and thus Standards Track. Or in other words: the
degree of consensus and process required for a document that extends
TLS depends heavily on minor technical details, not on what the
extension actually does.

RFC 2026 also says that "A Proposed Standard specification is
generally stable, has resolved known design choices, is believed to be
well-understood, has received significant community review, and
appears to enjoy enough community interest to be considered valuable."

I don't think we're quite there yet with this document.

On the other hand, I also think that just refusing to publish this
document would be a highly unproductive approach. If the document
solves a reasonable problem, the solution works, and it looks likely
it will be widely deployed, I don't think preventing publication on
minor process details would exactly "make the Internet work better".

I'm not sure what would be the best way to handle this, though.  Merge
this with draft-housley-tls-authz-extns? Refine the technical details
so that it does not need a new handshake message number? (E.g., map the
UPN to an URL, and use the existing CertificateURL message?) Change the 
IANA allocation rules for TLS? I don't have a strong opinion here...

Best regards,
Pasi

---

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 20 Feb 2006 17:32:07 -0800

Eric,

Thank you for your feedback.  Below are the problems that I see with the
alternative proposals that you suggested when compared to the approach
taken in the current draft:

1)	Proposal 1:  Send the user mapping extension in the initial
Client Hello (as data along with the extension value).

	a) Problem: Privacy/Lack of user consent in information
disclosure.  The UPN sent in the user extension, uniquely identifies a
principal - something that users concerned with preserving their privacy
may object to (i.e., the large majority of SSL sites are server side
auth only; the user was anonymous and now the user is identified by the
UPN).

To mitigate this problem to some extent (as I think you pointed out),
the client can be configured to only send the user mapping information
to some subset of servers (e.g., based on domain names).  However, this
completely lacks end user consent.  The user's principal name will be
automatically sent to every SSL server in the above list (as configured
by admin) - even if the user does not wish to be identified to the
target server (in SSL sessions with server side auth only and mutual
auth).

In contrast, if the mapping extension is sent on the third leg before
the certificate msg (as it is in the current draft), the user has the
option to bail out of client auth and not disclose the UPN or any data
in the cert (e.g., by not typing the pin for the smartcard).

	b) Problem: Performance.  In your email you stated that the
UserMapping extension is likely to be around ~ 100 bytes and that's
negligible and thus it is ok to send in the initial ClientHello msg -
even if the server does not need it as is the case for server side auth
only TLS connections.

I disagree.  As you know TLS is used in many different scenarios, for
example:  EAP/TLS  (RFC http://www.ietf.org/rfc/rfc2716.txt) is used for
Radius, wireless 802.1x, RAS (dial up), etc.  The MTU in EAP is 1600
bytes.  Thus even 100 bytes can cause additional fragmentation causing
additional latency for RAS (consider dial up across geographically
dispersed end points).  Furthermore, per the current draft the
userMapping structure can be extended, to carry multiple user mapping
hints, thus causes further degradation in this scenario ...

2)	Proposal 2:  

This is essentially saying that the current extensibility mechanism in
TLS is broken and that the userMapping extension in contrast to all
other extension requires to 2 handshakes instead of one.   The method
that you are proposing is inconsistent with the approach used for every
other TLS extension.  

>From a performance standpoint, proposal 2 is still a bad choice.  You
stated that "The performance issue is quite modest with modern servers".
While servers are getting faster, user load tends to follow suit;
furthermore, this proposal costs additional latency.  In contrast, the
approach used in the current draft does not suffer from these problems. 

Regards,

-Ari

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, February 18, 2006 5:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to
ProposedStandard

BACKGROUND

This works as follows:

      Client                                               Server

      ClientHello

                                                      ServerHello

-->   UserMappingDataList
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished

REVIEW COMMENTS
The obvious design here would simply be to place the information in the
UserMappingDataList (UMDL) message directly in the ClientHello
extension. The draft argues that this is bad for the following
reason:

One difference here is that the client now has the server's certificate
and that certificate could potentially contain some X.509 Extension that
indicated that the server was authorized to receive the UMDL data.
However, this is of very limited security value because in the static
RSA modes which are common with SSL/TLS, the server has not proved
possession of the corresponding private key at this point in the
handshake. Note that this draft does not describe any such extension.

An attacker who wished to impersonate the server in order to capture the
UMDL would be able to do so with a simple replay/cut-and-paste attack.
Moreover, because the UMDL is sent in the clear (the draft claims that
it could be encrypted but provides no facility for doing
so) any passive attacker can capture the UMDL by observing a single
handshake.	

At best this strategy stops the client from inadvertantly sending the
UMDL to a server which it *thinks* should support it (because it's got
the right domain name) but which actually doesn't (perhaps because it's
broken?). This seems to be of extremely limited value.

AN ALTERNATE DESIGN
There is an alternate design which has superior security properties and
does not involve defining a new HandshakeType. 

Note: there is an alternate design in which you do a client auth in the
first handshake and then do a resumption in the second one but do UME.
This is rather faster, both in terms of computation and round trips but
is technically precluded by S 2.3 of RFC3546 which requires ignoring
extensions if you do a resume. One could imagine relaxing this
restriction but that hasn't been done yet.

Another (hacky) approach would be for the client to probe the server
with an initial ClientHello (and no UME) and then abort the handshake
and restart if it decides that it likes the server and wants to do UME.
This would have equivalent security properties to this draft at the cost
of a single round trip.

SUMMARY
The technique described in this document appears to be of limited
usefulness. In particular, the lack of confidentiality for the UMDL is a
big limitation in extending it to other applications than the one
envisioned by Microsoft. There are alternate designs which don't have
those limitations and don't involve allocating a new HandshakeType
value. This document should not advance as a Proposed Standard.

-Ekr

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

---

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 20 Feb 2006 17:32:07 -0800

Eric,

2)	Proposal 2:  

Regards,

-Ari

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, February 18, 2006 5:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to
ProposedStandard

BACKGROUND

This works as follows:

      Client                                               Server

      ClientHello

                                                      ServerHello

-->   UserMappingDataList
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished

REVIEW COMMENTS

AN ALTERNATE DESIGN

SUMMARY

-Ekr

---

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 20 Feb 2006 17:32:07 -0800

Eric,

2)	Proposal 2:  

Regards,

-Ari

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, February 18, 2006 5:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to
ProposedStandard

BACKGROUND

This works as follows:

      Client                                               Server

      ClientHello

                                                      ServerHello

-->   UserMappingDataList
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished

REVIEW COMMENTS

AN ALTERNATE DESIGN

SUMMARY

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Feb 2006 19:34:26 -0500

>information to fetch authentication/authorization-related information

I do not think this is a good summary of the purpose of this 
document.  Currently in the Microsoft environment, a 
Microsoft-specific certificate extension that contains the username 
is required.  This extension allows certificates without this 
Microsoft-specific extension to be used.  The document refers to 
these as "legacy" certificates.  In fact, these are the certificates 
that are in common use in many large enterprises.

>e.g., the information is sent encrypted, and only after the server has

Based on the comments that I received from Eric Rescorla on 
draft-housley-tls-authz-extns, this draft is likely to move in a 
somewhat different direction; however, that is a discussion for a 
different thread.

>messages is not allowed, complicating the situation.

The change proposed here would require action by the TLS WG.  And, 
this alternative approach was not raised at the Vancouver IETF when 
this solution was presented to the TLS WG.

>be unwilling to make changes to the protocol.

This is not the case.  I raised a significant concern when I did my 
AD review, and after discussion of several alternative solutions, 
they picked one and changed the document.  I understand that they are 
also changing their implementation to match the document.

>is used, in which case the user mapping information would be

I agree with this assessment.

>than many documents these days...

I think that the folks that are using enterprise PKIs would like to 
see this capability, and Microsoft is prepared to make it available in Vista.

>think vendors should be encouraged to publish their extensions, even

I disagree with this point.  When I did my AD review, I considered 
the Microsoft-specific nature of the document.  The structure easily 
accommodates additional name forms.  Thus, I do not think we should 
ask for "Microsoft" in the document title.

>I don't think we're quite there yet with this document.

We need to strike a balance.  In this case, Microsoft is trying to 
follow the IANA allocation rules in 2246bis.  We do not want to 
punish them for trying to be good IETF participants.

>minor process details would exactly "make the Internet work better".

We agree on this point.

>IANA allocation rules for TLS? I don't have a strong opinion here...

Since the direction for draft-housley-tls-authz-extns remains 
unclear, I do not think we should delay draft-santesson-tls-ume while 
the other document gets sorted out.

Russ