Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

[Uma Chunduri <[e-mail]>]

Hi Spencer,

Quick response In-line [Uma]:

Thx!
--
Uma C.

From: Ideas [mailto:[e-mail]] On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, September 13, 2017 8:17 PM
To: Uma Chunduri <[e-mail]>
Cc: Tom Herbert <[e-mail]>; [e-mail]; [e-mail]; The IESG <[e-mail]>; Alvaro Retana <[e-mail]>
Subject: Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

So, responding to Uma's response to Tom's response to my response to the proposed charter (whew!),

On Wed, Sep 13, 2017 at 3:56 PM, Uma Chunduri <[e-mail]<mailto:[e-mail]>> wrote:
        > Is a look at general security implications, in a form that specific
        >framework  usages can point to, on the table for IDEAS?
        >e
        Spencer,

        I believe there are two discrete components being championed in IDEAS:
        One, is mapping system of identifier to locators and the other is introduction of identity mapping. The former looks much more like a routing or name resolution protocol, and the later would be doing identity management and possible collecting PII. There are obviously many security implications to      both parts, however I think the threats and sensitivity between these is quite different, i.e. hacking into the ID/loc mapping data base could result in misdirecting packets, hacking into identity store may result in loss of users' privacy.

Tom's response to me makes sense.

[Uma]: Tom, you summarized well. I would note there is interconnected aspect to these 2 items w.r.t security. Identity AUTH can inherently bring security (and if needed privacy) to Identifier/Location mapping and strengthen that area tremondoesly.
However, Identity privacy itself has  to be tackled and there are existing well defined mechanisms for that as discussed earlier in the IDEAS list (pointer from Diego, is a great example).
When we described identity and it's uses here https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01#section-7 , we noted threat analysis aspect in Section 7 and was reflected in charter too.

Uma's response to Tom makes sense.

        These seem fundamentally different so security considerations should probably be considered independently of each other.

[Uma]: Different but interdependent on some aspects as mentioned above.

So, what I'm not understanding, is that there are two work items, and only one framework deliverable. Is the intention that the identifier/locator mapping system and the identity mapping system are different enough to have different security considerations, but are so tightly interwoven that neither is usable without the other, or with any other mapping system separately, so it makes sense to lump them into one framework?

[Uma]: AFAICT, one cohesive framework to cover these 2 aspects is a good option. Obviously,  solutions are vastly different on how to do Identity privacy and federated Identifier/location mapping system with Identity services and those can be taken up in different documents later.


Again, either answer is OK, but if I'm going to ask, now would be the time :-)

[Uma]: Me too and would be happy to listen other opinions. Thanks for thoughtful comments and follow-up.


Spencer

        Tom

        > (It doesn't have to be, for me to ballot Yes, but I did have to ask,