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

[Michael Richardson <[e-mail]>]

https://tinyurl.com/yylruorn contains a diff against -24.

Benjamin Kaduk via Datatracker <[e-mail]> wrote:
    > [disclaimer: some of these comments get pretty blunt at the end; it's a
    > long document and I'm tired.  Please try not to get too annoyed if I'm
    > failing to see something that's right in front of me.]

    > I concur with the directorate reviewers that expected a
    > high-level security analysis of what information flows where, and what
    > policy choices can be made that affect it.  At a *very* high level
    > (skipping over a lot of things that I would expect to see), this would
    > be structured like:

    > On initial bootstrap, a new device uses local service autodiscovery to
    > locate a (proxy to a) local registrar.  Having found a candidate

I have included an edited version of this text. It was very well done, thank
you!

    > Abstract

    > (side note?) Is there a quick explanation of why bootstrapping can
    > complete with just installation of the PKI (trust anchor?) and
    > provisioning a locally issued certificate is not mandatory?

I don't think that we can fit a quick explanation into the Abstract.
I did split up the last sentence.

The hard thing that BRSKI provides is the trust of the network by the pledge.
The trust of the device by the network is generally an "easy" problem solved
by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
users.
So I'm not sure what further to do here.

    > Section 1

    > This document describes how pledges discover (or be discovered by) an
    > element of the network domain to which the pledge belongs to perform
    > the bootstrap.  [...]

    > nit: s/be/are/, IIUC.
    > I think there's also something funky with the wording of "to perform the
    > bootstrap"; we may be looking for an element "that will perform the
    > bootstrap".

yes, done.

    > 4.  Pledge authorizing the registrar: "Should I join it?"

    > nit: what is "it"?  Surely not the registrar, and presumably the
    > "network domain" in question?

yes, it = "network"

    > This document details protocols and messages to answer the above
    > questions.  It uses a TLS connection and an PKIX (X.509v3)
    > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
    > points 1 and 2.  It uses a new artifact called a "voucher" that the

    > I'm kind of confused by "[IDevID] LDevID", since my understanding was
    > that the LDevID is issued only after all four steps are complete.

Yes, that seems to be a typo.

    > Also, following the IDevID link lands me at a page that claims to be for
    > a standard of status "superseded".

Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
I don't have a copy, and the getieee program just goes in loops of logging
in, or results in servlet errors.
I even emailed support, and they were basically useless.
{fetching coffee to avoid rant}

    > nit: one can use X.509v3 without being PKIX, and it's not entirely clear
    > that the IDevIDs will chain up to the Internet PKI.

You didn't respond to my suggestion that PKIX!=Internet PKI.
I do think that we want many things the IETF PKIX WG has produced
since X.509v3, so I don't think that X.509v3 is an appropriate noun
to describe things.

    > Section 1.2

    > RFC 8174 has an updated version of the BCP 14 boilerplate.

done already.

    > I'd suggest adding "MASA Audit Log" as a defined term to give advance
    > warning that this is an explicit protocol feature.

added.

    > domainID:  The domain IDentity is the 160-bit SHA-1 hash of the BIT
    > STRING of the subjectPublicKey of the pinned-domain-cert leaf,
    > i.e. the Registrars' certificate.  This is consistent with the
    > subject key identifier (Section 4.2.1.2 [RFC5280]).

    > What would it take to move away from SHA-1 for this purpose?  It's
    > unclear how long it will be before finding a second preimage of the SPKI
    > hash is feasible and thus using it as an identifier no longer serves to
    > uniquely identify something.

This was asked by Eric as well.
It's the Subject Key Identifier that we want.
     https://tools.ietf.org/html/rfc5280#section-4.2.1.2

It's only guaranteed to exist in CA certificates.
Do you think we can demand that the extension be present in IDevID?
If so, we could just use that value in the MASA Audit Log.
But, if we did, it would often still be the SHA-1 hash of the public key, but
RFC5280 says:
        "Other methods of generating unique numbers are also acceptable."

When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage,
it didn't specify a way to identify keys with SHA-2, although the mechanism
is pretty clear.

    > enrollment:  The process where a device presents key material to a
    > network and acquires a network specific identity.  For example

    > nit: hyphenate "network-specific".

ok.

    > Section 1.4

    > As a result of the protocol described herein, the bootstrapped
    > devices have the Domain CA trust anchor in common.  An end entity
    > certificate has optionally been issued from the Domain CA.  [...]

    > This end-entity certificate is supposed "to authenticate each
    > bootstrapped device to other parties in the domain", right?

    > The major beneficiary is that it possible to use the credentials
    > deployed by this protocol to secure the Autonomic Control Plane (ACP)
    > ([I-D.ietf-anima-autonomic-control-plane]).



    > I might humbly suggest "major intended beneficiary", as there seem to be
    > many possibilities involving BRSKI.

ok

    > Section 1.5

    > The pledge must perform discovery of the proxy as described in
    > Section 4.1 using GRASP M_FLOOD announcements.

    > Is this DULL GRASP or full-on ACP GRASP flooding?

DULL GRASP, word inserted.

    > Upon successfully validating a voucher artiface, a status telemetry
    > MUST be returned.  See Section 5.7.

    > nit: artifact (right?)

previously fixed.

    > The ANI Join Registrar ASA MUST support all the BRSKI and above
    > listed EST operations.

    > nit: probably need to expand ASA the first time.

done.

    > Section 2

    > The text following Figure 1 suggests that the Domain Registrar is not
    > always (also) a PKI RA, but the parentheticals in the figure itself are
    > easy to read as a clarification and not an optional thing, especially
    > since parentheticals are used in a different manner for the Key
    > Infrastructure box.

text:      Optionally the registrar also acts as a PKI Registration
           Authority.

I think that the text should read:
           Optionally the registrar also acts as a PKI Certification
           Authority.



    > Section 2.1

    > 3.  Request to join the discovered registrar.  A unique nonce is
    > included ensuring that any responses can be associated with this
    > particular bootstrapping attempt.

    > But the nonce is not always present!

I have been thinking hard about this problem, and I agree it is hard to
understand here.  Part of the issue is that the decision as to when and how
to accept nonceless non-expiring ("offline") vouchers is a complex question,
but it's also a private decision between the manufacturer's MASA and
the manufacturer's device.

The non-expiring nonceless voucher is a bit like kryptonite: once the
manufacturer signs such a thing, it pretty much trumps everything else.

I think that we need to add a section on nonce-less offline operation.

    > 5.  Enroll.  After imprint an authenticated TLS (HTTPS) connection
    > exists between pledge and registrar.  Enrollment over Secure
    > Transport (EST) [RFC7030] is then used to obtain a domain
    > certificate from a registrar.

    > Isn't this step optional?

so, I can change the word to "can" rather than "is"

    > Section 2.2

    > A voucher is a cryptographically protected artifact (a digital
    > signature) to the pledge device authorizing a zero-touch imprint on
    > the registrar domain.

    > nit: "using a digital signature"

ok.

    > Vouchers provide a signed but non-encrypted communication channel
    > among the pledge, the MASA, and the registrar.  The registrar
    > maintains control over the transport and policy decisions allowing
    > the local security policy of the domain network to be enforced.

    > nit: is there supposed to be a comma after "policy decisions" (in that
    > both the transport and policy decisions allow for policy enforcement)?

okay.

    > 1.  Uniquely identifying the pledge by the Distinguished Name (DN)
    > and subjectAltName (SAN) parameters in the IDevID.  The unique
    > identification of a pledge in the voucher objects are derived
    > from those parameters as described below.

    > These unique identifiers can (by design) be used for tracking, so let's
    > be sure that we talk about any privacy considerations with them, later.
    > I see a mention in passing in Section 10.2, at least...

Are you asking for a forward reference to 10.2?  I will add this.
I think that section 10.2 is pretty clear about this.
I don't think it's mentioned just in passing.

    > 3.  Secure auto-discovery of the pledge's MASA by the registrar (see
    > Section 2.8).

    > I don't think this is an ironclad property, since the crypto chain is
    > slightly limited and you are in effect trusting the pledge to hand you
    > something that says "use this issuer" but without as much crypto to back
    > that up as we might want.  We have to know that the given manufacturer
    > that signed the IDevID actually is associated with the device we're
    > trying to bootstrap, which can probably be arranged but I don't remember
    > being called out explicitly.

