Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Sat, 29 August 2020 19:11 UTC

Return-Path: <stkent@verizon.net>
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 ED80D3A0140 for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 12:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 q3TnFzSMXkdB for <sidrops@ietfa.amsl.com>; Sat, 29 Aug 2020 12:11:25 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 D1B963A0E55 for <sidrops@ietf.org>; Sat, 29 Aug 2020 12:11:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598728283; bh=riBTl2uF1bybgFVWFEZFWD2r5iHoKBEXhdW6YCv8y5E=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=LpkuFyofDQ6C8cM6hss3JokgY0NdPgJHVyoSHsXuniIBXkiCZoUMzlCFAhzKyU0o+6dFpGVQzU1BAHfcqK8eYq48vXaykMGU6xN8YQJXmjvBMFpsfitc73VtO19sb2Yhu1mpURveog5MNMpYqBjETszJkbLNsiRykNPaJk0GmzgR7g6zWtITpT72iz3ZFeRdgeTu9Yc5YfGcVMieclum+o+5W+Oh8NmtiPXy4QoBeyRSA1GhcjRJ5Vexomm0WPukjOcbyyZskojPj9KTUi0YDptsunbK57gYzmZo3XP6YIkqWRN0t9ZsYrHWmnOu0vcAgwgqhIcFsu4nuRiaP/ADWw==
X-YMail-OSG: Dome6EkVM1kHUT1tUGv5EW2fOhp9TQ5sdP.jzn_19hp5LUCdrbAq4ijUIkT3QE1 QurU18jAI3oNqbNWHMwPaKSmDf05ZkqhB96AGZYV.WeO6mfCaEZqMYGcAxQ9x59ft2gQ55q1JPCc .XX84sDQXx.O9yEjTJzUvaOGMrhsHuuGdmT2EaiznDC.QSNO7TYsLXx4Zu6qXg7ZhLX7RErMd4s9 3CppghDBKj.QdrR1vICkVQYVwjlFz8KhQirkI1hVEmSBHz1nnNLiCxtU7G8rEnkBAGYkV_PiMfqi boO_QsKqtRB6xnX54WZNTMCe0YCdEZms7B11BmgSOg2sh39D90ZW5gIc5L1vjnejRzTjqa1xMR3W DwgZsHc7FTcuro_miU3zBrlbvPk7UoEgjAWL2JZe2C.K8N3h8.APqSr2NYg05Rdgxq8v_sYE_J63 dtd8GVDjp8ySgCMz.R6X_AnqwbRja24pTCf7re1X2reZiq8vDimqN_FN.rM3EBDevOLAYqX3m0bI k_EFmg47a4Q.8KDiuoSsnOXX5gmIdR.lcgr.6ThHiHjX1zvuy8cVkqEuhlFMNrwADeyxJx_cBdyj gVVRCjxzeuUAs2D.PHSthecB7Xf6FpAKLozcDtb0rK8wVmyqxwGL9LG3rKm_XbqFAmIUlRtl2MpP ZqcqOjtN3tFGdPWxSaJlFXNwEzT74mUax9k9xvLk2OePhmfwmHgNcpvJczfLeIAsBbYEg6pXGRMx 9Lbl4UfJeIEQlyWDpV6RwXkaX35j4I6ipkC6JII1v5balhYn5bp_iV3B0vCABSkeS_RkwOeJ48I0 Mxg1z0rM_9QBgg.Gtx6HiQhVcbgPVGygHc7l8wfdCEbiufeaLK_x8nQeQA8Ph1rzWBlFZ8SdqwKo X7ENs63xi78O6XXDidV6jlFHtEy5qo7FvfUptnpeHX03GEILkuTLWh2Zgd_OlSXghYxF2ZhnF9xR 6e3U.pDyCw4ShyBGcKMLgeZoFrwAz.oTIbXoWm_xP58Ohhl6sQePNgN9dC.Vdaann6bJ4FYgazZk zNculmLAOd17ZRSn3g6qvWnNtdl4gcZSYOCiziczsXDC6nXOTjt7klNawH8ioSHcCsyCv2_qu9Sx cVo3Xvj4iVEbZIpRCUb.DWN1XE3KsSsSCFf4z8vVcnIaJfKBaDuUTKKcQx6WeKJgh6SxW3a8BsqE 4zOqasSfqAN6D5mLTgcQGqNlMMR3I60cf4qkxqSQLdphzRZeG78aPXiT8bQEFB3fK6FIoJLmMhgn q13DPEoSXBO7.A5vkr4Na40774tEkwtnn_vhwLj4o3WSy.EAvdk4pQ2BBTsHUHtaFgfzkWOX7bM7 IyyyVD3zQATpBMM9Iaxc66ugGC.om.4Nv8JInJa0gYdngr2oFTVZqbjVIyb_R5Mjswjd8ft6TLTX .GePPzG_pxqR4Vs8ZC3jHagIjOnZM2bx.nj8QjoyfUL2.yF41OvmsENOb5FugDExutRsUeq5yt29 YvAXbaD8V4hG4g0lqN9i5xIvOUDSeh_pcbZfHCu_zNlG1ctBTkKvI_GRkSSWDrR1TivxiRs2BBWY u05VtxJsw5L6Z_UelZ6Wg67cTVTc-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sat, 29 Aug 2020 19:11:23 +0000
Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2d5fcd44c63216ac76794313453f4cfe; Sat, 29 Aug 2020 19:11:19 +0000 (UTC)
To: sidrops@ietf.org
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net> <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net> <24393.25181.84151.476185@oz.mt.att.com>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net>
Date: Sat, 29 Aug 2020 15:11:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <24393.25181.84151.476185@oz.mt.att.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tX50qbu3wN7fC98s4Gs7f-IrRoA>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Sat, 29 Aug 2020 19:11:27 -0000

