Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Mar 2018 17:59:49 -0500

Max, please search for QUESTION.

Toerless Eckert <[email-masked]> wrote:
> 1.) Introduction
>
> a) The intro of 1. is somehat confusing to the uninitiated.
>
> Suggest the followinf replacement text for two paragraps:
>
> BRSKI provides a solution for secure zero-touch (automated) bootstrap of
> virgin (untouched) devices that are called Pledges in this document. These Pledges
> need to discover (or be discovered by) an element of the network domain to which the
> Pledge belongs to perform the bootstrap.  This element (device) is called the
> (Domain Join) Registrar.  Before any other operation, Pledge and Registrar need to
>  establish mutual trust:
>
> Then the four existing bullet points, but number them.
>
> Then followed by th following paragraph to replace the existing paragraph after
> the four bullet poins.

All done, including:

> b) It would be nice to have a paragraph mentioning the proxy as a mean to
> provide easier connectivity for Pledges (no need for full network connectivity).

Also, we have tried to always say "PKIX" certificates, since the whole
"X.509" space is decades old... Credit to IETF for keeping it alive.

> 1.1)
>
> a) "other Bootstrapping Approaches": "other" -> "prior" or "existing" ?

I'll take Prior, but I'm not crazy about the change.

> b) "_or_ that domain-specific keying material". Is this not an _and_ ?

It's an or.
It's *insecure* *OR* there is a domain-specific key.

> c) "in a costly and non-scaleable manner". "non-scaleable" may be hard to
> argue. Whole economies where built on manual labor. Might rather use
> qualifiers such as "little or not at all automated", "error-prone" and/or
> referring to physical security (.e.g: trusted pre-staging location).

Generally, any process that requires linear amount of labour (or capacity) to
be added in order to grow linearly are consider non-scalable.
Of course you can make pigs fly with enough rockets, but it does not work for
arbitrarily sized pigs.

> d) "existing mechanisms" -> "existing automated mechanisms".

okay.

> e) Paragraph 2 and following about EST: The first two sentences sound
> contradictory/conflicting. "...minimize user action..." , "details a set of
> non-autonomic bootstrapping methods". Suggest text like:

>
> "EST does reduce user actions during bootstrap but does not provide
> solutions for how the following protocol steps can be made autonomic
> (not involving user actions).

okay, slightly adapted.

> -----------------------------------------------------------------------------
> 1.3)
>
> a) The order of paragraphs is confusing. Even if the mayority of readers
> (which i don't think) would primarily be interested in class 1 devices,
> it is irritating in style and context to start with the first two
> paragraphs.
>
> I would suggest to start with existing paragraph 3, change maybe the
> sentence to "This solution (BRSKI) can support large router platforms..."
>
> Then insert the first two paragraphs after current paragraph 5. All the
> text after paragraph 5 already discusses constrained situations so
> it would nicely follow on to the first two paragraphs.

okay.

> b) paragraph 5 is confusing: What is a handoff, why would somebody
> even think to apply BRSKI in a handoff, and why is there a normative,
> capital letter SHOULD. Here is how i would write it more explanatory
> (if i understand the implied use case correctly):
>
> BRSKI could be used by nomadic or mobile devices to aquire certificates
> used as credentials to access the network at the new location. This
> is usually called handoff. Nevertheless, BRSKI is not intended for low-latency
> handoff which is usually a requirement in mobility solutions (e.g.: seamless
> handover). For these solutions BRSKI could be used to aquire keying
> material and re-use that during handover without re-initiating BRSKI
> during handover later on.
>
> (which is also implying that re-using BRSKI in nomadic environments
>  is not off the table, but not saying so explicitly because we really
>  have not thought that trough a lot).

I have adapted your paragraph replacing the one we had.

> c) It would loosen up a very long section to create three subsection headings
>
> - supported environments
> - constrained envionments
> - network access control

Done.

> -----------------------------------------------------------------------------
>
> Section 2 1)
>
> a) ..Each component is logical and may be combined with other components as necessary..
>
>     Ok. I always want the pledge to live in the same device as the MASA.
>
>     Would suggest deleting that sentence. More harm than benefit.

Hmm.   The Circuit Proxy, Domain Registrar and Certificate Authority could be
done component.  I think that we need to say something about that.

> b) I suggest to move section 2.4 up to become section 2.1) directly after the
> picture in section 2., because otherwise there is no explanaction following
> the picture.
>
> c) "The a domain" (delete a)

I think that you mean it becomes section 2.2, after the first state machine?
(c) perhaps already done.

> -----------------------------------------------------------------------------
>
> Section 2.1
>
> a) The term "Request Join" is only used here, and its IMHO not very logical
> (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the
> pledge says "i want to join". And also sounds as if the pledge could be
> disappointed if rejected. I would rather call it "Domain membership inquiry".
> Or if you're hooked up on the term "joining", then maybe "Join Inquiry".

QUESTION?  what do you think?
Was "Request Voucher" one of the options you were thinking about?

> Whatever best makes it clear that rejection is a perfect and important
> outcome option.
>
> b) Please see my issue section 5.1 a). If you agree with that statement, then there
> should be no "rejected" arrow in Figure 2 coming out of the "Identify"
> block.

okay, I'll deal with this in that section.

> I would also suggest that the "Bad Vendor response" arrow does not come out
> of the "Imprint" block but out of the "Request Join" block. AFAIK, this is
> an error reply to the Request Voucher, so it happens before imprinting
> (imprinting happens only when there is a vocker reply. AFAIK).

[It says, "Bad MASA response" now, just for the reader who is following]

> I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical
> to me would
> be "Error or not member". In any case, the text in section 2 below should
> mention the exact words used on the labels, the text is missing ll the
> labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor
> response",...

more discussion.

> c)
>
>  Point 1 nicely explains how this is done during TLS.
>
> Likewise, Point 2 should mention that this is the "Voucher Request", and
> Point 3 should mention that it is the "Voucher Reply" - so readers can match
> up section 2.1 with the rest of the document.
>
> remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text
> outlining when something else than EST is to be used. (see next comment).

QUESTION: I couldn't figure out what text this applies to.

> d)
>
> I am missing in the initial chapters a succinct summary how EST enrollment is optional and
>  what can be achieved with/without it, there is only some side sentences later in the
> EST sections. I would suggest to insert such an explanation here.
>
> After point 4 insert (unnumbered) paragraph:
>
> | After step 4, the pledge has received  and authenticated an explicit TA (trust anchor)
> | (pinned-domain-cert in the Voucher response). In some use cases this may be sufficient
> | and the bootstrap can be terminated here. The pledge can now use this TA to securely
> | trust domain members, but it can not securely identify itself to them as a domain member.
> | Therefore BRSKI usually proceeds with the following steps that support this via EST
> | enrollment (see also 5.5.1 for the limitations of the trust feasible through the imprint).
>
> Also maybe insert some dotted line between imprint and enroll in Figure 2 to
> highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll part)
> on the right hand side

QUESTION: Max?

> -----------------------------------------------------------------------------
> Section 2.2
>
> a)
>
>  The core sentence is hard to understand because it does not spell out the
> implication of the alternatives:
>
>  At the
>  lowest security levels the MASA server can indiscriminately issue
>  vouchers.  At the highest security levels issuance of vouchers can be
>  integrated with complex sales channel integrations that are beyond
>  the scope of this document.
>
> Would suggest amending like this:
>
>  At the lowest security levels the MASA server can indiscriminately issue
>  vouchers AND LOG CLAIMS OF OWNERSHIP BY DOMAINS.  At the highest security
>  levels issuance of vouchers can be integrated with complex sales channel
>  integrations that are beyond the scope of this document BUT THAT WOULD
>  INTENT TO VERIFY ACTUAL (LEGAL) OWNERSHIP OF THE PLEDGE BY THE DOMAIN.

I split it into more sentences, but took the intent.

> b)
>
> "Vouchers provide a signed but non-encrypted communication channel
>    between the Pledge, the MASA, and the Registrar."
>
> Why is this  mentioned ? If there is a conclusion of this statement that
> is relevant to BRSKI it should be spelled out, otherwise its a detail
> belonging into voucher. I do not see how the following sentence is that
> relevant conclusion. But maybe i am too confused by the sentence structure.

