Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Christian Amsüss 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 --
Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Christian Amsüss wrote: >> We wrote something similiar for RFC8366 or 8995, but I think we ripped >> most of it out. For instance, if a device had a valid IDevID with a >> notBefore of 2021-02-01, and the RTC said 1980-01-01 [good old DOS >> epoch], then one could be sure it was at least 2021-02-01! > Does either of those have a versioned history? Without a change log in > them, and no mention of the example DOS epoch discoverable in either, I > couldn't find what was there. Yes, DT and github.com/anima-wg/bootstrap. I looked back a bunch coming up with: https://github.com/anima-wg/anima-bootstrap/blob/5f2527381c291af12f4f9df3c26feb1d079bda20/dtbootstrap-anima-keyinfra.txt section 2.6.1... but thtat's really the same text as in the RFC. Let' try git blame... https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-18#section-2.6.1 This might not be the last version that had this more complex text. It seemed like it was riff for distracting review comments, and didn't really help our primary focus, so it go removed sometime later. Unfortunate that the version buttons on the right don't retain the section number. -- Michael Richardson. 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
Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
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
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [T2TRG] Proposed document: draft-amsuess-t2trg-raytime-01
On 2023-07-20, at 14:52, Christian Amsüss wrote: > > On Wed, Jul 12, 2023 at 06:57:38PM -0400, Michael Richardson wrote: >> I don't think this belongs in t2trg, but I don't object. >> maybe it goes into ACE or IOTOPS. > > I'll appreciate if any of those wanted it; first people I've talked to > about it pointed me to T2TRG. I'll try to get a hold of the chairs on > the virtual hallways. I think the point is that each WG has started something and then found that really writing it up is a bit more work than it initially seemed. E.g., 7228bis (LWIG, soon IOTOPS?) has some relevant text. https://www.ietf.org/archive/id/draft-ietf-lwig-7228bis-00.html#section-4.4 If the focus of the document is on designing a protocol or an operational practice, an IETF WG is about right. If the focus is on understanding the design space and documenting existing approaches and evaluating them, T2TRG is right. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Hello Michael,
On Wed, Jul 12, 2023 at 06:57:38PM -0400, Michael Richardson wrote:
> I don't think this belongs in t2trg, but I don't object.
> maybe it goes into ACE or IOTOPS.
I'll appreciate if any of those wanted it; first people I've talked to
about it pointed me to T2TRG. I'll try to get a hold of the chairs on
the virtual hallways.
> We wrote something similiar for RFC8366 or 8995, but I think we ripped most
> of it out. For instance, if a device had a valid IDevID with a notBefore of
> 2021-02-01, and the RTC said 1980-01-01 [good old DOS epoch], then one could
> be sure it was at least 2021-02-01!
Does either of those have a versioned history? Without a change log in
them, and no mention of the example DOS epoch discoverable in either, I
couldn't find what was there.
(8366 has a section on clock sensitivity, but that is explicitly listing
required-verification-of-expiry, nonce-based and
never-expiring-vouchers, without touching the middle ground.)
> {There is a Doctor Who and/or Blakes Seven and/or Stargate plot here though.}
Yes, but I think I only get away with one toy reference per document ;-)
Thanks for your points and the issue
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
