TLS Handshake Message for Supplemental Data
draft-santesson-tls-supp-02

From Gen-ART review by Tom Taylor on draft-santesson-tls-ume-04.txt:


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

Russ's solution to move the part that I was worried about to informative resolves all my discuss level issues.

I am clearing my DISCUSS, entering a comment instead. 

Originally we had (from Bert Wijnen):

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

W.r.t draft-santesson-tls-ume-04.txt draft:

    struct {
            opaque user_principal_name<0..2^16-1>;
            opaque domain_name<0..2^16-1>;
    } UpnDomainHint;

So they cater for 64K for username and domain name??
Wow... we need more bandwidth in our future networks

I also find the use of SHALL and MAY not so great. 
Maybe I am too senstitive to those keywords possibly many of the uppercase uses can be just lowercase?

On page 6, I am surprised it is only RECOMMENDED to use some form of stringPrep.
That feels like the current MS implementations does not do it and so only deals with US ASCII for now? Which I think is not good.

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

The stringPrep issue was the main reason of the DISCUSS. In the new version they took away ALL of the stringPrep material. I think this is good for the domain name, they now refer to rfc3490 for that, but I doubt that this is good for the user_principal_name. I suggest that the APPS ADs have a look at this.