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