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

[Toerless Eckert <[e-mail]>]

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

> Toerless Eckert <[e-mail]> wrote:
>     >> 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.

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].

>     > 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... ?
> 
> 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.

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...

>     > 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.. ?)
> 
> 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.

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.

>     >> 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".
> 
> 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. 

>     >> 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" ?
> 
> 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... ?

> 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.

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

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