There are two issues here.

One is the question of what is the list of acceptable manufacturers (below).
The second part is whether a pledge could provide a fake IDevID to
the Registrar.  The pledge is doing TLS ClientCertificate, so the TLS
has proven that the pledge has the private key corresponding to the
certificate presented.  I conclude that an arbitrary IDevID can not be
provided by the Pledge; it has to be linked to SOME manufacturer. Some
manufacturer A could point it's product at MASA B, but I don't see how this
is an issue if MASA B will issues vouchers that pledge A can verify.

(The pledge could have a variety of certificates from
a variety of sources, perhaps all bound to the same public key, I guess, and
since the Registrar sends it's certificate first, the pledge could present
different identities to different networks. I think that this is a feature,
not a bug.  It reminds that "Kenmore" brand appliances were made by a variety
of manufacturers, but I don't see my dishwasher can know what identity
to use until after there is communication with the MASA)

The question then becomes how the Registrar comes to trust/verify the
pledge's IDevID.  We had a long discussion about this during the directorate
reviews and going back to Feb. 2018.  I thought that we resolved this.
Issues
  https://github.com/anima-wg/anima-bootstrap/issues/120
  https://github.com/anima-wg/anima-bootstrap/issues/43
  https://github.com/anima-wg/anima-bootstrap/issues/46
