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

["Peterson, Jon" <[e-mail]>]

Hi Roman,

Thanks for these notes, you have some good catches here. There’s a new version of the i-D with fixes detailed below.



----------------------------------------------------------------------
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.

Okay, I added some text.


** 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:

Upfront, this text is not describing on-the-wire protocol behavior, but is anticipating potential implementation environments that differ from the typical deployed STIR architecture, and is therefore just kind of sketching some approaches that might be helpful.

-- 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)?


It would be relevant if, for example, the verification service functions were executed on the user’s endpoint. Not the usual deployed architecture, but also not something I’d rule out.


-- 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.

I believe the final clause of the second sentence above explains how it would work if the certificate was expired.


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

At a store-and-forward messaging system, per the stat of the paragraph.



----------------------------------------------------------------------
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

Okay, I cut those.


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

Used “machine-in-the-middle”.


** 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)

Okay, added.


** 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?

Well, I mean, it’s not, which is what that sentence is trying to say (RFC8591 says that its interaction with STIR is out of scope). Changing this to “would require further specification.”


** 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”

“ppt” is short for “PASSporT Type”, I’m not sure it is less ambiguous to put it that way…


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

In the formal description you requested above, I added some text about that (but the short answer is, new spec required).


** 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.

Good catch – I meant RFC8591 there. Fixed.


** 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/

I think that’s an implementation-specific matter, rather than a protocol matter. That’s why I’m putting it a bit vaguely. I don’t think it’s our job to prescribe the user experience. I’m just trying to suggest what tools the protocol as it stands would offer to implementations.

(typo fixed)


** 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?

Well, what the text says now is that if the PASSporT is being conveyed via SIP in an Identity header, then it is checked by the VS as it would be in RFC8224. If it’s not, but instead conveyed by some out-of-band or store-and-forward system, it’s presumably done at the same time as the verification of the rest of the PASSporT, but I don’t really want to be too prescriptive. Bear in mind that verification is something that more than one entity in a signaling path can perform – you could have an intermediary perform it, say, and then some entity closer to the terminating party do it again.

Broadly, in the SIP context, a 438 “Invalid Identity Header” would be the most appropriate response. I added some text to that effect, but again, it is really up to the local policy of the recipient to determine whether an error is sent in the backwards direction when STIR verification fails (e.g., in some environments, a successful verification results in a “check mark” by the telephone number in the U/X, whereas an unsuccessful verification results in the call still going through but without a check mark – rather than the call being blocked or what have you).


** 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.

No, it’s intended to apply to out of band methods as well.


** 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).

Changed “timer” to “freshness window”..


** 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)

It it the interaction of STIR with DMARC that is out of scope here, not the notion that it is possible to convey a PASSporT to work with MMS, if someone wanted to do so.


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

Expanded (and a ref added).


** 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.

Added a “with”.


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


I’m not sure where that rumor got started, but this specification is not SIP-specific, any more than STIR itself is.

Jon Peterson
Neustar (a TransUnion company)


_______________________________________________
stir mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!7p4qMgqK95c6As9xa9-cIxwa6vmdEUTWkRnxZmcSgbLIa1ky_JRHBBeN7F3pHWvrkWukiWWrtm-Sr5JNOfkd5Q$