Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT)

["Ben Campbell" <[e-mail]>]

On 3 Nov 2016, at 9:16, Peterson, Jon wrote:

>
>>
>>> On 2 Nov 2016, at 23:38, Ben Campbell <[e-mail]> wrote:
>>>
>>> - 6.2, step 4:  This says that if the full form of passport is 
>>> included,
>>> and the Date header and iat do not match, use iat if it is fresh. 
>>> I'm
>>> curious why not just use iat in the first place?
>>
>> Good point.
>>
>>> What should one do if
>>> Date is fresh, but iat is not?
>>
>> Then it might be a cut & paste attack.
>
> That is the most material threat.
> But to the question of "why not use
> what's in the JWT claims in the first place?" this is largely a
> philosophical question about whether we want to use JWT as a check 
> that
> the SIP header field values are properly attested, or whether we want 
> to
> use SIP as a delivery vehicle for JWT and have its values be 
> authoritative
> instead of SIP's values. I guess I thought about this largely in terms 
> of
> how I want SIP user agents to behave: like, when it came to the
> originating identity, did I want the SIP From header field value to 
> kind
> of cede its place to the value in the "orig" claim of JWT? I guess 
> what I
> want is for SIP user agents to render to users the value of the From
> header field, and to use "orig" as a

I'm okay with a general preference for Date, but does the issue of a 
stale iat but fresh date change that?

>
>>
>>> -6.2.2: This section recommends specific result code reason phrases 
>>> for
>>> a
>>> couple of circumstances. I assume the idea is that one should use a
>>> "helpful" reason phrase, and these are examples of phrases helpful 
>>> for
>>> the circumstances. But it reads as if you mean to standardize those
>>> specific reason phrases.  If the intent is really to offer examples,
>>> please clarify. I'd hate to see us back in the days of commonly 
>>> seeing
>>> SIP code break due to unexpected reason phrases.
>>
>> This essentially a better version of my comment.
>
> Well, agreed on that last point. We can soften the language here. What 
> we
> wanted to do is to differentiate conditions that are signaled by the 
> same
> reason code, and to use new reason codes sparingly. The rough 
> guideline I
> use is that programmatic behavior has to trigger off the codes only, 
> but
> human behavior can rely on the reason phrases. We're not asking an
> automaton to react to "Stale Date" or "Use Supported PASSporT Format," 
> say.

Softening the language would make me happier. I note that elsewhere in 
this draft (and also in 4474), there are similar statements that use 
"For example,..."

>
> Jon Peterson
> Neustar, Inc.
>