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

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

Thanks for these notes Russ. Some responses inline.

Jon Peterson
Neustar (a TransUnion company)

On 5/10/22, 2:43 PM, "Russ Housley" <[e-mail]> wrote:

    I have two comments.
    
    Section 3.1: There is an informative reference to [I-D.peterson-stir-rfc4916-update].  It seems like we should have a reference to RFC 4916.  It is not clear to me that the already approved document is not sufficient for the point being made here.

I do think rfc4916update is a better ref here in so far as it is specific to STIR, rather than RFC4474 - but, I see your point. We can swap it out if you want. But since it's informative, there's no harm in keeping it, right?
    
    Section 3.2:  This should include a reference for SHA2.  (Also in Ben's list below.)
    
       [FIPS.180-3]
                   National Institute of Standards and Technology, "Secure
                   Hash Standard (SHS)", FIPS PUB 180-3, October 2008,
                   < https://urldefense.com/v3/__http://csrc.nist.gov/publications/fips/fips180-3/__;!!N14HnBHF!7u69jEQuIgKv2qDqGvzquD4aQTTQgMi0mmD3JXQC2L8NWNe7HZxR6g0l4UxKjwJy411KZuXcdlf6YuI8fAjUyA$  
                    fips180-3_final.pdf>.

Okay.
    
    Russ
    
    > On May 6, 2022, at 5:02 PM, Ben Campbell <[e-mail]> wrote:
    > 
    > (As individual)
    > 
    > Hi,
    > 
    > This is a WGLC review of draft-ietf-stir-messaging-02. I think this is pretty much ready to progress. I have a few minor comments that don’t necessarily need to block progress.
    > 
    > Thanks!
    > 
    > Ben.
    > 
    > 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?
    > 
    > 	• Do we want to say anything about “msgi” interaction with encrypted messages? I assume one would calculate the msgi digest post-encryption.
    > 
    > §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.)
    > 
    > §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.
    > 
    > §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.)
    > 	• 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.
    > 
    > Editorial:
    > ----------
    > 
    > General: There’s still quite a bit of “could be” language that perhaps “could be” recast as “can be” or even “is”.
    > 
    > 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.”
    > 
    > §1:
    > 	•  2nd paragraph, first sentence: “… however...” needs commas fore and aft.
    > 	• “… not currently widespread”: That statement is already becoming dated. I propose we just say “Spammers and fraudsters are increasingly turning to…”
    > 
    > §3.2
    > 	• First paragraph, 2nd sentence: “for example” needs commas.
    > 	• “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?
    > 
    > 
    > 
    > 
    > 
    > _______________________________________________
    > stir mailing list