Re: [Sidrops] [Gen-art] Genart last call review of draft-ietf-sidrops-https-tal-07

Alissa Cooper <alissa@cooperw.in> Tue, 09 April 2019 20:56 UTC

Return-Path: <alissa@cooperw.in>
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 94180120459; Tue, 9 Apr 2019 13:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=P3X9Yk9k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QrdDL8g/
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 rB-uRwpF0bBT; Tue, 9 Apr 2019 13:56:41 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5DB12043C; Tue, 9 Apr 2019 13:56:40 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id AC8C3293; Tue, 9 Apr 2019 16:56:39 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 09 Apr 2019 16:56:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=R fd8+OMr13fAr0+Ad0b2EOLcZZ7AS/OSRxIB7k1YTq8=; b=P3X9Yk9k1fi5UbX1d ACs8uMsOkP4Umikrxuw0SLy/nB378xBFuOIJQKmy6uqIq/4AfFVfcg0rCVabSh+V hS/tbWpbUa5CoMUdfRhGT3FoKiJaM6IWvYgxCKGk8cox/6zRsRNtT1laZfHIbSdP nOcd0/iGuEyCZ1cBkl5juoa1JDaBvsWgJkD32dLY27X0/eCFcX50ki00+8KThuFh KeQ90aYh44sVaKD38ABAxzxvIRimxbBHKYv3bTmKlrZ8d/lu4AADBUMIEujq3Bao cTbXfAUwf5SN8d1zQY3dPU0fTb619UEZDiEjUtkeffQmESpArAgTz8J16Ttgm64p +eGYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Rfd8+OMr13fAr0+Ad0b2EOLcZZ7AS/OSRxIB7k1YT q8=; b=QrdDL8g/HygiwGLNaxK9DI3pkYPpN8pim5ew4djYksUDTWNI66aDYWR9L VRkrKfpfwHiX0YDXCpgNbGfcne25wz2vyiojkjoV/9bia4/lKtOMpQlbb8oD6vI6 Vo/wacEARhZxb8lJFHSWDENZSnVYNBrM1l9Thrb0BjY2T6lnPi745U+OBbEnsf3e rDoSE6Sv30mn0PXGr33OYkUEVPCvAvbIizYDRXr/DQiaxbJQtw4yqhJL3W/e6/hs MYcCJjn+tyfJ96YYl3O1l+pl68xP65p/im1xBD49hxGB3UVQB/P3pEZ85l9eW+kE 6pSeEHEk4mO4yYSLtRLMfTUG4wToA==
X-ME-Sender: <xms:BgetXMHgd-sgJRn-x5FrHPGvoAOcn7E79jHx8ScQHPC1ijDYm7oKVw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehgdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepthhhrghtshgrihguihguohhnthhthhhinhhkthhhihhsshhhohhulhgusggvrghs hhhouhhlugdrihhnpdhivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekje enucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhen ucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:BgetXNFatmDP-ju9wwEI7pt-W4-dC1yn_gZq8VZGlzyIgPLfrGIIbA> <xmx:BgetXLLg-1DruRGeEsCdv2m350QpAP5NHszaDLIMANlUrfdBqcN71g> <xmx:BgetXGFSC0msVO-5i46_uFD0Wm31-9lbUTVvlkZpxkGyfG_OsenCRQ> <xmx:BwetXOxJjECDjmdZ97Os731TLZZ0Fqru1UAySj4PgqgnT7h01rWKsg>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 4EAF410398; Tue, 9 Apr 2019 16:56:38 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <9BA9AAE5-FC26-425E-A090-62B05E450A23@nlnetlabs.nl>
Date: Tue, 9 Apr 2019 16:56:36 -0400
Cc: draft-ietf-sidrops-https-tal.all@ietf.org, gen-art <gen-art@ietf.org>, sidrops@ietf.org, ietf discussion list <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BDB58D3A-B0B9-4A75-B65E-6A1C9AEC721F@cooperw.in>
References: <155327986751.23063.11928780401443919371@ietfa.amsl.com> <9BA9AAE5-FC26-425E-A090-62B05E450A23@nlnetlabs.nl>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>, Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/mF9Pbpd_N0PP5u_xl5zRNaQSOBE>
Subject: Re: [Sidrops] [Gen-art] Genart last call review of draft-ietf-sidrops-https-tal-07
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, 09 Apr 2019 20:56:44 -0000

