Hi Mike, We believe that we have addressed all your comments in the latest version: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/
Please, take a look and let us know what you think. Regards, Rifaat On Thu, Aug 28, 2025 at 9:08 AM Owen Friel (ofriel) <[email protected]> wrote: > Hi Mike, > > > > As the Pledge may be redirected to an Owner Registrar that follows the > standard BRSKI guidelines, the guidance in > https://datatracker.ietf.org/doc/html/rfc8995#section-5.6 applies > > > > This is the PR that we believe clarifies behaviour: > https://github.com/anima-wg/brski-cloud/pull/255 > > > > Thanks for the review. > > > > Owen > > > > > > *From:* Mike Bishop <[email protected]> > *Sent:* Friday 22 August 2025 16:28 > *To:* Michael Richardson <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected] > *Subject:* Re: [Anima] Mike Bishop's Discuss on > draft-ietf-anima-brski-clou d-16: (with DISCUSS and COMMENT) > > > > Looking for that general guidance, which may well be a single sentence. > You already have it for 4xx and 5xx responses (bootstrapping error, > indicate and retry later). > > > > Doing some checking of your references, I see that EST has this language: > > HTTP redirections (3xx status codes) to the same web origin (see > > [RFC6454 <https://www.rfc-editor.org/rfc/rfc6454>]) SHOULD be handled by > the client without user input so long > > as all applicable security checks (Sections 3.3 > <https://www.rfc-editor.org/rfc/rfc7030.html#section-3.3> and 3.6 > <https://www.rfc-editor.org/rfc/rfc7030.html#section-3.6>) have been > > enforced on the initial connection. The client initiates a new TLS > > connection and performs all applicable security checks when > > redirected to other web origin servers. Redirections to other web > > origins require the EST client to obtain user input for non-GET or > > HEAD requests as specified in [RFC2616 > <https://www.rfc-editor.org/rfc/rfc2616>]. > > ...which is updated in BRSKI: > > In order to avoid infinite redirect loops, which a malicious registrar > might do in order to keep the pledge from discovering the correct > registrar, the pledge *MUST NOT* follow more than one redirection (3xx > code) to another web origin. EST supports redirection but requires user > input; this change allows the pledge to follow a single redirection without > a user interaction. > > Your draft currently allows the pledge to follow multiple redirects so > long as they don't loop and they're specifically 307 versus any other 3xx > code; I'm just looking for something that says which of these behaviors > applies to any other 3xx code should the pledge encounter one. > > > > Reasonable options I see are: > > · Registrars send 307 specifically, but pledges follow any number > of redirects of any variety provided all the connections pass security > checks > > · Only 307 has the special property of chasing multiple redirects, > and any other redirect to a different origin is limited to one (per BRSKI) > > · Only 307 is a valid redirect for this scenario and any other 3xx > code is a bootstrapping failure > > > > I lean slightly toward the first one, but they're all defensible. The > draft just needs to pick one. > > > ------------------------------ > > *From:* Michael Richardson > *Sent:* Wednesday, August 20, 2025 10:09 PM > *To:* Mike Bishop > *Cc:* The IESG; [email protected]; > [email protected]; [email protected]; [email protected] > *Subject:* Re: [Anima] Mike Bishop's Discuss on > draft-ietf-anima-brski-clou d-16: (with DISCUSS and COMMENT) > > > > > Mike Bishop <[email protected]> wrote: > > Apologies — I think I dropped the ball on getting back to you about > > this one. The PR looks good, modulo text about handling of other > > redirect codes. > > > I'm used to 201+Location to refer to a *unique* place that should be > polled > > (GET,HEAD,If-*) to get the result. But, at each step, Cloud > Register X does > > not know what the unique URL for Cloud Register X+1 would be. > > 307 seems the correct answer to me. Go *THERE* and do a POST. > > MB> Using 307 for your expected flow is fine. You still need to specify > MB> what should happen with other status codes, since HTTP in general > MB> (intermediaries, etc.) might still encounter them in the wild. > > It's HTTPS, so there are not really any unknown/authorized intermediaries. > There is a concern with captive portals, but they do a forced proxy and > certificate failure before they can send a 3xx. > > The rest of the 3xx redirects would mostly seem to be invalid. > If they redirect within the same authority, I guess that's fine. > If they redirect to another authority, it would be mostly wrong. > > Is a single sentence saying the above what you are looking for? > > >> { > >> Note that we avoided 418. We really wanted to :-) > >> Well, technically it would have been: "You are teapot" > >> } > > MB> Maybe the pledge could use it from its management interface. One > MB> of the few areas of the IETF that could realistically specify a > use for > MB> 418! > > > NO SIR! I can also Brew expresso-sized Cappacinos! > > (as the machines in Madrid seemed to be...) > > Saw this video today on the TV during lunchtime. > https://www.youtube.com/watch?v=aqsEa1P8iPQ > Henk did not cover 451, which everyone felt he should have. > > -- > 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]
