[secdir] secdir review of draft-ietf-regext-rdap-object-tag-04

Taylor Yu <tlyu@mit.edu> Thu, 02 August 2018 05:40 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 49B0F12F1A2; Wed, 1 Aug 2018 22:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 41nrcZAPF0aG; Wed, 1 Aug 2018 22:40:48 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E34B128C65; Wed, 1 Aug 2018 22:40:48 -0700 (PDT)
X-AuditID: 12074422-589ff7000000235d-3d-5b62995cf8a6
Received: from mailhub-auth-2.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 04.92.09053.D59926B5; Thu, 2 Aug 2018 01:40:46 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU []) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w725ea0f028305; Thu, 2 Aug 2018 01:40:38 -0400
Received: from localhost (nyc-02.triskelion.com []) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w725eYtR013802; Thu, 2 Aug 2018 01:40:36 -0400
From: Taylor Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-regext-rdap-object-tag.all@ietf.org
Date: Thu, 02 Aug 2018 05:40:34 +0000
Message-ID: <ldvk1p9wckt.fsf@ubuntu-1gb-nyc1-01.localdomain>
Lines: 34
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUixG6nohs3Myna4MVVOYv9H6+xWsz4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MpYdKOZreAJd8XLaUsYGxgXcHYxcnJICJhI PLn9lbmLkYtDSGAxk8SdP18ZIZwNjBJr+yewQzhfGSX2P1jF1MXIwcEmICdx+VYwSLeIQLRE 79nDTCC2sICdxP1Pu5lBbBYBVYnd3/cwgti8AjYSty8/AqvhEeCU6O3rZoaIC0qcnPmEBcRm FpCQOPjiBfMERp5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3E CA4YF6UdjBP/eR1iFOBgVOLhvcGQFC3EmlhWXJl7iFGSg0lJlNclHSjEl5SfUpmRWJwRX1Sa k1p8iFGCg1lJhLfZAyjHm5JYWZValA+TkuZgURLnvV8THi0kkJ5YkpqdmlqQWgSTleHgUJLg FZsB1ChYlJqeWpGWmVOCkGbi4AQZzgM0vHU6yPDigsTc4sx0iPwpRmOOP++nTmLm2Nc9bRKz EEtefl6qlDjvGZBSAZDSjNI8uGmgqF/0ef2mV4ziQM8J86qDLOUBJgy4ea+AVjEBrcp2TARZ VZKIkJJqYAw7Mq2+Y2mK1oXFdmlyhsnMUzfa5q/rYI1fpWRqI7DuR/SWXL+s5eZ72m20e9Pc Dv7q7Pn7+bv3LIcL2/8/P3bBK41Z+ZPhErXmuOSznUW1Fn2qE6pzuVYvNzN+1XC3fuLTGIfs yxIs+/l2SjtN01Z7EmvfYajc807jnf3rfs8XFb/MuPl3KbEUZyQaajEXFScCAHNdSYPVAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/t_OuVFSIf7bct1MVqUz11pFeldY>
Subject: [secdir] secdir review of draft-ietf-regext-rdap-object-tag-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2018 05:40:50 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits.

I agree with Ben Kaduk's comment:

> Section 7
> Perhaps note that it is using IANA as a well-known central trusted
> authority in order to provide the property of allowing users to get RDAP
> data from an authoritative source?
>    [...] The method has the same security
>    properties as the RDAP protocols themselves.  The transport used to
>    access the IANA registries can be more secure by using TLS [RFC5246],
>    which IANA supports.
> Well, I don't know that "the same as" is quite right, especially given the
> following sentence.  The composed chain of "talk to iana, talk to referred
> RDAP server" depends both on the security of the connection to the RDAP
> server and that of the connection to IANA; it seems prudent to note that if
> TLS is used for the RDAP connection, TLS should also be used when talking
> to IANA, or even that TLS should always be used when talking to IANA.

There is also the issue of trust anchors when using TLS.  The normative
references also do not mention this issue, so maybe it is out of scope
to deal with it here.

Best regards,