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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 19 June 2020 20:22 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 C94283A0E1A for <anima@ietfa.amsl.com>; Fri, 19 Jun 2020 13:22: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 VURwrb4DlnNn for <anima@ietfa.amsl.com>; Fri, 19 Jun 2020 13:22:52 -0700 (PDT)
Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 ED4B03A0DAA for <anima@ietf.org>; Fri, 19 Jun 2020 13:22:51 -0700 (PDT)
Received: by mail-pj1-x1044.google.com with SMTP id s88so4736762pjb.5 for <anima@ietf.org>; Fri, 19 Jun 2020 13:22:51 -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=iWo7EcUpe2hP88Cu4EQrLIyrJ5D/ORCFeJWtjKx8YtE=; b=s2wkqM1SKA5zIMEVP2rx796VqHQp/0er9BMEEphDvh6CXH40iW19gBV3xB7mT9jhEC bHs6dFx/zCrcE7WSLAzhSj5mC8h1NCpbdHz349C2Sa5zKbt08sdtxT/oz8EZx9GhGtvg 2Nnshid3Lm8yFchAOq6xBS1rsvDwAl1ymGX9dERLrbCxrPzx+qRsps4xzlxK2tNmc/6w YpXDVm9yN2cM9/8AYutirb0gouiG1mm8VPvIQFHYUXjWjpq0lvmcrMxm+bRGUgCcJPC6 7ILub47jCg5CFwKQZ6X0YQwnnu74Oge83IT6wF9k2oR/UpaY2o8KgWZocSkR6eyyPM3K e/Rw==
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=iWo7EcUpe2hP88Cu4EQrLIyrJ5D/ORCFeJWtjKx8YtE=; b=LGTNjf/zpctybP6MakCr0h1A+QWr2pP1qvA6PObHT8xU4PtLd2Z8d8XsbfCruHeruj +K43uiKcL+OAYB7jn2Q1e1WwKiScQUbFtb3X5phrbjGnktbKDeyFXPzmOlsDnfOJgtQz FhIhD09y7WbuLllQaVQ766rj8RVPmMgqNKDgvB5/6FswTdcoCtTgaefYtkUTp98SgCpJ LMHZTRw77jec5PeC4NIv0xxSkixVg8EdYpexC08939r1Pg7kjhs11LPem46SZD7UjlJp iuzRvHwyDCzyWzHA8ti1xjq1mHuoc6NFXFfLz38Ata5EAdKrCN55HAiR6HFVS8KUTpMG EUqA==
X-Gm-Message-State: AOAM531Vs3Y94nbX/3bh9qYBqsv1c1BZE5xK88iiUt30bRTn2ALj8pUv fW0WmA+aAcDq+ZWD2emALy0lU69+0So=
X-Google-Smtp-Source: ABdhPJyRqdn3TBnsBt4+GztUr4h1n1TtgfdqBtrjGNerJf+erlWbyYlfsm5+BAYDr2s3i+LkJS4sXg==
X-Received: by 2002:a17:90a:7403:: with SMTP id a3mr4978343pjg.222.1592598171156; Fri, 19 Jun 2020 13:22:51 -0700 (PDT)
Received: from [192.168.178.30] (93.91.69.111.dynamic.snap.net.nz. [111.69.91.93]) by smtp.gmail.com with ESMTPSA id d25sm5683384pgn.2.2020.06.19.13.22.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 13:22:50 -0700 (PDT)
To: Russ Housley <housley@vigilsec.com>
Cc: Ben Kaduk <kaduk@mit.edu>, anima@ietf.org
References: <11428.1592266833@localhost> <a0face89-da68-f75d-4a57-4deb9d0f244d@gmail.com> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <40facb30-fde3-ae1c-b15c-d186da5c51c1@gmail.com>
Date: Sat, 20 Jun 2020 08:22: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: <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/HErNvrII4spJhRuW9ttWFhBHwPs>
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: Fri, 19 Jun 2020 20:22:54 -0000

Hi Russ,

I think everyone agrees that it's bending the purpose of a protocol element, for pragmatic reasons, and it isn't something I particularly like either. But it was a pragmatic choice made after discussing the alternatives.

Regards
   Brian

On 20-Jun-20 04:32, Russ Housley wrote:
> Brian:
> 
> I disagree with your characterization of the situation.  RFC 5280 talks about Subject Alternative Names, and the rfc822Name is used for an email address.  This specification puts something other than an email address in that field, and I raised a concern when I reviewed the document.  Other name forms are explicitly accommodated by otherName, and in my review, I suggested using otherName instead of rfc822Name.
> 
> I observe that jabber IDs have the same syntax as an email address, but they are not carried in rfc822name because the semantics are different.
> 
> One cannot send email to the character string in this specification, so it should not be carried in the rfc822name.
> 
> Russ
> 
> 
>> On Jun 19, 2020, at 1:11 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> Hi Ben,
>>
>> (Back on line after a couple of days spent moving apartments.)
>>
>> 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.
>>
>>>>> 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".
>>
>> 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.
>>>
>>> -Ben
>>>
> 
>