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

[Christian Amsüss <[e-mail]>]

Hello Michael,
(Group(s): See especially PS at the bottom)

thanks for your feedback, that's the very kind I was hoping for.

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.

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


> You did a bunch of YANG:
>   uses "vch:voucher-artifact-grouping" {
>      augment "voucher" {
> 
> And I really wish that it worked that way.
> But, it just doesn't.
> 
> https://play.conf.meetecho.com/Playout/?session=IETF116-NETMOD-20230331-0030
> Start at 1:53:00.

Thanks for the good pointer, I've enjoyed your cake example very much.
My takeaway is that not only would we need to linearize all
augmentations (something that'd be doable if additions required an
"updates" on the first document), but even then the updated versions
would be mutually incompatible.

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


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

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?

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?

If so, a next good step for me would be major rewrite in which data is
not transported in the voucher, but equivalent resources to /crts and
/sen are defined for ACE.

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.

BR
Christian

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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom