[weirds] FW: Gen-ART review of draft-ietf-weirds-rdap-sec-09

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 21 October 2014 10:50 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF101A0469 for <weirds@ietfa.amsl.com>; Tue, 21 Oct 2014 03:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6QA46S2f9GQ for <weirds@ietfa.amsl.com>; Tue, 21 Oct 2014 03:50:24 -0700 (PDT)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D89B1A03FF for <weirds@ietf.org>; Tue, 21 Oct 2014 03:50:23 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKVEY6bl/oRWlu66P9kDRyxEZFuIH9RIAI@postini.com; Tue, 21 Oct 2014 03:50:23 PDT
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9LAoMaK004121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <weirds@ietf.org>; Tue, 21 Oct 2014 06:50:22 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 06:50:21 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "weirds@ietf.org" <weirds@ietf.org>
Thread-Topic: Gen-ART review of draft-ietf-weirds-rdap-sec-09
Thread-Index: Ac/rwUIQou+UqyLTRGO9+RCo9ywghAAn5ZJAAC77BUA=
Date: Tue, 21 Oct 2014 10:50:21 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F494EF91C@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <7594FB04B1934943A5C02806D1A2204B1D4AF4C2@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F494EF91CBRN1WNEXMBX01vc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UBefBwoXS9V7B6Uqr0Q9zQRYYIo
Subject: [weirds] FW: Gen-ART review of draft-ietf-weirds-rdap-sec-09
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 10:50:32 -0000

FYI, folks.

Scott

From: Hollenbeck, Scott
Sent: Monday, October 20, 2014 9:18 AM
To: 'Christer Holmberg'; gen-art@ietf.org
Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-weirds-rdap-sec-09

Thanks for the comments, Christer. More below.

Scott

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, October 19, 2014 7:46 PM
To: gen-art@ietf.org<mailto:gen-art@ietf.org>
Cc: draft-ietf-weirds-rdap-sec.all@tools.ietf.org<mailto:draft-ietf-weirds-rdap-sec.all@tools.ietf.org>
Subject: Gen-ART review of draft-ietf-weirds-rdap-sec-09


(Re-send with correct subject)



I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>



Document:                         draft-ietf-weirds-rdap-sec-09



Reviewer:                           Christer Holmberg



Review Date:                     19 October 2014



IETF LC End Date:             24 October 2014



IETF Telechat Date:         30 October 2014



Summary:                         I have found a number of issues. They are of editorial nature, but makes it difficult to understand the mechanism. I ask the authors to look at those, and consider if/how they can be addressed.



Major Issues: None



Minor Issues: None



Q1_GENERAL:



In the Introduction, you say that one of the goal of RDAP is to provide security services, that do not exist in WHOIS.



However, in section 3 you then say that RDAP doesn't provide any of these security services, but relies on other protocols.



First, I think you need to re-formulate the text in the Introduction, and talk about how other protocols can be used to provide security services for RDAP.

[SAH] The introduction currently states "This document describes how each of these services is achieved by RDAP". The details are described in later sections. I'm comfortable with changing "This document describes how each of these services is achieved by RDAP" to "This document describes how each of these services is achieved by RDAP using features that are available in other protocol layers", but I think it's more appropriate to leave the details where they are and not replicate them in the introduction.



Second, there is no text on why "other protocols" couldn't be used to provide security services for WHOIS. I think you need to

say that, if you want to claim that RDAP provides better security than WHOIS.

[SAH] This document isn't focused on WHOIS deficiencies. The reference to RFC 3912 provides a pointer to WHOIS and its lack of security services.



Q2_GENERAL:



              In some places you say that additional/alternative mechanisms may be defined in the future. I think it would be good to in

the Introduction indicate that additional/alternative mechanisms can be added in the future.

[SAH] OK, that's reasonable.



Q3_GENERAL:



              You start some subsections by describing what WHOIS does/doesn't do. I think you should first describe of

the specific security service is provided for RDAP, and then later describe e.g. why the same cannot be provided

for WHOIS

[SAH] Since this document isn't focused on WHOIS deficiencies I don't think this is necessary.



Q4_3_1_1:



              Section 3.1.1. says: "Federated authentication mechanisms used by RDAP are OPTIONAL."



              That statement is confusing. Does it mean that everything else in the document is mandatory to support?

[SAH] Good point. I can modify that sentence and the second sentence in that paragraph as follows:



"Federated authentication mechanisms MAY be used by RDAP. If used, they MUST be fully supported by HTTP."



Q5_3_3:



              The name of section 3.3 is "Availability". I don't see how that is a security service, and the text mostly talks about

throttling. Would it be more appropriate to say "Request throttling" instead?

[SAH] The property of availability is described in Section 4 of RFC 4949. I believe the text is appropriate as-is.





Q6_3_4:



              Section 3.4 says:



              "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to provide that protection by encrypting all

              traffic sent on the connection between client and server."



              To me that sounds like something from a BCP document. I think you should say that the document defines

the usage of HTTP over TLS for providing the security service.

[SAH] OK. I can change the sentence to "RDAP SHOULD use HTTP Over TLS [RFC2818] to provide that protection by encrypting all traffic sent on the connection between client and server". I'm sure there are people who will suggest that MUST is better than SHOULD, but that adds a requirement that hasn't been discussed in the WG. WG chairs - what do you think?



Editorial nits: None




Regards,

Christer