Document: draft-santesson-tls-ume-04.txt  
Reviewer: Tom Taylor
Review Date:  Wednesday 4/12/2006 3:05 PM CST
IESG Telechat Date:  Thursday, 13 April 2006

IETF Last Call (ends 13 April 2006)

Summary: This draft raised some questions in my mind that may need to be 
answered before it goes forward. One of these questions actually implies 
the need for new text in draft-santesson-tls-supp-00.txt.

I have some suggestions for editing.

---------------------

Substantive comments:

1. Section 1.2 Design Considerations, second sentence. This sentence is 
talking about a possible alternative design approach to protect the data 
being sent. A concern over inappropriate dissemination is expressed in 
the Security Considerations section of the draft.

The proposal in the Security Considerations section that the client use 
discretion in sending the information is a half-hearted look at the 
issue, since an attacker can view the SupplementalData in transit. The 
authors may need to make up their minds whether exposure is an issue or not.

2. The protocol requires assignment of an extension type number to the 
user_mapping extension. Similarly, a supplemental data type number needs 
to be assigned to user_mapping_data. I suppose this can be left to IANA 
to assign the next available number, since the numbering sequence 
doesn't seem to have any protocol significance.

3. A literal reading of 2246bis section 4.3 suggests, based on the upper 
bounds of the various data structures in section 3 of the present 
document, that the user_mapping_data_list doesn't provide enough space 
to hold even one instance of UserMappingData. Is such a cavalier use of 
upper bounds normal TLS specification usage?

4. Is there any relationship between the value of user_principal_name 
and the value of domain_name, if they are both present in the same 
UpnDomainHint instance?

5. In section 4, after the user_mapping extension has been negotiated, 
the sending of the SupplementalData message is only a MAY. Is this the 
intended strength?

6. In section 5, Security Considerations, there are two SHOULD bullets 
for client behaviour. The first one raises a question in my mind that 
may need additional text in draft-santesson-tls-supp-00.txt. The 
question is: what is the behaviour expected of a server that receives 
supplemental data of a type that has not been negotiated as an extension?

7. Same bullets: any time a SHOULD is specified, the document should 
also describe the exceptional case. When would a client send 
supplemental data it has not negotiated? Isn't this a protocol 
violation? What exception do you see for the second bullet?


----------------------

Editorial
---------

1. The fifth and sixth paragraphs of the introduction are a bit awkward. 
You alternate between failure and success cases. Also, there is an 
alternation between present and future tense. I suggest a rearrangement 
like this:

   "The new TLS extension (user_mapping) is sent in the client hello
    message. Per convention defined in RFC 4366 [N4], if the
    server does not understand the extension, it responds with a
    server hello omitting it. In response, the client proceeds as
    normal, and does not include the UserMappingDataList data in the TLS
    handshake. Note that the SupplementalData handshake message may still
    be sent because of other mutually-agreed extensions.

   "If the new extension is understood, the server places the same
    extension (user_mapping) in the server hello message, to
    inform the client that the server understands it. In response,
    the client inserts UserMappingDataList data into a SupplementalData
    handshake message sent prior to the Client's Certificate message. The
    server will then parse this message, extracting the client's domain,
    and store it in the context for use when mapping the certificate to
    the user's directory account. Note that the SupplementalData
    handshake message may also contain data relating to other
    mutually-agreed extensions."

I added a sentence to each paragraph that you may also find useful to add.


2. Section 4 repeats some of the material that was stated more clearly 
and completely in section 2. Could you combine the sections, or take the 
repeated material out of section 4 and refer back to section 2?

3. In the Acknowledgements, you have an extra 'o' in "Rescorla".