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

[Michael Richardson <[e-mail]>]

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.




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