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

[Brian E Carpenter <[e-mail]>]

Russ,

My DISCUSS is not about these points which I put more in
the useful clarification category. The DISCUSS is specifically
about the proprietary references in the draft which aren't
suitable for standards track. I'll drop it if it goes for
Informational with Microsoft in the title.

    Brian

Russ Housley wrote:
> 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
> 

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