I think that it explains why the voucher exists.

> Do you mean something like this:
>
> | Vouchers are signed but not encrypted. This allows registars to maintain
> | better control over pledges attached to the domains network by examining
> | and filtering Vouchers received from a MASA before sending them to the pledge.
>
> If thats the idea, i suggest to use language like i suggested because it's
> more explicit and simpler (not having to think what the relevance of
> "communication channel" is etc..).

QUESTION: I'm not sure that's the essence of the point.

> Also may warrant a note that this control does not necessarily apply to the
> case of a Cloud Registrar (see section 2.6).

The could registrar is not a BRSKI interaction.

Stopping here today.
here is a diff against -11  https://goo.gl/CpZHqd

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Mar 2018 00:37:52 -0500

I would ideally like to begin the WGLC once I've posted the revised document
and then take any of your issues that I wasn't able to resolve as last call
comments (open issues on tools or github).

    > I am missing in the initial chapters a succinct summary how EST
    > enrollment is optional and what can be achieved with/without it, there
    > is only some side sentences later in the EST sections. I would suggest
    > to insert such an explanation here.

    > After point 4 insert (unnumbered) paragraph:

I have added a paragraph at the end of section 4:

          After step 4, the pledge has received  and authenticated an
          explicit TA (trust anchor) (pinned-domain-cert in the Voucher
          response).  A secure transport exists between pledge and registrar,
          and it may be used for things other than enrollment into a PKI.

    > Also maybe insert some dotted line between imprint and enroll in Figure
    > 2 to highlight this distinction. Maybe with "mandatory" / "optional"
    > (EST enroll part) on the right hand side

But, in the ACP case, which we are documenting, it's not optional, so
I prefer to show the ACP case in all diagrams.

    > Section 2.3)

    > The first paragraph is too terse and not very explanatory arguing why

okay, I'ave used your text.

    > - (Optional) authorizing pledge (by registrar) to receive certificate
    > from local CA.

Are you referring to the signed CSR?

That's signed by the private key, and does not directly involve the public
certificate part.  The "Signing of voucher-request" actually also is about
the private key too....
So I'm taking your comments, but maybe here we need to open an issue?

see: https://goo.gl/viMcAG
and: https://goo.gl/SNzWtJ

    > Please keep the "There is no requirement for a common root PKI
    > hierarchy.  Each device vendor can generate their own root
    > certificate."

Done.

    > Section 2.3 2)

    > a) Please put the description of identification of the pledge into a
    > subsection 2.3.1 "Identification of the Pledge"

done.

    > b) I am confused about the first MUST (serialNumber) and following
    > SHOULD (HardwareModuleName).

    > The conversion rules make it clear that you want the device to be
    > uniquely identified via the serialNumber, but if that is not in the
    > certificate, then you would use the HardwareModuleName. Therefore the
    > conversion rules contradict the MUST for serialNumber.  Or else you
    > wouldn't define a fallback if it does not exist.

We really want it in the serialNumber.
We acknowledge the PKI tools suck, particularly the ones without source code,
and it's likely that some variety of creation tools will be unable to comply
or the Registrar / Certificate Authority will be unable to do the right thing.
The 30 year history of trying make PKIX thing work properly has provided
experience that says that as much as we want to write MUSTs, if we don't have
workaround documented, then things will fail.  It's sad.

    > c) The MUST/SHOULD bullet points are IMHO a duplication of the
    > conversion rules, so maybe just drop them.

I think an issue is warranteed here.

    > d) I would start the section with a sentence clearly describing what is
    > done here:

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

    > The serial-number is derived from the IDevID as follows:

    > ... then add the three bullet-points.

okay, I think that I got this.

    > e) I do not see "serialNumber" attribute mentioned in rfc4514 nor
    > rfc4108. You mention "previously defined". Could you provide a
    > reference where "serialNumber" was defined ?

https://github.com/anima-wg/anima-bootstrap/issues/44

so, it's rfc4514 "string representation" format, of the RFC5280 SerialNumber
https://tools.ietf.org/html/rfc5280#section-4.1.2.2

RFC4108 has hwSerialNum, but that's point two.

I'm not sure how to clarify this well.

    > f) Please provide example of each of the three fields and how they
    > convert into serial-number. This is especially important because for
    > the average reader who has never seen a certificate (and with no actual
    > reference to e.g.: serialNumber format thats easily readable), it may
    > be hard to understand if or how something called "serialNumber" can
    > unique identify a device - aka: that it includes also the device-type
    > (unless a company only produces one type of device and somehow even the
    > name of the company can be implied).

I created issue 45.
https://github.com/anima-wg/anima-bootstrap/issues/45

    > Section 2.3 2)

    > a) Please put the description of MASA URI into a subsection 2.3.2 "MASA
    > URI"

done.

    > b) If the following statements are correct, i would suggest to
    > integrate them into the section text to make it clearer and more
    > explicit. If not then i did not understand how it is meant to work and
    > the explanations could be approved accordingly to make it clearer:

    > - The type and format of the MASA URI indicates the protocol supported
    > by the MASA.
    > - If a MASA supports multiple protocols, multiple
    > instances of the new MASA URI can be put into the certificate.

I don't think so.
If there was a protocol that wasn't BRSKI-MASA, then it would have a new
extension defined.
QUESTION/DISCUSS.

    > - This
    > document defines the BRSKI-MASA protocol. It is indicated through a URI
    > of the form

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

    >   see section 5 for more explanations. (this would replace the current
    > sentence mentioning section 5).

    > c) We discussed the risk of introducing new certificate fields and
    > potential compatibility issues with existing code parsing such a
    > certificate. Which is why we went for the obfuscated email encoding of
    > the ACP information in the LDevID. It would therefore be good to have
    > an explaining sentence why the new MASA URI extension is a better
    > solution than encoding into existing attributes and safe to deploy into
    > devices.

Well, I'm not convinced we needed to do that in the ACP.
On the other hand, the open source IPsec (IKE) implementations I'm familiar with
have relatively simple DER implementations, and are easily extended.
I am aware of IPsec implementations which are total disasters in this way,
and they would no more be able to parse the obfuscated email than an extension.

    > I am not sure about the full extent of the answer, but probably IDevIDs
    > are meant to and actually used in a far smaller and newer set of
    > software than that processing arbitrary LDevIDs. Therefore the risk is
    > smaller and the clean encoding outweights the risk of compatibility
    > issues with badly written old software.

The manufacturer creates the certificates, the pledge never has to examine
it.  The registrar has to examine it, and the registrar has to be new code.
Where we get into trouble, I think, is with the PKI interfaces.

    > Section 2.4.1) 1)

    >   "it does has network" -> "it does have network"

    > But better: "it does only require subnet (link) local connectivity to
    > the circuit proxy but no routeable IPv6/IPv6 address (exception: see
    > section 2.6)".

Already changed, but added your text.

    > Section 2.4.2) 1)

    >   "The proxy mechanism" -> "The circuit proxy mechanism"

    >   " optional stateless mechanism" -> "optional stateless proxy
    > mechanism"

    >   add: The registrar (likely?) also needs manual configuration of
    > per-MASA credentials to contact them (see section 5.3).

okay.

    >   Q: Any case where unauthenticated BRSKI-MASA connections make sense ?

QUESTION: This seems like a non-sequitor to me.

    > Section 2.4.3) 1)

It's 2.4.4, I think. About the Manufacturer Service.

    >   Suggest to clarify roles: separate functions: the MANDATORY ...MASA
    > including audit log, and an ADDITIONAL OPTIONAL Ownership Tracker
    > providing sales channel integration.

I don't think it's optional.

    >   Aka: reuse same terminology so readers are not confused. Maybe go
    > through text to check only "ownership tracker" and "sales channel
    > integration" are used for that part.

    > Section 2.4.3) 1)

    > a) Expand CMC.  "authenticate any pledge" -> "authenticate (the IDevID
    > of) any pledge"

    > b) The document is still very vague on terminology to distinguish
    > between the initial bootstrap and the (optional) EST server
    > role. Please come up with a clear terminology and clearly summarize the
    > functionality required to be supported by the roles.

I think that this no longer reflectes the text?

That's today's edits are at the same rfcdiff URL, since the file is
loaded by reference:
        https://goo.gl/CpZHqd

