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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 03:25:17 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you (and so many friends in the authors' list!) for the work put into
this document; it took a while to get to this stage ;-) The intersection with
MUD is also a nice feature.

I have a couple of DISCUSSes (probably easy to fix) and _several_ COMMENTs and
some nits (after a couple of nits, I stopped marking them). I also stopped
writing COMMENTs after section 5.3.

Regards,

-éric

== 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.

-- 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".

-- 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.

-- 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.

-- 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 ?

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

-- Section 1 --

Please introduce the MASA acronym used after.

-- 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"

-- Section 1.2 --

Please use the RFC 8174 boilerplate.

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

- Section 1.5 --

Please explain/refer GRASP acronym.

-- Section 2 --

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

-- Section 2.2 --

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

-- Section 3.4 --

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

Please refer to RFC 8174.

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

-- Section 5 --

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

...

-- 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.

-- 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.

== NITS ==

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

-- Abstract --

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

-- 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/ ?

-- Section 2.3.2 --

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

....

-- 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?
(ok I am not an English native speaker so I can be wrong)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 15:26:31 -0400

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 <[email-masked]> 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?

    > 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.

    > It should also state that the cert is not included for saving space in
    > this document.

I have added serial-number to the example.

    > 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.

    > 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

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).

    > Please introduce the MASA acronym used after.

Done.

    > 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.

    > Please use the RFC 8174 boilerplate.

<insert old guy gripping about new-fangled things>

    > 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.

    > Please explain/refer GRASP acronym.

reference added.

    > 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.

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

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

    > 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.

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

Fixed.

    > 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.

    > But, IANA is of course the source of truth.

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

    > 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

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.

    > "Ethernet" or "Internet".

okay, fixed.

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

okay

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

agreed.

    > including ldap, http and ftp"

okay.

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

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-