Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Fri, 13 Dec 2019 05:31:29 -0500

Hi Michael,

I have not seen a response to Tom Petch’s last email (copied in below).

Thanks,
Alissa

> Begin forwarded message:
> 
> From: tom petch <[email-masked]>
> Subject: Re: [Last-Call] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28
> Date: October 29, 2019 at 7:49:39 AM EDT
> To: Michael Richardson <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alissa Cooper <[email-masked]>, Last Call <[email-masked]>, Dan Romascanu <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Michael
> 
> I just saw -29 after my last message and it still needs work.
> 
> Appendix C confuses me.  The reference to it from IANA Considerations
> suggests that it is Normative but there is nothing in it to say that it
> is and my take is that by default it is Informational.
> 
> It contains a YANG module which
> - lacks references on import statements
> - lacks authors
> - lacks copyright
> - is not listed in IANA Considerations
> - has http: not https:
> - has a reference clause with a different title to that of the I-D
> - mixes URI and URL
> all in 35 lines :-)
> 
> The YANG module in s.3.4
> - references RFC8040 which is not in the I-D References
> - references
>  Voucher Profile for Bootstrapping Protocols
> whereas this I-D has a title of
>  Bootstrapping Remote Secure Key Infrastructures (BRSKI)
> - has
>  // Grouping defined for future usage
> whereas the grouping is used in the previous YANG statement which leaves
> me puzzled
> - lacks YANG reference statements for
>          leaf proximity-registrar-cert {
> i.e. RFC5280, X.690, RFC8446
> - has [RFC8446] which looks like an XML/HTML anchor where a YANG module
> must be plain text
> 
> - IANA Considerations does not register either module, 3.4 or Appendix
> C, as per RFC6020 s.14
> 
> - Security Consideratrions does not include the required YANG
> considerations which in turn generates further Normative References
> 
> - Appendix A
> /The secification/The specification/
> 
> Tom Petch

> On Nov 26, 2019, at 3:29 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> Hi Alissa, just a reminder that the -30 draft posted during IETF week
> resolves the Yang Doctor issue that you had raised.
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Dec 2019 14:56:18 -0500

{Hi Tom, I don't quite understand, but I don't seem to get emails directly
From you.  Or perhaps it has to do with it being posted through the
datatracker.  This is not the first review I have missed in this way.}

We had forgotten about the content of Appendix C, which is not normative.
It stems from an era when we were not sure how successful RFC8520 will be.

I have issued version -31 in which we remove Appendix C rather than fix it.

This extension could be added correctly at a later date, and at this point,
we don't see the MUD FILE->MASA URL flow as particularly important.

Both URLs can be in the IDevID if needed, at the cost of bytes in the IDevID
certificate.

I think that there are operational problems with embedding the MUD URL in the
IDevID relating to firmware upgrades, nor is that related to this appendix.
It is not a BRSKI issue, but it does mean that the likelyhood of a MUD URL
being the only extension that can be afforded an IDevID is significantly less
likely.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 Dec 2019 15:08:35 -0500

Thanks Michael. Should Section 8.1 now be removed as well?

Alissa

> On Dec 16, 2019, at 2:56 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Dec 2019 11:55:01 +1300

> Thanks Michael. Should Section 8.1 now be removed as well?

I think that's a good catch.

FYI and largely irrelevant, I did lash together some code at the
IETF106 hackathon using GRASP to communicate a MUD URL to the
network management system. So if we need to integrate MUD handling
into the ANIMA infrastructure, there's already a proof of concept,
without complicating BRSKI.

   Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: tom petch <[email-masked]>
Date: Tue, 17 Dec 2019 17:19:08 +0000

Michael,  my initial posts were a response to the Genart review and so 
did not include your name, just Anima, Anima chairs, ibagdona, IETF; you 
are in this one as [email-masked] (but IETF mailers may have a 
habit of thinking you will get an e-mail via one way and suppress other 
ways with different e-mail addresses).

Yes you have removed the second YANG module which addresses my comments 
about the second YANG module but my other comments mostly remain.  Those 
about the YANG prefix are fixed.

RFC8040  needs to be in the I-D References

IANA Considerations mentions the removed module but lacks the two 
required actions for the remaining module

XXXX is used as a place holder for a document name which is not that of 
this I-D and does not exist AFAICT

The YANG module must be plain text - [RFC8446] looks like HTML/XML

Security Considerations lacks the required boiler plate for a YANG module

Appendix A still has a typo

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2019 15:29:05 -0500

> Thanks Michael. Should Section 8.1 now be removed as well?

I thought that I got it, but I see that I didn't git commit that part.

I have removed it, and I'll post that in a day, once I hear from Roman and
Ben about whether they feel I am done with their comment stream.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: tom petch <[email-masked]>
Date: Thu, 19 Dec 2019 12:45:28 +0000

Michael

Just to reiterate.

For a YANG module, you MUST have two IANA actions to register the 
namespace and the module itself so removing s.8.1 fixes one problem but 
leaves two outstanding.  Details in YANG Guidelines or in any other 
I-D/RFC with a YANG module

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Dec 2019 14:37:55 -0500

A diff against -31 is at:  https://tinyurl.com/vuls2ge
and will grow to include my responses to Ben's 2019-12-20 comments later today.

tom petch <[email-masked]> wrote:
    > about the second YANG module but my other comments mostly remain.
    > Those about the YANG prefix are fixed.

    > required actions for the remaining module

I understand now.  I wonder if idnits could be taught to find such issues :-)
Please see commit:
 https://github.com/anima-wg/anima-bootstrap/commit/75d7ef8a78b2c03cd2e558705861194357f1e643

    > this I-D and does not exist AFAICT