A thread starts here:
  https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs

Some changes that we made for this:
  https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54

    > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
    > extensions in the IDevID certificate.  Any restrictions included

    > I only got my hands on the 2018 rev of [IDevID], but that one does not
    > actually talk about extendedKeyUsage.

Max was the editor of the 2009 edition, and we pointed at it.
I don't seem to be able to get the 2018 edition.

7.2.13:

  7.2.13 extensions

  The optional extensions field defined in RFC 5280 shall not be used for
  critical extensions in any IDevID credential with the exception of the
  keyUsage extension. The non-critical extensions included are specified
  in 7.2.5 (authorityKeyIdentifier) and 7.2.9 (subjectAltName).
  The key usage field defined in RFC 5280 is intended to restrict the
  associated key material to only the
  specified usages. The intention of an IDevID is to provide a long lived
  credential useful for identifying the
  device in any future protocol uses. Restrictions applied during issuance may
  limit the future usefulness of
  the DevID. If a critical keyUsage extension is included in the IDevID, it
  shall include digitalSignature as
  defined in RFC 5280. The keyUsage extension may include keyEncipherment.
  The optional extensions field defined in RFC 5280 should not be used for
  critical extensions in any LDevID
  credential. As specified in RFC 5280 a network solution that uses the LDevID
  credentials and encounters a
  critical extension it does not understand will signal an error and fail
  validation of the LDevID credential.

I don't know why this advice against EKU is gone from the 2018 edition.

    > Section 2.3.1

    > In the context of BRSKI, pledges are uniquely identified by a
    > "serial-number".  This serial-number is used both in the "serial-
    > number" field of voucher or voucher-requests (see Section 3) and in
    > local policies on registrar or MASA (see Section 5).

    > (editorial) if the IDevID is supposed to be a unique identifier, why do
    > we need another one?

