[Gen-art] Re: Gen-ART review of draft-santesson-tls-ume-04.txt

[Russ Housley <[e-mail]>]

Tom:

>I was selected as General Area Review Team reviewer for this specification
>(for background on Gen-ART, please see
>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>Document: draft-santesson-tls-ume-04.txt
>Intended Status: Proposed Standard (Individual submission via AD)
>Shepherding AD: Russ Housley
>Review Trigger: 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.

I do not agree.  The solution is not described will in 
draft-santesson-tls-supp-00.txt, but the double handshake is the 
solution.  I have written a description of it in the security 
considerations of draft-housley-tls-authz-extns-03.txt.  I'm please 
to include that text in this document if you believe it will help.

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

Leaving the number assignment to IANA is the usual practice.

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

I think of these values as maximum buffer sizes.  Take a look at 
2246bis, and you will see many cases like this.

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

Text was added in draft-santesson-tls-ume-05.txt to address a similar 
Last Call comment.  It has already had many eyes look at it, so I 
hope you are also satisfied.

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

Text was added in draft-santesson-tls-ume-05.txt to address a similar 
Last Call comment.  It has already had many eyes look at it, so I 
hope you are also satisfied,

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

Good point.  I suggest:

OLD:

    If present, the SupplementalData handshake message MUST contain a
    non-empty SupplementalDataEntry structure carrying data associated
    with at least one defined SupplementalDataType.  An explicit
    agreement that governs presence of any supplemental data MUST be
    concluded between client and server for each SupplementalDataType
    using the TLS extensions in the client and server hello messages.

NEW:

    If present, the SupplementalData handshake message MUST contain a
    non-empty SupplementalDataEntry structure carrying data associated
    with at least one defined SupplementalDataType.  An explicit
    agreement that governs presence of any supplemental data MUST be
    concluded between client and server for each SupplementalDataType
    using the TLS extensions in the client and server hello messages.
    Receiving an unexpected SupplementalData handshake message
    results in a fatal error, and the receiver MUST close the connection
    with a fatal unexpected_message alert.

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

Is this handled by the above text too?

Russ


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art