Subject: Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

From: Michael Richardson <[email-masked]>
Date: Sun, 2 Jun 2019 16:39:53 -0400

On 2019-05-29 11:06 a.m., Fries, Steffen wrote:
> Hi,
> 
> As this is the last call, it may not be to late to ask the question. I read the draft a couple of times and was stumbling upon the following:
> 
> In Figure 1 of the BRSKI draft, for the communication between the Domain Registrar (RA) and the Key Infrastructure (CA), EST is stated.
>>From my understanding of the description EST as enrollment protocol between an RA and the CA is meant exemplary but not prescriptive? From the protocol flow for the enrollment itself I understood BRSKI describes the flow until the Domain Registrar but is open regarding the protocol applied between the domain registrar and the CA. It may be EST. 

Yes, it may. I don't think, other than the figure, we say anything else.
Would an "e.g." in the figure help?

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 3 Jun 2019 06:34:34 +0000

Hi Michael,

Yes, definitely. This would help. Thanks.

Best regards
Steffen

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: Sonntag, 2. Juni 2019 22:40
> To: [email-masked]
> Subject: Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures
> (BRSKI)) to Proposed Standard
> 
> >>From my understanding of the description EST as enrollment protocol between an RA and the CA is meant exemplary but not
> prescriptive? From the protocol flow for the enrollment itself I understood BRSKI describes the flow until the Domain Registrar but is
> open regarding the protocol applied between the domain registrar and the CA. It may be EST.
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Jun 2019 14:20:33 -0400

> Yes, definitely. This would help. Thanks.

https://github.com/anima-wg/anima-bootstrap/blob/master/component-diagram.txt

edited, will be in -21.

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

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 4 Jun 2019 07:09:09 +0000

Hi Michael,

Cristal clear. Thank you for the prompt response.

Best regards
Steffen

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jun 2019 18:33:00 +0200

Just on this text:

In Section 10.3 the following text exists:

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

First, this isn’t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval".  This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer.

Eliot

> On 21 May 2019, at 23:21, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from the Autonomic Networking Integrated
> Model and Approach WG (anima) to consider the following document: -
> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
>  <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard
> 
> This is a second Last Call. IoT Directorate review was done after the ANIMA
> WG Last Call and consensus to request the publication, and that review resulted
> in substantial changes to the document.
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2019-06-04. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document specifies automated bootstrapping of an Autonomic
>   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
>   is created using manufacturer installed X.509 certificate, in
>   combination with a manufacturer's authorizing service, both online
>   and offline.  Bootstrapping a new device can occur using a routable
>   address and a cloud service, or using only link-local connectivity,
>   or on limited/disconnected networks.  Support for lower security
>   models, including devices with minimal identity, is described for
>   legacy reasons but not encouraged.  Bootstrapping is complete when
>   the cryptographic identity of the new key infrastructure is
>   successfully deployed to the device but the established secure
>   connection can be used to deploy a locally issued certificate to the
>   device as well.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
> 
> The following IPR Declarations may be related to this I-D:
> 
>   https://datatracker.ietf.org/ipr/2816/
>   https://datatracker.ietf.org/ipr/3233/
>   https://datatracker.ietf.org/ipr/2463/
> 
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>    rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream)
> 
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 4 Jun 2019 21:28:43 +0200

Thanks, Eliot,

re-reading 10.3, my impression is: 

a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2.
The sentence stubs in 103 mentioning TOFU also don't seem to add value, the text
doesn't become IMHO worse if they are simply removed. And i am sure
there can easily be similar non-cyptographic leap of faiths in sales integration,
or consortium memberships trust chaing establishment.

b) The text could IMHO be crisper:

"will have no problem collaborating with it's MASA" ->
"will have no problem collaborating with it's malicious MASA" ->

"the domain (registrar) still needs to trust the manufacturer" ->
"the domain (registrar) still needs to authenticate the MASA" ?
(i hope the latter is the correct interpretation of the text)

Cheers
    Toerless

On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval".  This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer.
> 
> Eliot
> 

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jun 2019 13:09:09 +0200

Hi Toerless,

> On 4 Jun 2019, at 21:28, Toerless Eckert <[email-masked]> wrote:
> 
> Thanks, Eliot,
> 

My point is that those are no longer leaps of faith.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 7 Jun 2019 23:17:20 +0200

Ok, now i got you (i hope ;-).

I really liked the c1sco example (not sure if we should mention a real
company name in such an rfc someone not reading the draft might take
offense, maybe examp1e.com insted though).