The pledge extracts it from it's IDevID.
The registrar extracts it again from the IDevID that it sees.
It's seems hard to construct an attack where the provisional TLS connection
is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders
here.... the cross-check seems useful, but maybe in the end, it's a left-over
From when voucher-requests could be unsigned.

    > o  The subject field's DN encoding MUST include the "serialNumber"
    > attribute with the device's unique serial number.  (from [IDevID]
    > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
    > attributes)

    > side note: I had to think a  bit to convince myself that DN is the right
    > thing here; when we use dnsNames it's preferred to put them in
    > subjectAltName to avoid having to pick a preferred/privileged one, but
    > the serial number does seem to be in a privileged position for
    > distinguishing the subject.

The dnsNames are hard to use when we have no FQDN to attach to :-)

    > o  The subject-alt field's encoding MAY include a non-critical
    > version of the RFC4108 defined HardwareModuleName.  (from [IDevID]
    > section 7.2.9) If the IDevID is stored in a Trusted Platform
    > Module (TPM), then this field MAY contain the TPM identification
    > rather than the device's serial number.  If both fields are
    > present, then the subject field takes precedence.

    > "if both fields are present", but the subject field MUST be present, so
    > this field can never take precedence.

I'm willing to drop, because I never got proper clarification.
We were told by implementors that if the IDevID is contained in a TPM that
the resulting IDevID often has the serialNumber of the TPM,not the device
itself.

*** MAX ***

    > 1.  [RFC4519] section 2.31 provides an example ("WI-3005") of the
    > Distinguished Name "serialNumber" attribute.  [RFC4514] indicates
    > this is a printable string so no encoding is necessary.

    > I don't understand why these references were chosen.  Why are LDAP specs
    > authoritative about what the encoding format for the serialNumber DN
    > attribute is?  E.g., one could look at RFC 5280 to see that
    > X520SerialNumber is a PrintableString.

*** MAX ***

    > 2.  The HardwareModuleName hwSerialNum OCTET STRING.  This value is
    > base64 encoded to convert it to a printable string format.

    > Please cite Section 4 of RFC 4648 (unless you mean base64url, in which
    > case use Section 5).
    > Also, it might be nice to somehow (maybe enumerate the first list in the same
    > way) tie these two items to the respective subject ND/subjectAltName
    > fields, to clarify why these are the only two choices.

    > As explained in Section 5.5 the Registrar MUST extract the serial-
    > number again itself from the pledge's TLS certificate.  [...]

    > To be clear, this is still the device's IDevID certificate, that just
    > happens to be getting used as a TLS client certificate.

Yes, that's right.

    > Section 2.3.2

    > nit: maybe put a blank line after the IMPORTS are over?

done.

    > Section 2.4

    > In Figure 3, I had to think a bit to figure out whether the text that
    > did not fit mid-arrow was supposed to apply to the arrow above or below
    > the text (e.g., "optional: mDNS query RFC6763/RFC6762").

Yes... we did struggle to fit it into a single page.
It applies to both the arrow above and below, and there are M_FLOOD
and mDNS possible here.  Do you have suggestions on making it clearer.

    > [Hmm, so we send our TLS client cert on the provisional connection,
    > meaning that we have to trust the proxy and registrar to be doing the
    > right thing w.r.t. broadcasting our identity to the world]

Yes. TLS1.3 makes the certificate less visible to onlookers, but still a MITM
would be able to collect it.

We spent some time considering if we could turn the connection around so that
the Registrar spoke first, giving the Pledge the opportunity to decide
whether to provide it's identity or not.
But, how would it decide?