---

From: Eliot Lear <[email-masked]>
Date: Sun, 4 Mar 2018 12:04:26 +0100

Hi,

I'm not Max but I hope you won't mind me commenting in three places:

> Was "Request Voucher" one of the options you were thinking about?

I would very much prefer that we not use "Domain membership inquiry". 
If a change is necessary, I would prefer "Join Inquiry", to avoid
introducing ambiguities about domains.
> QUESTION: I couldn't figure out what text this applies to.

I can't be sure.  I think Toerless may be referring to both the Diagram
and the text in Section 2.1, as compared to, say, Figure 3 in Section
2.4.  I think the main change, IMHO is Figure 3, just to change
<---voucher--- to <---voucher reply--.

???

>> highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll part)

If it is just a dotted line, ok.  But then use text at the beginning of,
or just before, Step 5 to indicate that the step is optional.

Regards,

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Mar 2018 07:55:48 +1300

> introducing ambiguities about domains.

Yes. We have explicitly left the (tricky) issue of AN domain boundaries
and membership for later. (Recharter alert!)

   Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Mar 2018 15:21:32 -0500

Sunday I was skiing (it didn't rain!) and this morning I was distracted by
another urgent matter, so I'll get another two hours to work on this now, and
then I'll post a new version of the draft before the deadline.

It is unlikely that I'll get through all your suggested edits, and I still
need to come back to William Atwood's comments and some followups to my
previous comments.  Sorry for so many emails: next time be more negligent :-)

    > a) Expand CMC.  "authenticate any pledge" -> "authenticate (the IDevID

expanded and linked to RFC5272.

    > functionality required to be supported by the roles.

What is the "(optional) EST server role"?
Nothing is optional in this document when operating for the ACP.
The EST server role is an EST server according 7030.

    > Here is my suggested text. If any explanation to cover this information
    > is felt to be too long for 2.4.3, please find another place but make
    > 2.4.3 refer to that place.

    > | A "Domain Join Registar and CMC" (abbreviated Domain Registrar in
    > most of the document) | serves two roles: BRSKI Bootstrap Service and
    > BRSKI enhanced EST Enrollment Service.

I don't think that there are two roles.

There is no requirement that the Join Registrar is also the EST for the
purposes of ongoing certificate renewal.  I don't know if you are speaking
about certificate lifetime management (renewal, etc.) when you say
"EST Enrollment service".  I'll assume that you mean that for the moment.

In a big network I would want the roles (bootstrap and initial certificate,
vs certificate renewal) split up.

So I don't think your text is correct; but if it is, then I don't want to
insert a bunch of text that is depth first into explaining everything when
the goal of section 2 is to go breadth first.
I opened an issue: https://github.com/anima-wg/anima-bootstrap/issues/46

    > | While not recommended, BRSKI Bootstrap Server and BRSKI enhanced
    > EST-Server can |be provided by separate servers. In this case, the
    > BRSKI Bootstrap Server must | support redirection of the Pledge after a
    > successfull requestauditlog to the | URI of a BRSKI enhanced
    > EST-Server.

no, that's not what I'm saying at all.
I would never want to redirect or reconnect after processing the voucher and
before issuing the first certificate to the pledge.  The entire "Secure
Transport" depends upon it occuring over a single TLS connection.

    > Section 2.4.4)

    > a) It would be IMHO good to move the (mayority of the) initial
    > paragraph of 5.4 into this section to explain what the scope of the
    > MASA functionality is by listing the interface services requestvoucher
    > and requestauditlog here - similar to how i proposed to summarize the
    > interfaces of the Domain Registrar above for section 2.4.3.

I have changed the text to say:

2.4.4.  Architectural component: Manufacturer Service

   The Manufacturer Service provides two logically seperate functions:
   the Manufacturer Authorized Signing Authority (MASA) described in
   Section 5.4 and Section 5.5, and an ownership tracking/auditing
   function described in Section 5.6 and Section 5.7.

    > 5.4 is not a good place to do that because it's only about
    > requestvoucher, and then after another non-maza intermezzo 5.6
    > requestauditlog is again about the MASA. So no single place summarizing
    > the MASA functionality at this level.

Section 5 is a time sequence explanation about the process.
We want from role based descriptions to time based descriptions based upon
feedback from implementers.
Section 5.6 is about pledge->JRC.

QUESTION: Max, I thought that the Voucher Status Telemetry was also to be
          relayed to the MASA?
          (I didn't implement that far yet)

    > Section 2.4.x)

    > a) Please add subsection "Architectural Component: Key Infrastructure
    > (PKI)"

    > Suggested text (as in: this is the type of information i would like to
    > see explained here, whatever language you use):

    > | The Key Infrastructure (PKI) administers certificates for the domain
    > of concerns, | providing the trust anchor(s) for it and allowing
    > enrollment of Pledges | with domain certificates.

    > | The Domain Registrar ('s BRSKI Bootstrap service role) uses a Trust
    > Anchor (TE) | from the PKI in the BRSKI Voucher pinned-domain-cert to
    > authenticate itself to the | Pledge with the help of MASA.

I have put this text in place, but this paragraph is not quite correct.
I don't know how to fix it yet.

My text:

+2.4.5.  Architectural component: Public Key Infrastructure (PKI)
+
+   The Key Infrastructure (PKI) administers certificates for the domain
+   of concerns, providing the trust anchor(s) for it and allowing
+   enrollment of Pledges with domain certificates.
+
+   The Domain Registrar uses a Trust Anchor (TE) from the PKI in the
+   BRSKI Voucher pinned-domain-cert to authenticate itself to the Pledge
+   with the help of MASA.  (XXX fix me)
+
+   The Domain Registrar acts as an [RFC5272] Registration Authority,
+   requesting certificates for Pledges from the Key Infrastructure.
+
+   The above requirements and expectations against the Key
+   Infrastructure are unchanged from RFC7030.  This document does not
+   place any additional architectural requirements on the Public Key
+   Infrastructure.

    > b) Figure 1 labels the path to the PKI with "EST" and i remember Max to
    > repeatedly state that CAs could support EST. Nevertheless, i read in
    > RFC7030:

    > "The nature of communication between an EST server and a CA is not
    > described in this document".

So perhaps the labelling of the Domain Registrar/PKI interface shouldn't
say EST RFC 7030 afterall.

    > But then it defines the term "EST CA". So i am confused if there is an
    > actual spec stating the EST profile? of an EST CA.

You are asking for us to define what the northbound connection (well, in our
diagram, it's a southbound connection...) from the JRC to the PKI is.  What
we are trying to say is that it's not in scope, because it has no effect on
interoperation with the pledge or MASA.

The options include:
    1) CMC (RFC5272)
    2) CMP
    3) system("openssl xyz")  [it's all internal]
    4) a variety of RESTful interfaces,
        for instance https://www.digicert.com/rest-api/

I really don't think we should specify anything here because it will just be
ignored with vendors of JRCs doing whatever they need to do to get into the
customer.   On day one I expect to see (3) used a lot and others to follow.

    > Section 2.5) 1)

    > a) If the following sentence is functionally correct, please add text
    > accordingly:

    >   Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use it
    > to verify certificate validity.

    > b) And from my own experience, it should add:

    >   but they MUST be prepared to recognize local time failure and revert
    > to the above described mechanisms. For example when RTC battery failure
    > leads to a well-known default-time (e.g.: Jan 1 1970).

Done.

    > Section 2.5) 2)

    > a) Please move the bullet about the registrar behavior out of the
    > bullet list, maybe at the end of the section.  Even better: - rename
    > 2.5 to "Certificate Validity" - 2.5.1 "Lack of Realtime Clock in
    > Pledges - 2.5.2 "Infinite Lifetime of IDevID" (move text into 2.5.1)

okay.

    > b) Its hard to comprehend what the pargraph means to say. I think its
    > something like:

    >    According to RFC5280, IDevIDs are examples of certificates that
    > should have no well-defined expiration date. This is indicated through
    > the GeneralizedTime value of 99991231235959Z". Registrars SHOULD have a
    > configuration option to ignore IDevID lifetime values if they do not
    > conform to this recommendation.