But taking your thought into account: There is a fundamental difference
betwen TOFU and out-of-band-authentication/approval (pick a term),
and the fact that different such mechanisms may have (often human)
weaknesses does not change this fundamental difference ??

Maybe you want to propose text ?

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 8 Jun 2019 15:37:16 +0200

> On 7 Jun 2019, at 23:17, Toerless Eckert <[email-masked]> wrote:
> 

This is a bit tricky with the glyph attack, but certainly the base should be
example.com.

> weaknesses does not change this fundamental difference ??

I think the key is that humans oughtn’t rely solely on a visual inspection of whatever is presented in front of them, but rather that they might rely on alternative inputs, such as recommendations made by the registrar provider, or federated services.

> Maybe you want to propose text ?

Manual approval by administrator or selection by administrator.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Jun 2019 11:20:45 +1200

> This is a bit tricky with the glyph attack, but certainly the base should be

Can you use null.example.com and nu11.example.com?

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jun 2019 04:16:52 -0700

> Can you use null.example.com and nu11.example.com?

That's a little unfortunate from the perspective of this attack because
.com is a public suffix [0] whereas example.com is not.

-Ekr

[0] https://publicsuffix.org/

> > I think the key is that humans oughtn’t rely solely on a visual
> inspection of whatever is presented in front of them, but rather that they
> might rely on alternative inputs, such as recommendations made by the
> registrar provider, or federated services.
> >
> >
> >>
> >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer
> that the term be replaced with something like "out-of-band approval".  This
> would also be a good area for certification services to step in to indicate
> the trustworthiness of a manufacturer.
> >>>>>
> >>>>> Eliot
> >>>>>
> >>>>>>  rfc8368: Using an Autonomic Control Plane for Stable Connectivity
> of Network Operations, Administration, and Maintenance (OAM) (Informational
> - IETF stream)
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2019 10:49:48 -0400

