Subject: [Anima] draft-ietf-anima-constrained-voucher discovery questions

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Apr 2022 14:26:51 +0200

> 6.5.1.  Discovery
> 
>    The Pledge discovers an IP address and port number that connects to
>    the Registrar (possibly via a Join Proxy), and it establishes a DTLS
>    connection.

This is very terse and possibly not completely correct. 

How about:

   The Pledge discovers an IP address and UDP port number which together allow the
   pledge to establish a DTLS connection to the Registrar, directly via a UDP
   port of the Registrar or via a UDP port of a BRSKI-DTLS Join Proxy.

Is this a correct expansion ?

But the discovery itself is described in draft-ietf-anima-constrained-join-proxy,
right ? E.g.: it could involve either directly discovering brski.rjp if there
is no join proxy or discoverin brski.jp if there is a join proxy. True ?
Would be good to at least provide an appropriate pointer that describes this. And
i am not sure that  draft-ietf-anima-constrained-join-proxy actually describes how
a pledge would use either brski.jp or brski.rjp... ?

>    No further discovery of hosts or port numbers is required, but a

beyond the discovery described in the prior paragraph ? Would suggest to
either remove this part of the sentence or add more details. As it stands it
is like be inserting into this email: It is not required to send toerless chocolade.
(huh, why the heck does toerless mention this - what other cases are there
 where toerless would actuallt expect chocoade. why does he mention it.. ?)

>    pledge that can do more than one kind of enrollment
>    (future work offers protocols other than [I-D.ietf-ace-coap-est]),
>    then a pledge may need to use CoAP Discovery to determine what other protocols are
>    available.

If the solultion os CoAP Discovery, then it seems the problem should maybe also
be rewritten to "pledge that can do more than one kind of enrollment mechanism using CoAP".

I of course would equally be worried about a pledge that could not ONLY do CoAP
based enrolments but also other enrollments, for which CoAP discovery would not
help, so when you open the box of alternative pandoras, i wonder why you explicitly
only discuss CoAP discovery. Some explanation might help for the text to avoid
raising questions it doesn't answer.

>    A Pledge that only supports the EST-coaps enrollment method SHOULD
>    NOT use discovery for BRSKI resources.  It is more efficient to just

Confused. Do i translate this correctly to say "do not use brski.jp/brski.rjp discovery
from anima-constrained-join-proxy" ?

Cheers
    Toerless

>    try the supported enrollment method via the well-known BRSKI/EST-
>    coaps resources.  This also avoids the Pledge doing any CoRE Link
>    Format parsing, which is specified in [I-D.ietf-ace-coap-est],
>    Section 4.1.
> 
-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Apr 2022 11:29:20 -0400

> How about:

Seems like good WGLC comment :-)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Apr 2022 11:58:20 -0400

> This is very terse and possibly not completely correct.

https://github.com/anima-wg/constrained-voucher/issues/224

    > a pledge would use either brski.jp or brski.rjp... ?

You are a bit right.
The discovery by the proxy of the Registrar on a *NON* ACP network uses brski.rjp.
This discovery is *specific* to *this* kind of stateless join proxy.
The registrar and the proxy have to agree to use this extension.

The discovery by the pledge of the Registrar does not have any other place
discovery by CoAP RD.   constrained-voucher does not define it, so that's why
it is in join-proxy.

    > where toerless would actuallt expect chocoade. why does he mention

To point it your analogy, once we have determine that Toerless is Hungry, we
do not need to determine whether you want chocolate or not, because, only
triangular chocolate bars will fit through the transport protocol.

    > be rewritten to "pledge that can do more than one kind of enrollment mechanism using CoAP".

The pledge could also do DPP or CHIP/MATTER or 802.1x, which is not using CoAP.

    > from anima-constrained-join-proxy" ?

brski.jp is used to find the proxy in order to reach the Registrar.

Once a connection to the Registrar is found, then the question becomes: can
the pledge do CMP as well as EST? If so, it might need to discover if the
Registrar can do that.

I haven't opened another issue yet,because I'm not sure what to write yet.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 8 Apr 2022 17:19:59 +0200

1. One more thing i stumbled across:

| 6.2 TLS Client Certificates: IDevID authentication
| 
|    As described in Section 5.1 of [RFC8995], the Pledge makes a
|    connection to the Registrar using a TLS Client Certificate for
|    authentication.