Done.

    >    As expected, i always like an explicit example to bring it to the
    > point:

    >    For example, IDevID may have incorrect lifetime of N <= 3 years,
    > rendering replacement Pledges from storage useless after N years unless
    > registrars support this option.

Done.

    > Section 2.6)

    > IMHO, without further text, it is unclear a) what a cloud registrar is,
    > b) why we care and c) how a solution using a cloud registrar would have
    > to be built to work.

I think that we explain why (b) well enough.
I prefer not to try to specify anything here for two reasons:

1) it's proprietary: No BRSKI is involved.
2) it's out of scope: No BRSKI is involved.
3) it's possible that it will be draft-ietf-netconf-zerotouch-20

So, I don't think your assumptions are right about who runs what.

{In my thinking about this, btw, the pledge calls home a la
netconf-zerotouch, and the vendor provided service acts as a Join Proxy to
the owners' JRC.  But, I'd want to write code and think about before
I dared document it.  Running code...}

    > If you feel this is overall too much, then maybe delete the whole
    > section 2.6 and put it into a followup document. Borderline to me. If
    > its "just" what i sugested above, its fine, if there is more to it to
    > make it work, maybe better in separate document.

No, we added this section because someone (maybe you) asked for it.

    > Section 2.7 1)

    >> Note that the Registrar can only select the configured MASA URL based
    >> on the trust anchor -- so vendors can only leverage this approach if
    >> they ensure a single MASA URL works for all Pledge's associated with
    >> each trust anchor.

    > I do not think this is true. A registrar could have configuration
    > policy mapping from IDevID serial-number patterns to MASA URI.

Yes, it could be more complex.
I'd rather delete that sentence than fix it.

    > Rewrite accordingly ? Let me know if you hate this approach, i had had
    > to brainstorm it for my planned yang model for ANI.

Only if this functionality is standardized :-)

    > b) I also think it might be necessary for Registrars to allow policies
    > that override MASA URIs learned from the IDevID because the longevity
    > of URIs can not always be guaranteed and the MASA may move (merger &
    > aquisitions etc.. ).

Agreed.

    > c) I am unclear from the document whether registrars may require
    > configuration to know what specific options for voucher-requests a MASA
    > supports.

> - If i understand it correctly, a registrar may use a voucher-request to
> request a voucher in the absence of the pledge (stage the voucher). This
> certainly is something not every MASA must support, so that would need to
> be configured.

The MASA must support nonce-less, unsigned voucher-requests.
You are right that we did not say that the MASA MUST do this.
I'm comfortable leaving that to some other applicability document.
  {e.g, "Use of BRSKI to bootstrap lightbulbs for underground military bunkers",
      MIL-SPEC 843.1958, by Strangelove, Sellers and George}

> - It is not clear to me if the Registrar can correctly fill out all
> Registrar voucher-requests in the presence of the pledge (aka: after
> receiving the Pledge voucher-request). See also discussion for Section
> 3. If this is not fully automatic, but may rquire Registrar configuration,
> this counfig should be mentionedhere.

Do you mean, in the absence of the pledge, or ...?

    > Setion 3. 1)

    > So... I guess Registrars can request Vouchers for pledges before being
    > in contact with that pledge, right ?

    > If correct, the following would be less confusing to read for me:

Here is my revised text:

+   Voucher-requests are how vouchers are requested.  The semantics of
+   the vouchers are described below, in the YANG model.
+
+   A Pledge forms the "Pledge voucher-request" and submits it to the
+   Registrar.
+
+   The Registrar in turn forms the "Registrar voucher-request", and
+   submits it to the MASA server.
+
+   The "proximity-registrar-cert" leaf is used in the Pledge voucher-
+   requests.
+
+   The "prior-signed-voucher-request" leaf is be used in Registrar
+   voucher-requests to the Pledge voucher-request.  It contains the
+   encoded (signed form) of the Pledge voucher-request.
+
+   A Registar MAY also retrieve (nonceless) vouchers by sending voucher-
+   requests to the MASA.  No "prior-signed-voucher-request" leaf would
+   be included.  This can be used to retrieve vouchers for later offline
+   use.  The Registrar will need to know the serial number of the
+   pledge.  This document does not provide a mechanism for the Registrar
+   to learn that in an automated fashion.  Typically this will be done
+   via scanning of bar-code or QR-code on packaging, or via some sales
+   channel integration.

    > In any case, you need at least a forward reference for those leaf types
    > if you want to mention them without other explanations.

It's hard to reference into the YANG model text.

    > Setion 3. 1)

    > a) Even with above concern Section 3. 1) fixed the section still does
    > not provide a good taxonomy of the different type of voucher-requests
    > and how to fully identify them because of the "may be used"...

I removed "may" to say "is".

    > b) There is no text here explaning how a registrar transforms a Pledge
    > Voucher request to a Registrar voucher request. If explained later,
    > insert a forward reference. Else. pls add text to explain.

I added some text above.

    > b) I have my doubts that the flow of the document is ideal with all the
    > yang formalisms thrown into section 3. If this is what other documents
    > do as well, fine. I for once would like it better if it was put into a
    > separate section towards the end of the document.

    > "nah, not going to happen" is an acceptable answer ;-)

"not going to happen"

    > Setion 3.2 1)

    >  "provides voucher examples" -> "provides voucher-request examples"

okay.

Again, changes to here updated to: https://goo.gl/CpZHqd

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Mar 2018 17:44:45 -0500

> Section 4. 1)

    > a.1) Suggest to change title to "Proxying Details (Plege - Proxy -
    > Registrar)" because the section does not only discuss the proxy but
    > also the aspects/reqirements of proxying relevant to Client and
    > Registrar.

    > a.2) paragraph 1: "configured on the Proxy" append: "or automatically
    > discoverded (e.g.: via GRASP, see below)

In fact, we never want it configured in an autonomic network, it should
always be discovered.

    > b) Add: This section defines a statefu proxy which is therefore called
    > a "circuit" proxy.

okay.

    > c) Simplify whole paragraph with "(In a completely autonomic
    > network...)" - this discussion is not specific to AN. E.g.:

    > Registrars are assumed to have logically a locally integrated Proxy to
    > support directly (subnet) connected Pledges - because Registrars
    > themself does not define any functions for Pledges to discover
    > them. Such a logical local proxy does not need to provide actual TCP
    > proxying (just discovery) as long as the Registrar can operate with
    > subnet (link) local addresses on the interfaces where Pledges may
    > connect to.

done

    > d) "to discovery the" -> "to discover the"

already fixed I think.

    > e) Paragraph starting with: "If the Proxy joins an Autonomic Control
    > Plane" Suggest following replacement:

    >    In the ANI, the Autonomic Control Plane (ACP) secured instance of
    > GRASP (<ref>) MUST be used for discovery of ANI Registrar ACP addresses
    > and ports by ANI Proxies.  The TCP leg of the proxy connection between
    > ANI Proxy and ANI Registrar therefore also runs across the ACP.

    >    (separate because it would apply for any GRASP learning, not only
    > ACP):

    >    If GRASP is used by proxies for discovery of Registrars (ACP or
    > not), the proxy can also learn the proxy mechanism (Circuit Proxy
    > vs. IPIP encapsulation or other)

    >    (there is no negotiation in GRASP, therefore "agreed" as in current
    > text is not a good choice of word).

okay.

    > f) "SHOULD be the same as on the registrar in order for the proxy to
    > remain stateless".  Does such a proxy makes sense when it is not
    > stateless ? Aka: should this not be a MUST instead of a SHOULD ?

I can imagine ways to not use the same port, while still avoiding
O(number-of-pledges) storage of state.  But it involves messing with
packet headers in a way that I find distasteful.  That's why I write SHOULD.

    > Section 4. 2)

    > "In order to permit the proxy functionality to be implemented on the
    > maximum variety of devices...  with available capabilities for the
    > proxy function similar to many class 2 IoT devices"

    > This IMHO is an incorrect assumption. I am not aware of any network
    > device in ANIMAs "well managed network" charter" that would today fall
    > into class 2. I was and am often extremely annoyed how underpowered
    > control plane of multi-terrabit switches are but those too don't get
    > down to that level. Even OpenWRT small home rotuers (outside scope of
    > ANIMA) don't go below 4 MByte these days.

Yes, but I'm not talking about using the whole control plane CPU:
     -> "available capabilities for the proxy function"