{I've clipped the CC list}

    > ..com is a public suffix [0] whereas example.com is not.

    > [0] https://publicsuffix.org/

okay, I'm trying to understand the relevance of this from the point of an
example in an RFC.

We need to put the example under example.*, but we can't use examp1e.com,
because it's not an example domain.

Brian suggested the example null vs nu11.
This is not about super-cookies, etc. and it doesn't suggest any kind of
process involving the list of publicsuffixes.

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jun 2019 09:21:47 -0700

> process involving the list of publicsuffixes.

The general shape of this kind of attack is that the attacker wants to
impersonate A and so gets a domain with name A' that looks like A. However,
this depends on A' being something the attacker can register. The public
suffix list embodies the concept (more or less) of "anyone can register
here". By contrast, a.example.com is (I assume) owned by example.com and so
your average attacker can't do anything with b.example.com.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2019 08:48:35 +1200

On 11-Jun-19 04:21, Eric Rescorla wrote:
> 
> 
> On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>         >> On 09-Jun-19 01:37, Eliot Lear wrote:
>         >> >
>         >> >
>         >> >> On 7 Jun 2019, at 23:17, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>         >> >>
>         >> >> Ok, now i got you (i hope ;-).
>         >> >>
>         >> >> I really liked the c1sco example (not sure if we should mention a real
>         >> >> company name in such an rfc someone not reading the draft might take
>         >> >> offense, maybe examp1e.com <http://examp1e.com> insted though).
>         >> >
>         >> > This is a bit tricky with the glyph attack, but certainly the base
>         >> should be
>         >> > example.com <http://example.com>.
>         >>
>         >> Can you use null.example.com <http://null.example.com> and nu11.example.com <http://nu11.example.com>?
>         >>
> 
>         > That's a little unfortunate from the perspective of this attack because
>         > ..com is a public suffix [0] whereas example.com <http://example.com> is not.
> 
>         > -Ekr
> 
>         > [0] https://publicsuffix.org/
> 
>     We need to put the example under example.*, but we can't use examp1e.com <http://examp1e.com>,
> The general shape of this kind of attack is that the attacker wants to impersonate A and so gets a domain with name A' that looks like A. However, this depends on A' being something the attacker can register. The public suffix list embodies the concept (more or less) of "anyone can register here". By contrast, a.example.com <http://a.example.com> is (I assume) owned by example.com <http://example.com> and so your average attacker can't do anything with b.example.com <http://b.example.com>.

However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so we *really* can't use it. examp1e.net is 133.242.206.244 and actually responds to HTTP.

You're right that in theory subdomains are unrealistic examples, but does that
matter for an illustrative example?

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jun 2019 13:52:06 -0700

On Mon, Jun 10, 2019 at 1:48 PM Brian E Carpenter <
[email-masked]> wrote:

> > On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >         >> >> On 7 Jun 2019, at 23:17, Toerless Eckert <[email-masked]
> <mailto:[email-masked]>> wrote:
> >         >> >>
> >         >> >> offense, maybe examp1e.com <http://examp1e.com> insted
> though).
> >         >> >
> >         >> > This is a bit tricky with the glyph attack, but certainly
> the base
> >         >> should be
> >         >> > example.com <http://example.com>.
> >         >>
> >         >> Can you use null.example.com <http://null.example.com> and
> nu11.example.com <http://nu11.example.com>?
> >         >>
> >
> >         > ..com is a public suffix [0] whereas example.com <
> http://example.com> is not.
> >
> >         > -Ekr
> >
> here". By contrast, a.example.com <http://a.example.com> is (I assume)
> owned by example.com <http://example.com> and so your average attacker
> can't do anything with b.example.com <http://b.example.com>.
>
> However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so we
> *really* can't use it. examp1e.net is 133.242.206.244 and actually
> responds to HTTP.
>

Why not instead use two domain names that end in .example? E.g.,
demo.example and dem0.example

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2019 19:14:29 -0400

Brian E Carpenter <[email-masked]> wrote:
    mcr> Brian suggested the example null vs nu11.
    mcr> This is not about super-cookies, etc. and it doesn't suggest any kind of
    mcr> process involving the list of publicsuffixes.

    ekr> The general shape of this kind of attack is that the attacker wants
    ekr> to impersonate A and so gets a domain with name A' that looks like
    ekr> A. However, this depends on A' being something the attacker can
    ekr> register. The public suffix list embodies the concept (more or less)
    ekr> of "anyone can register here". By contrast, a.example.com
    ekr> <http://a.example.com> is (I assume) owned by example.com
    ekr> <http://example.com> and so your average attacker can't do anything
    ekr> with b.example.com <http://b.example.com>.

    bc> However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so
    bc> we *really* can't use it. examp1e.net is 133.242.206.244 and actually
    bc> responds to HTTP.

yes, some nice people have been sending example.* traffic to /dev/null.

    > matter for an illustrative example?

Exactly.
We are just trying to avoid c1sco.com / cisco.com as the example.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2019 19:15:03 -0400

> demo.example and dem0.example

works for me.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jun 2019 11:38:42 +1200

>     > demo.example and dem0.example

Absolutely, I had forgotten that .example. was reserved by RFC2606.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2019 20:36:26 -0400

> Absolutely, I had forgotten that .example. was reserved by RFC2606.

I upcased "demO" so that it looks like "dem0".

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jun 2019 10:40:03 +0200

Hi

> On 10 Jun 2019, at 13:16, Eric Rescorla <[email-masked]> wrote:
> 
> 
> That's a little unfortunate from the perspective of this attack because .com is a public suffix [0] whereas example.com <http://example.com/> is not.
> 

After a private exchange, I understand the nature of Eric's concern. The issue is that you want to demonstrate separate administrative entities, and subdomains generally wouldn’t that point clear.  The problem is that the obvious examp1e is already registered.  Thoughts?

Eliot

> -Ekr
> 
> [0] https://publicsuffix.org/ <https://publicsuffix.org/>
> 
>     Brian
> 
> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> >>>> Thanks, Eliot,
> >>>>
> >>>>>     that the name is a look alike: e.g, c1sco.com <http://c1sco.com/>, ..
> >>>>>
> >>>>>> On 21 May 2019, at 23:21, The IESG <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> [email-masked] <mailto:[email-masked]> mailing lists by 2019-06-04. Exceptionally, comments may be
> >>>>>> sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning of
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ <https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/>
> >>>>>>
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/>
> >>>>>>
> >>>>>> https://datatracker.ietf.org/ipr/2816/ <https://datatracker.ietf.org/ipr/2816/>
> >>>>>> https://datatracker.ietf.org/ipr/3233/ <https://datatracker.ietf.org/ipr/3233/>
> >>>>>> https://datatracker.ietf.org/ipr/2463/ <https://datatracker.ietf.org/ipr/2463/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> >>>>
> >>>>
> >>>> --
> >>>> ---
> >>>> [email-masked] <mailto:[email-masked]>
> >>>
> >>
> >>
> >>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> >>
> >>
> >> --
> >> ---
> >> [email-masked] <mailto:[email-masked]>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> >
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Jun 2019 04:39:11 -0700

As I mentioned in another email exchange, why not use two domains under
.example?

On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <[email-masked]> wrote:

> After a private exchange, I understand the nature of Eric's concern. The
> issue is that you want to demonstrate separate administrative entities, and
> subdomains generally wouldn’t that point clear.  The problem is that the
> obvious examp1e is already registered.  Thoughts?
>
> Eliot
>
> -Ekr
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jun 2019 14:00:18 +0200

> On 11 Jun 2019, at 13:39, Eric Rescorla <[email-masked]> wrote:
> 
> As I mentioned in another email exchange, why not use two domains under .example?

I missed that.  That would be fine with a good example.

Eliot

> 
> On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> Hi
> 
>> On 10 Jun 2019, at 13:16, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 13 Jun 2019 12:00:58 +0000

Hi,
Late feedback, but its ambiguous in the draft how vendor default Cloud Registrar https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7 and redirects as described in https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6 should interact.

Should the cloud registrar redirect immediately in response to the voucher request, so that the pledge then sends the voucher request via a local domain RA?
Should the cloud registrar issue a voucher, and then the redirect happens during the EST enrol flow?
When redirected, what trust anchor database should the pledge use?

It seems like:
- the cloud registrar should redirect to the local Registrar immediately and not issue a voucher (and this assumes a level of sales channel integration / ownership tracking so that the cloud registrar knows which registrar owns the pledge)
- the pledge should use the implicit trust anchor database for the initial connection to the cloud registrar, but then revert to standard provisional TLS connection for the initial connection to the local Registrar
- the pledge may include a proximity-registrar-cert in the new voucher request to the local Registrar

Doing the redirect immediately facilitates proximity assertions in the voucher request and associated audit logs in the MASA, and allows the MASA to discover the local domain CA from the voucher request signature. Maybe a clarifying sentence in section 2.7 would help?
Regards,
Owen

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of The IESG
Sent: 21 May 2019 22:21
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
  <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard

This is a second Last Call. IoT Directorate review was done after the ANIMA WG Last Call and consensus to request the publication, and that review resulted in substantial changes to the document.  

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2019-06-04. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jun 2019 10:53:46 -0400

Owen Friel (ofriel) <[email-masked]> wrote:
    > Late feedback, but its ambiguous in the draft how vendor default Cloud
    > Registrar
    > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7
    > and redirects as described in
    > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6
    > should interact.

    > Should the cloud registrar redirect immediately in response to the
    > voucher request, so that the pledge then sends the voucher request via
    > a local domain RA?

The cloud registrar concept is not intended to be a normative part of BRSKI.
We went through a bunch of text to try to make that clear, but maybe we have
still failed.

We are simply saying that a pledge MAY do something else, such as direct EST
back to the manufacturer, and you are astute to realize that the manufacturer
might redirect to the customer's Internet visible Registrar.

Please feel free to start a document that explains this, as I have this as
part of a back of the envelope design as well.  We think it's a large ocean,
and we think that NETMOD ZERO TOUCH has some really good ideas here too.

We are also trying to keep the door open to completely autonomous networks,
where even the Registrar bootstraps itself:

draft>   In such a future situation, the device might use this
draft>   management interface to learn that it should configure itself to
draft>   become the local registrar.

As such, I think that your questions and feedback are "future work"
5.6 has the text:

draft>   In order to avoid infinite redirect loops, which a malicious
draft>   registrar might do in order to keep the pledge from discovering the
draft>   correct registrar, the pledge MUST NOT follow more than one
draft>   redirection (3xx code) to another web origins.  EST supports
draft>   redirection but requires user input; this change allows the pledge to
draft>   follow a single redirection without a user interaction.

We had to say something about redirection, because EST supports it.
We decided that we would permit a single redirection, but we did not
have a definite operational reason for this, we just felt it was important.

In most cases, the pledge connects to the Registrar using a proxy,
so the pledge actually cannot decide to connect elsewhere. It always
connects through the proxy, and the proxy does not interpret the URL.

So, the only useful redirection that makes sense is to a different
URL and/or virtual Host: on the same end point.  This might be done
for reasons of load balancing, or to leverage the EST domain concept.
We did not want to predict or proscribe something here, just to make
the pledge did not get into an infinite redirect loop, yet still permit 3xx
codes to be useful in the future.