Hi, Was there any conclusion of what to do here, which I think applies to errata 6648: https://www.rfc-editor.org/errata_search.php?eid=6648
I don't think that this is an errata that can be verified, hence I'm questioning whether "Held for document update" would be both correct and helpful. Would it be useful to update the text of the errata at all, or alternatively, I could just point to this thread in the notes. Any opinions on how I should process this? Regards, Rob > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Sunday, August 8, 2021 12:16 AM > To: Toerless Eckert <t...@cs.fau.de> > Cc: Rob Wilton (rwilton) <rwil...@cisco.com>; anima@ietf.org > Subject: Re: MichaelR/Rob/*: RFC8995 errata concerns > > > Toerless Eckert <t...@cs.fau.de> wrote: > >> The other bit is that Registrars MUST IGNORE SNI when accepting Pledge > >> connections. Pledges ought to not send it, since they don't really > know > >> what to put. > > > Are there never methods by which pledges or proxies discover registrar > > DNS names ? Isn't that at least commonly expected for BRSKI cloud ? > > BRSKI-cloud pledges are code to connect to their cloud register by some > method. A DNS name + DNS-lookup + RFC6125 DNS-ID validation (with SNI) > against WebPKI, sounds reasonable. > But, it could also be via TLS-PSK authentication to a hard coded IP address. > (That would be stupid, and maybe even seriously insecure, but you could do > it) > > But, the BRSKI-cloud connection is not the prospective TLS connection that > section 5.1 defines. > > > If this was a problem, it should be a problem already with a lot more > > TLS use-cases ?! > > > Aka: I'd opt for not having to require an additional MUST IGNORE SNI.. > > What does a Registrar called "frank.example" do when it receives a BRSL-EST > TLS > connection for "jones.example"? Fail it? That's silly. > > For all we know, the pledge did a mDNS discovery to find a join proxy and > that's why it's using the wrong name. > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
