[stir] Roman Danyliw's Discuss on draft-ietf-stir-messaging-06: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-stir-messaging-06: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-messaging/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.2.  The format of the msgi claim is defined by a single example. 
Is the format ‘{“sha256”,”sha384”,”sha512”} <hyphen> <hex encoded hash>’? 
Please specify it more formally.

** Section 4.
   Thus any store-and-forward messaging
   system relying on PASSporTs must take into account the possibility
   that the certificate that signed the PASSporT, though valid at the
   time the PASSporT was generated, could expire before a user reads the
   message.  This might require storing some indicator of the validity
   of the signature and certificate at the time the message was
   received, or securely storing the certificate along with the
   PASSporT, so that the "iat" field can be compared the expiry window
   of the certificate prior to validation.

Please correct me here if I am misunderstanding the deployed STIR architecture:

-- Why is the time the user reads the message relevant?  Isn’t the verification
done by either the proxy or UA at the time of receipt (irrespective of when it
is read)?

-- How would the verification process work if the certificate was expired?  As
some short-lived certificates are used instead of revocation, how would a
verifier distinguish that.

-- Who is the guidance of storing additional state directed at – all verifiers?
verification proxies?


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

** idnits returned:
  == Unused Reference: 'RFC4474' is defined on line 392, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7159' is defined on line 398, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3311' is defined on line 437, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4916' is defined on line 445, but no explicit
     reference was found in the text

** Section 3.1.  In the spirit of inclusive language, please rephrase
“man-in-the-middle attacks”.

** Section 3.2.  Please provide a bit more explanation on a “cut-and-paste
attack” either inline or with citation.  Perhaps “A cut-and-paste attack is one
where the Identity header field from a legitimate request for one user is
reused into a request for a different user.” (from RFC8224)

** Section 3.2.
   The interaction of [RFC8226] STIR certificates with S/
   MIME for messaging applications requires some further explication;
   and additionally,

Where is using STIR certificates with S/MIME explained?

** Section 3.2.  Editorial.
   In order to differentiate a PASSporT for an individual message from a
   PASSporT used to secure a telephone call or message stream, this
   document defines a new "msg" PASSporT Type

It would be helpful to clarify that the behavior being described here is
extending PASSporT via a “ppt” claim set to “msg”

** Section 3.2.  What is the expected approach for hash algorithm agility?

** Section 3.2.

   Any such environment would require a profile of
   this specification that reduces the scope of protection only to the
   CPIM payload, as discussed in [RFC8946] Section 9.1.

Section 9.1 of RFC8946 doesn’t explain any CPIM mechanism or a way to reduce
the scope of a protection.

** Section 3.2.
   The
   potential for replay attacks can, however, be largely mitigated by
   the timestamp in PASSporTs; duplicate messages are easily detected,
   and the timestamp can order mesages displayed to the user inbox in a
   way that precludes showing stale messages as fresh.

-- Can the approach by which replay attacks are mitigated be clarified?  It
looks like the text is saying deliver all messages, sort them by timestamp and
by human inspection the “replay attack” is mitigated. -- Typo.
s/mesages/messages/

** Section 3.2.  When in the hash conveyed in the msgi claim checked relative
to the verification procedures of Section 6.2 of RFC8224?  What is the expected
error handling if the hash does not match?

** Section 3.2.  Editorial. In this discussion of messaging, it would be
helpful to clearly state the applicability/scope of the new ppt=”msg”
extension.  I think it intended only for messaged conveyed via SIP via the
MESSAGE method.

** Section 3.2.
   In such cases, the expiry timers recommended by
   [RFC8224] may be too strict, as routine behavior might dictate the
   delivery of a MESSAGE minutes or hours after it was sent.

I couldn’t find a use of the term “timer” in RFC8224.  Is this text referring
to Step 4 of Section 6.2 of RFC8224 which notes the need for checking whether a
message meets freshness according to local policy and RECOMMENDS 60 seconds? If
so, please make the language more consistent (and/or provide a reference into
RFC8224).

** Section 3.2.1.   Editorial. Note that using PASSporT for any protocols other
than SIP is also out of scope (the same way support for MMS with SMTP is out of
scope)

** Section 3.2.1. Is the “SMPP” referenced here “Short Message Peer-to-Peer
Protocol”?  Can this be expanded and cited?

** Section 4.  Editorial.
... so that the "iat" field can be compared the expiry window
   of the certificate prior to validation.

There is a missing word here.

** Section 8. The second paragraph appears to be commenting on behavior not
described by this document.  Is it needed?