Re: [stir] WGLC Review of draft-ietf-stir-messaging-02

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

Hi Ben,

Getting to some older comments here (apologies for not getting to them sooner...). Inline below.

Jon Peterson
Neustar (a TransUnion company)
    
    Substantive:
    ----------------
    
    §3.2: 
    	• “msgi" MUST NOT appear in PASSporTs with a type other than "msg”…”
    		• Why is that? I guess if a VS that does not understand “msgi”, it might verify the sender number but not check integrity even though it was offered. Given that the fallback position is to do neither, is that really a fail?
    
The general fail that worried me is that someone might mistake a PASSporT covering a message for a PASSporT covering a telephone call. What would it mean to add a "msgi" to a SHAKEN PASSporT type, say? Does that mean the PASSporT is now about a message rather than a telephone call? Obviously any implementation that doesn't understand "msgi" would just ignore the element. I think it makes more sense to 

    	• Do we want to say anything about “msgi” interaction with encrypted messages? I assume one would calculate the msgi digest post-encryption.

Agreed it would be calculated after, but since we're scoping the integrity protection to the MIME layer, I think that goes without saying. But still, I'll add something about that.
    
    §3.2.1: “in which case something like out-of-band [RFC8816] conveyance”
    	• Would it make sense to also reference servprovider-oob?  (I can be convinced not to make this depend on a WIP draft, but I assume we are talking about an informative reference.)

I think for our current purposes it's fine to just reference the RFC. Nothing about servprovider-oob changes the high-level guidance we're giving here in stir-messaging, anyway.
    
    §7:
    	• It might be worth noting that this mechanism does not add any privacy protection to the original message content that wasn’t there in the first place.

Okay, will add.
    
    §8: 
    	• It might be good for the sec cons to refer back to the text about store-and-forward (and any other place we see the messaging use case differ from the calling user case). (No strong feelings on this except that the sec cons feel a bit light.)

Okay, I at least added a pointer to the store-and-forward text.

    	• It might be worth observing that, while “msgi” can contribute to replay prevention for the passport, it does not help with replay of the same identical message.
    
The section on "msgi" does contain some considerations about replay protection; that is now pointed to by the Sec Cons as well. 


    Editorial:
    ----------
    
    General: There’s still quite a bit of “could be” language that perhaps “could be” recast as “can be” or even “is”.

Yeah, um, I agree it's a little hand-wavy rather than normative in many areas, but I think we get the normative stuff we need.
    
    Abstract: 
    
    	• s/Persona/Personal
    	• Last sentence: I propose “… both for messages carried as a payload in SIP requests and for messages sent in sessions negotiated with SIP.”

OK.
    
    §1:
    	•  2nd paragraph, first sentence: “… however...” needs commas fore and aft.

OK.

    	• “… not currently widespread”: That statement is already becoming dated. I propose we just say “Spammers and fraudsters are increasingly turning to…”

OK.
    
    §3.2
    	• First paragraph, 2nd sentence: “for example” needs commas.

OK

    	• “MUST support the following hash algorithms: "SHA256", "SHA384", or "SHA512", which are defined as part of the SHA-2 set of cryptographic hash functions by the NIST.”
    		• Is there a reasonable citation?

Um, I think so?