Re: [Anima] We want BRSKI and ACP!

Benjamin Kaduk <kaduk@mit.edu> Wed, 11 March 2020 19:06 UTC

Return-Path: <kaduk@mit.edu>
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 A8DA33A00C1 for <anima@ietfa.amsl.com>; Wed, 11 Mar 2020 12:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Level:
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1F4sD2T31fKL for <anima@ietfa.amsl.com>; Wed, 11 Mar 2020 12:06:40 -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 808E03A00B0 for <anima@ietf.org>; Wed, 11 Mar 2020 12:06:40 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02BJ6RtG012014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Mar 2020 15:06:29 -0400
Date: Wed, 11 Mar 2020 12:06:27 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Warren Kumari <warren@kumari.net>, Anima WG <anima@ietf.org>, evyncke@cisco.com
Message-ID: <20200311190627.GG98042@kduck.mit.edu>
References: <8e18470b-1d6a-19f1-efb2-bc2e72ef2665@gmail.com> <6011.1583935076@localhost> <20200311151744.GA24905@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200311151744.GA24905@faui48f.informatik.uni-erlangen.de>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/5U2SmTA6VXeDkQvaTQ8KiwkykFU>
Subject: Re: [Anima] We want BRSKI and ACP!
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: Wed, 11 Mar 2020 19:06:43 -0000

Hi Toerless,

On Wed, Mar 11, 2020 at 04:17:44PM +0100, Toerless Eckert wrote:
> Thanks, Michael
> 
> Brian,
> 
> At IETF106 i thought if Bens review would remove all discuss, we would have
> finished IESG review, but that is not the case because two of the
> IESG members that had approved ACP draft have since left office, so
> their votes do not count. I did report that at ANIMA WG @IETF106.
> 
> At IETF106 we had both the ACP report from me of -21, as well as Ben's
> presentation on the main issue he saw, the encoding of the ACP
> domain information field in the certificate.
> 
> While i had hoped that the in-person discuss about that issue would
> resolve that discuss because we did explain all the argments for it,
> his discuss of -21 on 12/30/2019 did i think not change his position,

I had also hoped that, though it did at least give me a better
understanding of the situation and the interplay amongst the various
pieces.

> instead it also mentioned IPsec experts supporting that view, but
> without a technical explanation why, or who all those experts where.

I think it's more of a matter for PKIX experts (e.g., LAMPS WG) than IPsec,
since it relates to X.509 certificate contents.

I've asked Russ Housley to take a closer look and produce some comments,
and have a todo item to get another expert or two to opine.

> In January, i worked on -22 to answer to Bens review of -21. which i
> published 02/03/2020. For the encoding issue i rewrote the bullet
> points justifying the choice of encoding, primarily pointing to the
> fact that rfc822 names are nowadays quite common identifiers in a
> lot of e.g.: web systems, in addition to all the benefits of avoiding
> new or extensions to certificate parsing libraries and the like.
> 
> Through IETF106 and writeup of -22 i even think more this
> is a pragmatic, prudent and logical choice, and i couldn't find
> anything in the cert related RFCs i read that seemed to contradict this for me.

I'll also mention again that there are procedures in place that can allow a
document to proceed even with a "holdout" Discuss position such as mine:
per https://www.ietf.org/standards/process/iesg-ballots/ the sponsoring AD
can request the "Single Discuss" procedure be used, or ask the chair to
invoke the "Alternate" ballot procedure.

> In February, Ben had told me, that -22 resolves his other points,
> except that that he continues on his position re. the encoding.
> But there was also security profile work improved in -22.

I'm very happy to see those improvements and the exchanges with the IPSECME
WG; thank you again for driving that!

-Ben

> Shortly after IETF 106, Eric Vyncke took over as sponsoring AD for
> ACP. He provided a review with 72 comments in january to the authors.
> After i finished -22, i worked on these 72 points through february and posted
> -23/24 last week.
> 
> In addition, during february, i also started to reach out to IPsec
> mailing list to further discuss details of the proposed enhancements
> to the IPsec profile. I ran out of time last week, and plan to
> finalize those fixes quickly (together with the WG fix sugestions i
> received for -24).
> 
> In addition, i will also reach out directly to the IPsec experts
> i know and ask for the rfc822name encoding. I did that already
> last year, but never received replies.
> 
> Eric told me, he wants to put ACP back onto the IESG agenda for April,
> and this would result in a new IETF review.
> 
> Thats all i know.
> 
> Cheers 
>     Toerless
> 
> On Wed, Mar 11, 2020 at 09:57:56AM -0400, Michael Richardson wrote:
> > 
> > Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> >     > Could those on the hook for the ACP and BRSKI drafts, which have been
> >     > very seriously delayed, update the WG with the plan for getting them
> >     > approved? It seems to me that there has been endless nitpicking, of the
> >     > kind that is appropriate for full Standard status, but very surprising
> >     > for Proposed Standard where there is no expectation of perfection.
> > 
> > I don't know what kind of plan I can relate: It seems to be above my pay grade.
> > 
> > For BRSKI, since IETF106, all DISCUSSes, except Ben Kaduk's desire to have
> > the examples redone have been cleared.  I had originally tagged redoing that
> > for AUTH48 time, since all IANA allocations would be done by then.
> > All allocations have been done at this point, and in January I redid the
> > examples in the non-normative Appendix with the right OIDs.  Ben found some
> > errors (one repeated certificate), and so I generated the examples again.
> > 
> > I then asked Jim Schaad and Max Pritikin (a BRSKI co-author, who has been
> > redirected on other important Cisco work), to validate.  Max reviewed, and
> > this resulted in an additional clarifiying sentence committed to the github.
> > (I thought I posted it on Monday, I don't seem to have. I will do that now.
> > 
> > Warren Kumari has taken over as the sponsoring AD.
> > 
> >     > Can we expect these drafts to be approved in the next one or two weeks,
> >     > for example? If not then, when?
> > 
> > I know that ACP has gone through a similar set of DISCUSSes, and I think that
> > they are mostly all done.
> > I don't see an update from Ben.
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/
> > says that most have No Objections, rather than Yes. Three YES are needed to
> > override a DISCUSS.
> > I guess this document has been in front of the IESG since 2018 when Terry was
> > an AD!
> > 
> > I think that the WG participants need to actively engage the DISCUSSes and
> > the choices that the WG has made.
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 
> 
> 
> 
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> 
> 
> -- 
> ---
> tte@cs.fau.de