IETF Logo Mail Archive

Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Benjamin Kaduk <kaduk@mit.edu> Sun, 14 June 2020 05:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68463A0A99 for <secdir@ietfa.amsl.com>; Sat, 13 Jun 2020 22:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 32n4cnu5WtNy for <secdir@ietfa.amsl.com>; Sat, 13 Jun 2020 22:12:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 90FBE3A0A96 for <secdir@ietf.org>; Sat, 13 Jun 2020 22:12:55 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05E5CpqW028034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Jun 2020 01:12:53 -0400
Date: Sat, 13 Jun 2020 22:12:50 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: secdir@ietf.org
Message-ID: <20200614051250.GK11992@kduck.mit.edu>
References: <158833501993.21190.4904257765699741589@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <158833501993.21190.4904257765699741589@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/eMrAlkWJYTabOLZNrHIWe9eh-T8>
Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 14 Jun 2020 05:12:57 -0000

Hi Rifaat,

Thanks for the review and extended discussion with the authors/shepherd/AD.
I made some comments continuing in a similar line of reasoning, seeking to
clarify what is expected to be user-facing and how the chain of trust is
established.  (I also filed a Discuss point about an apparent internal
inconsistency on whether the API URLs distributed by different mechanisms
must be "identical" or merely "equivalent".)

Thanks again,

Ben

On Fri, May 01, 2020 at 05:10:19AM -0700, Rifaat Shekh-Yusef via Datatracker wrote:
> Reviewer: Rifaat Shekh-Yusef
> Review result: Has Issues
> 
> Since the use of IP address literal is not forbidden by this document, what if 
> an attacker with the ability to inject DHCP messages or RAs uses this option 
> to force the user to contact an IP address of his choosing? In this case, the use 
> of TLS and presenting the identity in the certificate might not be of much help.
> 
> I think this case should be discussed in the security consideration section.
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

v2.23.0 | Report a Bug | By Email