Re: [Anima] rfc822Name use in Autonomic Control Plane document

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 21 June 2020 02:41 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1063A0848 for <anima@ietfa.amsl.com>; Sat, 20 Jun 2020 19:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 4bhgzLCT1Gwz for <anima@ietfa.amsl.com>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 DC3E73A0846 for <anima@ietf.org>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id x207so6636309pfc.5 for <anima@ietf.org>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=I+G6L86Rp9X7dPFj5e044ZivrPV8SPCFJ44PMzVp+PVwLYh4dKhqvKUOEnlGL4EYWZ tK+dXOFVel3d+Za1H4Gd5ZRAlEuc/Ur1I9gc1Drd8Hu16YjNHbFlya/SjUHmjIU1tvGO 0JHWzSF7eZFjO/yeJbA5z0izwH4xy7a8igvyeubeID19OWKaK7WNsKHUnVDo8Klc7NTE Qe/QMOZypMlQsXs7zswO6/UcV/q+rqjWj4i6jpRIppwAPJptAuoqfzaddEg8wbMLcPhd a0Eb8P865h4ssIoMhz0EfVsS4HhPtNzVz9hiFZLFa6/KdKCTSU437kLnIMKPSyqL0oP2 YTUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=TyX46ygC7pqf9krYYlu9mI2+VVBHrh5j6kEUuD6l1HX2F5LFvI2VFJm05FPTFY5kbZ RBNI+JgyxauzCkHYLwA+MrF2/FuwmkUNHhLrtavzT/mwNk0Qa2joQ+4kJERcBByz8O2Q //WPLh8sMT9xuJJCppmpnLnxbEP2bdxU0wDH1w45RA8PlNBSQfmpiyACbCRiexd8VrEP 2UOl3ppdxtFbFC341N9u37qiMUDVuXBJD9HhQQuDbhY+eLnfmJxavnvgRFUtLB/PkmJS 4kCph+ZnTB/QXChWKhnm2tCjXiSL+0jJvJcfBrv2TjYYTXleFhm6EZCsIk9AOdNMzhGz yaKw==
X-Gm-Message-State: AOAM5300/ubflGrwV0McfVsgZo8eVgBRm2YB3+mW3yv1FHaQgctgA3+B NhGj6X3128PpG0815VzZx4in/zPVF5Q=
X-Google-Smtp-Source: ABdhPJzbnhjTHqXKURH/4w2lLv+7pXhgCcP4vUoEB/tkZhEDcioObA15HZtk/qfKSnIRXPrAfuFVsw==
X-Received: by 2002:a63:d847:: with SMTP id k7mr8155931pgj.93.1592707310173; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: from [192.168.178.30] (247.90.69.111.dynamic.snap.net.nz. [111.69.90.247]) by smtp.gmail.com with ESMTPSA id w206sm10004064pfc.28.2020.06.20.19.41.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 19:41:49 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org, Russ Housley <housley@vigilsec.com>, sean+ietf@sn3rd.com
References: <11428.1592266833@localhost> <a0face89-da68-f75d-4a57-4deb9d0f244d@gmail.com> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <20200620234814.GC11992@kduck.mit.edu>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <596df468-58d2-1a5c-f667-952d2b668191@gmail.com>
Date: Sun, 21 Jun 2020 14:41:43 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200620234814.GC11992@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/f8-r8TgNqQInv_KNFbnNvlO2M_k>
Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jun 2020 02:41:53 -0000

Thanks Ben. It's important IMHO to be precise about technical objections and your statement below is precise. As a non-expert, I'll refrain from technical comment.

Regards
   Brian

On 21-Jun-20 11:48, Benjamin Kaduk wrote:
> Hi Brian,
> 
> On Fri, Jun 19, 2020 at 05:11:30PM +1200, Brian E Carpenter wrote:
>> Hi Ben,
>>
>> (Back on line after a couple of days spent moving apartments.)
> 
> (and me after getting slowed down by being sick)
> 
>> On 17-Jun-20 14:44, Benjamin Kaduk wrote:
>>> Hi Brian, Michael,
>>>
>>> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote:
>>>> On 16-Jun-20 12:20, Michael Richardson wrote:
>>>>>
>>>>> Hi, I have had a few conversations with Toerless who is trying to deal with
>>>>> the feedback on the ACP document.
>>>>>
>>>>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN.
>>>>>
>>>>> We already had this debate.
>>>>> Some time ago.  The WG decided.
>>>
>>> With all due respect, this is not the sole decision of the ANIMA WG to
>>> make.  If WGs had such authority then why bother with cross-area review?
>>
>> Yes, but that was exactly the reason we had the discussion a year ago.
> 
> I think the expansion of the "we" is important, here -- who did you have in
> mind?

Well, I guess it was between you and the WG, but prior to IETF-wide review.
My understanding was that we'd reached an unhappy compromise, but apparently
not.

    Brian

