Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 03 May 2019 01:04 UTC

Return-Path: <kaduk@mit.edu>
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 3B2011200EA; Thu, 2 May 2019 18:04:09 -0700 (PDT)
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 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 IPtc2-3tEHz3; Thu, 2 May 2019 18:04:06 -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 BD5DE12004D; Thu, 2 May 2019 18:04:05 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4313xYa021697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 21:04:01 -0400
Date: Thu, 2 May 2019 20:03:58 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: The IESG <iesg@ietf.org>, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-https-tal@ietf.org
Message-ID: <20190503010358.GL59871@kduck.mit.edu>
References: <155486682558.19696.15312172563014424742.idtracker@ietfa.amsl.com> <F08A7D95-6482-4530-8609-0594060F2A12@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F08A7D95-6482-4530-8609-0594060F2A12@nlnetlabs.nl>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/wvtLzYNxep2WffUuNNKU7roCz6I>
Subject: Re: [Sidrops] Benjamin Kaduk's No Objection 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: Fri, 03 May 2019 01:04:09 -0000

(just one note inline)

On Tue, Apr 30, 2019 at 10:36:16AM +0200, Tim Bruijnzeels wrote:
> Hi Benjamin,
> 
> My apologies. While updating -07 based on the review comments I found that I overlooked your response.
> 
> See response in-line, I am including these in the -08 that will follow shortly.
> 
> > On 10 Apr 2019, at 05:27, Benjamin Kaduk via Datatracker <noreply@ietf.org>; wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-sidrops-https-tal-07: No Objection
> > 
> > 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:
> > ----------------------------------------------------------------------
> > 
> > Thank you for keeping the diff from RFC 7730 tidy!
> > 
> > Abstract
> > 
> >   their CA certificate.  In particular it allows TAs to change the set
> >   of Internet Number Resources included in the RFC3779 extension of
> >   their certificate.
> > 
> > Neither "Internet Number" nor "Number Resources" appears in RFC 3779 that I
> > can see.  (On a quick skim, I'm still not sure if we mean AS number or IP
> > address/prefix.)
> > 
> 
> ack, clarified.
> 
> 
> > Section 2.1
> > 
> >   the trust anchor per se.  In the RPKI, certificates contain
> >   extensions that represent Internet Number Resources (INRs) [RFC3779].
> > 
> 
> good point, I am used to this term so I took it for granted. Now clarified.
> 
> 
> > (As above, I don't see INRs mentioned in RFC 3779.)
> > 
> > Since comments are new in this rev of TAL, do we want to caution consumers
> > that implementations may not necessarily support comments yet?
> 
> I added the following section:
> 
> 1.2. Changes from RFC7730
> 
> The TAL format defined in this document differs from the definition in [RFC7730] in that: 
> 
> 	• it allows for the use of the HTTPS scheme in URIs; and
> 	• it allows for the inclusion of an optional comment section.
> 
> Note that current Relying Parties may not support this new format yet. Therefore it is RECOMMENDED that a Trust Anchor operator maintains a [RFC7730] TAL file for a time as well until they are satisfied that RP tooling has been updated.
> 
> 
> > 
> > Section 2.3
> > 
> >   The trust anchor MUST contain a stable key.  This key MUST NOT change
> >   when the certificate is reissued due to changes in the INR
> >   extension(s), when the certificate is renewed prior to expiration, or
> >   for any reason other than a key change.
> > 
> > (This seems a bit tautological...)
> > 
> >   If an entity wishes to withdraw a self-signed CA certificate as a
> >   putative trust anchor, for any reason, including key rollover, the
> >   entity MUST remove the object from the location referenced in the
> >   TAL.
> > 
> > Certain classes of attacker could continue to publish the last-known
> > certificate as a trust anchor and prevent this withdrawl from taking
> > effect; we should probably cover that in the security considerations.
> > 
> 
> see below 2.4, or am I missing another point here?
> 
> > Section 2.4
> > 
> > We say that it's RECOMMENDED to have different domains (so as to get
> > different IP addresses) but this example shows only a single domain.
> > 
> > Section 4
> > 
> >   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.  [...]
> > 
> > I think the key part is that the attacker cannot produce a *new* CA
> > certificate that differs from a legitimate one, but they can MITM the HTTPS
> > connection and present a legitimate (but potentially stale) CA certificate.
> 
> We have this (slightly re-worded text) in the Security section:
> 
> 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.

I think (but am only about 80% sure) that we want "updated or removed"
here.  So add it if it makes sense to you, and if not, don't worry about
it.

Thanks,

Ben

> This does not go on to clarify the consequences of such possible attacks, but I believe this is sufficient warning to implementers.
> 
> 
> > 
> >   o  DNS names in Repository Server certificates SHOULD NOT contain the
> >      wildcard character "*".
> > 
> > Would a Relying Party ever reject the HTTPS connection (and thus, the
> > delivered TA) if a wildcard certificate is presented for the HTTPS
> > connection?
> 
> This is most likely controlled by the HTTPS client library used by the RP software. In some cases it may not be possible to tweak the behaviour. Therefore I think the SHOULD NOT is the right level. 
> 
> 
> > 
> > Section 5
> > 
> >   This TAL does not directly provide a list of resources covered by the
> >   referenced self-signed CA certificate.  Instead, the RP is referred
> >   to the trust anchor itself and the INR extension(s) within this
> >   certificate.  This provides necessary operational flexibility, but it
> >   also allows the certificate issuer to claim to be authoritative for
> >   any resource.  Relying parties should either have great confidence in
> >   the issuers of such certificates that they are configuring as trust
> >   anchors, or they should issue their own self-signed certificate as a
> >   trust anchor and, in doing so, impose constraints on the subordinate
> >   certificates.
> > 
> > Are there any external databases that a RP could consult to affect the
> > decision of whether to believe that a TA should actually be claiming the
> > indicated resource(s)?  (It would be a bit silly, given that this is the
> > RPKI already, but still...)
> 
> I think this is out of scope for this document. But the RIRs do publish their stats here on the NRO website:
> https://www.nro.net/about/rirs/statistics/
> 
> 
> 
> 
> 
> > 
> > 
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>