Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)
"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 15 December 2014 13:11 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 69C941A1BBD; Mon, 15 Dec 2014 05:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6I3dfGh7YoFD; Mon, 15 Dec 2014 05:11:45 -0800 (PST)
Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECC91A1AC3; Mon, 15 Dec 2014 05:11:39 -0800 (PST)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVI7eCoe++jlXfBcD9RzIdpxLcUhdc1DA@postini.com; Mon, 15 Dec 2014 05:11:44 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sBFDBb4x026053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 08:11:37 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 15 Dec 2014 08:11:37 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)
Thread-Index: AQHQDljueW9VDFy+VkqDhH8RMvacQJx8lcFwgBQeSwA=
Date: Mon, 15 Dec 2014 13:11:36 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F49543B83@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <20141028231547.11097.50169.idtracker@ietfa.amsl.com> <A0B88EC0-BEC4-496D-AB7A-D3F26FDCEC9D@cooperw.in> <831693C2CDA2E849A7D7A712B24E257F49536C35@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49536C35@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/zzEAKlc6oXZ3F8Jvx3OoSGC8KxE
Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" <draft-ietf-weirds-rdap-sec@tools.ietf.org>, "weirds-chairs@tools.ietf.org" <weirds-chairs@tools.ietf.org>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)
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: Mon, 15 Dec 2014 13:11:47 -0000
Top posting... Alissa, draft-ietf-weirds-rdap-sec was updated on 2 December to address the comments described below. Could you please take another look and update your discuss position if the new version addresses your feedback appropriately? Scott > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Hollenbeck, > Scott > Sent: Tuesday, December 02, 2014 1:00 PM > To: Alissa Cooper; IESG > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > chairs@tools.ietf.org; weirds@ietf.org > Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds- > rdap-sec-10: (with DISCUSS and COMMENT) > > > -----Original Message----- > > From: Alissa Cooper [mailto:alissa@cooperw.in] > > Sent: Tuesday, December 02, 2014 12:54 PM > > To: IESG > > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds- > > chairs@tools.ietf.org; weirds@ietf.org > > Subject: Re: Alissa Cooper's Discuss on draft-ietf-weirds-rdap-sec- > 10: > > (with DISCUSS and COMMENT) > > > > Thanks for addressing my DISCUSS points. I just have a couple of > > follow-ups. > > > > I'm glad to see this new text in 3.5: > > > > HTTP Over TLS MUST be used to > > protect all client-server exchanges unless operational constraints > > make it impossible to meet this requirement. > > > > Is it implied that this applies to rdap-bootstrap as well? > > Yes. The bootstrap document currently says this: > > "The transport used to access the registries could be more secure by > using TLS [RFC5246] if IANA supports it." > > So if IANA supports it TLS MUST be used. > > > Couple of comments on this text in section 5: > > > > In addition to privacy risks to registrants, there are also > > potential > > privacy risks for those who query registration data. For example, > > the fact that a law enforcement officer performs a particular > query > > may reveal information about the officer's activities that he or > she > > would have preferred to keep private. RDAP supports the use of > HTTP > > over TLS to provide privacy protection for those querying > registrant > > data as well as registrants. > > > > Someone in Honolulu suggested to me that the law enforcement officer > > example might not be the best one, and that's probably right. I would > > suggest substituting another term instead - maybe "registry > employee"? > > > > I would also suggest editing the last sentence to match the above > text > > from 3.5: "RDAP requires the use of HTTP over TLS to provide privacy > > protection for those querying registrant data as well as registrants, > > unless operational constraints make it impossible to meet this > > requirement." > > > > Also given the new text in 3.5, it seems like the recommendations in > > section 6 regarding the TLS null cipher suite should be updated as > > well. I would suggest "This option MUST NOT be used" - assuming the > > same operational constraints caveat does not apply here. > > These are all reasonable suggestions. I'll do another edit. > > I can't think of an operational reason to use the TLS null cipher... > > Scott > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds
- [weirds] Alissa Cooper's Discuss on draft-ietf-we… Alissa Cooper
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Hollenbeck, Scott
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Pete Resnick
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… John Levine
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… John R Levine
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Andy Newton
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Kathleen Moriarty
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… John Levine
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Edward Lewis
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Hollenbeck, Scott
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Kathleen Moriarty
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Hollenbeck, Scott
- Re: [weirds] Alissa Cooper's Discuss on draft-iet… Hollenbeck, Scott