[Gen-art] Gen-ART review of draft-santesson-tls-ume-04.txt
"Tom-PT Taylor" <taylor@nortel.com> Wed, 12 April 2006 20:05 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlb8-0004fx-V5; Wed, 12 Apr 2006 16:05:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlb7-0004f6-As for gen-art@ietf.org; Wed, 12 Apr 2006 16:05:53 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlb7-0005f6-8l for gen-art@ietf.org; Wed, 12 Apr 2006 16:05:53 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTlas-0006Mh-Lm for gen-art@ietf.org; Wed, 12 Apr 2006 16:05:40 -0400
Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3CK5UV00993; Wed, 12 Apr 2006 16:05:30 -0400 (EDT)
Received: from [127.0.0.1] ([47.130.18.52] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 16:05:08 -0400
Message-ID: <443D5D6E.70107@nortel.com>
Date: Wed, 12 Apr 2006 16:05:02 -0400
From: Tom-PT Taylor <taylor@nortel.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Stefan Santesson <stefans@microsoft.com>, Ari Medvinsky <arimed@microsoft.com>, Joshua Ball <joshball@microsoft.com>, Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Apr 2006 20:05:08.0844 (UTC) FILETIME=[660FFAC0:01C65E6C]
X-Spam-Score: -2.6 (--)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: gen-art@ietf.org
Subject: [Gen-art] Gen-ART review of draft-santesson-tls-ume-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
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. 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". Hope these comments are helpful. Sorry they're so late. Tom Taylor _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-santesson-tls-u… Tom-PT Taylor
- [Gen-art] Re: Gen-ART review of draft-santesson-t… Russ Housley
- Re: [Gen-art] Re: Gen-ART review of draft-santess… Brian E Carpenter
- [Gen-art] Re: Gen-ART review of draft-santesson-t… Tom-PT Taylor
- [Gen-art] RE: Gen-ART review of draft-santesson-t… Stefan Santesson
- [Gen-art] Re: Gen-ART review of draft-santesson-t… Tom-PT Taylor