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

["Tom-PT Taylor" <[e-mail]>]

Inline.

Russ Housley wrote:
> Tom:
> 
...
>> 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.
> 
[PTT] Perhaps the second sentence of section 1.2 could be modified to 
refer to the double handshake solution?

>> 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.
> 
[PTT] I see that has been added to the IANA Considerations section in 
-05. I didn't realize -05 had come out, BTW -- must have misread some of 
the messages that went by.

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

[PTT] OK
> 
>> 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.
> 
[PTT] OK, I found it -- not quite where I expected, but it works.

>> 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,
> 
[PTT] I'll have to take your word for it -- I see no change.

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

[PTT] Looks good.
> 
>> 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?
> 
[PTT] Still not sure why the first bullet is a SHOULD, given that the 
above text implies a MUST.

> Russ
> 
> 
> 


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