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

["Eric Vyncke (evyncke)" <[e-mail]>]

Michael

Sorry for belated reply... My brain switched focus to IETF-105 and then holidays and I am afraid failed to switch back to your document.

Please find below some comments on your detailed reply to my DISCUSSes:
- lack of TLS version, I understand your comment. You suggestion to add some text (justification, clarification, ...) in Section 5.1 about the TLS version would be a plus (albeit a -27 would be required) but I am removing my DISCUSS
- section 2.3.1 and serial number: thank you for the clarified text => DISCUSS is cleared
- section 3.3 and examples: thank you for improving the text & example => DISCUSS is cleared
- section 4.1 and the 2 back-off mechanisms description: the new text is clear => DISCUSS is cleared
- section 4.3 and "IPPROTO_TCP, 80": using a different port number also fix my DISCUSS
- section 4.3 and ULA rather than documentation prefix => DISCUSS is clear

I have updated the datatracker with my new ballot position.

Regards and kudos to all authors for their patience and effort beind this document

-éric

On 10/07/2019, 21:26, "iesg on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

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