we gotta fit into whatever is left over, or product management will kick our
code out next time there is a code space crunch.

As far as I can tell, due to SDN outsourcing the control protocols
(like BGP and OSPF and even), and the rest being in forwarding-element
hardware, one COULD probably get away with an OpenWRT scale CPU as the
control plane CPU for a L2/L3-aware switch with hundreds and hundreds of
ports...

    > Here are statements i could support/recommend:

    > - Registrars must support the proxy method supportable by the type of
    > proxies it needs to support. If pledges could be IoT class 2, then IPIP
    > would be a better solution for them than a CP circuit proxy. Note that
    > in ANI adopted to class 2 IoT or similar "mesh network" solutions,
    > Plege become proxies proxy and therefore IoT class 2 pledges imply also
    > the need to support IoT class 2 proxies.

So, it matters not what the pledge is.
The Pledge in this document is always doing HTTPS over TCP over Link-Local
IPv6, and never needs to know what the relay protocol is.

So, I don't agree with your paragraph here.

    > Section 4.1 1)

    > a) "[RFC4941] temporary addresses is encouraged...."  Please remove or
    > add text explaining why. Given how a pledge is happy to spill it's
    > IDevID to everyone claiming to be a proxy i am not sure what benefit
    > privacy addresses have, and they are additional implementation work for
    > pledges, whereas link-local (permanent) addresses are always
    > required. And changing addresses makes diagnostics harder.

    >    I also am not even sure if RFC4941 is even creating additional
    > link-local (temporary) addresses. I don't even think so. And all the
    > concerns RFC4941 discusses about correlating traffic is hardly
    > applicable to what the link-local address is used for.  link local GASP
    > discovery, BRSKI-TCP, maybe later some ACP tunnell..

We had a long discussion about this at design team meetings a year plus ago,
and I tend to AGREE WITH YOU.
Note that we temporary addresses do not require any long term storage
(vs privacy enhanced stable addresses)

Our discussion, you might recall centered on the question of whether the
connection should be initiated from the JRC->Pledge (as a result of some
signal) or the other way around.  The reasoning is that the <TLS1.2 connection
reveals the ClientCertificate first.

Note that TLS1.3 will keep contents of the certificates transmitted private
against passive eavesdroppers, while TLS 1.2 will not.

If you feel strongly about removing this recommendation, I'd like to make
this a WGLC issue (in the tools issue tracker), so that we can point to the
discussion when we are asked why we aren't mandating them.

I wrote a Privacy Concern section here:

   https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-01#section-10

tell me if you'd like to copy and paste some of that into a Privacy
Considerations section in BRSKI.

    > Section 4.1 2)

    >> Methods SHOULD be run in parallel to avoid head of queue problems
    >> wherein an attacker running a fake proxy or registrar can operate
    >> protocol actions intentionally slowly.

    > methods == circuit proy, IPIP, ... ?  would also be recommended to try
    > different proxies in parallel, right ?

No methods refers to M_GRASP vs optional things like mDNS or IPv4.

Changes too long to post.

    > Section 4.1 1)

    > a) The requirement to do proxy discovery via GRASP was already written
    > in 4.1. Please remove. Please use term DULL GRASP instead of just
    > GRASP.

okay.

    > I would also suggest to revisit the name of the objective. The

bikeshed.

    > Here is suggested text:

    > 180000, [ ["SRV.brski-proxy", 4, 1, "https" ], [O_IPv6_LOCATOR,

But, we didn't register a service called "brski-proxy", so that would be wrong.
I don't think we are interested in registered that name.

I didn't understand your CDDL.

    > objective-value = method
    > method = "https" ; or future methods ; CoAP not considered yet, see below

Like why would I do that?

    > Section 4.2) 1)

    > a) Append: Therefore the "coap" method in the previous section was only
    > used for the example but is not included in the CDDL definition of the
    > GRASP objective above.

That's why I didn't include it as an example.

    > Section 4.3) 1)

    > a) I would suggest removing this section and putting the requirement
    > into 4.1 together with the rest of the requirments.

I agree that the section is redundant.

    > Section 4.3) 1)

I guess you mean 4.4.

    > a) Suggest to move the first paragraph with requirements to section 4.1

    > b) Requirements must include:

    > ANI Registrars MUST announce their Registrar service via the ACP
    > instance of GRASP. They MUST support ANI TLS circuit Proxy and
    > therefore BRSKI across HTTPS/TLS native across the ACP. ANI Registrars
    > MAY support the IPIP proxy method by implementing IPIP tunneling for
    > their HTTPS/TLS traffic across the ACP.  ANI Proxies MUST support GRASP
    > discovery of Registrars .

okay.

    > c) The following is fixed up text for the remainder of 4.3 to solve the
    > following issues: - change of GRASP objective-name
    > (SRV.brski-registrar) and methods ("https", "https-ipip" as well as

Point not well taken.

    > coap for examples sake).
    >- changed address of registrar to be an actual ACP address

Because fda3:79a6:f6ee:0000:0200:0000:6400:0001 (I missed a zero!)
is somehow not a ULA?

    > - GRASP example was cut off/incomplete

I think only the closing ]], which is confusing because the artwork
ends with ]]>.  I've moved it into all into new files:

https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/jrcgrasp-cddl.txt

https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/jrcgrasp-example.txt

https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/proxygrasp-cddl.txt

https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/proxygrasp-example.txt

You'll find that there is a "pencil" icon on each page that lets you edit the
example or CDDL right there and send it as a pull request.

Please if you could seperate:
a) fixes to the syntax of the CBOR diag notation, or CDDL

from:
b) proposals to change any of the bits on the wire (including changing
   the name of the objective).

I'm skipping to the next section.

    >   a) The above "transport-proto /= 41" is technically an update to
    > GRASP RFC which allows only UDP / TCP. There is some process around

really?
QUESTION to Brian.

    >   c) I am not sure how we solve the problem of multiple IPIP Proxies on
    > a single LAN fighting to own h'fe80::1234. It seems to me we would have

You are solving a problem that does not exist.
You are right that IPIP is inadequately described at this point.
If only I was accepting a few dozen github pull requests rather than
this hundred page long email...

I wonder if we could remember that this is a Proposed Standard?

    >       "The Join Proxy SHOULD do a GRASP M_NEG_SYN for each interface
    > which they wish to relay traffic, as this allows the Registrar to do
    > any static tunnel configuration that may be required"

    >       Please insert implementable GRASP objective specifications for
    > this step here...

It's an error.
M_NEG_SYNC was replaced with M_FLOOD.  I've removed that.

Version -12 submitted at this point.
        https://goo.gl/Xyd5N2

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Mar 2018 12:10:28 +1300

>     > GRASP RFC which allows only UDP / TCP. There is some process around

It's an extension, which seems to me is not strictly speaking
an update. So the WG has two choices, IMHO:

1. Leave it here described as an extension, don't touch the GRASP spec.
2. Add this to the CDDL in GRASP at AUTH48, with the AD's approval.

The addition would give:

transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6
IPPROTO_TCP = 6
IPPROTO_UDP = 17
IPPROTO_IPV6 = 41

(It is not an accident that the names chosen are those used
in the socket API. Sadly, they are not maintained by IANA.)

I don't really care which solution we choose.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Mar 2018 13:27:33 -0500

> in the socket API. Sadly, they are not maintained by IANA.)

I guess I thought that any value from
  https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
was valid.

>   Note 3: The IPPROTO values are taken from the existing IANA Protocol
>   Numbers registry in order to specify TCP or UDP.  If GRASP requires
>   future values that are not in that registry, a new registry for
>   values outside the range 0..255 will be needed.

"not in that registry", and IPV6=41, is in that registry.
While there a bunch which probably are nonsense to use (e.g, PRM)
a bunch are relatively clear: SCTP, RDP, DCCP...

I believe that the answer is to move all the IPIP specification to another
document.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Mar 2018 07:46:36 +1300

>   https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

That was certainly my thinking, but we surely didn't want to write
out the CDDL for the whole registry.
 
> a bunch are relatively clear: SCTP, RDP, DCCP...

Yes. To my mind, an application of GRASP can choose to add any valid
protocol number to its use of GRASP.  So I think we are OK without
changing the GRASP text.

