Subject: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 22 Jun 2020 10:43:00 +0000

As the shepherding AD for this document, I am happy to see recent technical discussions on this document. OTOH, I do not observe any convergence to remove the pending DISCUSS.

The 2nd IETF Last Call was completed 2 months ago in April 2020. Joel Halpern did the review for routing directorate and found a couple of issues (zone-ID, loopback definition) and it seems that there is now an agreement within the community for updated the text.

In order to progress the document, a revised I-D is needed to fix Ben’s DISCUSS points:

- Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use otherName (even with the section 6.1.2 justifications)

- “MTI cryptographic mechanisms are under-specified” that should not be controversial and easy to fix

- Clarification about the RPL root

Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on -16); but, this would be a plus to fix these points.

I understand that the authors have worked on this for 6 years and may be bored but I would love to see this I-D going forward. Again, as many others I fail to see the reason of using rfc822Name and the fix would be to use otherName.

May I also suggest to the authors to add new co-authors in order to have ‘fresh blood’ and energy ?

Regards

-éric

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 Jun 2020 20:31:16 -0700

Hi Éric,

> - Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use otherName (even with the section 6.1.2 justifications)

Russ has been helping reach out to more of the PKIX community; one
suggestion that came up so far is to consider defining a dedicated URI
scheme and using a uniformResourceIdentifier SAN -- did the WG consider
that in the initial discussions?

> - “MTI cryptographic mechanisms are under-specified” that should not be controversial and easy to fix

Toerless has been doing an incredible job reaching out to the IPsec
community and getting this text nailed down.  There are still a couple
points still under discussion but I'm confident that we will have something
good here (and IIRC the TLS stuff has already been polished).

> - Clarification about the RPL root

I'm pretty sure this is already done -- note that my latest ballot position
is only for the -19, so I think I just didn't update it yet.

> Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on -16); but, this would be a plus to fix these points.

Indeed.  I expect the current SEC ADs to review those when the document
comes up on a telechat again.

> I understand that the authors have worked on this for 6 years and may be bored but I would love to see this I-D going forward. Again, as many others I fail to see the reason of using rfc822Name and…

I do not want to put words in anyone's mouth, but my understanding is that
the "obvious alternatives" to otherName are believed to suffer from strong
deployment difficulties, whether one attempts to use an existing
(commercial, or so-called "public" CA) or COTS CA software to run one's own
CA.  (There is some question as to whether the "public CA" route is
advisable at all, given the legal agreements and policy documents
surrounding such CAs and whether issuing certificates intended for ACP use
is compatible with those policy documents.  Sean's review alluded to some
of these topics, and if you manage to catch Ryan Sleevi when he has time,
he can talk about them at length.)

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Jun 2020 08:51:20 +0200

Hi Ben

> On 23 Jun 2020, at 05:31, Benjamin Kaduk <[email-masked]> wrote:
> 

I don’t know if the group looked at this, but I can say that from a public CA standpoint, it’s not much different from otherName because there is a requirement to validate the name.  A new URI scheme would require a new resolution mechanism.  Perhaps that is needed as part of ACP anyway.  The one value of URI is that it is easier to configure in some of the tooling like OpenSSL.

What disturbs me about all of this is that public CAs will accept otherNames and produce garbage out.  That’s just asking for a boot to the head* from a vulnerability perspective.

Eliot

*https://www.youtube.com/watch?v=-V1Mn5-xF0w <https://www.youtube.com/watch?v=-V1Mn5-xF0w>
** (And one for Jenny and the whimp)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Jun 2020 05:01:48 -0700

On Mon, Jun 22, 2020 at 11:51 PM Eliot Lear <[email-masked]> wrote:

> I don’t know if the group looked at this, but I can say that from a public
> CA standpoint, it’s not much different from otherName because there is a
> requirement to validate the name.  A new URI scheme would require a new
> resolution mechanism.  Perhaps that is needed as part of ACP *anyway*.
> The one value of URI is that it is easier to configure in some of the
> tooling like OpenSSL.
>
> What disturbs me about all of this is that public CAs will accept
> otherNames and produce garbage out.  That’s just asking for a boot to the
> head* from a vulnerability perspective.
>

This would at present appear to violate the BRs. S 7.1.4.2.1 says:

Contents: This extension MUST contain at least one entry. Each entry MUST
be either a dNSName containing the Fully-Qualified Domain Name or an
iPAddress containing the IP address of a server. The CA MUST confirm that
the Applicant controls the Fully-Qualified Domain Name or IP address or has
been granted the right to use it by the Domain Name Registrant or IP
address assignee, as appropriate.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Jun 2020 14:49:30 +0200

> On 23 Jun 2020, at 14:01, Eric Rescorla <[email-masked]> wrote:
> 
> Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. 
> 
> -Ekr
> 

Oh it does the DV. It just adds garbage into the cert :-(

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Jun 2020 08:28:46 -0700

On Tue, Jun 23, 2020 at 5:49 AM Eliot Lear <[email-masked]> wrote:

>> I don’t know if the group looked at this, but I can say that from a
>> public CA standpoint, it’s not much different from otherName because there
>> is a requirement to validate the name.  A new URI scheme would require a
>> new resolution mechanism.  Perhaps that is needed as part of ACP *anyway*.

I'm talking about the second sentence, which requires that the SAN contain
only dNSName or IPAddress.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Jun 2020 17:35:44 +0200

> On 23 Jun 2020, at 17:28, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I'm talking about the second sentence, which requires that the SAN contain only dNSName or IPAddress.

Regardless, the garbage that is left in was the point of my note.

Eliot