In the ANI case, we are likely doing this over wired links (long-haul fiber
or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch
use, this would be WIFI / 802.15.4.

What is needed is a three-party zero-knowledge proof, but how would the
Registrar identify the third party (the MASA)?

You are right to worry, but I don't know what to do about this.

    > Section 2.5.1

    > The pledge is the device that is attempting to join.  Until the
    > pledge completes the enrollment process, it has link-local network
    > connectivity only to the proxy.

    > nit(?): I think there is a subtle difference in  meaning between "only
    > has link-local network connectivity to the proxy" and this text, and I'm
    > not sure which is intended.

I'm confused.

    > Section 2.5.3

    > This may just be my personal preference (so feel free to ignore), but
    > talking about a "trust store used to authenticate the MASA" and "trust
    > store used to authenticate the pledge" would feel more readable than
    > "trust anchor database for authenticating the [thing] TLS connection
    > [thing] certificate".

    > It may be worth some comment about how this requirement for out-of-band
    > distribution of implicit trust anchors is something that BRSKI is
    > designed to avoid, but that distributing to just the registrar is a much
    > more manageable task than distributing them to all devices/pledges.

I think that the words "Implicit Trust Anchor" are supposed to invoke
RFC7030's section 3.6.2.   *** MAX ***
I'm okay with your text too.

    > Section 2.5.5

    > The Public Key Infrastructure (PKI) administers certificates for the
    > domain of concerns, providing the trust anchor(s) for it and allowing

    > nit: "domain of concern" singular

fixed.

    > The voucher provides a method for the distribution of a single PKI
    > trust anchor (as the "pinned-domain-cert").  A distribution of the

    > Earlier we talked about the "pinned-domain-cert leaf" in  the domainID
    > definition.  Was that supposed to be "leaf"  in the YANG sense and not
    > in the PKIX "leaf certificate"/"end-entity certificate" sense?

Yes.
I'll change "leaf" above to "attribute"

    > The expectations of the PKI are unchanged from EST [[RFC7030]].  This
    > Which parts of RFC 7030 talk about its expectations of the PKI?

The fact that the public key infrastructure can enroll new
end-entity certificates?   I agree that 7030 doesn't really set out
the expectations in one place.
*** MAX ***

    > Section 2.6.1

    > Many devices when bootstrapping do not have knowledge of the current
    > time.  Mechanisms such as Network Time Protocols cannot be secured
    > until bootstrapping is complete.  Therefore bootstrapping is defined
    > in a method that does not require knowledge of the current time.  A

    > nit: I'd suggest maybe "framework", "scenario", or "environment" rather
    > than "method".

done.

    > Section 2.6.2

    > [RFC5280] explains that long lived pledge certificates "SHOULD be
    > assigned the GeneralizedTime value of 99991231235959Z".  Registrars

    > This misses the important "for the notAfter field" part.

    > Why is 3 years the relevant cutoff here?

That's a good question. *** MAX ***

    > Section 2.7

    > There exist operationally open network wherein devices gain

    > nit: "networks"  plural

fixed.

    > unauthenticated access to the internet at large.  In these use cases
    > the management domain for the device needs to be discovered within
    > the larger internet.  These are less likely within the anima scope
    > but may be more important in the future.

    > nit: less likely than what?

changed to:
          The case where a device can boot and get access to
          larger Internet are less likely within the ANIMA ACP scope but may
          be more important in the future.
          In the ANIMA ACP scope, new
          devices will be quarantined behind a Join Proxy.

    > In order to support these scenarios, the pledge MAY contact a well
    > known URI of a cloud registrar if a local registrar cannot be
    > discovered or if the pledge's target use cases do not include a local
    > registrar.

    ben> I don't see the connection between "configure itself to become the
    ben> local registrar" and "contact a well-known URI of a cloud registrar".

In a completely Greenfield situation, where there is no local infrastructure
at all, given an appropriately magic "Intent" (remember where this WG
started...), then a cloud registrar could inform a device that it is
to become the Registrar.  How this would work depends upon the details
of the magic unicorn Intent (see failed SUPA WG).

    > If the pledge uses a well known URI for contacting a cloud registrar
    > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
    > authenticate service as described in [RFC6125].  This is consistent

    ben> Would this be more likely to be installed by the manufacturer or
    ben> device owner?

Manufacturer, as it's implicit.  That's how EST works today.

    > nit: "service" needs an article.

add "that"

    > Section 2.8

    > approach if they ensure a single MASA URL works for all pledge's
    > associated with each trust anchor.

    > nit: "pledges" non-possessive

Seems pledges should be plural to be.
Changed to:
        This is useful for Registrars which are servicing pledges on directly
        connected networks.or plural

    > Section 3

    > A pledge forms the "pledge voucher-request" and submits it to the
    > registrar.

already fixed.

    > The "proximity-registrar-cert" leaf is used in the pledge voucher-
    > requests.  This provides a method for the pledge to assert the
    > registrar's proximity.

    > "proximity" in what sense?  How much verification/confidence needs to be
    > done?  (Also, I would have expected the assertion to go the other way;
    > that the registrar asserts the pledge's proximity -- how does the pledge
    > have a way to know that the registrar is nearby when the proxy is
    > transparent?)

There is a TLS connection between them.  Yes, it could go anywhere.
The proxy was link-local, and the proxy pointed the connection at the
Registrar.  I guess it would be useful if the proxy was stateful, and
contributed another cryptographic layer for non-ACP cases.

In the ACP case, the Registrar knows it can trust the proxy because it's on
the ACP, and is connecting from an ULA address that is part of the ACP.

Yes, the Registrar could be anywhere, but the proxy makes it appear
to be on the local link.

I'm not sure what else I can add to the text.

    > Section 3.3

    > Example (1)  The following example illustrates a pledge voucher-
    > request.  The assertion leaf is indicated as 'proximity'
    > and the registrar's TLS server certificate is included
    > in the 'proximity-registrar-cert' leaf.  See
    > Section 5.2.

    > {
    > "ietf-voucher-request:voucher": {
    > "nonce": "62a2e7693d82fcda2624de58fb6722e5",
    > "created-on": "2017-01-01T00:00:00.000Z",
    > "proximity-registrar-cert": "base64encodedvalue=="
    > }
    > }

    > I do not see an 'assertion' leaf populated.

added.

    > Example (2)  The following example illustrates a registrar voucher-
    > request.  The 'prior-signed-voucher-request' leaf is
    > populated with the pledge's voucher-request (such as the
    > prior example).  The pledge's voucher-request is a
    > binary object.  In the JSON encoding used here it must

    > Why is it a binary object?  We just saw a previous example with a JSON
    > (non-binary) encoding.  (Hint: CMS-signed,but we didn't say that.)

okay, I'll say that.

    > There is (again) no assertion, and the created-on does not match
    > exactly.

added.

    > Section 3.4

    > The RFC 8174 version of the BCP 14 boilerplate could be used in the
    > module, too.
    > Also, is the 2017 copyright still correct, especially given that it is a
    > 2018-02-14 revision?

already fixed.
fixing date.

    > For example, a pledge might sign a voucher request
    > with a proximity-registrar-cert, and the registrar
    > then includes it in the prior-signed-voucher-request field.

    > nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)?