The tricky bit is if we want to add a non-IP protocol such as HTTP,
which is where we would need a new registry for values >255.
> I believe that the answer is to move all the IPIP specification to another

Well, you can use 41 in BRSKI with a reference to that "Note 3" in GRASP,
I think. "As mentioned in Note 3 of the definition of the Locator IPv6 address option
in [GRASP],..."

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Mar 2018 18:17:47 +0000

MAX: please look for your name.

Toerless Eckert <[email-masked]> wrote:
    > Section 5)

    > a) Suggest changing the title to "Protocol Details (Pledge - Registrar
    > - MASA / CA)"
    > to distinguish from Section 4. Might consider also to move up section

renamed.

    > b) MASA URI is "https:// authority "./well-known/est".
    > ^
    > missing a " ?

already fixed.

    > c) BRSKI-EST connections SHOULD use persistent connections
    > The intention of this guidance is to ensure the provisional TLS
    > authentication occurs only once and is properly managed.

    > This is not clear to me, please rephrase.

    > - What does "properly managed" mean ?

I no longer recall.
I think it's content-free.  It means don't throw away the connection
each time or do dumb things with your SSL context.

    > - Why would provisional TLS authentication have to occur more than once
    > without persistent connection ?

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

    > The first connection only retrieves the voucher, but then lets say the
    > Pledge closes the connection and builds a new one for EST
    > enrollment. On that second one it would not need to do provisional
    > authentication. /cacerts after /requestvoucher ?

I agree that it's possible to come up with a number of places in which
one could restart the TLS connection, at which point a MITM would either
be detected, or would cause a failure, but I would rather not open this door.

The pledge would have to remember the server's certificate and make sure that
it always connects to a server with the same (identical) certificate.

If the JRC is implemented in a load-balanced scenario with a front-end
*TCP* (not SSL) proxy that distributes load, then it is possible that it
would be legitimate for the different servers to have different
certificates.  As long as the voucher comes out correct, that's fine.

But, if the pledge is directed to different servers, which a non-persistent
connection could cause to occur, then the pledge will have a hard time.

What if the single server executes a planned reboot, and when it restarts, a
new (fresher) certificate has been installed?    The persistent connection
could be tuned to keep server from rebooting until that transaction is over.

Finally, the non-persistent connections could be redirected by the Join Proxy
to different JRCs!

    > d)  Q: How would BRSKI work in the absence of persistent connections or
    > in the presence of failures ? I guess each request from the pledge is a
    > standalone transaction and the pledge would just repeat them until it
    > succeeds or until a return code would indicate that the Registrar does
    > not support this step and the pledge has to terminate.

The requests from the pledge are not standalone transactions.
They are a series of connections that build towards a result.
I don't think we need to support non-persistent connection.

    > Aka: The way i see it, the reason for persistent connections is really
    > just
    > avoiding unnecessary repeated (expensive) TLS connection setup...

yes.  So, couldn't you have edited your comments then?

    > e)  "If the Registrar responds with a redirection to other web origins"

    > A reason for this rule should be written into that paragraph.
    > ... This is to minimize attacks by fake registrars trying to
    > indefinitely redirect a pledge.

MAX: I think that there are other reason as well?
MAX: Also, the pledge can't go anywhere by URL, only to where the Proxy
     directs it, so really can any redirection be accepted?
     Of course, it can do Host:

I have opened ticket: https://github.com/anima-wg/anima-bootstrap/issues/50

    > f)  "It should proceed to other discovered Registrars if there are any"

    > Pledes don't discover Registrars, the discover Proxies.
    > the Proxy can see a couple redundant Registrars.

fixed with:

            <t>
              To avoid blocking on a single erroneous Registrar the Pledge
              MUST drop the connection after 5 seconds in which there has
              been no progress on the TCP connection.
              It should proceed to
                connect to any other Registrar's via any other discovered
                Proxies if there are any.  If there were no
                other Proxies discovered, the Pledge MAY continue to wait,
                as long as it is concurrently listening for new Proxy
                announcements.
            </t>

    > f.1) "If necessary the Pledge calls the EST defined /cacerts method to
    > obtain the domain owners' CA certificate."

    > Please add an explanation when/why this is necessary. This seems to
    > contradict the statement in 5.8.1 about not doing /cacerts,/fullcmc
    > during Bootstrap but only during enrollment: "Although these
    > limitations are acceptable during initial bootstrapping"
    > (aka: "no need for /cacerts during bootstrap").

Now https://github.com/anima-wg/anima-bootstrap/issues/51

    > g)  After "This moves the BRSKI-EST TLS connection out of the provisional state." add:

    > - Afterwards the Pledge trusts this and other Registrars using the same
    > trust anchor. It MAY permit more than one redirects, but it MAY still
    > time out the registrar for further REST operations and revert to
    > another one.

We need to talk more about ticket #50.

    > - Mandatory boostrap steps conclude with Voucher Status Telementry (see
    > XXX)

done.

    > - Move "Optionally, the BRSKI- EST TLS connection can now be used for EST enrollment."
    > out of the bullet list merge wi next sentence ("The extensions...").

done.

    > h)  "In the language of RFC6125 this provides for a SERIALNUM-ID category of identifier.."

    > RFC6125 does not use the term SERIALNUM-ID and BRSKI does not use this
    > term outside of this paragraph either, so it seems redundant. The whole
    > paragraph is also quite dense,
    > so maybe rewrite/simplify the language.

We thought a lot about how one does matching of identities in PKIX
SubjectAltNames', and RFC6125 provides the best guidance.
I split the paragraph up.

    > Would suggest to also move any details o the whitelist logic
    > desccription to 5.1,
    > 5.0 is just overview. And in 5.1 you mention TLS setup uses RFC7030
    > mechanisms while in 5.0 it refers to RFC6125, so i think it would
    > become easier to write & read if tht 5.0 whitelisting stuff was moved
    > into 5.1 paragraphs refering to EST TLS setup.

Actually, I agree that 5.0 is way too detailed *IN GENERAL*
          https://github.com/anima-wg/anima-bootstrap/issues/52

    > Suggested append if you agree with it (whatever wording you like):

    > a) "nonce:  The Pledge voucher-request MUST contain" ...
    > ..."Doing so ensures Section 2.5 functionality"

    > If one just follows the reference to section 2.5, it looks contradictory:
    > "_If_ the voucher contains a nonce then the Pledge MUST confirm "

    > Please clarify, this is confusing:
    > - If the nonce is a MUST because of section 2.5, then the MUST would
    > only have to
    > apply to RTCless Pledges. But its not clear to me why... (forgot our
    > discussions,
    > and readers where never part of them, so explanation would be nice).

5.2 is about requesting a voucher, not about checking.
We decided that all voucher requests MUST have nonces, to enable noncefull
freshness, but whether or not vouchers are required to have nonces is
a manufacturer's decision.

    > - fix to "MUST NOT be reused for _MULTIPLE_ bootstrapping attempts
    > IMHO also: (especially not across repeated first bootstrap attempts
    > after power cycling).

done.

    > Section 5.3 1)

    > a) "The Registrar initiates the connection and uses the MASA URL obtained
    > as described in Section 2.7 for RFC6125 authentication of the MASA server."

    > Q: Does this mean:
    > "The Registrar initiates the connection and uses the DNS name of the
    > MASA URL obtained
    > as described in Section 2.7 for (RFC6125) authentication of the MASA
    > server certificate."

MAX, do you think we need to more this precise?
I think that we really want people to read 6125, not just guess.

    > Aka: for the less PKIX/Websecurity initiated readers like me, writing out
    > what is actually implied could make the sentence easier to parse
    > (instead of having to read more of RFC6125.

But, I want you to read 6125 rather than guess.
Or use a library (libcurl or whatever) that does the right thing.

I'll stop here, since there are a number of issues open.

https://goo.gl/8sQfkb for rfcdiff between -12 and github content.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 15:11:04 -0400

Comments on section 5, 6 and 7.

    > ----------------------------------------------------------------------
    > Section 5.4

    > a) See comment for section 2.4.4  for where i think the first paragraph
    > description should be.

