Thanks for that work. Just one quick suggestion now, I'll review the rest after the telechat today.
sheltered could be 'protected' or 'isolated'? Deb On Wed, Aug 6, 2025 at 6:34 PM Michael Richardson <[email protected]> wrote: > > Deb Cooley via Datatracker <[email protected]> wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > In the security considerations section, please state what the > consequences are > > for the issues listed. For example: > > --- Section 8.1, para 1: So what? Is there an issue with a Pledge > > connecting to the Internet before being enrolled? [hint: yes, there > > is] > > > https://github.com/anima-wg/brski-cloud/pull/248/commits/5cee6c47d3948ab4df3bff5080d62b4f5e9b664e > +The Pledge SHOULD NOT assume that the connectivity that it has is > sheltered. > +In a majority of cases, the Pledge will be connected to a network behind > an enterprise firewall, or a home router, with typical restrictions on > incoming TCP connections due to NAT44 {{?RFC6144}} and {{?RFC7084, Sections > 3.1}}, and {{RFC6092, Section 4}}. > +In such situations, the Pledge might think it can be assured that it can > not be attacked, but this is not the case. > +Pledges could be deployed on networks with unfiltered connectivity, there > could be incoming connections enabled, and there could also be malicious > devices within this network. > > (I don't like BCP14 keywords in SC, but, it seems to fit here) > Not sure if the term "sheltered" is well enough understood. > Maybe it's enough to say "RFC6092 is not universal" > > {Saw a talk a decade ago about critical power control relays for Heathrow > Terminal 4 > being on a public IP... of course with default password. > Because how else do you power cycle the firewall remotely?} > > > --- Section 8.1, para 2: While a Pledge should check for firmware > updates, > > validation and transfer of those updates needs to happen in a secure > fashion > > - usually this means source integrity (did the f/w come from the > correct > > place), firmware integrity (is the f/w load the same?), and possibly > > confidentiality. A sentence to make this more obvious would be good. > > +The Pledge SHOULD contact the Manufacturer before bootstrapping in order > to apply any available firmware patches. > +Firmware patches need to validated before being applied. > +This is best done via signatures on the firmware updates, such as > described in {{?RFC9019}} or an equivalent mechanism. > +Origin authentication of updates is also sometimes enough. > + > +In order to best protect the Pledge from attacks of all kinds, > Manufacturers are encouraged to make MUD {{?RFC8520}} files available. > +Care needs to be taken in those definitions to allow for retrieval of > firmware updates. > > > --- Section 8.2: While reading this long section, I see a > recommendation > > near the bottom. Perhaps reorganizing this section so the > recommendation is > > closer to the top. The goal here is to reduce security issues due to > > compromised trust anchors (i.e. keep the list small). The second > goal is to > > reduce the issues with requiring an update to the trust store list > (properly > > validating the service). > > > ---- One comment in particular, in para 2, while it might be > easier, > > using one of the WebPKI trust stores will result in many trust > anchors that > > are not applicable. > > I moved the last point to the top, and I wound up rewriting things, > changing > some of the order. The rich-text diff result is at > > https://github.com/anima-wg/brski-cloud/pull/248/commits/1f7efb049d968511eed36436246da746338492d7?short_path=95c06ef#diff-95c06efda4eae4c6bd2b739bded9ef7a0d5c210ba88be1e034bffd3872816030 > > > --- Section 8.3: What are the consequences of accepting a > redirect when > > validation fails? > > > https://github.com/anima-wg/brski-cloud/pull/248/commits/aa7b5d0493335e2ad35706256ac44b04340c6ade > > +Provisional TLS connections are not immediately validated. > +A provisional TLS connection can be intercepted by an attacker, as unlike > in {{BRSKI}}, this connection crosses the Internet. > +There can be IP address hijacks, possibly DNS attacks that could send the > Pledge to the wrong place. > +Such a diversion would be detected when the resulting Voucher can not be > validated. > + > There is a conflict between these requirements: one says to validate, and > the other one says not to. > -This is resolved by having the Pledge attempt validation, and if it > succeeds, then an HTTP 307 redirect will be accepted. > +This is resolved by having the Pledge attempt validation, and if it > succeeds, then and only then, an HTTP 307 redirect will be accepted. > If validation fails, then an HTTP 307 redirect MUST be rejected as an > error. > If that occurs, then the onboarding process SHOULD restart after a delay. > This failure should be reported to the initial Cloud Registrar via the > mechanism described in {{BRSKI, Section 5.7}}. > > +If the Pledge were to accept a 307 Redirect from a malicious entity, then > it could be directed to connect to some other Registrar-like entity. > +This could be used to turn the Pledge into part of a distributed denial > of service (DDoS) attack. > +As the Pledge will send it's details in the Voucher Request that it does > send, there is also a possible disclosure of the Pledge's identifiable > private information. > + > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > Thanks to Mike Ounsworth for their (multiple) secdir reviews. > > > Section 4.2, step 6: What/where is this: > {pledge-certificate-identity-considerations} ? > > Section 8.4: What/where is this: > {bootstrap-via-cloud-registrar-and-owner-est-service} ? > > I hate it when that happens. Of course it should be {{FOO}}. > It's only {#FOO} when defining the anchors. Fixed. > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
