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

Adam Roach <adam@nostrum.com> Thu, 02 May 2019 13:52 UTC

Return-Path: <adam@nostrum.com>
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 32C6D120103; Thu, 2 May 2019 06:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 eBoa8SnsOvvh; Thu, 2 May 2019 06:52:02 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A781C120372; Thu, 2 May 2019 06:52:02 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x42DpvIA091924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 May 2019 08:51:58 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1556805122; bh=k5mhRrFMT2/VH74PFl4nZeufL3aKpR9H5dW66I44P5s=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=F/axvkMCswnJ3KCE+qBsis6qe+IJ3UwOE2i0xTVrR6J1SoBKsM8v9XQrP74DYVKIY g6cFEY0QTUAa8Ypb6qnkrJGKwsb7EtSDLzyoOSFZL7TaPFy8KwWbzzqFMwjDDS3FFT BpSuEayGppWkeCLQFOoCb3b0eCTUgrugBEAsew9Q=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org, The IESG <iesg@ietf.org>
References: <155491689193.9336.11988651941770388340.idtracker@ietfa.amsl.com> <06A75E77-16DA-4391-91A0-7A0A53AFB66F@nlnetlabs.nl>
From: Adam Roach <adam@nostrum.com>
Message-ID: <fe5f40a9-98cf-4bd2-a500-28a99bd2f969@nostrum.com>
Date: Thu, 2 May 2019 08:51:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <06A75E77-16DA-4391-91A0-7A0A53AFB66F@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/uV7QxbC7-BrATmlG1CjCs3AlOB4>
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: Thu, 02 May 2019 13:52:04 -0000

My apologies for the slow response here -- somehow I missed this message 
back when you sent it. Reply inline.

On 4/16/19 7:47 AM, Tim Bruijnzeels wrote:
> 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.


Thanks! These changes address the issue.

/a