There isn't a 2.4.4, so I'm not really sure I understand what you want me to do.

    > (aka: make this paragrap a summary of what the MASA interface is,
    > mentioning both requestvoucher and requestauditlog and move to 2.4.4).

    > b) The paragraph is difficult to parse and has IMHO wrong pieces.
    > - What does "simplicity" mean ?

I think it's mostly content-free.
It makes the text simpler to not have explain all of EST here.

    > - "the Registrar is not required to make use of any other EST
    > functionality when communicating with the MASA service"... what does
    > that mean.. ? Not required = but could optionally do it ?

I guess, we probably gained nothing by saying it was EST rather than a
straight RESTful web service.

I've opened issue,
     https://github.com/anima-wg/anima-bootstrap/issues/53

I think that's what you are asking here.

    > If a shared code basis is used for MASA and other EST/BRSKI defined
    > service roles (Domain Registrar, CA,...), the MASA service MUST
    > properly reject any EST functionality requests it does not wish to
    > service; a requirement that holds for any REST interface.

For me there is/was no code sharing.

    > "when the Registrar is expected to be offline" ->
    > "when the Registrar is expected to be unable to connect to a MASA"

    > Offline can be confusing because it does not explain who is not able to
    > talk with whom, and i think in both cases two of the three are still
    > expected to talk with each other (or at least that part does not
    > matter).

    > I am still confused about the "Pledge is unable to connect to the
    > Registrar" case.  Is this a case where BRSKI-EST does not happen but
    > something else (e.g.: sneakernet) between Registrar and Plege ? Please
    > add a sentence explaining what this case means.

https://github.com/anima-wg/anima-bootstrap/issues/54

    > f) "since the registrar is not known to the MASA server in advance"

    > Given how the HTTPS connection requires authentication, there is some
    > knowledge about the registrar from that, so the above sentence is
    > confusing. Whats the
    > correct statement to be made here thats takes the existance of the HTTPS
    > authentication of the Registrar to the MASA into account ?

https://github.com/anima-wg/anima-bootstrap/issues/55

    > g) Registrar revocation consistency:

    > Maybe change the lead in in this section to something like: "If the Registrar
    > uses a CA known to the MASA to make certificate revocation information
    > available
    > to the MASA, MASA SHOULD check ... of the Registrar Certificate. MASA MAY
    > limit service to Registrar where this applies to provide owners
    > protection against impacted registrar (e.g.: stolen).

okay, clarified text a bunch of text, and went back to 2.6.1 and changed
some text to put a few additional constrained on time.   I also turned the
point form into sections because they needed more detail, and so that they
can be referenced.
See:   https://goo.gl/166KTe

    > In any case a short reasoning why to do this step would be helpfull.

    > h) Pledge proximity assertion:

    > Sentence summarizing one most important attack vector reducet by
    > this. Or pointer to reference where this is explained.

I agree, we should expand this section to explain why.
  https://github.com/anima-wg/anima-bootstrap/issues/56

    > Section 5.5

    > a) "immediately complete authentication of the provisional"

    > This sounds contradictory to the potential need to perform /cacerts first as
    > described in section 5. Add something like (potentially after
    > performing /cacerts,
    > see section 5.) ?

We opened an issue before about this. I added this to it.
   https://github.com/anima-wg/anima-bootstrap/issues/51

    > Section 5.5.1

    > a) "which is an additional justification
    > for the recommendation to proceed with EST key management operations.
    > Once a full CA Certificate Response is obtained it is more
    > authoritative for the domain than the limited 'pinned-domain-cert'
    > response."

    > This sounds contradicting to the statement in section 5., where it sounds as if
    > provisional state is completes only after the (optional /cacerts) and cacerts
    > is part of bootstrap, whereas here it sounds as if its part of
    > enrollment only.

okay, part of issue above.

    > Section 5.6)

    > a) "The domain is expected to provide indications to the system
    > administrators concerning device lifecycle status.  To facilitate
    > this it needs telemetry information concerning the device's status."

    > Nice language.

    > Whats missing is the IMHO quite relevant recommendation to go beyond that
    > and provide diagnostics / suggestions that could go as much as

    > "actionable recommendations in support of expedient resolution of the
    > failure".

    > Aka:
    > (Failure) Reason: "voucher certificate not valid yet".
    > Suggestion:      "Replace empty RTC battery "

    > Can we add something like Suggestion to the structure ?
    > Not sure if "suggestion" is the best word, but it would be great if we
    > can put a stake in the ground adding this to the structure. I have seen
    > too many times
    > where it took eternities to find the magic offline manual mapping from
    > a range
    > of crazy error codes (reasons) to the suggestions what to do next.

    > b)  Recommendations for how to mitigate the potential security issues
    > of diagnostics
    > would be great:

    > - Reasons could be per-device encoded, requiring vendor for further insight:
    > Reason: "error 23498y354AZRFF"
    > Suggestion: "call manufacturer"
    > - Operations after errors can be slowed down to reduce/eliminate brute force attacks

    > c)  "message is being sent" -> "message may be sent" (above example of
    > non-attack issue).

So that was the reason for the reason-context.
It's very much specific to the device.
I'm not sure what text you are suggesting here.

    > Section 5.7)

    > a) Paragraph 1: Did we not discuss the option that the Registrar might
    > want to examine the authorization log before even forwarding the
    > voucher to the Pledge ?

Yes, but the critical thing is that it occurs prior to accepting the
certificate request from the Pledge.

    > b) It is recommended put to put some
    > ^^^^^^^^^^

    > And not even clear what it would mean if the sentence was fixed.
    > Does it mean something like: Cacheable object name could be large
    > randomn number ?

Fixed the text.

    > Section 5.7)

    > a) The current described examples of the Audit Log are all somewhat scary,
    > a bit like "The doctor told me something bad... should i ignore it".
    > Or worse: This audit log stuff is made up by Vendors to scare us into buying
    > only manufacturer refurbished gear with a clean history bill.

    > Can we mention some simple positive examples o better sell the value of
    > the audit log,

I'm not really sure what to do with this comment.
If we are doing marketing here, perhaps you can tell me what the audience is
(Manufacturer? ISP? Enterprise? Consumer?) and what their risk profile is?

    > The biggest concern i think we will see from privacy advocats is that
    > vouchers/audit-logs are a big-brother initiative from vendors. This too might
    > be something to document counter arguments for:

No, vouchers with supply chain integration are big-brother initiatives from
vendors...   Audit logs are the way in which we avoid having to do that for
every product.

I don't know what you want me to do here.

    > Section 5.8)

    > a) "The Pledge is also RECOMMENDED to implement the following EST
    > automation extensions"
    > add: An ANI Pledge MUST implement them.

okay.

    > b) Last paragraph: It looks as if this is in answer of my question about
    > enrolling multiple certificates. Thanks!

    > - Please put at the end of 5.8 (eg: new subsection before CoAP -
    > "enrolling multiple
    > certificates). No need to derail the core track what BRSKI does with
    > consideratations of what it can not do.

done.

    > Section 5.8.2)

    > a) The wording of the first paragraph makes it somewhat hard to understand what point
    > it is trying to make:

    > | In some deployments its plausible that the Pledge generates a certificate
    > | request containing only identity information known to the Pledge (essentially
    > | the X.509 IDevID  information) specific identity information

    > "in other deployments the pledge magically generates a certificate request
    > including information not known to the pledge"  ???

You put the "not" in there.  We didn't.

    > Section 5.8.4)

    > a) "The EST protocol assumes an end user" -> "RFC7030 assumes an end
    > user"

okay.

    > b) There seems to be text missing after second paragraph (before
    > discussing success/failure):

I don't understand what is it that you find missing.

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

    > Bullocks. First you scare off readers with "diagnostics bad" (5.6), and
    > now Pleges SHOULD just do good diagnostics (try new LDevID to see it works) ?

    > Please make the SHOULD re-negotiate a MUST and delete this last paragraph.
    > If a plege can not afford a single validation of a BRSKI certificate, its not
    > worth receiving one.

Could you please start again about this issue.
5.6 does not say diagnostics bad.
5.6 says not to tell attacking registrars too many details.

At 5.6, if there is a failure, the voucher has not been accepted, and we do
not have trust.

At 5.8, Pledge already trusts Registrar, but the certificate request has
failed, and we already have trust.  Knowing all the details is acceptable.

    > Section 6)

    > a) Suggest Change title to eg: "Additional security options"