> 
>>>>> Three or four years ago, I think.
>>>>
>>>> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS:
>>>
>>> I'm not sure I understand why you use the word "resolved" here:
>>>
>>>> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc
>>>
>>> In this message, I say that "I still feel like this is not the best
>>> architectural choice" and that I will provide a sketch of an alternative in
>>> my (then-)forthcoming ballot position; that ballot position retains the
>>> Discuss-level concern about rfc822Name usage along with the promised
>>> alternative.
>> "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc
>>
>> It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place.
>>
>> If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice".
> 
> Sorry, that was the second round of Discuss and my politness filter may
> have been overactive.  Allow me to rephrase:
> 
> I think that the use of rfc822Name in this document is inconsistent with
> the specification for that field given in RFC 5280.  I do not believe that there
> is IETF consensus (specifically, including the IETF PKIX community, e.g.,
> the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not
> documented (and consensus obtained for it) as such a deviation from RFC
> 5280.
> 
> I believe there are several ways in which the necessary functionality for
> this specification can be obtained that remain consistent with RFC 5280;
> specifying the use of any of them would suffice to resolve the Discuss
> point.  The "smallest diff to the text" option would be to define an
> otherName OID to carry the same contents currently specified for
> rfc822Name, but other options involving splitting the semantic components
> into EKU/iPAddress SAN/extension/etc. are possible.  I could probably even
> accept a non-normative note saying that some legacy deployments used the
> rfc822Name field, though given Sean's review there would probably need to
> be a pretty strong disclaimer of the risks of doing so.
> 
> [one more note at the end]
> 
>> Not to mention that this is only a Proposed Standard discussion; perfection not required.
>>
>> I don't consider myself enough of a subject matter expert to comment on the technical issue itself.
>>
>> Regards
>>     Brian
>>
>>>
>>>> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26
>>>
>>> I appreciate that the attempted justification is clearly written; however,
>>> I do not find it compelling.  Russ did not, either, and I just heard back
>>> from Sean Turner a few days ago to confirm that he supports Russ's
>>> comments.  (There should be a few other editorial-ish comments that came
>>> out of that review that are still pending.)
>>>
>>>> I believe it is incorrect IETF process to rediscuss this point yet again.
>>>
>>> (I'm not sure if the "yet again" refers to "after the WG decided" or "after
>>> the (alleged) resolution of my first Discuss point".)
>>>
>>> If you believe the technical answer is clear and that I am in error to
>>> continue to hold my Discuss point for it, are there not also clear IETF
>>> processes to follow?  E.g., asking for the "Single Discuss" ballot procedure
>>> described at https://www.ietf.org/standards/process/iesg-ballots/?  I
>>> believe I have mentioned this option to Toerless previously; my apologies
>>> if that is not the case.  While I'm willing to continue discussing the
>>> topic and pull in additional PKIX experts to weigh in, there is perhaps
>>> some consideration to matters of expediency.
>>>
>>>>>
>>>>> I sure wish that we could use something else.
>>>>> But, CAs and CA software make that very difficult.
>>>>>
>>>>> Given that the era of publically anchored Enterprise CAs is dead, there are
>>>>> only two ways an (Enterprise) ACP Registrar is going to occur.
>>>>>
>>>>> 1) by running a private CA.
>>>>>    Sure anything is possible if you are writing your own code, but
>>>>>    most will not be doing that. (I've supported otherName in my code for
>>>>>    other purposes, and it's not that difficult, but it's not trivial either)
>>>>>    My experience with COTS CA systems it that it's really hard to
>>>>>    get them to do it.    Please prove me wrong.
>>>
>>> (Sadly, I have zero experience with COTS CA systems; I know too much about
>>> openssl at this point and would presumably be writing my own, in this
>>> position.)
>>>
>>>>>    The most popular Enterprise CA software is the Microsoft CA.
>>>>>
>>>>> 2) by using ACME to speak to a hosted CA.  Maybe WebPKI, maybe not.
>>>>>    Either way, getting otherName supported is even harder, because
>>>>>    nobody else uses it.
>>>
>>> Is the concern the ACME protocol support or just getting the hosted CA to
>>> cope with it?  The former seems like something that we could make happen in
>>> the IETF, and the latter seems to have high overlap with point (1).
>>>
>>>>> If we can't depend upon otherName being filled in, then we have to look for
>>>>> two things.  That means more code paths (two more) to test, more test
>>>>> vectors, and what exactly does an end point do when both are present, BUT
>>>>> THEY DO NOT MATCH?  So three more pages of text there.
>>>>> Remember, that just rejecting the certificate means that we have to send out
>>>>> a truck, which is what ACP aims to avoid, so that won't be popular.
>>>>> And of course, there could also be bugs (maybe even CVEs) in the code that
>>>>> tries to deal with the tie.
>>>
>>> To be honest, this argument feels like a stronger one to me than the bits
>>> in the -24.  I'm still not willing to accept into the RFC Series a document
>>> that violates the rules set down by the specification for the technology
>>> it's making use of, but the refocus on the "running code" aspect is
>>> appreciated.
>>>
> 
> Thinking about this a bit more, it seems like it would be doable (and, more
> importantly, testable) to require that if the otherName (or whatever) is
> present, there MUST NOT be an rfc822Name present.  Which doesn't
> necessarily help with the "need to implement" bit for sites that use
> rfc822Name, of course, but should avoid the worst of the risks for when two
> sources of data don't match.
> 
> -Ben
>