okay.

    > This is a simple mechanism for a chain of trusted
    > parties to change a voucher request, while
    > maintaining the prior signature information.

    > "chain" seems to admit the possibility of more than one
    > modification/resigning event, but the architecture as described seems to
    > only have the registrar doing this.

Yes. prior-signed-voucher-request could be used in new ways.

    > registrar agree on proximity assertions. The MASA SHOULD
    > remove all prior-signed-voucher-request information when
    > signing a voucher for imprinting so as to minimize the
    > final voucher size.";

    > (side note?) This removal would open up some minor exotic attacks in
    > cases where a pledge reuses an existing nonce (potentially from a
    > different device), but is probably an okay tradeoff to make.

agreed.

    > The first certificate in the Registrar TLS server
    > certificate_list sequence  (see [RFC5246]) presented by
    > the Registrar to the Pledge. This MUST be populated in a
    > Pledge's voucher request if a proximity assertion is
    > requested.";

    > 5246 is replaced by 8446.

okay.  Annoying to have references in the YANG module itself.

    > It might be simplest to just say the "end-entity TLS certificate", at
    > least for TLS practitioners.  (Maybe nof for a different audience,
    > though.)
    > How do I know that a proximity assertion is requested?

That is, How does the pledge knows it wants one?
Because it's been programmed that way.
I have removed "if", and replaced it with "when".
I have added the words "end-entity TLS certificate" to hammer the point.

    > Section 4

    > The role of the proxy is to facilitate communications.  The proxy
    > forwards packets between the pledge and a registrar that has been
    > provisioned to the proxy via GRASP discovery.

    > [same DULL question as above]

