Re: [Rats] Response to Eliot's major issues with EAT

[Kathleen Moriarty <[e-mail]>]

Good morning.  I read through the response and have some comments.

My first concern is that Eliot, a long time IETFer walked away from the
conversation due to responses and not getting anywhere. He offered very
good advice not just to get through the IETF process, but to increase
interoperability for EAT implementations. Another look at his (and likely
other) reviews would be a good starting point.

Please see the RFC on consensus (
https://datatracker.ietf.org/doc/html/rfc7282) in the IETF as it will be
important as this document nears the next stages. Consensus in the IETF
could mean that one person is correct and it trumps all other views, and it
also means consensus is a majority. Consensus may be judged by the chairs
and if it remains locked, it can go up to the AD.

On Thu, Jun 23, 2022 at 3:09 PM Laurence Lundblade <[e-mail]>
wrote:

> Here’s PR’s and comments on the major issues from Elot’s IoT review of
> EAT.  I have made some PR’s for the minor issues, but haven’t listed them
> here.
>
> Thanks for the comments. They are making the document better.
>
> LL
>
>
> Major:
>
> The most major problem with the document is this:
>
> 7.  Profiles
>
>    This EAT specification does not gaurantee that implementations of it
>    will interoperate.  The variability in this specification is
>    necessary to accommodate the widely varying use cases.  An EAT
>    profile narrows the specification for a specific use case.  An ideal
>    EAT profile will guarantee interoperability.
>
> This is quite counter-cultural to the IETF.  You start with the
> smallest set of functionality and then expand outward to cover
> different use cases that make use of different extensions.  I'm
> not saying that profiles would not be necessary, but that some
> additional thought be given to extension mechanisms.
>
> I agree, it may be helpful to look at the studies on success for adoption.
It points back to what Eliot is suggesting. You have a small core that is
extensible to meet other use cases. EAt has the potential to be a very
important protocol. If it does not meet criteria to aid adoption, something
else that does will come along after and enjoy greater success. It would be
a shame to have to do this multiple times.  An example includes the
incident related exchange protocol formats. There are several. The most
complex that has lots of flexibility and has been mandated has struggled.
STIX covers just about every use case and then you apply a profile to make
sure parties interoperate. This means that implementations vary and may
focus on a profile, so there may not be a core set of data that allows
interoperability between implementations. On the other hand, there's MISP
with a small core that is extensible. MISP is the clear winner and it's due
to this simplicity to enable interoperability as well as extensibility to
meet specific use cases. Here's a workshop report:
https://www.ietf.org/blog/views-internet-technology-adoption/

> This statement in particular is quite disturbing.
>
>    In some cases CDDL may be created that replaces CDDL in this or other
>    document to express some profile requirements.
>
> Not only is this counter-cultural, but it would require an Updates:
> header on any such profile, and would further just be plain out
> confusing.
>
> In short, the profile mechanism is harmful to the very concept of
> interoperability.
>
> The updated text points out the sections in CBOR, COSE and JWT that
> discuss implementation variation. COSE actually use the term “profile” to
> name its section.
>
> As I commented previously, I think EAT profiles are a mechanism to
> explicitly tackle all this stuff all in one place that predated EAT (and is
> mentioned in various RFCs already).
>

It's important to consider Eliot's point here and this will likely be
raised again in other review phases of this document to hold up its
publication.


>
> https://github.com/ietf-rats-wg/eat/pull/215
> https://github.com/ietf-rats-wg/eat/pull/216
> https://github.com/ietf-rats-wg/eat/pull/210
>
>
> Section 4.1:
>
>    The nonce MUST have 64 bits of entropy as fewer bits are unlikely to
>    be secure.  A maximum nonce size is set to limit the memory required
>    for an implementation.
>
> There are two sides to this equation: the generator of the nonce and
> the consumer.  How is the generator supposed to know how much memory
> the consumer has?
>
> The memory use of the nonce for the consumer is capped by the
> specification of a maximum size. That maximum is 74 bytes per nonce which
> is a relatively small amount that any implementation should be able to
> afford.
>
> I think it is right to cap the size of the nonce and a few other critical
> and common claims like UEID, but obviously we can’t cap them all.
>

Was there any agreement on this? I just see your response?

>
>
> Section 4.2.1:
>
>    UEIDs are variable length.  All implementations MUST be able to
>    receive UEIDs that are 33 bytes long (1 type byte and 256 bits).  No
>    UEID longer than 33 bytes SHOULD be sent.
>
> 256/8 = 8.  8+1 = 9.  I don't understand the parenthetical.
>
> Clarifications here <https://github.com/ietf-rats-wg/eat/pull/196>. No
> more need to do math.
>

What update was made in the draft? What explains the discrepancy in the
byte length? The link didn't explain it or the link isn't the right one
anymore.


>
> Between Section 4.2.1 and 4.2.2 there is a particular use case I would
> like to understand:
>
> If a system integrator resells a bunch of components that have been
> tied together, what guidance is given as to which [S]UEID should be
> exposed and for what purpose?  Does the consumer consume a full array
> of each of these things?  What's the intent?
>
> The main intent here is that this is use case specific and that detailed
> behavior should be addressed by a profile. There’s no way this document can
> address all the use cases.
>
> Wording improvement to SUEDs is here:
> https://github.com/ietf-rats-wg/eat/pull/197/files
>
>
> Section 4.2.6:
>
> Please do not use a free-form text field for the software.  That makes
> comparisons and authorities quite difficult.  In fact between this
> section and section 4.2.7, you may wish to consider using Package
> URLs.
>
>
> It seems like there a lot of ways of naming SW and no particular one that
> is as broadly applicable as EAT is so it’s not really possible to create a
> broad standard here.
>
> So the purpose of this claim is kind of a crude last resort (that I think
> will be valuable and useful).
>
> Note that this claim is to describe the final SW build/load for a finished
> device. Package URLs seem more about naming SW libraries that will be used
> in the build process. That said, I have no objection to a claim for them,
> but think it should be outside of EAT.
>
> I made some wording improvements:
>
> https://github.com/ietf-rats-wg/eat/pull/217
>
>
>
> Section 4.2.8:
>
> As a whole this section is a bit too talkative.  Also, there are many
> claims programs, and so I question the value its value.  If it is seen
> as important, then some qualitative statement about specific
> certifications seems more appropriate.
>
> A very controversial claim. See other discussion on RATS list.
>
> It tries very hard to explain why it is not based on certification and
> that if you want a list of certifications you should use a DLOA. Any
> suggestions to make it more clear without being more talkative?
>
>
> In general the CDDL for uints in particular requires .size values.
> Otherwise you are just asking for random failures based on the limits
> of varying tests.
>
> I went through all int and uint in the CDDL to see where a size could be
> imposed.
>
> I added a limit <https://github.com/ietf-rats-wg/eat/pull/201> for CoAP
> content-format.
>
> Others like bootseed and time stamps shouldn’t have a limit.
>
> The PEN registry doesn’t specify a limit and there is no limit on OID arc
> integers so I have not put a limit on it, but maybe we should. A limit of
> 32 bits would certainly be enough.
>
>
> 4.2.15  DLOA
>
>    This claim is typically issued by a Verifier, not an Attester.  When
>    this claim is issued by a Verifier, it MUST be because the entity has
>    received the certification in the DLOA.
>
> Unclear antedent.  Perhaps you mean:
>
>    This claim is typically issued by a Verifier, not an Attester.
>    Verifiers MUST NOT issue this claim unless they have received the
>    the certification in the DLOA.
>
> Same issue with multiple DLOAs.
>
> Also, is it possible that DLOAs will be produced in JSON at some point
> in the future?  If so, why not allow for that by not mentioning XML,
> and simply requirng observance of HTTP Content-type semantics?
>
> I’ve made fixes here <https://github.com/ietf-rats-wg/eat/pull/200>.
>
> To allow for JSON DLOAs I’ve removed any mention of XML. However this
> still relies on the DLOA standard so it would be up to it to specify JSON.
>
>
> Section 4.2.16
>
> Can a software manifest be an SPDX or CycloneDX document or a pointer
> to same?  There's a WHOLE lot of the former out there, and the latter
> is growing in popularity.  If this is the case, let's define
> appropriate types now.
>
>    If there is no CoAP identifier
>    registered for the manifest format, one should be registered, perhaps
>    in the experimental or first-come-first-served range.
>
> This sentence seems redundant, and the policy aspects opens this work
> up to the peril of a policy change for the IANA registry.
>
> There’s not any restrictions put on what can be use here, so yes an SPDX
> or CycloneDX can be used here.
>
> I floated the question of registering it now on the RATS list and no one
> expressed any interest, so I haven’t done anything to add that to EAT
>

I agree that these two formats should be supported. Eliot is correct that
these enjoy wide and growing adoption, especially SPDX. Industry players
not participating in this discussion are using these formats and are also
considering how they will do remote attestations.


>
>
> Section 9
>
> The IANA will not know what to do with this section as most of it is
> not directed to them.  Much of it might be better suited as a
> standalone document.  But it does raise the question of whether or not
> some sort of subregistry should be formed for new claims, where an
> appropriate evaluation could be managed through the IANA process (pick
> your favorite).  How that would be accomplished I leave to you.
>
> A lot of the early discussion in RATS was about how to define claims. It
> was a lot and it seems valuable to me so I wanted to capture and keep it.
> I’ve moved it into an appendix.
>
> https://github.com/ietf-rats-wg/eat/pull/202
>
>
>
>
I'd like this draft to be successful as a standard. Remote attestation and
having a lead format will go a long way toward automating security and
reducing the distributed demand on organizations for management in some
areas. Getting this right now will make a big difference. I echo Eliot's
concerns, especially on profiles.

Thank you for your work on this draft. I hope that the links are helpful to
better understand the IETF process and what is to come. In the IESG review,
the document will be held up on such points raised at this point of the
discussion as well as new points discovered. The DISCUSS positions block a
draft from moving forward until resolved as satisfactorily agreed by the
holder of the DISCUSS point.  Please let me know if I can assist with any
process questions as I'd like this document to be successful in its
publication process and in industry adoption rates.


>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen