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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

(1) The text of the document suffers from lack of clarity throughout about
whether the nonce-ful operation is mandatory or not, with several
figures and discussions making declarative statements about nonce usage
and others saying that nonce usage is optional. (See COMMENT.)

(2) There also seems to be internal inconsistency about the proximity
assertion process (and, any sort of assertion in a voucher-request at
all, it seems).  I've tried to note some locations in the Comment
section.

(3) There are other internal inconsistencies as well, including about
section references for when various behaviors occur (see COMMENT).

(4) In Section 5.6.1

   The pledge MUST verify that the voucher nonce field is accurate and
   matches the nonce the pledge submitted to this registrar, or that the
   voucher is nonceless (see Section 7.2).

Is the pledge supposed to accept a nonceless voucher in response to a
nonce-ful voucher request?

(5) RFC7951 is cited for the audit log response, but I cannot find the
underlying YANG module that is JSON-encoded using the RFC 7951
procedures.
Furthermore, I don't think the "nonce" handling (with explicit "NULL"
string where base64-encoded binary data might be expected) would be
consistent with the 7951 rules.

(5) the new /enrollstatus EST endpoint seems under-specified.

(6) In Section 7.2:

   The pledge can choose to accept vouchers using less secure methods.
   These methods enable offline and emergency (touch based) deployment
   use cases:

   1.  The pledge MUST accept nonceless vouchers.  This allows for a use

It's very unclear to me what this "MUST" means, especially so given that
the entire section 7 is declared to be non-normative.  Is it that the
client "can choose" whether it "MUST accept nonceless vouchers"?
That would seem to make the MUST basically ineffective.

More broadly, if the entire Section 6 is non-normative, why is there any
normative language in it?

(7) the new /enrollstatus and /voucher_status well-known EST endpoints
are not registered in Section 8.1

(7.1) I think we also need to register the
"urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"  XML namespace.

(8) The versioning mechanism for Pledge BRSKI Status Telemetry is
underspecified, including the interaction with new registered values.

(9) The versioning mechainsm for the MASA audit log response is
underspecified, including whether a registry of field names is
appropriate.

(10) The term PKIX seems to be incorrectly used a few times; it refers
to the Internet PKI, and so things like a private PKI internal to a
manufacturer would probably not be best described as such.  Such private
PKIs can of course still reuse the protocols and mechanisms developed
for PKIX, and it's accurate to describe them as such.

(11) In a few places we describe the voucher-request in terms of its
YANG structure but do not say that it has to be wrapped in a signed CMS
object as is done for the RFC 8366 voucher.

