Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of proxy/registrar insufficient (GRASP and) more).

[Toerless Eckert <[e-mail]>]

On Thu, May 05, 2022 at 01:16:12PM -0400, Michael Richardson wrote:
> Toerless Eckert <[e-mail]> wrote:
>     > Just for the fun of it i just registered service-name est-coaps against RFC9148 with IANA
>     > yesterday, like Jack registered "est" against RFC7030 a decade afterwards. That should/could
>     > then be used for constrained networks to use any working (*grin*) discovery for automatic cert
>     > renewal, which to me is equally important to bootstrap. See for example RFC8994 for SRV.est
>     > for how ACP defines to do this with EST/RFC7030 (via GRASP).
> 
> I'm not sure that I agree with the name "est-coaps", as I think it's still
> "est" with a transport of CoAP/UDP.

a) I think you're logically right, but practically we do not have any actual
formal service specification agnostic to transport for that abstract EST,
such as a TAP-like service interface definition. We only have stuff in
rfc9148 and ANIMA cBRSKI draft that reads: "this does the same as XXX
in RFC7030/RFC8995".

b) I was just looking at the openthread brski code, and it would be interesting
to see how far one could get with actual code and a set of API functions
shared bteween BRSKI/cBRSKI..

c) Can i circle that argument back to you and ask why we should actually
introduce brski.jp/brski.rjp if we already have brski-proxy and brski-registrar ?

>  I'm pretty sure that SRV records can encode that.

d) Actually no. SRV is just one RR for a DNS-SD service definition, and its not
extensible. The extensible one is the TXT one. See my other mails proposing
to exactly do that, e.g. ensure we do not introduce unnecessarily many
service names just for protocol variations by using TXT proto=<variation>

e) But: For this quick est-coaps service registration, without any draft/rfc
describing/specifying any such parameters, i didn't want to start having a long
discussion with Jack about updating/expanding the individual est registration
to introduce TXT parameters. Thats exactly one of those problems of forgetting
to do this work in e.g.: RFC9148 where it could have nicely been documented
(but we can of course always do it in constrained voucher, updating (amending) RFC9148.
Except that i have no idea what bureaucracy we're inviting trying to maned an
RFC from a different WG.

>     > A lot more disappointed that RFC9148 didn't care about DNS-SD discovery than back when
>     > RFC7030 was written, but i guess they probably think their CoAP group communications discovery
>     > is better.
> 
> If we had known that we'd spend 2 years in the RFC-editor Q waiting for
> DTLS1.3, then maybe we would have done the document differently.

Sure.

>     > Except that neither one works for L3 networks multicast IMHO (i am getting no
>     > response to that request i sent meaning at least nobody knows or cares), and COAP
>     > does not provide unicast discovery like DNS-SD from all i know.
> 
> RD is a core part of RFC7252:
> https://www.rfc-editor.org/rfc/rfc7252.html#section-7
> 
> you can do it multicast or unicast, and RFC9148 does that.

Sure, but i am worried about understanding how realistically working either
of these dependencies are:

-> Which network of interest has multihop ASM IP MUlticast to support
   multicast coap discovery (via FF05::FD) ? I just have a few decades
   of challenges in other networks of getting multicast deployed there,
   which is why i am burned. And remember that the IETF explicitly worked
   on avoiding multihop mDNS for exactly the same reason. I wrote this in
   more detail in the question i sent to other WGs (that nobody replied to!)

-> For unicast, what exactly is then the method to discover the URI of the
   registrar (across >= 1 L3 hop) ? If there is some mandatory support
   not only for unicast DNS (requests) but also automatically working
   registration of DNS names in some type of networks, that would be great.
   But that would then for example increase priority for us to define
   DNS-SD details for cBRSKI (and BRSKI outside ANI for that matter equally).

This is what i am trying to figure out. Without either of these answers,
RFC7252 could equally define that discovery depends on perpetuum mobiles
or human configuration of discovered results (which i fear is what happens
right now in all lab settings).

>     > I really wonder how networks using RFC9148 intend to automate renewal, even absent
>     > automated secure bootstrap. I bet there is not going to be any interop requirements
>     > anyhow, and vendors are just hacking in some well-known DNS name for
>     > EST servers (est-server.<domain>) and ultimately do rely on unicast DNS.
> 
> At the beginning of the effort, I asked this question.
> 
> I was told that there were multiple sensor networks (consisting of millions
> of sensors) where the devices had been deployed with manufacturer installed
> IDevID.  The (WiSun) network operates with them today.  My understanding is
> that there is a desire to rekey all these devices (over UDP) using 9148.
> That the presence of the keygen target was important for this use case,
> because there was a desire not to rely upon in-device random number
> generator.   (And the private key size for IDevID was now considered weak)

Interesting data point, although i am not sure how it relates to the question:
Any idea how those networks discover the EST (over coaps) server ?

> If not for the above, I think that we would not have split RFC9148 out.

What do you men with "split out" ? 

Thanks!
    Toerless

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]