Why?  A common complain about BRSKI and vouchers is that it's too secure.

I have added:
      <t>
        This section is considered non-normative: use suggested methods
        MUST be detailed in specific profiles of BRSKI.  This is the
        subject for future work.
      </t>

    > - Some text (eg. first paragraph mentioning NEA) talks also about
    > additional/higher
    > security, so lower is not necessarily always true.

Which methods are higher security?
I can't find which ones you might refer to.

    > Section 6.2)

    > a)  fix to "not involved in security considerations in this chapter"

    > Remember text in earlier sections where you claimed that yu do expect
    > fewer attacks after completion of TLS/provisional and how having trusted
    > Plege/Registar-Pledge path achieves this.

I can't parse this.

    > Section 6.3)

    > a) MASA server -> MASA service (i may have said that in before, but you
    > can ignore

already done.

    > b) "Trust on first Use" for physical ports: suggest to modify to:
    > "trust on first use" for methods with a strong dependency on physcial
    > posession,
    > such as taking ownership via configuration on a serial console.

fixed.

    > Section 7)

    > a) This document is extending the .well-known "est" definition. We need to
    > determine how to correctly handle this and have started to inquire.

This document extends RFC7030.
It probably needs to be marked as Updates RFC7030.
7030 does not establish an IANA registry for .well-known/est, so there are
no IANA intructions, but the most restrictive kind of RFC Standards Action,
which this document does... so I think we are just fine.

    > I suggest to add the following text to the IANA section for this:

    > | This document extends the definitions of "est" (so far defined via RFC7030) in
    > | the "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" registry
    > | as follows:
    > |
    > |   - add /.well-known/est/requestvoucher (see section 5.4)
    > |   - add /.well-known/est/requestauditlog (see section 5.7)

So, really, it should now have two entries in that list?

    > b) It would be good to create subsections for each registray mentioned so
    > that one can see from the table of content what registries are impacted.

Don't we already have that?
We are only creating one registry.

    > c) Probably need a summary of updates this document makes to RFC7030, the
    > easiest way would IMHO be to create a short section "Updates to RFC7030",
    > saying that all REST services introduced in this document are extensions ot
    > RFC7030 ESTE because they use the EST well-known prefix, and then point to
    > section 2.4 which with the text i proposed provides IMHO a good summary
    > of those services as used by each role (Pledge, Registrar, MASA).

I think that you do that above.

    > d) Add section to request brksi-proxy and brski-registrar to
    > IANA service name registry.

I'm still not sure I understand the why of dns-sd discovery in an ANI
environment.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 08:30:42 +1300

On one point only:

On 27/03/2018 08:11, Michael Richardson wrote:
...
> I'm still not sure I understand the why of dns-sd discovery in an ANI

That's a discussion on its own and I think it should be kept separate.
So I would leave these registrations aside for now; nobody else
is going to ask for brksi-* service names, so there's no urgency.

Once this phase is done, I hope we can discuss draft-eckert-anima-grasp-dnssd
properly in the WG, and the deeper implications.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 15:36:09 -0400

Final comments/actions on Toerless' awesome review.
The -13 is coming out soon, but we have 13 issues to resolve still.

    > Section 8)

    > a) First paragraph: Unvailable MASA is not a security but an
    > operational consideration.
    > Feel free to add "Operational considerations" section before security
    > considerations and move it there. Might want to add some more
    > considerations around
    > MASA to set context: Suggest something like:

It's due to that operational consideration that someone might want a nonceless
voucher, and therein is the security consideration.

So while I'm not oppposed to an Operational Considerations section,
it would not start with that first paragraph.

    > c) "The MASA authorization log..."

    > Not security consideration either IMHO.  Suggest to move into a new
    > "Privacy considerations"

Agreed.
MAX: when did the MASA audit log became an authorization log?
     Is this intentional?

    > Appendix A)

    > a) Would change title to non-IPv6 or non-ANI operations:
    > b) Initial explanation:

I'm changing it to IPv4 and non-ANI operations.
I'd rather search found "IPv4"

    > Specification of BRSKI in Section 4. only covered the mechanisms for an IP6
    > Pledge (link-local IPv6 address) and Proxy options necessary for IPv6
    > and ANI.
    > It does not cover the options for non-IPv6 Pledge or non-ANI Proxies
    > (IPv4 or IPv6).

done.

    > Appendix A.2)

    > a) Replace with:

    > A.2.  Use of DHCP

Not sure I agree. I think that DHCPv6 considerations are very different.
There are RAs, DHCPv6, as well as what kind of address will be given.
An IPv4 address is almost 100% certain to be RFC1918/NAPT, while IPv6 will not.

I don't mind adding a section on this, but I'd prefer to have a seperate
section as it needs significantly more details.

    > Appendix B)

    > a) Use suggested service name of "_brski-proxy" in all caes where
    > "_bootstrapks"
    > is used. (see comment for section 4.1.1 for why that name is better).

Opened issue: https://github.com/anima-wg/anima-bootstrap/issues/57

    > b) After "The Pledge MAY perform DNS-based Service Discovery", new paragraph:

    > A non-ANI Proxy MAY perform DNS-based Service Discovery using unicast DNS
    > to discover Registrars searching for searching for the service
    > "_brski-registrar._tcp.local.".

okay.

    > c) "To prevent unaccceptable levels of network traffic" -> add ", when
    > using mDNS"

okay.

    > d) "received a useable IPv4 address via DHCPv4 as suggested in Appendix A" ->
    > "received a useable IP address via DHCP/DHCPv6 as suggested in Appendix
    > A.2"

see above.

    > e) "If no local bootstrapks service": Add at end of paragraph: See
    > Section 2.6 (Cloud Registrar).

done.

    > Appendix C)

    > a) See discussion for section 4.3 above for the issues i see with
    > current IPIP
    > specification and suggestion to maybe move out of BRSKI to resolve with
    > more time.

Yes, I think that I agreed to remove it.

    > Appendix E)

    > a) Please add a sentence how to decode Hex Certs (not keys) with utility
    > at the very top of the appendix (right now its further down in the
    > text).

I'm confused by this.
a) there are no Hex Certs, they are all base64, and they are in standard
   PEM format.
b) I never say how to decode them... so?

    > b) E.1.4: which element in the cert would become the serial-number ?

Good point, it's not in the Subject in this example.
     https://github.com/anima-wg/anima-bootstrap/issues/58

I expect to regenerate the examples at AUTH48 time, once IANA
has assigned everything.

    > c) There are no ASN1 decodings of the artefacts, Please fix.
    > If this is subject to IANA assignments, please add RFC editor note to
    > block draft progressing.

Sorry?  Which one is missing?

    > X) Applicability outside ANIMA

    > If i am not mistaken, BRSKI-MASA should be one option how a bootstrap
    > server in "draft-ietf-netconf-zerotouch" could obtain a voucher from a
    > MASA (if i understand it correctly, the mean by which such a bootstrap
    > server obtains a voucher is left open). If that is correct, then it would
    > be great to mention this in a sentence or two in an appropriate section
    > of BRSKI as a very explicit example how BRSKI can be reused outside the
    > complete ANIMA scope (also add draft-ietf-netconf-zerotouch as an
    > informational
    > reference).

I would prefer to let ietf-netconf-zerotouch do that.
Or a new document in netconf, to be done after we finish BRSKI.
Otherwise, I think we wind up with too close coupling, and cycles
in the review process.

DONE your comments.
Many issues open.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 16:13:32 -0400

Brian E Carpenter <[email-masked]> wrote:
    > I definitely recommend replacing lower-case "may" in a case like
    > the one below.

Agreed.

    > Perhaps:

    >>> , and MUST NOT be
    >>> enabled unless the JRC indicates support for them

Changed.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 17:47:47 -0400

> That's a discussion on its own and I think it should be kept separate.

Good, I think so as well.

    > properly in the WG, and the deeper implications.

I'm not sure what to do about the current statements in the appendix then.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 12:19:51 +1300

> I'm not sure what to do about the current statements in the appendix then.

I really can't judge whether that material is sufficiently 
baked to be normative text (even under a MAY). I do have
sympathy with making BRSKI usable more generally, but I'm
not competent to judge whether this text is ready for the
standards track.

    Brian