(12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the
domainID calculation?

(13) In Section 5.5.1:

   As described in [RFC8366] vouchers are normally short lived to avoid
   revocation issues.  If the request is for a previous (expired)
   voucher using the same registrar then the request for a renewed
   voucher SHOULD be automatically authorized.  The MASA has sufficient

I don't understand what "for a previous (expired) voucher" means.
Is it something like "containing the same content as a previous voucher
request for which a voucher was issued", with the presumption that the
voucher expired before the pledge could successfully imprint, so it
needs to try again?  Or does this extend to longer timescales, like a
device that gets deployed for a couple years and is  then reset to
factory settings and has to rebootstrap but is still by the same
registrar?


(14) In Section 5.6:

                            The server MUST answer with a suitable 4xx
   or 5xx HTTP [RFC2616] error code when a problem occurs.  In this
   case, the response data from the MASA MUST be a plaintext human-
   readable (ASCII, English) error message containing explanatory
   information describing why the request was rejected.

It seems hard to support this stance on internationalization in 2019.


(15) In Section 5.9.4:

   To indicate successful enrollment the client SHOULD re-negotiate the
   EST TLS session using the newly obtained credentials.  This occurs by
   the client initiating a new TLS ClientHello message on the existing
   TLS connection.  The client MAY simply close the old TLS session and
   start a new one.  The server MUST support either model.

Is this supposed to be sending a new TLS ClientHello in the application
data channel or as a new handshake message (aka "renegotiation")?  The
latter is not possible in TLS 1.3 and is generally disrecommended
anyways even in TLS 1.2.  I would strongly suggest to remove the
"renegotiation" option and just leave "close the connection and start a
new connection/handshake".


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

[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
registrar, the fledgling pledge sends a fair bit of information about
itself to the registrar, including its serial number and device identity
(IDevID) along with a voucher request.  The registrar can determine
whether it expected such a device to appear, and locate a MASA, probably
from an extension in the IDevID.  Having determined that the MASA is
suitable, the entire information from the initial voucher request
(including device serial number) is transmitted over the internet in a
TLS protected channel to the manufacturer, along with information about
the registrar/owner.  The manufacturer can then apply policy based onthe
provided information and other sources of information, deciding whether
to approve the claim  by the registrar to own the device; if the claim
is accepted, a voucher is issued that directs the device to accept its
new owner.  The voucher is returned to the registrar, but not
necessarily to the device -- the registrar has an opportunity to examine
the voucher, the MASA's audit logs, and other sources of information to
determine whether the device has been tampered with, whether the
bootstrap should be accepted, etc.  No filtering of information is
possible in the signed voucher, so this is a binary accept-or-not
decision.  If the registrar accepts the voucher as a proper one for its
device, the voucher is returned to the pledge for imprinting.
The voucher also includes a trust anchor that the pledge should use as
representing the owner, successfully bootstrapping from an environment
where only the manufacturer has some (limited) level of trust by the
device into an environment where an owner has a PKI footprint on the
device.  When BRSKI is followed with EST this single footprint is
further leveraged into the full owner's PKI and a LDevID for the device.
Subsequent reporting steps provide flows of  information to indicate
success/failure of the process.

I also concur with the directorate reviewer that wanted to see more
discussion about the tradeoff in the applicability statement between
manufacturer control and ease/automation of bootstrap

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?

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

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

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

   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.
Also, following the IDevID link lands me at a page that claims to be for
a standard of status "superseded".
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.

Section 1.2

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

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

   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.

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

nit: hyphenate "network-specific".

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.

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?

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

nit: artifact (right?)

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

nit: probably need to expand ASA the first time.

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.

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!

   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?

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"

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

Section 2.3

   Pledge authentication and pledge voucher-request signing is via a
   PKIX certificate installed during the manufacturing process.  This is

(As noted elsewhere, "PKIX" may not be the best term here.)

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

   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.

   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.

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?

   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.

   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.

   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.

   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.

Section 2.3.2

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

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

[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]

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.

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.

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

   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?

   The expectations of the PKI are unchanged from EST [[RFC7030]].  This

Which parts of RFC 7030 talk about its expectations of the PKI?

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

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?

Section 2.7

   There exist operationally open network wherein devices gain

nit: "networks"  plural

   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?

   There are additionally some greenfield situations involving an
   entirely new installation where a device may have some kind of
   management uplink that it can use (such as via 3G network for
   instance).  In such a future situation, the device might use this
   management interface to learn that it should configure itself to
   become the local registrar.

   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.

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

   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

Would this be more likely to be installed by the manufacturer or device
owner?
nit: "service" needs an article.

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

Section 3

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

It would be helpful (at least to me) to know that the request is signed
by the IDevID cert, here.

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

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.

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

                be base64 encoded.  The nonce, created-on and assertion
                is carried forward.  The serial-number is extracted from

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

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?

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

             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.

             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.

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

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]

   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 .

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?

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

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

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

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.

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

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?

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

RFC 7159 is obsoleted by RFC 8259.

   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.

   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.

   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?

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.

   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.

   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.

Section 5.2

   application/voucher-cms+json  The request is a "YANG-defined JSON
      document that has been signed using a CMS structure" as described
      in Section 3 using the JSON encoding described in [RFC7951].  This

Section 3 does not describe any "sign[ing] using a CMS structure"
operation.

      voucher media type is defined in [RFC8366] and is also used for
      the pledge voucher-request.  The pledge SHOULD sign the request
      using the Section 2.3 credential.

To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
credential) to sign?

   constrained voucher formats are expected in the future.  Registrar's
   and MASA's are expected to be flexible in what they accept.

nits: no apostrophes for plurals.

   proximity-registrar-cert:  In a pledge voucher-request this is the
      first certificate in the TLS server 'certificate_list' sequence
      (see [RFC5246]) presented by the registrar to the pledge.  This
      MUST be populated in a pledge voucher-request if the "proximity"
      assertion is populated.

[same comment as above about "end-entity certificate"]

   The registrar validates the client identity as described in EST
   [RFC7030] section 3.3.2.  The registrar confirms that the 'proximity'
   assertion and associated 'proximity-registrar-cert' are correct.

what 'proximity' assertion?
Does verifying proximity-registrar-cert just mean checking that it's the
same leaf certificate that the registrar presented?  What happens if the
validation fails?

Section 5.3

   A Registrar accepts or declines a request to join the domain, based
   on the authenticated identity presented.  Automated acceptance
   criteria include:

I suggest "for different networks, examples of automated acceptance
criteria may include".

   If these validations fail the registrar SHOULD respond with an
   appropriate HTTP error code.

Similarly, "If validation fails".

Section 5.4

   The BRSKI-MASA TLS connection is a 'normal' TLS connection
   appropriate for HTTPS REST interfaces.  The registrar initiates the
   connection and uses the MASA URL obtained as described in Section 2.8
   for [RFC6125] authentication of the MASA.

I'd consider mentioning  the implicit trust anchor database as well as
the MASA URL.

   The MASA and the registrars SHOULD be prepared to support TLS client
   certificate authentication and/or HTTP Basic or Digest authentication
   as described in [RFC7030] for EST clients.  This connection MAY also
   have no client authentication at all (Section 7.4)

I don't see discussion of skipping client authentication in Section 7.4.
It would be great to have some, there!

   The authentication of the BRSKI-MASA connection does not affect the
   voucher-request process, as voucher-requests are already signed by
   the registrar.  Instead, this authentication provides access control
   to the audit log.

I don't understand what "access control to the audit log" means.  Is the
idea that the TLS client identity in the BSRKI-MASA connection is only
used when processing requests to the requestauditlog endpoint and that
some clients might be denied access?

Section 5.5

   created-on:  Registrars are RECOMMENDED to populate this field.  This
      provides additional information to the MASA.

Earlier we said that this field would be propagated from the pledge
voucher-request; we should probably say something like "populate this
field; if it was present in the pledge voucher-request it is copied
unchanged to the registrar voucher-request; otherwise the current time
is used".

   nonce:  This is the value from the pledge voucher-request.  The
      registrar voucher-request MAY omit the nonce as per Section 3.1)

I'd suggest "value from the pledge voucher-request, if present" and
changing the second sentence to refer to the pledge voucher-request.

   idevid-issuer:  The idevid-issuer value from the pledge certificate
      is included to ensure a statistically unique identity.