Jay,
> Steve,
>
> I would like to comment on two things you recently wrote to this list:
>
> Stephen Kent writes:
>   > When I the WG chairs tell me that I misunderstood the WG consensus re:
>   > strict correctness then I will revisit this topic. However, the recent
>   > messages from Mikael and Job suggest that your perception of WG
>   > consensus is not accurate. This issue is one that needs to be decided by
>   > network operators, not by developers of RP software. I agree with the
>   > observations made by Mikael and Job, i.e., that requiring strict
>   > conformance with manifest rules is the preferred approach.
>
> I don't think viewing this as "network operators" vs "developers of RP
> software" is a productive approach.
>
> I am a professional network operator -- somebody pays me to do that.
> I also happen to have some opinions on how a successful PKI should
> operate, but so far no one has offered to pay me for those opinions.
> If asked to use only the network operator part of my brain to say
> whether strict conformance is the best approach here, I would answer
> "Honestly, I don't care.  As a network operator I care only that the
> VRPs I use in my network are as trustable and reliable as possible."
> I certainly have opinions how _how_ to make the system as trustable
> and reliable as possible, but I know others have thought about such
> aspects far more than I have -- in particular folks who have
> implemented RP software.
>
> At the risk of making my comments here too personal (they are not
> intended that way), my friend Job wears both of these hats: he is a
> network operator, and he is involved in developing an RP
> implementation.  That's great!  I value his opinions, and I am happy
> to hear that you do, too.  But it would be fruitless to attempt to
> determine which parts of Job's psyche most inform his opinions voiced
> in this WG.  So rather than attempting to do so, I would like to ask
> you to also value the opinions and contributions of other RP
> implementors, particularly those who have been active in this
> discussion.  Many network operators do not participate here in
> SIDROPS, but presumably all RP implementors do.
The crux of the issue is whether it is preferable to reject all objects 
at a pub point if an error is detected (until the error is rectified), 
and thus potentially treat many more routes as having an unknown 
verification status, or to accept bits and pieces of data from a pub 
point with the potential that some routes will be treated as valid, even 
if they are invalid. To me, that is a value judgement to be made by 
network operators, not by developers of RP software. Job can pick 
whatever hat fits him best.
> > >> You absolutely have to deal with this issue in 6486bis in its current
>   > >> strict form. Any introduction of a new object type will permanently
>   > >> break CAs that use these objects when validated with a relying party
>   > >> software that is not aware of this type. I don’t think this is
>   > >> acceptable, as it effectively blocks the introduction of new types
>   > >> pretty much forever.
>
>   > No, it does not. What I suggested is that when a new object is proposed,
>   > it is the responsibility of the those proposing the new object to
>   > explain how it will be incrementally deployed. That explanation belongs
>   > in the RFC defining the new object, and in an updated version of 6486
>   > will need to be generated. We have no good examples of new objects that
>   > provide a basis for describing how to accommodate incremental
>   > deployment, and thus no basis for defining such mechanisms at this time.
>   > It might be the case that a new object will be defined that requires the
>   > CA to maintain a separate pub point using some newly-defined SIA
>   > pointer, indicting that the new pub point contains the new object and
>   > thus RPs that don't know how to process the object MUST NOT follow that
>   > pointer. There will need to be agreement on how long a CA MUST maintain
>   > the old pub point, etc. But, absent a concrete example of a new object
>   > type that warrants this sort of effort it is premature to write a spec.
>
>
> The situation you describe here sounds horrible, trying to keep older
> RPs from seeing newer objects they're not equipped to fully
> understand.  A much more robust system would be one where RPs are not
> thrown off by unknown object types retrieved from known publication
> points and listed in manifests.  Clearly older RPs would not know what
> use to make of newer objects, and thus would ignore them.  Network
> operators interested in taking advantage of the new objects would
> first need to upgrade their RPs in order to do so, but that's BAU.

Experience with X.509 cert extensions suggests that the approach I noted 
is preferable. Saying that older RPs can ignore objects they don't 
understand introduces ambiguity in RP behavior, which is precisely the 
concern that motivated the effort to generate 6486bis.

Steve