Do you mean the self-reference should say "XXXX"?  I have used "THIS
DOCUMENT" in the past.

I'm confused by this comment. I see:

    > did not include your name, just Anima, Anima chairs, ibagdona, IETF;
    > you are in this one as [email-masked] (but IETF mailers may have
    > a habit of thinking you will get an e-mail via one way and suppress
    > other ways with different e-mail addresses).

Yes, I wasn't complaining about your actions, but more just lamenting: my
impression is that the problem is that DMARC is getting in the way, since the
DT acts as a remailer.   However, btconnect.com has a p=none policy, so it
shouldn't be a problem... however, maybe it fails the SPF tests themselves.
{I was forced to switch spam processing systems in the spring, and it really
has been a PITA to get it configured sensibly.  Very few of them support
IPv6, and a surprising number of them will not use TLS for final delivery.
I specifically need to whitelist everything coming from the IETF SMTP machine,
and I don't think I've accomplished that perfectly yet.}

        leaf proximity-registrar-cert {
          type binary;
          description
            "An X.509 v3 certificate structure as specified by RFC 5280,
             Section 4 encoded using the ASN.1 distinguished encoding
             rules (DER), as specified in ITU-T X.690.

             The first certificate in the Registrar TLS server
             certificate_list sequence  (the end-entity TLS certificate,
             see [RFC8446]) presented by the Registrar to the Pledge.
             This MUST be populated in a Pledge's voucher request when a
             proximity assertion is requested.";
        }

I'm not sure I see how you are seeing HTML here.
If you are looking at:
  https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-31#section-3.4
then the links you are saying are because the HTMLizer sees the reference and
HTMLizes it.

    > Security Considerations lacks the required boiler plate for a YANG

I see. I have adapted the text from RFC8366, as we extend it, and the normal
template does not apply.

Fixed in commit:
  https://github.com/anima-wg/anima-bootstrap/commit/c138bbd24db038f0704770b545e74ba202a98e4e

    > Appendix A still has a typo

secification -> specification. plege->Pledge.

---

From: tom petch <[email-masked]>
Date: Tue, 31 Dec 2019 21:22:31 +0000

Michael

My e-mail has been rendered almost unusable so I struggle (I cannot 
access the I-D or much else from this PC:-(

My comment about XXXX is that you ask RFC Editor to supply the RFC 
number for an I-D with a name you give but that name is not the same as 
the name at the front of the I-D:-(

When I see [RFC8446] those square brackets make me suspect HTML/XML 
which must not appear in the YANG module which must be plain text.

Security Considerations, the YANG Guidelines RFC says that you must 
mention TLS, HTTPS, etc and give pro forma text for doing so.  As long 
as you still have a YANG module, as you do in s.3.4, I would expect 
those guidelines to apply and so to see something like the pro forma text

HTH

tom petch

with apologies to the IESG for all this noise - I would like to drop 
them from the Cc: list but do not quite dare.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Dec 2019 17:01:34 -0500

tom petch <[email-masked]> wrote:
    > Security Considerations, the YANG Guidelines RFC says that you must mention
    > TLS, HTTPS, etc and give pro forma text for doing so.  As long as you still
    > have a YANG module, as you do in s.3.4, I would expect those guidelines to
    > apply and so to see something like the pro forma text

Please see:
       https://www.rfc-editor.org/rfc/rfc8366.html#section-7.4

TLS is already specified and discussed at length in the document.
If you want me to copy the second paragraph from there in, I can do that, but
it seems like needless text.  You can't implement BRSKI without reading
RFC8366.