Re: [Sidrops] Adam Roach's Yes on draft-ietf-sidrops-https-tal-07: (with COMMENT)

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 16 April 2019 12:47 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE91120362; Tue, 16 Apr 2019 05:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 Xay53a20agTs; Tue, 16 Apr 2019 05:47:50 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 9D774120352; Tue, 16 Apr 2019 05:47:49 -0700 (PDT)
Received: from [IPv6:2a04:b900::1:f49b:919b:4c21:e66] (unknown [IPv6:2a04:b900:0:1:f49b:919b:4c21:e66]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 7A382278AD; Tue, 16 Apr 2019 14:47:46 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1555418866; bh=ta0Tu8C6ce5dFg7wnGNfjgjngMI4YmIaGhHLAsZt7cE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=f/akMA8K1nuJuP1QTCoe9/lh11dJ810VQS/ujSjfB8Z8QZrENMIxl6e8AnR+GB8QF Yk3mFijc576fO3oClzUHVkHjUQUaGpR7Dz+d+54WK/LpcD0qxRItKBI7QqNwDpr6XM tKXqIZZ2YwJ//ntZephLuQ4KFPRhI87Jfe5w5CxE=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <155491689193.9336.11988651941770388340.idtracker@ietfa.amsl.com>
Date: Tue, 16 Apr 2019 14:47:45 +0200
Cc: The IESG <iesg@ietf.org>, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <06A75E77-16DA-4391-91A0-7A0A53AFB66F@nlnetlabs.nl>
References: <155491689193.9336.11988651941770388340.idtracker@ietfa.amsl.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sZ1f0ZSg97XrMTh4o1V3xzl-cEU>
Subject: Re: [Sidrops] Adam Roach's Yes on draft-ietf-sidrops-https-tal-07: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 12:47:51 -0000

Hi Adam, all,

> On 10 Apr 2019, at 19:21, Adam Roach via Datatracker <noreply@ietf.org>; wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-sidrops-https-tal-07: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who worked on this document.
> 
> ---------------------------------------------------------------------------
> 
> I find it curious and somewhat problematic that there is not a section,
> equivalent to the existing section 4, that deals with RSYNC considerations. In
> particular, the attack described in the first paragraph of section 4 appears
> to be unavoidable when the TAL contains an RSYNC URI. Minimally, this document
> should draw attention to that fact, at least in the Security Considerations
> section. Ideally, it would deprecate -- or at least discourage -- the use of
> RSYNC URIs for this reason.

Good point.

How about if we change the name of section 4 from "HTTPS Considerations" to "URI Scheme Considerations"

And start off with:

Please note that the RSYNC protocol provides neither transport security nor any means by which the Relying Party can validate that they are connected to the proper host. There it is RECOMMENDED that HTTPS is used as the preferred scheme.

And change:
   Note that a Man in the Middle (MITM) cannot produce a CA certificate
   that would be considered valid according to the process described in    
   Section 3.  However, a MITM attack can be performed to prevent the
   Relying Party from learning about an updated CA certificate.  Because
   of this, Relying Parties MUST do TLS certificate and host name
   validation when they fetch a CA certificate using an HTTPS URI on a
   TAL.

To:
 
   Relying Parties MUST do TLS certificate and host name validation when
   they fetch a CA certificate using an HTTPS URI on a TAL. Note that,
   although a Man in the Middle (MITM) cannot produce a CA certificate
   that would be considered valid according to the process described in    
   Section 3, this attack can prevent that the Relying Party learns about
   an updated CA certificate.


Some background - I don't think the following needs to be in the document:

In my mind it was implicit and obvious that rsync should be discouraged, to the point that I forgot to mention this completely.. The end goal is to phase out rsync. But this document still allows both. 

I proposed at some point that it should allow HTTPS only - in my mind this would just mean that for some time TALs could be presented in both RFC7730 format and this new format. But the WG preferred the approach where this update allows both schemes, and a future update can be done to remove RSYNC.

With this in mind we introduced the "Trust Anchor URI" in this document and only specify once (section 2.2) which schemes are allowed. This should make a future update easy.

 



> 
> [This would be a discuss-level comment if this were a green-field document, but
> I don't want to stand in the way of improving an existing mechanism, so I'm only
> leaving it as a comment. The authors may choose to move forward without fixing
> this issue]
> 
> ---------------------------------------------------------------------------
> 
> ยง2.2:
> 
>> In this document we define a Trust Anchor URI as a URI that can be
>> used to retrieved a current Trust Anchor certificate
> 
> Nit: "...to retrieve..."

ack


Kind regards,

Tim Bruijnzeels


> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops