Subject: [sacm] Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 08:54:54 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-sacm-nea-swima-patnc-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

More detail in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3336

IMPORTANT
I consider the following comment important, though I have chosen to make
it a comment rather than a discuss.

   Software records on an endpoint are generally not considered to be
   sensitive, although there can be exceptions to this generalization as
   noted in the section on Privacy Considerations.  In general, an

I'm not sure where "generally" comes from. I consider it
sensitive and we know that people have been jailed for running certain
software.  Even the rest of this section provides strong evidence that
this is sensitive. So I think you should remove this claim and rewrite
this paragraph to acknowledge that this is sensitive information

MINOR
   The primary use of exchanging software inventory information over the
   PA-TNC interface is to enable a challenger (e.g.  NEA Server) to
   obtain inventory evidence about some system in a way that conforms to
Nit: e.g.,

   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly and reliably providing the
   reported Software Inventory Evidence Collection to the NEA Server.
This seems like a pretty significant narrowing of the use cases. Can you
explain what use cases this is useful for if the machine can lie?

   A Record Identifier is a 4-byte integer generated by the SWIMA-PC
   that is uniquely associated with a specific record within the
In what byte order? Signed or unsigned? If it's actually an integer this is
important.

   that SWIMA-PV), the SWIMA-PC MUST assign that source a Source
   Identification Number, which is an 8-bit unsigned integer.  Each item
   reported includes the Source Identification Number that provided that
What happens if you have 256 sources? Must these be sequential?

   record that is no longer available, the SWIMA-PC SHOULD return a
   0-length record.