There is no "idevid-issuer" field in the pledge certificate; I assume
this is supposed to be the Issuer Name of the IDevID certificate.

   prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  (NOTE: what
      is included is the complete pledge voucher-request, inclusive of
      the 'assertion', 'proximity-registrar-cert', etc wrapped by the
      pledge's original signature).  If a signed voucher-request was not
      recieved from the pledge then this leaf is omitted from the
      registrar voucher request.

This is a good example of text that implies the signed voucher is
binary.  (And as such would be a good place to talk about the base64
encoding.)

   All other fields MAY be omitted in the registrar voucher-request.

Should the proximity-registrar-cert field *not* be present?

Section 5.5.2

   The MASA MUST verify that the registrar voucher-request is signed by
   a registrar.  This is confirmed by verifying that the id-kp-cmcRA
   extended key usage extension field (as detailed in EST RFC7030
   section 3.6.1) exists in the certificate of the entity that signed
   the registrar voucher-request.  This verification is only a
   consistency check that the unauthenticated domain CA intended the
   voucher-request signer to be a registrar.  Performing this check
   provides value to the domain PKI by assuring the domain administrator
   that the MASA service will only respect claims from authorized
   Registration Authorities of the domain.

If the MASA has no prior knowledge of the domain (certificate), this is
susceptible to anyone spinning up something that claims to be a domain
CA and issuing registrar certs with that extension.  We need to document
somewhere what other part of the system prevents that from causing an
unauthorized voucher to be used.  (Perhaps preventing one from being
issued is not feasible, but acceptable if the pledge will not accept
it, though there remains risk of DoS on the MASA.)

Section 5.5.3

   If a nonceless voucher-request is submitted the MASA MUST
   authenticate the registrar as described in either EST [RFC7030]
   section 3.2, section 3.3, or by validating the registrar's

Subsubsection references might be more helpful.

   In the nonced case, validation of the registrar MAY be omitted if the
   device policy is to accept audit-only vouchers.

I don't see any (SHOULD?) guidance about validating the registrar in the
nonced case when other policy is used.  Even the previous section does
not really say much to indicate there is value in authenticating the
signature on the voucher request.

Section 5.5.4

   authentication or voucher-request signature validation.  Similarly,
   as noted in Section 5.5.2, the MASA performs normal PKIX revocation
   checking during signature consistency checks (a signature by a
   registrar certificate that has been revoked is an inconsistency).

I think this needs to be noted more clearly in Section 5.5.2.

Section 5.5.5

   The MASA MAY verify that the registrar voucher-request includes the
   'prior-signed-voucher-request' field.  If so the prior-signed-
   voucher-request MUST include a 'proximity-registrar-cert' that is
   consistent with the certificate used to sign the registrar voucher-
   request.  Additionally the voucher-request serial-number leaf MUST

This seems kind of tautological ("if the MASA is checking X, X MUST have
happened").  Also, what does "consistent with"  mean?

   match the pledge serial-number that the MASA extracts from the
   signing certificate of the prior-signed-voucher-request.  The MASA is
   aware of which pledges support signing of their voucher requests and
   can use this information to confirm proximity of the pledge with the
   registrar, thus ensuring that the BRSKI-EST TLS connection has no
   man-in-the-middle.

To be clear, this MITM detection is only for the case of pledges that
sign their voucher requests, right?  And it seems to only hold if
pledges that support signing actually do sign, every time.

Section 5.5.6

   The registrar's certificate chain is extracted from the signature
   method.  The chain includes the domain CA certificate as specified in
   Section 5.5.  This certificate is used to populate the "pinned-

I don't think Section 5.5 is the right reference for "includes the
domain CA certificate" (both here and in 5.5.2).

   domain-cert" of the voucher being issued.  The domainID (e.g., hash
   of the root public key) is determined from the pinned-domain-cert and
   is used to update the audit log.

If the pinning takes the whole cert (per RFC 8366), then what do we need
the domainID for?  Just the audit log?  Surely in that case SHA-1 is
not a hard requirement...

Section 5.5.7

   The MASA MUST use the nonce from the registrar voucher-request for
   the resulting voucher and audit log.  The prior-signed-voucher-
   request nonce is ignored during this operation.

I don't understand this requirement.  They could only be different if
the MUST from the previous paragraph is ignored.

Section 5.6

   The MASA voucher response to the registrar is forwarded without
   changes to the pledge; therefore this section applies to both the
   MASA and the registrar.  The HTTP signaling described applies to both
   the MASA and registrar responses.  A registrar either caches prior
   MASA responses or dynamically requests a new voucher based on local
   policy (it does not generate or sign a voucher).  [...]

Do we need to say how this local caching policy interacts with HTTP
cache control headers?
I got confused by "or dynamically requests a new voucher" the first
couple times I read it; I landed on something like "when a voucher
request arrives at the registrar, if it has a cached response from the
MASA for the corresponding registrar voucher-request, that cached
response can be used according to local policy; otherwise the registrar
constructs a new registrar voucher-request and sends it to the MASA".

   type.  The registrar SHOULD use this response if it determines the
   pledge is unacceptable due to inventory control, MASA audit logs, or
   any other reason.

What does "unacceptable due to inventory control" mean?

   A 415 (Unsupported Media Type) response is approriate for a request
   that has a voucher-request or accept encoding that is not understood.

Isn't "Accept-Encoding:" a more typical spelling?

   vouchers are described in detail in [RFC8366].  For example, the
   voucher consists of:

   {
     "ietf-voucher:voucher": {
       "nonce": "62a2e7693d82fcda2624de58fb6722e5",
       "assertion": "logging"
       "pinned-domain-cert": "base64encodedvalue=="
       "serial-number": "JADA123456789"
     }
   }

nit: I think "might consist of" is better than "consists of".

   assertion:  The method used to verify assertion.  See Section 5.5.5.

The method used to verify itself?

   The pledge MUST be prepared to parse and fail gracefully from a
   voucher response that does not contain a 'pinned-domain-cert' field.

What would such a graceful failure look like?  Reverting back to the
discovery stage, since without a manufacturer-validated indication of
the trust anchor for the domain, the pledge cannot  consider itself to
be a part of a domain?

Section 5.6.2

   found.  It SHOULD return to the same proxy again after attempting
   with other proxies.  Attempts should be attempted in the exponential

But only if those other proxies failed to produce a valid voucher?

   The pledge's PKIX path validation of a registrar certificate's
   validity period information is as described in Section 2.6.1.  Once
   the PKIX path validation is successful the TLS connection is no
   longer provisional.

Section 2.6.1 doesn't actually say that the pledge has to check the five
listed timestamps in the case that it does have a realtime clock.

Section 5.7

   To indicate pledge status regarding the voucher, the pledge MUST post
   a status message.

I think we've had other text that implies that providing telemetry is
optional; perhaps just "the pledge POSTs a status message"?

   The client HTTP POSTs the following to the server at the EST well
   known URI "/voucher_status".  The Status field indicates if the

I think it's probably more clear to write out
".well-known/est/voucher_status"; there's not a separate registry of EST
well-known URIs.


We don't actually have anything in  this section that declares "this is
the structure of the JSON object used as the POST body"; it's only
implicitly provided.

   indicates why.  In the failure case this message may be sent to an
   unauthenticated, potentially malicious registrar and therefore the
   Reason string SHOULD NOT provide information beneficial to an
   attacker.  The operational benefit of this telemetry information is

What sort of information might a pledge consider including that would be
beneficial to an attacker?

   {
     "version":"1",
     "Status":FALSE /* TRUE=Success, FALSE=Fail"

I guess you should probably close the comment, not that this is a
formal comment syntax for JSON...

   The reason-context attribute is an arbitrary JSON object (literal
   value or hash of values) which provides additional information
   specific to this pledge.  The contents of this field are not subject
   to standardization.

This still have some privacy considerations, though.

Section 5.8

   is posted to the /requestauditlog URI instead.  The "idevid-issuer"
   and "serial-number" informs the MASA which log is requested so the
   appropriate log can be prepared for the response.  Using the same

Is the implicit point that the other fields are ignored?

   A registrar MAY request logs at future times.  If the registrar
   generates a new request then the MASA is forced to perform the
   additional cryptographic operations to verify the new request.

Is this statement just supposed to be further justification for using
the original voucher-request as the POST body, or describing new
behavior?

   A MASA that receives a request for a device that does not exist, or
   for which the requesting owner was never an owner returns an HTTP 404
   ("Not found") code.

What is a "requesting owner"?  I thought devices were owned by the
domain, not the specific registrar.

   In order to avoid enumeration of device audit logs, MASA that return
   URLs SHOULD take care to make the returned URL unguessable.  For
   instance, rather than returning URLs containing a database number
   such as https://example.com/auditlog/1234 or the EUI of the device
   such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
   return a randomly generated value (a "slug" in web parlance).  The
   value is used to find the relevant database entry.

https://www.w3.org/TR/capability-urls/ may also be a useful reference.

Section 5.8.1

   A log data file is returned consisting of all log entries associated
   with the the device selected by the IDevID presented in the request.
   The audit log may be truncated of old or repeated values as explained
   below.  The returned data is in JSON format ([RFC7951]), and the
   Content-Type SHOULD be "application/json".  For example:

If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data".

   This document specifies a simple log format as provided by the MASA
   service to the registrar.  This format could be improved by
   distributed consensus technologies that integrate vouchers with
   technologies such as block-chain or hash trees or optimized logging
   approaches.  Doing so is out of the scope of this document but is an
   anticipated improvement for future work.  As such, the registrar
   client SHOULD anticipate new kinds of responses, and SHOULD provide
   operator controls to indicate how to process unknown responses.

This would be a great place to talk about the "version" field that's
otherwise ignored.

   anticipated improvement for future work.  As such, the registrar
   client SHOULD anticipate new kinds of responses, and SHOULD provide
   operator controls to indicate how to process unknown responses.

Is "registrar client" intended to be both words or just one?

   A registrar SHOULD use the log information to make an informed
   decision regarding the continued bootstrapping of the pledge.  The

I may be confused, but I thought the registrar was asking for the log
after the voucher had already been issued.  Are these check supposed to
keep the registrar from forwarding the voucher to the  pledge, or just
as a check for future renewal operations?

   A relatively simple policy is to white list known (internal or
   external) domainIDs and to require all vouchers to have a nonce and/
   or require that all nonceless vouchers be from a subset (e.g. only
   internal) domainIDs.  A simple action is to revoke any locally issued

nit: missing "of"

   credentials for the pledge in question or to refuse to forward the
   voucher.  A registrar MAY be configured to ignore the history of the

"simple action" in the case that the registrar doesn't like the audit
log results?

   device but it is RECOMMENDED that this only be configured if hardware
   assisted NEA [RFC5209] is supported.

Probably need to expand NEA.

Section 5.9

   Although EST allows clients to obtain multiple certificates by
   sending multiple CSR requests BRSKI mandates use of the CSR
   Attributes request and mandates that the registrar validate the CSR
   against the expected attributes.  This implies that client requests

Where is this requirement stated normatively?

Section 5.9.1

   This ensures that the pledge has the complete set of current CA
   certificates beyond the pinned-domain-cert (see Section 5.6.1 for a
   discussion of the limitations inherent in having a single certificate
   instead of a full CA Certificates response.)  Although these

I don't see such a discussion in the indicated section.

Section 5.9.2

   To alleviate these operational difficulties, the pledge MUST request
   the EST "CSR Attributes" from the EST server and the EST server needs
   to be able to reply with the attributes necessary for use of the
   certificate in its intended protocols/services.  This approach allows

"intended" implies that the EST server has some knowledge of what the
pledge is expected to be doing in the network, right?

   To alleviate these operational difficulties, the pledge MUST request
   the EST "CSR Attributes" from the EST server and the EST server needs
   to be able to reply with the attributes necessary for use of the
   certificate in its intended protocols/services.  This approach allows
   for minimal CA integrations and instead the local infrastructure (EST
   server) informs the pledge of the proper fields to include in the
   generated CSR.  This approach is beneficial to automated boostrapping
   in the widest number of environments.

This is convenient, but has some security considerations in that it
implies that the validation policy on the CA is somewhat  lax, since the
EST server is expected to be doing most of the policy controls.  Thus, a
compromised pledge/device could send a CSR with unauthorized fields and
it is likely to be signed, allowing for some level of privilege
escalation.  When the registrar acts as a proxy to the CA as well as its
EST role, as described later, this risk is diminished.

   In networks using the BRSKI enrolled certificate to authenticate the
   ACP (Autonomic Control Plane), the EST attributes MUST include the
   "ACP information" field.  See
   [I-D.ietf-anima-autonomic-control-plane] for more details.

This MUST seems like it belongs in the ACP spec and need not be repeated
here using normative language.

Section 5.9.4

   administrators concerning device lifecycle status.  This might
   include information concerning attempted bootstrapping messages seen
   by the client, MASA provides logs and status of credential
   enrollment.  [RFC7030] assumes an end user and therefore does not

This looks like a comma splice.

   In the case of a FAIL, the Reason string indicates why the most
   recent enrollment failed.  The SubjectKeyIdentifier field MUST be
   included if the enrollment attempt was for a keypair that is locally

We haven't talked about POSTing to a new status-report endpoing yet, so
this comes out of the blue.  It would probably be worth adding above
"SHOULD [start a new TLS handshake] and POST a enrollment status
message".

     "Status":TRUE /* TRUE=Success, FALSE=Fail"

[same note about JSON comments]

     "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

   This allows for clients that wish to minimize their crypto operations
   to simply POST this response without renegotiating the TLS session -
   at the cost of the server not being able to accurately verify that
   enrollment was truly successful.

I'd prefer to not have this sort of option available, but I can't
disprove the claim of its utility, so I will not object if it stays.

Section 5.9.5

Is the idea that the initial BRSKI-EST-issued certificate would
authenticate the client for the subsequent EST requests?

Section 7

If this is non-normative and will need to be fleshed out in a separate
document, would an Appendix be more appropriate?

Section 7.1

   Pledge:  The pledge could be compromised and providing an attack
      vector for malware.  The entity is trusted to only imprint using
      secure methods described in this document.  Additional endpoint

How do "could be compromised" and "is trusted to only [...]" go
together?

   Vendor Service, MASA:  This form of manufacturer service is trusted
      to accurately log all claim attempts and to provide authoritative
      log information to registrars.  The MASA does not know which
      devices are associated with which domains.  These claims could be

I think this is maybe more of a "does not enforce" than "does not know",
since the domainID ends up in the audit logs that the MASA holds.

      Current text provides only for a trusted manufacturer.

nit: not a complete sentence.

Section 7.3

   A registrar can choose to accept devices using less secure methods.
   These methods are acceptable when low security models are needed, as
   the security decisions are being made by the local administrator, but
   they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

   Lower security modes chosen by the MASA service affect all device
   deployments unless bound to the specific device identities.  In which

Is this "unless the lower-security behavior is tied to specific device
identities"?

   case these modes can be provided as additional features for specific
   customers.  The MASA service can choose to run in less secure modes

nit: This middle sentence is not a complete sentence.

   1.  Not enforcing that a nonce is in the voucher.  This results in
       distribution of a voucher that never expires and in effect makes

A nonceless voucher can still include an expiration time ... it is just
in practice possible for it to never expire, if the target pledge does
not have an accurate clock.

       subsequent bootstrapping attempts.  That this occurred is
       captured in the log information so that the registrar can make
       appropriate security decisions when a pledge joins the Domain.
       This is useful to support use cases where registrars might not be
       online during actual device deployment.  Because this results in

nit: I think that grammatically the "This" at the start of this sentence
refers to the behavior described in the previous sentence  (the
availability of the log information) rather than the issuance of the
nonceless voucher.

Section 9

   The autonomic control plane that this document provides bootstrap for
   is typically a medium to large Internet Service Provider
   organization, or an equivalent Enterprise that has signficant layer-3
   router connectivity.  (A network consistenting of primarily layer-2

nit: "is used in" -- the ACP is not the entire organization!

Section 10.1

   The MASA audit log includes a hash of the domainID for each Registrar
   a voucher has been issued to.  This information is closely related to
   the actual domain identity, especially when paired with the anti-DDoS
   authentication information the MASA might collect.  This could

I thought I remembered some discussion of collecting this information
and thus what sort of information might be collected, but searching for
"DDoS" in the document didn't find it.

   There are a number of design choices that mitigate this risk.  The
   domain can maintain some privacy since it has not necessarily been
   authenticated and is not authoritatively bound to the supply chain.

Is this really "privacy" or just "semi-plausible deniability"?

   Additionally the domainID captures only the unauthenticated subject
   key identifier of the domain.  A privacy sensitive domain could

It's interesting to see "unauthenticated" used here, since the domainID
is deterministically generated from the pinned-domain-cert that is
included in the voucher and inserted into the pledge's trust store.  So
in a sense it is a committal by "the domain" to tie that domain cert to
that device or have the device otherwise be unusable.  The subsequent
text here seems to be suggesting that instead of having a single root CA
cert used by all devices in the domain, distinct certs would be used for
each device, thus attempting to remove an ability to associate devices
with each other via joint domain membership.  One might imagine doing
this by entering intermediate CAs (or even leafs?) into the
pinned-domain-cert field, but if those certs ever become visible (e.g.,
via certificate transparency), then the domainIDs can be independently
computed and associated to the MASA audit log, and the issuer chain used
to recorrelate the devices by domainID.  So to fully protect privacy,
the per-device pinned-domain-certs would need to be "root"s (i.e.,
self-issued), which greatly increases the manageability complexity and
is in effect counter to the goals of ANIMA and BRSKI.

Section 10.2

   While the contents of the signed part of the pledge voucher request
   can not be changed, they are not encrypted at the registrar.  The
   ability to audit the messages by the owner of the network prevents
   exfiltration of data by a nefarious pledge.  The contents of an

I think "prevents" is too strong -- steganography and concealed channels
are really hard to completely defend against.  "Gives a mechanism to
defend against" would be more accurate, in my opinion.

   The above situation is to be distinguished from a residential/
   individual person who registers a device from a manufacturer: that an
   enterprise/ISP purchases routing products is hardly worth mentioning.
   Deviations would, however, be notable.

Deviations in what sense?

Section 10.3

   4.  There is a fourth case, if the manufacturer is providing
       protection against stolen devices.  The manufacturer then has a
       responsability to protect the legitimate owner against fraudulent
       claims that the the equipment was stolen.  Such a claim would
       cause the manufacturer to refuse to issue a new voucher.  Should
       the device go through a deep factory reset (for instance,
       replacement of a damaged main board component, the device would
       not bootstrap.

I'm  not sure I understand this scenario -- is it talking about where a
third party makes a false theft report in the hopes that the real owner
will have to do a deep reset and then have the device fail to bootstrap
because of the reported theft?

Section 11

   To facilitate logging and administrative oversight, in addition to
   triggering Registration verification of MASA logs, the pledge reports

I'm not sure if "Registration verification" is a typo or not.

   registrar.  This is mandated anyway because of the operational
   benefits of an informed administrator in cases where the failure is
   indicative of a problem.  The registrar is RECOMMENDED to verify MASA

I'd also expect some comment about the limited value of the additional
information to an attacker in the context where the attacker already
would know [other information].

   To facilitate truely limited clients EST RFC7030 section 3.3.2
   requirements that the client MUST support a client authentication
   model have been reduced in Section 7 to a statement that the
   registrar "MAY" choose to accept devices that fail cryptographic
   authentication.  This reflects current (poor) practices in shipping

But section 7 is non-normative!

   devices without a cryptographic identity that are NOT RECOMMENDED.

I guess if we really wanted to disrecommend this practice we could split
it out into a separate document that profiles core BRSKI for such usage.

Section 11.1

   this might be an issue during disaster recovery.  This risk can be
   mitigated by Registrars that request and maintain long term copies of
   "nonceless" vouchers.  In that way they are guaranteed to be able to
   bootstrap their devices.

This, of course, comes with a different risk of what is something like a
long-term credential existing that needs to be protected and stored.

   The issuance of nonceless vouchers themselves creates a security
   concern.  If the Registrar of a previous domain can intercept
   protocol communications then it can use a previously issued nonceless
   voucher to establish management control of a pledge device even after
   having sold it.  This risk is mitigated by recording the issuance of
   such vouchers in the MASA audit log that is verified by the
   subsequent Registrar and by Pledges only bootstrapping when in a
   factory default state.  This reflects a balance between enabling MASA
   independence during future bootstrapping and the security of
   bootstrapping itself.  Registrar control over requesting and auditing
   nonceless vouchers allows device owners to choose an appropriate
   balance.

I would expect some discussion here about nonceless vouchers
with/without expiration times.

I also wonder whether the owner or registrar should expect to be doing
soem periodic MASA audit log checking, akin to a CT auditor or monitor.

   of specific pledge devices, helps to mitigate this.  Pledge
   signatures on the pledge voucher-request, as forwarded by the
   registrar in the prior-signed-voucher-request field of the registrar
   voucher-request, significantly reduce this risk by ensuring the MASA
   can confirm proximity between the pledge and the registrar making the
   request.  This mechanism is optional to allow for constrained
   devices.  Supply chain integration ("know your customer") is an

And so the protection is only available when all devices served by the
MASA are known to produce signed voucher-requests.

   additional step that MASA providers and device vendors can explore.

In terms of adding some more crypto to the BRSKI-MASA flow that would
prevent unauthenticated DoS?

Section 11.2

I appreciate having this discussion present; thanks!

   The fake registrar (Rm) can obtain a voucher signed by the MASA
   either directly or through arbitrary intermediaries.  Assuming that

I'm not sure what sort of intermediary this is thinking about.

   This pledge voucher-request would be 'stale' in that it has a nonce
   that no longer matches the internal state of the pledge.  In order to
   successfully use any resulting voucher the Rm would need to remove
   the stale nonce or anticipate the pledge's future nonce state.
   Reducing the possibility of this is why the pledge is mandated to
   generate a strong random or pseudo-random number nonce.

This gets a bit more complicated to reason about when we assume that a
pledge will have multiple voucher requests out in parallel, instead of
doing them in sequence and timing out (so that there is literally only
one valid nonce at a given time)...

   Additionally, in order to successfully use the resulting voucher the
   Rm would have to attack the pledge and return it to a bootstrapping
   enabled state.  This would require wiping the pledge of current

... and I think there is a different attack if the Rm is in a position
to delay or drop network traffic between the  pledge and the intended
registrar, to cause Rm's voucher to be delivered first even though it is
generated after the intended registrar's authorization process.  The
intended registrar would need to require reports on voucher processing
status (or investigate their absence) in order to detect such a case.

   o  Retreival and examination of MASA log information upon the
      occurance of any such unexpected events.  Rm will be listed in the
      logs along with nonce information for analysis.

How strongly guaranteed is it that a given device will only have a single
specific MASA that it trusts to issue vouchers (and thus limit the scope
of monitoring needed by the owner)?

Section 11.3

   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
      upon seeing a manufacturer's trust anchor for the first time, and
      then the trust anchor would be installed to the trusted store.
      There are risks with this; even if the key to name is validated
      using something like the WebPKI, there remains the possibility

nit: is this "key to name mapping"?

Section 11.4

It is not entirely clear to me whether device manufacturers are set up
with incentives to maintain a well-run secure CA with strong hardware
protections on the offline signing key for the root CA, cycling through
various levels of intermediates, etc., that CAs in the Web PKI do today.
If the manufacturer uses a less stringent process, that would leave the
manufacturer's key as a more tempting attack surface, and it may be
worth some discussion here about what damage could be done with a
compromised MASA signing key.  E.g., would an attack require restoring
devices to factory defaults or otherwise waiting for natural
bootstrapping events to occur?  Would the attacker need to be on-path?
Etc.

Section 13.2

I think CDDL needs to be a normative reference, as does RFC 7231.
RFC 2473 is listed but not referenced in the text, as are RFC 2663,
RFC 7217, and RFC 7575.

Appendix B

   Discovery of registrar MAY also be performed with DNS-based service
   discovery by searching for the service "_brski-
   registrar._tcp.example.com".  In this case the domain "example.com"
   is discovered as described in [RFC6763] section 11 (Appendix A.2
   suggests the use of DHCP parameters).

I'd suggest using "<domain>" per 6763 rather than "example.com".

   If no local proxy or registrar service is located using the GRASP
   mechanisms or the above mentioned DNS-based Service Discovery methods
   the pledge MAY contact a well known manufacturer provided
   bootstrapping server by performing a DNS lookup using a well known
   URI such as "brski-registrar.manufacturer.example.com".  The details
   of the URI are manufacturer specific.  Manufacturers that leverage
   this method on the pledge are responsible for providing the registrar
   service.  Also see Section 2.7.

It seems like there are some security considerations for device owners
that may wish to prevent such registrars from being used.  Do we need to
direct them to run a firewall or similar?

Appendix C

I don't know how important
file "[e-mail]"
is, but it seems a tad generic.

Appendix D

[Just checking that Michael wants sandelman.ca embedded in the final
RFC]