It's not DULL, because this is the Proxy speaking within the ACP.
I will write "full GRASP".

    > The proxy does not terminate the TLS handshake: it passes streams of
    > bytes onward without examination.  A proxy MUST NOT assume any
    > specific TLS version.

    > Passing bytes without examination is by definition not assuming any
    > version of TLS.  So while I  think it would make the most  sense to just
    > remove that sentence, if it's going to say it  might be worth also
    > noting the TLS invariants discussed in
    > https://tools.ietf.org/html/rfc8446#section-9.3 .

added reference.

    > Section 4.1

    > through a proxy.  The proxy is transparent to the pledge.  The
    > communication between the pledge is over IPv6 Link-Local addresses.

    > nit: between the pledge and what?

Join Proxy added.

    > M_FLOOD.  The active methods SHOULD exponentially back-off to a
    > maximum of one hour to avoid overloading the network with discovery
    > attempts.  Detection of change of physical link status (ethernet
    > carrier for instance) SHOULD reset the exponential back off.

    > Mathematically, "exponential" requires to specify the base of the
    > exponent (or just say "by doubling").  (Also later in the section.)

Well, of course the base should be "e" :-)
I'll write doubling.

    > Once all discovered services are attempted (assuming that none
    > succeeded) the device MUST return to listening for GRASP M_FLOOD.  It
    > SHOULD periodically retry the manufacturer specific mechanisms.  The
    > pledge MAY prioritize selection order as appropriate for the
    > anticipated environment.

    > nit: "manufacturer-specific" takes a hyphen
    > not-nit: what are "the manufacturer-specific mechanisms"?  (I don't
    > remember such discussion yet.)

1) Appendix A and Appendix B.
2) a bunch of manufacturers have proprietary equivalent of BRSKI.
   I think that this includes both Cisco and Juniper.

    > Section 4.1.1

    > Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or
    > some other notation?
    > Also, I'm not sure that picking an arbitrary (representative) session-id
    > value, LL address, and port is helpful when describing the formatting of
    > the message.  Maybe some different introductory text would change
    > things.

I have placed the example after the CDDL.

    > Section 4.3

    > If we're only defining an EST-TLS objective, how will proxies know that
    > the registrar supports BRSKI?

    > It's a little weird to put the reference for GRASP but not ACP.  Either
    > none or both would feel more natural (given that we've seen both already
    > a couple times).

The name is "AN_join_registrar", which implies BRSKI.
The objective-value of "EST-TLS" means EST. (vs CMP or some other enrollment
mechanism that people have asked for).  There could be many announcements
From different things.
This announcement and the Join Proxy described here only applies to ACP.

Added:
      <t>
        This section applies is normative for uses with an ANIMA ACP.
        The use of GRASP mechanism part of the ACP.
        Other users of BRSKI will need to define an equivalent proxy
        mechanism, and an equivalent mechanism to configure the proxy.
      </t>

the beginning of section 4.

    > Section 5

    > MASA URI is "https://" iauthority "/.well-known/est".

    > nit: "The MASA URI".
    > Is this always the case, with no opportunity for modification, even as
    > included in an IDevID certificate extension?

Either just the iauthority (now "authority") is present in the IDevID, or the
entire URL (with ports numbers and paths) is present.  I think that is what
you want.

    > BRSKI uses JSON [RFC7159] for all new operations defined here, and

    > RFC 7159 is obsoleted by RFC 8259.

