Re: [stir] current draft charter

["DOLLY, MARTIN C" <[e-mail]>]

Hello all,

Charter:
1. The issue/problem is "spoofing", and not routing nor media security.
2. And WRT spoofing, IP to IP spoofing solution is the low hanging fruit, and we need to have a timely solution (timely includes standard, deployable, including affordable) 
3. validation is associated with authentication, which is best done by the carrier or enterprise (though enterprises are a source of the robo-calls), but should be allowed to be done by callee UAs (IF trusted, this is a big IF)
4. ISUP cannot be modified, FULL STOP 
5. Creatively using/reusing an existing ISUP parameter/field could only between trust domains. (WTS PAI works between trust domains)

Regards,

Martin


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave Crocker
Sent: Sunday, June 16, 2013 12:38 PM
To: Peterson, Jon
Cc: [e-mail]
Subject: Re: [stir] current draft charter

On 6/13/2013 6:58 PM, Peterson, Jon wrote:
> On 6/13/13 3:24 PM, "Dave Crocker" <[e-mail]> wrote:
>> On 6/13/2013 10:25 AM, Peterson, Jon wrote:
>>> 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.
...
> Potentially, yes, callee-side enterprises and even callee UAs would be
> able to validate.

OK.  Again:  No "private" mechanisms.


> 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.

RFC 4474 has been standards track for 7 years; that's a long time.

What is its level of operational deployment and use, so far?  If the 
answer is "not much", then it's not clear that automatically invoking 
its application here is as comforting or facilitative as one might wish...

The cornerstone of RFC 4474 is an (independent) authentication service. 
  Where are it's details specified?  (Note that you correctly described 
RFC 4474 as describing an abstract service; that begs the question of 
the concrete details for its cornerstone. I'm also therefore assuming 
that Section 5 of that document is not the concrete service protocol 
details, since it's far from complete, in spite of having quite a bit of 
detail. A telling example is the text in Step 2: "Some possible ways in 
which this authentication might be performed include:")

If I understand the RFC 4474 model correctly, a validated Identity field 
has the semantics of asserting that the From field is valid.  So the 
assertion is not limited to the owner of the From field value.  Correct? 
  While such a model is understandable, it dramatically increases the 
reputation-management complexity of the task.  I'm not aware of an 
extant service over the public Internet of similar complexity.

Better still is that it's the entity making the assertion that tells the 
verifier where to look for verification information...  What's seems to 
be missing from the text in RFC 4474 is how the verifier can tell 
whether the credential is a valid authorization for use of the From 
field value. (If it wasn't clear before, now you can understand why I'm 
curious about the concrete details of this authentication service.)


> 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

"in that sense"?  What other sense is possible and plausible?

Perhaps I missed the details about the credential use that are specific 
to this application.  Where are they provided, so that it's possible to 
tell how the credential is applicable for authorization validation?

(Naive question:  Are the details of the referenced URI use for 
credential acquisition sufficient and well-deployed?  It's a significant 
protocol mechanism for this service and I'm not clear that it's the 
mechanism or its semantics are standard practice.)


> 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.

This being a global, public, integrated query service, and the track 
record of deploying such things being highly discouraging, it's 
definitely good to stay with a proven, deployed service.  That's why I 
asked after the experience with the independent authentication service 
specified in RFC 4474.


>> 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

"Resembles" implies that it doesn't exist yet.  So it's subject to 
whatever challenges any other proposal must address.


> 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.

That mostly says that the reality of this mechanism hasn't been 
established yet.  If it had, we'd know whether it had multiple roots and 
whether that approach scaled well.

The use of a multiple roots model for web validation is already showing 
some signs of stress.


>> 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.

https is not a query service.  In this context, it is at most a 
transport service, that might have a query protocol running on top of it.


>>>> 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.

Operational lessons abound.  Globally viable query services that are 
applicable to real-time use do not.

To date, the Web's PKI's has seen extremely narrow success. The biggest 
lesson to take from a mechanism intended to be so flexible, after this 
long, is that the continuing narrowness of current use should be a caution.


>>> 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.
...
> 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.

Ok.  So it's /not/ "potentially playing a role" for this discussion.



> 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.
...
> Both have some dependency on credentials which capture authority over
> telephone numbers.

Unless I've missed something, this translates into creation of a new 
global PKI service for authorizing third-party validation of number use. 
  (The third-party aspect refers to the use of the Identity field I 
cited above.)

That's pretty ambitious, especially in terms of OA&M, nevermind viable 
trust/reputation.


> 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.

Nevermind the IETF.  Credentials are at the heart of your proposal for 
this globally-integrated authorization service.  So the details had 
better be specified and reviewed somewhere.


> 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.

"Foster" suggests that the service could be viable without that 
interoperability being standardized?


> 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?

Any of it.

As I said, I had been told private and rather forcefully that this 
effort already had a solution in hand.

I'm trying to re-gauge things, now that's it's clear that none of the 
details are actually worked out yet.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir