Re: [Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Eric, thank you for the comments.

WG and other authors, please look for XXX as your point where
I'd like your input.

I will push a -23 on the 22nd when draft submissions open, unless you want it
faster.  Here is a pointer to get a diff between -22 and what is now
in github:  https://tinyurl.com/y2ex324x

I want to point to a thread that this document needs to Updates: RFC7030,
as it is extending the /.well-known/est namespace.  It would be great
to have the IESG's agreement on this, or suggest an alternative.

Éric Vyncke via Datatracker <[e-mail]> wrote:
    > == DISCUSS ==
    > TLS is assumed to be used but I failed to find WHICH version of TLS
    > MUST be used. The only reference in the reference section is version
    > 1.2. Probably worth to refer to this version in the text as well and
    > use version 1.3 of TLS.

First, in developing this protocol we thought a lot about some of the privacy
enhancements that TLS 1.3 could provide us, particularly around keeping the
identifying parts of the IDevID (present in the Certificate), and we thought
about >=1.3, but we did not want to tie things up for vendors.

We also considered strongly always having the JRC initiate the TLS, because
the ClientCertificate is sent first in TLS, and the JRC has no real privacy
needs.  We did not do this, even though there were strong requirements from
the 6tisch WG to give the JRC more control over enrollment order/bandwidth.

We decided to sit on the fence about TLS versions because Getting a TLS
version through an evaluation process and into a firmware for a BFR wasn't
something we wanted to gate BRSKI upon.

As such, we think we are happy with any version of TLS that the TLS WG
recommends. We further recognize that Registrar's MAY have to be willing to
talk to versions which are older than whatever is considered secure that
year.  A device that has been in a box in a warehouse won't have the latest
patches, and it won't have the latest patches until it goes through an
onboarding process.

The alternative is a truck roll, a USB stick, and some gum.

We reference RFC7030, and it's section 3.3.1 says TLS 1.1 (now considered
old), but we didn't like that it even specified what is now an obsolete
cipher suite.  That's one reason we felt that we shouldn't overspecify:
that's the TLS WG's job.

It would be nice to be able to point to a STD XX for this.

Would you like us the add something in section 5.1?

    > -- Section 2.3.1 --

    > Does the "serial number" need to be unique per vendor ? I guess so then I
    > strongly suggest to use a different word than "serial number"
    > (e.g. unique device ID) as a vendor can have multiple products in its
    > portfolio, each having a different set of unique "serial numbers".

We are leverging the serialNumber attribute from 802.1AR (and
RFC5280).  Since this is an attribute in a certificate's DN, it's uniqueness
is defined by the issuer of the certificate.  Different issuer public keys
would have different serialNumber namespaces.  Since the voucher-request
is signed by the IDevID, that value is also within the IDevID issuer's
namespace.

A vendor that operates different signing authorities for different products
could decide to keep it's serialNumbers unique across all products. I would
certainly recommend that, but from a technical point of view, unnecessary.

    > -- Section 3.3 --

    > The example 1 does not include the mandatory (per YANG module)
    > serial-number.
    > It should also state that the cert is not included for saving space in
    > this document.

I have added serial-number to the example.

    > -- Section 4.1 --

    > There are TWO back-off mechanisms: one for the method and one for the
    > proxy but
    > no description on how those mechanisms interact together.

The first back-off is for the active methods of discovery.
(Those methods are optional, GRASP M_FLOOD is the MTI)

The second back-off is for attempts to connect to a specific proxy.
I don't see an interaction or an issue. The timers are separate.
Maybe you can explain your concern?

If we see M_FLOOD messages from a new proxy, then we'd start (immediately)
trying that new connection, even if there are TCP half-open connections to
via proxies.


    > -- Section 4.3 --

    > Probably a naive question about GRASP (that I do not know), but in the
    > example there is "IPPROTO_TCP, 80" that seems to indicate the use of
    > plain HTTP and no TLS at all. Is it an issue ?

Yes, I agree that is confusing.  It can be 443,, or actually any port that
the registrar chooses.  Are you okay with 8443 to emphasize that
it is arbitrary?

    > Is there a reason why IPv6 ULA are used rather than the documentation
    > prefix ?

yes, we assume that this communication runs over ANIMA's ANI ACP.
The ACP is explicitely numbered in ULAs, and we felt that using a GUA
(which the documentation prefix is), would confuse people, particularly
security people, into thinking that parts of the protocol run over the
open internet.