already fixed.

    > While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
    > connections, BRSKI-EST connections SHOULD use persistent connections.
    > The intention of this guidance is to ensure the provisional TLS state
    > occurs only once, and that the subsequent resolution of the provision
    > state is not subject to a MITM attack during a critical phase.

    > I think we probably want a requirement that if persistent connections
    > are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST
    > check that the exact same certificate is used to authenticate the
    > registrar for all transactions.  If the signature in the handshake is
    > valid but you can only chain the certificate up to your trust anchor
    > once you finish imprinting, you still know that the entire session's
    > data has been talking to the now-authenticated party (as opposed to the
    > TLS case where you try to add a new certificate mid-connection, where
    > that boundary is unclear), but things are much easier to reason about if
    > you are sure that each EST transaction is talking to the same peer.

We had a conversation two years ago about what we might need to say about
HTTP/2, and aside from being unable to handle QUIC (due to proxy), we don't
see any issue.

I have added:
        <t>
          If non-persistent connections are used, then both the pledge and
          the registrar MUST remember the certificates seen, and also sent
          for the first connection.  They MUST check each subsequent
          connections for the same certificates, and each end MUST use
          the same certificates as well.  This places a difficult restriction
          on rolling certificates on the Registrar.
        </t>

But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to
allow for some fancy HTTP/3 we know nothing about :-)

    > o  In the language of [RFC6125] this provides for a SERIALNUM-ID
    > category of identifier that can be included in a certificate and
    > therefore that can also be used for matching purposes.  The
    > SERIALNUM-ID whitelist is collated according to manufacturer trust
    > anchor since serial numbers are not globally unique.

    > RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
    > the model of RFC 6125" or "provides a new SERIAL-ID category" or
    > similar.

I have an open request to *** MAX *** to clarify this part.

    > o  The registrar performs log verifications in addition to local
    > authorization checks before accepting optional pledge device
    > enrollment requests.

    > Maybe give us a section reference to what the "log validations" are?

We decided that we did not have enough experience to write normative language
here.  (It's not an Internet Standard)

    > Section 5.1

    > Establishment of the BRSKI-EST TLS connection is as specified in EST
    > [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
    > [RFC7030] wherein the client is authenticated with the IDevID
    > certificate, and the EST server (the registrar) is provisionally
    > authenticated with an unverified server certificate.

    > I'd consider noting that the signature (or other operation) made by the
    > certificate must be validated, and that the received certificate and
    > chain must be retained for later validation.

Added:
            <t>
              The signatures in the certificate MUST be validated even if a
              signing key can not (yet) be validated.  The certificate (or
              chain) MUST be retained for later validation.
            </t>
            <t>
              A self-signed
              certificate for the Registrar is acceptable as the voucher
              will validate it.
            </t>


    > The pledge maintains a security paranoia concerning the provisional
    > state, and all data received, until a voucher is received and
    > verified as specified in Section 5.6.1

    > Since section 5.6.1 just talks about the voucher verification process, I
    > think we need to say more about what "security paranoia" entails:
    > acknowledging that all data transmitted is sent to an unauthenticated
    > peer, with corresponding privacy considerations, and that all received
    > data is not authenticated by the TLS connection and must be
    > self-authenticating or otherwise considered untrusted.

            <t>
              The pledge code needs to be written with the assumption that
              all data is being transmitted at this point to an
              unauthenticated peer, and that received data, while inside a
              TLS connection, MUST be considered untrusted.  This
              particularly applies to HTTP headers and CMS structures that
              make up the voucher.
            </t>


    > A pledge that can not maintain as many connections as there are
    > eligible proxies.  If no connection is making process after 5 seconds

    > nit: that's not a complete sentence.

already fixed to:
            <t>
              A pledge that can not maintain as many connections as there are
              eligible proxies will need to rotate among the various choices,
              terminating connections that do not appear to be making
              progress.

stopping here for today.

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


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