Re: [savi] Status of draft-ietf-savi-threat-scope

[Stephen Farrell <[e-mail]>]

Hi Jean-Michel,

On 15/06/11 15:11, Jean-Michel Combes wrote:
> Hi Stephen,
> 
> I totally agree with you about the fact that deploying different SAVI
> solutions on a same architecture may have as consequences extra
> residual threats.
> That's why, from my point of view, the right place for such an
> analysis was the MIX SAVI document
> (http://tools.ietf.org/html/draft-ietf-savi-mix-00).

So if you're saying that that document will eventually contain
the residual threat analysis for all the others then I'm fine
with that. Sorry for not spotting it, but I guess I can use
the missing security considerations section in the -00 as my
lame excuse:-)

If that's the plan I'm happy to clear that part of the discuss.

Cheers,
S.


> 
> Cheers.
> 
> JMC.
> 
> 2011/6/15 Stephen Farrell <[e-mail]>:
>>
>> Hi Jean-Michel,
>>
>> On 08/06/11 18:28, Jean-Michel Combes wrote:
>>> Hi,
>>>
>>> At first sorry for the delayed reply.
>>>
>>> Please, see my comments inline.
>>>
>>> 2011/5/30 Jari Arkko <[e-mail]>:
>>>> Joel,
>>>>
>>>>> As I have said, i am happy to make most of the changes.
>>>>> However, there are two changes requested by Ralph that change the scope in
>>>>> a way that I do not feel I (or you) can call for.
>>>>> I have been awaiting the Chair's review on these two substantive issues:
>>>>>
>>>>> 1) The issue of analysis of the effect of SAVI, and what threats remain
>>>>> after SAVI was requested by Stephen.  I pointed out that this is not in
>>>>> scope for the document, and he said that he wanted it anyway.  I punted to
>>>>> you and the chairs.  I believe it would take WG agreement, AD agreement on
>>>>> scope change, and chair direction, before I can make that change.
>>>>
>>>> My opinion is that this document should NOT do that analysis or attempt to
>>>> find out precisely what residual threats are after some set of SAVI tools
>>>> have been implemented in a network. I think we touched upon it in the call,
>>>> but I  can talk to Stephen about it.
>>>
>>>
>>> I agree with Jari:
>>> (1) IMHO, this would be like to put the cart before the horse :)
>>> (2) to doing such an analysis you need a clear specification of a SAVI
>>> mechanism which is outside the scope of this document. BTW, during my
>>> review of FCFS SAVI for the ID Write-Up document, text about residual
>>> threats was added inside the Security Considerations section. I will
>>> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario
>>> documents take into account this issue before requesting AD/IESG
>>> review.
>>
>> So my question then is where will I go to find a description of
>> the residual threat for SAVI generally? Right now, it looks like
>> there's going to be no place for that.
>>
>> The problem I see with that not being available is the following.
>>
>> Each SAVI mechanism (FCFS etc.) is going to catch certain forms
>> of spoofing but inevitably leave others available and as you
>> say those mechanism-specific residual threats will need to be
>> documented in each SAVI spec.
>>
>> But I think there are dangers inherent in deploying a network
>> with multiple SAVI mechanisms because of this - the issue being
>> that an innocent party might be blamed for some action on the
>> basis that a combination of SAVI mechanisms makes it "impossible"
>> that the action actually involved spoofing.
>>
>> That kind of thing has happened in DRM-related cases so I
>> think its important that the residual threat when all the various
>> SAVI mechanisms are defined be properly documented somewhere.
>>
>> In addition I would assume that vendors are likely to implement
>> more than one SAVI mechanism in some of their products, so
>> customers for those products should also be interested in the
>> residual threat for combinations of SAVI mechanisms.
>>
>> And I think that only the SAVI WG will have the expertise
>> required to do that.
>>
>> Would it make sense to try get someone to write a document
>> just on that towards the end of the process? (Assuming you
>> could get a volunteer? I can try see if some security area
>> type person would be willing to help as well if you like.)
>>
>> Cheers,
>> Stephen.
>>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>