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

On 15/06/11 15:46, Jean-Michel Combes wrote:
> Hi again,
> 
> 2011/6/15 Stephen Farrell <stephen.farrell@cs.tcd.ie>:
>>
>> 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.
>>
> 
> Yes that's the plan and this is clearly identified in my TODO list for
> the review of this document.

Grand. I've cleared the two relevant discuss points (2 & 17). I
copied that text down to the end of the comments to help keep
track as we kill off the other discuss and comment points.

Thanks,
S.

> 
> Cheers.
> 
> JMC.
> 
>> Cheers,
>> S.
>>
>>
>>>
>>> Cheers.
>>>
>>> JMC.
>>>
>>> 2011/6/15 Stephen Farrell <stephen.farrell@cs.tcd.ie>:
>>>>
>>>> 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 <jari.arkko@piuha.net>:
>>>>>> 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
>>> savi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>>
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi
> 