Pete, thanks for your review. Tim, thanks for your responses. I entered a No Objection ballot. I think the general approach of limiting the changes to the HTTPS-related ones seems right, and I agree with your argument below about TLS validation.

Alissa

> On Apr 8, 2019, at 11:52 AM, Tim Bruijnzeels <tim@nlnetlabs.nl>; wrote:
> 
> Dear Pete,
> 
> Thank you for the review and my apologies for the late reply (I have been moving house).
> 
> Replies in-line.
> 
>> On 22 Mar 2019, at 19:37, Pete Resnick via Datatracker <noreply@ietf.org>; wrote:
>> 
>> Reviewer: Pete Resnick
>> Review result: Ready with Issues
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
>> 
>> Document: draft-ietf-sidrops-https-tal-07
>> Reviewer: Pete Resnick
>> Review Date: 2019-03-22
>> IETF LC End Date: 2019-03-18
>> IESG Telechat date: 2019-04-11
>> 
>> Summary:
>> 
>> I MUST say that this document is quite MUSTy. I only noted those that caused me
>> confusion or seemed useless. All of these are either minor issues or nits.
>> Either way, the document is generally ready.
>> 
>> Major issues:
>> 
>> None.
>> 
>> Minor issues (or might be nits):
>> 
>> In 2.3:
>> 
>>  The validity interval of this trust anchor SHOULD reflect the
>>  anticipated period of stability...
>> 
>> Are there cases where it wouldn't reflect the period of stability? If so, it
>> would be good to give an example. If not, then s/SHOULD reflect/reflects.
> 
> This is not modified from RFC 7730 - to which I was not an author. I have limited my changes to adding HTTPS support.
> 
> That said, I don't think this should be a SHOULD. In practice Relying Parties will retrieve TA certificates on every validation run, and changes happen at unpredictable intervals.
> 
> I would prefer a text that said:
> 
> The validity interval of this trust anchor is chosen such that the "notBefore" time predates the moment that this certificate is published, and the "notAfter" time is after the planned time of re-issuance of this certificate.
> 
>> 
>> Similarly for:
>> 
>>  Thus, the entity that issues the trust anchor SHOULD issue a
>>  subordinate CA certificate that contains...
>> 
>> In this case, that SHOULD might even be a MUST.
> 
> Also unchanged since 7730.
> 
> In my opinion this whole section makes recommendations and assumptions about operations of a Trust Anchor. But it's not complete, and it does not reflect the operational realities, and there may be other choices that are valid here too.
> 
> It may be worthwhile discussing these things in sidrops, but for now I would propose to make this section a bit less formal.
> 
> So I would suggest:
> 
> CURRENT:
> Because the public key in the TAL and the trust anchor MUST be stable, this motivates operation of that CA in an offline mode. Thus, the entity that issues the trust anchor SHOULD issue a subordinate CA certificate that contains the same INRs (via the use of the "inherit" option in the INR extensions of the subordinate certificate).
> 
> NEW:
> Because the public key in the TAL and the trust anchor MUST be stable, this motivates operation of that CA in an offline mode. In that case a subordinate CA certificate containing the same INRs, or in theory any sub-set of INRs, can be issued  for online operations.
> 
> I suspect though that some of the RFC7730 authors may object to this change.
> 
>> In section 4, in the last full paragraph and the bullets, I'm not at all clear
>> why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems
>> like you should explain circumstances (at least in general terms) where an
>> implementation would choose to do deviate from these.
>> 
> 
> Personally I would prefer that this document does not try to prescribe how TLS Verification is done. I don't think this is the right place. The current text is based on similar text in section 4.3 of RFC8182, which I co-authored. I don't consider myself an expert on TLS verification - that section is largely based on IESG feedback at the time. 
> 
> I kind of understand where the IESG came from at the time. It's a reference to RFC7525 which is a BCP for this kind of thing, but in my opinion it requires too much in the way of specifying local behaviour (to this RFC). I am not confident that this is the best way - it may not get sufficient review, it may get outdated, and it may be un-implementable.
> 
> In practice Relying Party implementers will use whatever TLS verification is done by the HTTPS client libraries that they use. They will have little control over the exact behaviour. And implementing their own from scratch will most likely make things more brittle and less secure.
> 
> I am open to suggestions :D
> 
> 
>> Nits/editorial comments:
>> 
>> In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some
>> important implementation advice that someone wouldn't otherwise notice in the
>> protocol. But it's a nit if ever there was one.
> 
> ack 
> 
> 
> 
> Thanks
> Tim
> 
> 
>> 
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art