This reads as if constrained-voucher/BRSKI uses TLS instead of DTLS.
Suggest something like:

! 6.2 Client Certificates: IDevID authentication
! 
!    As described in Section 5.1 of [RFC8995], the Pledge makes a
!    connection to the Registrar using a Client Certificate (called the IDevID)
!    for authentication, but uses DTLS instead of TLS.

(aka: remove confusing use of TLS, and establish a linkage from IDevID in the
title to client certificate. Especially 5.1 of rfc8994 is the only place that
doesn't mention IDevID and is therefore somewhat confusing when read by itself
(which readers might do when they just try to read the reference here).

2. I kinda fail why 6.5.1 and 6.5.2 are extensions to BRSKI. To me they just look
like separate aspects of constrained browser BRSKI as 6.1 ... 6.4. Aka:
renumber 6.5.1 to 6.5, and 6.5.2 to 6.6, remove that "extensions to BRSKI" notion ?

3. It seems cumbersome to talk about the modified BRSKI in this solution without
having a proper name for it. Could we / should we not call it cBRSKI, C-BRSKI, CBRSKI
or anything similarily compact ? And of course put it in the title - (cBRSKI)
instead of (BRSKI).

4. Wrt to 6.5.1

>     >> the Registrar (possibly via a Join Proxy), and it establishes a DTLS

Would suggest to replace with (if correct):

! As described in RFC8995, section 4.2 and 4.2, BRSKI discovers an IP address
! and TCP port number for the registrar and (when used) proxy to establish
! the TLS connection from pledge to Registrar. Likewise, cBRSKI needs to
! discover IP address and UDP port number for the registrar and (when used) proxy
! to establish the DTLS connection from pledge to Registrar. This is described
! in [I-D.ietf-anima-constrained-join-proxy].

> The registrar and the proxy have to agree to use this extension.

Ok, but we need to text to point to constrained-join-proxy for this section (as
proposed by my text proposal above) in constrained-voucher to make any sense at all,
otherwise its confusing leading nowhere.

> The discovery by the pledge of the Registrar does not have any other place discovery by CoAP RD.

"any other place discovery by CoAP RD" ? Can you rephrase pls. can't parse.

|No further discovery of hosts or port numbers is required, but a
|pledge that can do more than one kind of enrollment (future work
|offers protocols other than [I-D.ietf-ace-coap-est]), then a pledge
|may need to use CoAP Discovery to determine what other protocols are
|available.

I would still recommend to remove "N further discovery of hosts or port numbers is required",
as its unnecessary and at least to me confusing to be mentioned.

Is CoAP Discovery applicable to non-coap based protocols ? I would think not.
In that case the sentence should be changed to "can do more than one kind of CoAP based enrollment...".

But still, the sentence is confusing, because to the best of my understanding,
constrained-join-proxy already says that cBRSKI _IS_ using CoAP Discovery, whereas
this sentence sounds as if CoAP discovery would only required when more than
whats defined in this doc and constrained-proxy is done...

> triangular chocolate bars will fit through the transport protocol.

When you state the obvious without a good lead-in, people will start to question
that it was obvious in the first place. Hence i am suggesting to remove.

> The pledge could also do DPP or CHIP/MATTER or 802.1x, which is not using CoAP.

If CoAP Discovery can axctually be used to do discovery for those non-CoAP protocols,
then text should explicitly say so, because that would i think be non-obvious and
unexpected. 

> brski.jp is used to find the proxy in order to reach the Registrar.

I thought that looking for brski.jp is an instance of CoAP discovery... ?

> the pledge do CMP as well as EST? If so, it might need to discover if the

Hah, ok. That IMHO must be written explicitly. Especially the fact its dual-stage.

But that confuses me further.

Do brski.jp and brski.rjp guarantee that the proxy/registrar do support EST-coap ?

Or else: How do we avoid that a registrar that may only support CMP-coap but not
ESP-coap is not discovered by a pledge that can only do EST-coap ?

> I haven't opened another issue yet,because I'm not sure what to write yet.

Sure. And i have not responded to the github yet so that we can keep the whole WG in the loop,
while we're discussing the best resolution ;-)

Cheers
    Toerless