Is this different from what happens if you are requested to send something that
never existed? If so, is this a recipe for unlimited growth.

   An EID is a 4-byte unsigned integer that the SWIMA-PC assigns
   sequentially to each observed event (whether detected in real-time or
What byte order?

   very first recorded event in a SWIMA-PC's records within an EID Epoch
   MUST be assigned a value of 1 or greater.  Note that EID and EID
   Epoch values are assigned by the SWIMA-PC without regard to whether
Why "or greater" this is the only place you allow a gap.

   event records MUST only contain events with EIDs that all come from
   the current Epoch.
How does the SWIMA-PC garbage collect? It seems like the answer is it can just
change epochs?

   records.  This ensures that every partial list of event records is
   always complete within its indicated range.
Is the point here that the list must be consecutive?

   |              | (8)        | PA-TNC specification [RFC5792].       |
   +--------------+------------+---------------------------------------+
It's up to you, but isn't this table largely duplicative of S 5.2?

   |   Software Identifier Length  | Software Identifier (var len) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OK, I think I see what's going on here: you can have an arbitrary number of
instances of this block. Maybe you should show more than one in the diagram
with an indication that it's controlled by SWID Count? Or a .... or something?
This comment applies to the other PDUs in this document as well.

   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
I would not put lines between these timestamp fields because they are actually
one giant field

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 20 Feb 2018 14:21:30 +0000

Hello Eric,

>    sequentially to each observed event (whether detected in real-time or

Section 5.3 (Message Diagram Syntax) states that "Multi-octet fields representing numeric values MUST be sent in network (big-endian) byte order." I have tweaked this to simply say "All fields representing numeric values MUST be sent in network (big-endian) byte order". Is this sufficient or do feel that this should be reiterated in the individual field descriptions? (I did go through and make sure that every integer is explicitly "unsigned", per your other comment.)

> How does the SWIMA-PC garbage collect? It seems like the answer is it can
> just change epochs?

You are correct. The second paragraph of section 3.7.1 (Event Identifiers) states that "In the case where a SWIMA-PC needs to reset its EID counter, either because it has exhausted all available EID values or because the SWIMA-PC's event log becomes corrupted, then a new EID Epoch MUST be selected." Apart from that passing mention, I don't believe the document makes any comment. Do you feel additional emphasis on this topic is necessary?

Finally, an aesthetic check on repeated fields. I have attempted the following:
--------------
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags        |                Event Count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request ID Copy / Subscription ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       EID Epoch                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Last Consulted EID                              |
   =================================================================
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Record Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Data Model Type PEN                 |Data Model Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Id Num |  Action       |   Software Identifier Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Software Identifier (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Software Locator Length     |Software Locator (variable len)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 8: Software Identifier Events Attribute

   Everything after the line of double bars (======) is repeated a
   number of times equal to Event Count.
-------------

Do you feel that this clarifies the repeated fields in the diagram? The alternative would be to do something like:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags        |                Event Count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request ID Copy / Subscription ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       EID Epoch                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Last Consulted EID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               						|
   |    SUB-BLOCK (Event Count times)			|
   |							|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure n: Main message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Record Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Data Model Type PEN                 |Data Model Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Id Num |  Action       |   Software Identifier Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Software Identifier (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Software Locator Length     |Software Locator (variable len)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure M: Sub-block

I'm interested in your thoughts as to which of these better clarifies the nature of the repeated fields.

Thanks again for your help.

Charles

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 10:55 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Karen
> O'Donoghue <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-patnc-02:
> (with COMMENT)
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Feb 2018 06:55:35 -0800

On Tue, Feb 20, 2018 at 6:21 AM, Schmidt, Charles M. <[email-masked]>
wrote:

> Section 5.3 (Message Diagram Syntax) states that "Multi-octet fields
> representing numeric values MUST be sent in network (big-endian) byte
> order." I have tweaked this to simply say "All fields representing numeric
> values MUST be sent in network (big-endian) byte order". Is this sufficient
> or do feel that this should be reiterated in the individual field
> descriptions? (I did go through and make sure that every integer is
> explicitly "unsigned", per your other comment.)
>
>
Yeah, I make notes as I go and then left this one because I think that
might be confusing as people read in order.

I'm not sure what the best approach is, TBH. Maybe say it up front too?

> You are correct. The second paragraph of section 3.7.1 (Event Identifiers)
> states that "In the case where a SWIMA-PC needs to reset its EID counter,
> either because it has exhausted all available EID values or because the
> SWIMA-PC's event log becomes corrupted, then a new EID Epoch MUST be
> selected." Apart from that passing mention, I don't believe the document
> makes any comment. Do you feel additional emphasis on this topic is
> necessary?
>

It confused me a bit. Perhaps you might say "or has exhausted the space
allowed for event storage"

> Do you feel that this clarifies the repeated fields in the diagram? The
> alternative would be to do something like:
>
>                         1                   2                   3

I think the second is better, but as you say it's aesthetic.

FWIW, I usually do these big blockaf (e.g., timestamp) s by eliding the
horizontal bars rather than the vertical ones, but again, it's taste.

Best,
-Ekr

> > Is this different from what happens if you are requested to send
> something
> > that
> > just

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 21 Feb 2018 18:52:54 +0000

Hi Eric,

Thanks for the clarifications. I'll make the updates you suggest.

Thanks for the help.

Charles

> Sent: Tuesday, February 20, 2018 8:56 AM
> To: Schmidt, Charles M. <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-
> patnc-02: (with COMMENT)
> 
> 
> 
> On Tue, Feb 20, 2018 at 6:21 AM, Schmidt, Charles M. <[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 	Hello Eric,
> 
> values MUST be sent in network (big-endian) byte order". Is this sufficient or
> do feel that this should be reiterated in the individual field descriptions? (I
> did go through and make sure that every integer is explicitly "unsigned", per
> your other comment.)
> 
> 
> 
> 
> Yeah, I make notes as I go and then left this one because I think that might
> be confusing as people read in order.
> 
> 	You are correct. The second paragraph of section 3.7.1 (Event
> Identifiers) states that "In the case where a SWIMA-PC needs to reset its EID
> counter, either because it has exhausted all available EID values or because
> the SWIMA-PC's event log becomes corrupted, then a new EID Epoch MUST
> be selected." Apart from that passing mention, I don't believe the document
> 	> From: Eric Rescorla [mailto:[email-masked] <mailto:[email-masked]>
> ]
> 	> To: The IESG <[email-masked] <mailto:[email-masked]> >
> 	> Cc: [email-masked] <mailto:draft-ietf-
> [email-masked]> ; [email-masked] <mailto:[email-masked]> ;
> Karen
> 	> O'Donoghue <[email-masked] <mailto:[email-masked]>
> >; [email-masked] <mailto:[email-masked]> ;
> 	> [email-masked] <mailto:[email-masked]> ;
> [email-masked] <mailto:[email-masked]>
> <http://ietf.devsvcdev.mozaws.net/D3336>
> 	>
> 	> IMPORTANT
> 	> instances of this block. Maybe you should show more than one in
> the
> 	> diagram
> 	> I would not put lines between these timestamp fields because they
> are
> 	> actually
> 	> one giant field
> 	>
> 	>
> 
> 
>