If have considered that we ought to have a documentation ULA prefix,
and we could allocate that out of the ULA-"C" space (fc00::/8).

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > == COMMENTS ==

    > -- Section 1 --

    > Please introduce the MASA acronym used after.

Done.

    > -- Section 1.1 --

    >> the pledge requires realtime connectivity to the manufacturer
    >> service

    > Why this connection requires "realtime" ? Esp when reading in section
    > 1.3.1  "The bootstrapping process can take minutes to complete"

realtime as opposed store and forward, via, for instance USB key
or email over UUCP.

    > -- Section 1.2 --

    > Please use the RFC 8174 boilerplate.

<insert old guy gripping about new-fangled things>

    > "160-bit SHA-1 hash" I will let the security AD to check whether SHA-1 is
    > deemed sufficient for this purpose.

RFC5280 uses it, and we don't have a common replacement for this
(or even a good name for it).  It is only used in the audit log to identify
previous owners.  We could easily add a second hash to the audit log.

    > - Section 1.5 --

    > Please explain/refer GRASP acronym.

reference added.

    > -- Section 2 --

    > I wonder what will happen when the device vendor stops maintaining the
    > MASA on-line?

please see flamewar^Wsec-dir review thread last fall :-)
   https://mailarchive.ietf.org/arch/msg/anima/XCS6JpwQSm3naOivwCYaO0AAsVs

We added most of section 10 on this.
In particular section 10.5 suggests that a manufacturer could permit the MASA
anchors to be replaced and/or augmented.  This divorces the device entirely
From the manufacturer.  An operator that goes this way probably should have
source code: but that's no longer unreasonable for many platforms that
provide virtualized services.

    > -- Section 2.2 --

    > Out of curiosity, why this document uses the word "voucher" as opposed to
    > "ticket" ?

Not sure, but I'd have argued against ticket because BRSKI/RFC8366 vouchers
are significantly less functional than Kerberos tickets.

    > -- Section 3.4 --

    > I find a little weird that the included YANG module has a different
    > authors list than the document itself.

A good point. Steinthor changed jobs before we got fully into the YANG
modelling.  Kent did most of heavy YANG lifting, so we put him first,
but I've sorted the rest alphabetically.

    > Please refer to RFC 8174.

    > "RFC YYYY: Voucher Profile for Bootstrapping Protocols" does not seem
    > correct in a YANG module reference.

Fixed.

    > -- Section 5 --

    > The MASA URI synthesis explanation is a duplicate of a previous
    > explanation.
    > Unsure whether it helps the reader.

We included it in both section 5 and section 2.3.2, because in interop
testing, we noticed that implementors of Registrar's often do *not* read the
part about MASA operations, and VV, the IDevID certificate authority
programmer is unlikely to understand section 5.

    > -- Section 8.4 --

    > I am afraid that the DNS service names have a length of maximum 15
    > characters.
    > But, IANA is of course the source of truth.

XXX
We have heard from IANA, and they did not complain as yet.

    > -- Appendix A --

    > Using IPv6 LLA should be enough, I do not see the reason to describe a
    > new protocol using legacy IPv4 addresses because IPV6 link-local
    > addresses should
    > work on any decent layer-2 network.

XXX:
I personally have no objection to ripping out that legacy 1980s crap :-)
I was happy to relegate it to a non-normative appendix.
I'm gonna let the other authors and WG argue this point.

    > == NITS ==

    > A lot of "ethernet" and "internet" while those words are usually
    > capitalized as
    > "Ethernet" or "Internet".

okay, fixed.

    > -- Abstract --

    > Shouldn't the plural form used in "using manufacturer installed X.509
    > certificate" ?

okay

    > -- Section 1.5 --

    > s/Some of the options in this document is the result of
    > requirements/Some of
    > the options in this document are the result of requirements/ ?

agreed.

    > -- Section 2.3.2 --

    > Please use uppercase in the protocol acronyms in "that MUST be supported,
    > including ldap, http and ftp"

okay.

    > ....

    > -- Section 5.1 --

    > "A Pledge that can connect to multiple registries concurrently, SHOULD
    > do so."

    > lower case for pledge and what is the purpose of the comma in this
    > sentence?

we had a mania at some point that argued that Pledge was a proper noun.
We recovered from it.

I think that comma belongs; maybe it SHOULD be a semi-colon.
I'm happy to let the copy-editor argue it.  I think that it seperates
out a qualifying noun phrase.

    > (ok I am not an English native speaker so I can be wrong)

ps: here is a video of the protocol from another non-native English speaker:
      https://vimeo.com/305041755


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-