Christian Amsüss <christ...@amsuess.com> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
