Re: [Anima] [Ace] Proposing document draft-amsuess-ace-brski-ace-00

[Michael Richardson <[e-mail]>]

Christian Amsüss <[e-mail]> wrote:
    > On Wed, Jul 12, 2023 at 05:52:30PM -0400, Michael Richardson wrote:
    >> IN section 1.1, without having given a picture of what you are doing
    >> you start to say: "The alternative to this constraint is to declare
    >> this a blob" and this is really distracting to understanding what you
    >> *ARE* doing.

    > I think it's important, when limiting a reader's options, to point them
    > at what else they could do. I've created issue [1] for the time being
    > to not lose this, for I want to both resolve it for smooth reading and
    > keep all the pointers around.

All I'm saying is that it's an objection/diversion of thought essentially mid-sentence.
I'm not saying to remove it, I'm saying that is seriously distracts the reader.

    > [1]: https://gitlab.com/chrysn/brski-ace/-/issues/1

    >> "the pledge initiates EDHOC to the lake-authz.arpa anycast address,
    >> sending an encrypted identifier for its MASA (party W) in EAD_1."
    >>
    >> This sounds like it's a new thing, but I think it's just the
    >> lake-authz step one, right?

    > It is; a wording enhancement will be in the editor's copy soon.

Good.

    > If this is pursued in its YANG form (even partially), then I suppose
    > that the draft would only serve as a staging ground for the extra YANG
    > statements, with hopes to be sufficiently mature in time to be merged
    > into constrained-voucher before the batch is through. (No clue how
    > realistic that is right now).

Basically what I get from OPSAWG's publication of YANG modules is that they
go into a new RFC, with *JUST* the YANG module and when we need to revise the
YANG in anyway, a new RFC is published.
For instance https://datatracker.ietf.org/doc/rfc9418/ and RFC9417.

    >> My impression is that you don't really want the *MANUFACTURER*
    >> (authorized) to send down some ACE keying material.  That is, Volvo
    >> shouldn't be sending your car a key to open your building garage door,
    >> rather, your building owner should be.
    >>
    >> So, augmenting the voucher, which comes from the Manufacuter (MASA,
    >> aka W) to your pledge is wrong.  You want the ACE Authorization
    >> Server, aka V, to actually send the right keys.
    >>
    >> I think that either you want to use the new V/W relationship that
    >> EDHOC, lake-authz setup to send the keys in message 4, or you want to
    >> do a new FETCH on some some new resource to get them.

    > My hope has been that like with BRSKI where a domain CA public key can
    > be shipped right with the voucher, so I hoped to replicate the same
    > slimness here. IIUC, a device can use BRSKI to enroll DTLS credentials
    > without the need to do GETs to the registrar's /crts and the /s(r)en
    > interactions.

So draft-ietf-anima-constrained-voucher, has some optimizations that can
sometimes let the pledge skip the /crts, but why is that interaction so expensive?
Note that in lake-authz, the voucher isn't actually sent, rather just the
signature on what we expected to see in the voucher.... so extensions to the
voucher would be difficult to do.

    > Revisiting what cBRSKI can do, maybe I was wrong, and only the /crts
    > (and not the /s(r)en) part has an equivalence in BRSKI. Is that an
    > equivalence (between /crts and pinned-domain-cert)? And if so: Why can
    > the registrar not take a certificate request in the PVR and send the
    > result of /sen on to the pledge through the RVR?

So if I understand you, you'd like to avoid additional round trips by
stacking the certificate request with the PVR.   BRSKI-PRM does *exactly*
that, because in the store-and-forward ("DTN") nature of PRM, round trips
involve people walking up/down stairs.

In PRM we assume HTTP(S), and TCP and networks without much in the way of
challenge.  So transfering a few tens of kilobytes shouldn't be a concern,
and of course it will take multiple TCP segments.

In a challenged network I don't understand making any step of the transaction
bigger than 1200, or even close to that, rather than just doing a second
transaction.  Block mode seems less reliable from a state machine point of
view than a second transaction.

    > Or did I get things so wrong that everything in the voucher was only to
    > establish the first secure connection, and getting /crts etc is a
    > necessary next step anyway?

Yes, in general, that's the case.
https://www.sandelman.ca/SSW/talks/brski/brski-animation.pdf
slide 117.  Screencasts linked from https://brski.org/brski-impls.html

    > But then, looking at CoJP-over-authz, how does the pledge learn any
    > further keys and identities? Would it follow up the message_3 CoJP
    > request and the CoJP response with more requests in the same OSCORE
    > context that est-oscore requests (to get a DTLS context), or the next
    > version of this document's exchange? That'd mean that party V needs to
    > serve both as a JRC and DTLS/OSCORE data -- nothing I'd rule out, just
    > something that wouldn't have been apparent to me from the documents
    > I've read so far.

Why would you need a DTLS context?
I would think it would be okay to use the OSCORE context directly.
There are some elements here where I worry that we need some signaling from
Registrar to Pledge as to which flavour of onboarding is supported and/or
pledge is expected to do.  I think this will be a problem, but it's a problem
I welcome.

    > PS. It may make sense to meet on IETF117 hallways and chat on this some
    > more. It's too narrow a topic for a side meeting, but if there is
    > anyone else who may join in, we may want to pick a time for when and
    > where to chat. (I'm only there remotely this time).

pick a "morning" in gather.town.
I'm also remote.  Maybe Wednesday before ANIMA.

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