Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Jul 2013 12:57:51 -0400

Sure, but such caching schemes only work for the same protocol with the same query string: either the same HTTP URL or the same DNS query key.  An HTTP URL isn't simply used to indicate the protocol being used or what server to issue the HTTP request to - it indicates a full path, with various embedded information in the URL that only has meaning to the HTTP server.  So ignoring the rfc4474 identity-info URL and changing to a different protocol such as DNS is going to be tricky.

As a very simple example of how this would be a problem: when a certificate expires, the originator will need to use a new cert for calls at some point.  So they'd get a new cert and put it in their HTTP server - but they can't remove their old one because of the cached copies of it elsewhere, not to mention there would be SIP requests in-flight during the cut-over.  So they'd need some way to indicate, per SIP request they sign, which cert they're using for each particular request.

With HTTP, they could do this:
http://foo.com/sipcerts/newcert.cer
Or maybe something like this:
http://foo.com/sipcerts/callerid.cer?inst=sd87gfbi

The verifier can't simply ignore those URLs and switch to using DNS queries locally.

-hadriel

On Jun 30, 2013, at 12:16 PM, Henning Schulzrinne <[email-masked]> wrote:

> We do some version of this in every web browser and DNS resolver: If the data is locally cached, no protocol request is made, along with other local caching mechanism where the HTTP or DNS request never reaches the origin server named, including both transparent and explicit (redirect) caching.
> 
> As long as verifying entities have a way to fall back to retrieving content via the URL at the designated location, this doesn't seem to affect interoperability (and probably doesn't even need a detailed specification). As with all caching mechanisms, there is a trade-off between extra querying and possibly stale data.
> 
> Henning
> 
> ________________________________________
> From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
> Sent: Saturday, June 29, 2013 4:18 AM
> To: Peterson, Jon
> Cc: [email-masked]; [email-masked]; Michael Hammer
> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)
> 
> On Jun 28, 2013, at 5:45 PM, "Peterson, Jon" <[email-masked]> wrote:
> 
>>> And I *am* expecting to discuss design and architecture, and don't want
>>> to be constrained to even having to support a URL model.  Yes one could
>>> put 'dns' in it, but if it would be up to the originator to decide
>>> whether to put 'dns' or 'http' in it, then I think there will be a
>>> discussion to have about that in the WG - and I don't want someone to
>>> just be able to say "we have to have it because it's already in RFC
>>> 4474".  And you know people say things like that all the time in WG's,
>>> using the charter as a club to beat down discussion.
>> 
>> Um. Hmm. Is there something that the Identity-Info URI model practically
>> is preventing? I mean, the model is completely open - you don't even have
>> to execute the URI, if you have an alternate way of getting credentials
>> (as RFC4474 says). I was also vaguely imagining that an auth service could
>> put multiple options in Identity-Info, if that helps. If you explain more
>> what the concern is here, I'd certainly be open to finding the right
>> language.
> 
> 
> So are you saying that verifiers can basically just ignore the HTTP URL?  I hadn't noticed that exception before in RFC 4474.  It seems really weird to me to do that - I mean it sounds like an interop problem waiting to happen - but I guess I'd be ok with having more unused header fields floating around.
> 
> -hadriel
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Jul 2013 17:57:19 +0000

On 6/29/13 1:18 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>So are you saying that verifiers can basically just ignore the HTTP URL?
>I hadn't noticed that exception before in RFC 4474.  It seems really
>weird to me to do that - I mean it sounds like an interop problem waiting
>to happen - but I guess I'd be ok with having more unused header fields
>floating around.

That has always been true in RFC4474, yes. See the language in Section 6,
step 1: "SIP entities SHOULD discover this certificate by dereferencing
the Identity-Info header, unless they have some more efficient
implementation-specific way of acquiring certificates for that domain."

The Identity-Info header is there to solve the credential discovery
problem for environments where discovery is a problem. It provides "a" way
to find the credential, not "the" way. That was always the intention here.

As for whether it is an interop problem waiting to happen, the critical
point here is that without "a" way to do it, yes, there would be interop
problems. RFC4474 does have an MTI for Identity-Info, and yes it's worth
considering whether it's right or if this should be adjusted somewhere.

Jon Peterson
Neustar, Inc.