Re: [stir] current draft charter

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

Inline below.

On 6/13/13 3:24 PM, "Dave Crocker" <[e-mail]> wrote:

>Jon, et al,
>
>
>On 6/13/2013 10:25 AM, Peterson, Jon wrote:
>> On 6/12/13 9:01 PM, "Dave Crocker" <[e-mail]> wrote:
>>
>>> On 6/12/2013 3:01 PM, Peterson, Jon wrote:
>>>> But we don't even have to be asking ourselves about the relevance of
>>>> public ENUM to the proposed work here in STIR unless we want to try to
>>>> base everything on keying in the public DNS for telephone numbers.
>>>>There
>>>> are other models for this that don't have the liabilities I described
>>>> above, anyway. Keying in private DNS is more viable, for example. I
>>>> think
>>>> a PKI is more viable.
>>>
>>>
>>> Other models?
>>
>> I just meant for example private DNS, or PKI, as it says up there.
>
>1. The functional description that's been offered said that validation
>is to be permitted by entities such as callee-side enterprises and even
>callee UAs.  That precludes any sort of private service.  Whatever
>parameters must be obtained outside of the SIP headers -- such as public
>keys -- they need to be publicly accessible.

Potentially, yes, callee-side enterprises and even callee UAs would be
able to validate. The original RFC4474 model describes an abstract
"verification service" function that can be performed either by an
intermediary or an endpoint. I've been assuming we'd retain that
architecture.

The RFC4474 model also has the concept that a URI is carried alongside the
signature, in a separate header called Identity-Info, to designate the
credential that was used to generate the signature. So yes, any
verification service needs to be able to resolve that URI, so it must be
public in at least that sense (and the verification service must trust
whatever trust anchor generated the credential on the other side of that
URI too). IF we were to transpose this to a DNS-like model, presumably the
Identity-Info header or its successor would be extended in some fashion to
allow it to designate that the DNS should be consulted.

>2. From one of your earlier notes, I gather that by "PKI" you mean the
>bushy (multi-root) system that operates for SSL/TLS web services?  You
>appear to be using PKI to mean a specific, integrated, operating
>credential service, so I would like to be clear about which specific one
>you mean; the one used by the Web seems to be it?

I mean a system that resembles that "bushy" system, yes. I imagine it
could encompass multiple roots. The secure-origins-ps document does
however contain some text to the effect that it would be real nice if we
could avoid having different roots claiming authority over the same name,
though, given what the consequences of that have been for web PKI.

And by PKI I here I'm not sure I mean any specific, integrated, operating
credential service as such, though certainly one that would use technical
components familiar to anyone who was familiar with web PKI.

>
>>> Is there a written description of the integrated query service that you
>>> folks are considering, in terms of design, administration and
>>>operation?
>>
>> I wasn't talking about some kind of integrated query service, I was
>> talking about where the keys should live. So, written descriptions would
>> be CP/CPS sorts of things, if that's what you mean here?
>
>I suspect you mean more than where they live, since they aren't much use
>if they can't be retrieved, and in fact retrieved publicly.

Right, no, as I said above I was assuming something like Identity-Info
from RFC4474 would be available to facilitate retrieval.

>By "query service" I meant the term generically as a mechanism that
>askes for something and gets it. I didn't want to imply or constrain any
>details about the form of the request or what was returned; merely that
>it's in the service of performing validation.

Sure, as specified in RFC4474, https or even cid (to designate a multipart
MIME body attached to the request) are examples of how the credential
fetch would happen. It is definitely in the scope of proposed work to
expand those options.

>Since the intent here is to develop a global validation service for
>SIP-based calls and since such a service will need to obtain some types
>of information to permit validation, it will need a mechanism for
>retrieving whatever that information is.  That's all I meant by query
>service.

Sure, agreed, we're on the same page.

>While yes, one can imagine designing a service that permits packaging
>everything in-line with the SIP data, it's clear that that won't be
>sufficient, based on one or more of the documents -- and much of the
>message postings -- for this topic.  Hence, it needs a query service of
>some sort.

Gotcha.

>>> It would help to also hear where such a design has already been
>>> successfully deployed.
>>
>> Do you think that is an issue for CAs/PKIs? Certainly they have some
>>rough
>
>The PKI service used for the web has the advantage of existing and being
>heavily used.  A base of experience is goodness, when considering
>out-sourcing a component of a new service.  Whether its characteristics
>suffice for the current project, I don't know.  Some times, rough edges
>cut thing and bleed them dry.

Like I said, I'd hope we could benefit from some of the operational
lessons of web PKI while still retaining the tried and true technologies
that have succeeded here.

>
>> edges, which is why we see the DNS (through DANE) potentially playing a
>
>Ah yes, the great promise of DANE.  I'm sure it will yet deliver, as
>have all of the other promising efforts in the IETF.  Oh, no, this one
>really will.  No, honest, it will.  And I hope I'm serious.

>That's not a criticism of DANE.  It's an attempt to raise a flag about
>relying on it.
>
>One of the classic errors in a new project is creating a critical
>dependency on a parallel, independent project.  Sometimes it's
>necessary, but it's always extremely risky.  Extremely.  Always.

I want to make an allowance for DANE, especially where it can help with
greenfield SIP URIs rather than telephone numbers (e.g. Which cert should
I trust for sip:[e-mail]?). I do have some sense of the state of
DANE adoption, and I've certainly heard pushback from browser vendors and
others about its mid-term prospects.

But DANE wouldn't play a role in our story about how credentials are
managed for TNs unless of course we assume some ENUM-like TN hierarchy in
the DNS is a part of this key management solution.

>> role in their future. Or maybe it will be more like the SSL Observatory
>>or
>
>The 'maybe' -- and equivalent phrasings that you've used -- point up
>something that I've become confused about.  What I was told (rather
>forcefully offline) is that there is a solution already formulated.
>However what's been put forward on the list so far sounds more like some
>ideas, at least some of which are not yet close to being solid.

Um. In so far as there is IETF work already formulated, as far as I know
it's what's captured in the various drafts under discussion. I would say
you can judge for yourself how baked those ideas are. We have two proposed
areas of IETF work, one on providing a better in-band identity indication
in SIP, and another (more ambitious) effort to work on an out-of-band
solution. 

Both have some dependency on credentials which capture authority over
telephone numbers. The degree to which those credentials are a subject of
IETF work is less obvious to me. Let's assume we're talking about a PKI,
for the moment. In the web world, we have RFCs that talk about how you
need to process certs to make web security work, what information needs to
be in them and where it lives, and that is all clearly IETF work. But we
don't have RFCs that constrain the set of CAs to any particular vendor(s)
or that overly prescribe their operational environment, like how a CA
enrolls customers or sorts them into levels of assurance, say.

So right now in the proposed charter there is a placeholder for a document
that would cover the sorts of things about the key management system that
would be in the scope of the IETF, to foster interoperability of signers
and verifiers. I think we'd need to know more about where we're going
before I could tell you in more detail what the document would contain. So
yeah, a lot of things are not solid at this stage.

>If there is in fact a concrete, detailed design already in hand, that
>attends to relevant security, privacy, scaling, deployment,
>administration and operations issues, let's hear it.

For what part of the work?

But I guess whichever part you mean, I don't think having a document with
that level of detail in hand is necessary to charter this proposed work or
to set a direction for it. If we assume the two main key management
options here are something like the DNS (public or private, with or
without DNSSEC/DANE) and something like a web PKI, I think both are fairly
well understood in the dimensions you describe here. I would be hesitant
to explore options where that didn't seem to be case.

Jon Peterson
Neustar, Inc.

>d/
>
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net