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

Jean-Michel Combes <jeanmichel.combes@gmail.com> Wed, 15 June 2011 14:46 UTC

Return-Path: <jeanmichel.combes@gmail.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA1921F8585 for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 07:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.384
X-Spam-Level:
X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUWd4iJSg9dl for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 07:46:25 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A72021F8584 for <savi@ietf.org>; Wed, 15 Jun 2011 07:46:23 -0700 (PDT)
Received: by yie30 with SMTP id 30so399746yie.31 for <savi@ietf.org>; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=563b64dweD8HSqdjNJ03PTHLcr33B/ZLJQXQBDK0BEY=; b=lDgpf2aWl1qIEWo/esE6TGJge4U66cCUsWaFZWcslec5lRVlu5vc9FPRYVthHF6NQy 4aYjdttJ5oHhL+9YslrshS/BCJEJi91kdgoGkvDbfhlavFSZ6+7v9Q+uAhQvA27grhRV yf3AW5SVfKkdyo8wXNHIBbfy/tF0tKbRXljbg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CLkgq124GsBKZvHAfFkPBfg1fVzvR+1jii4KyuXA2BmFPyQVuOn1K5OtnP8sjObXUd fvnZa0CjfhCd4wBmovcfz2OP8hpMczR/DnaRuI5jYCVXeE4APzTgQPt4qyd6EPRBJV39 4zbeSv664y1dLCL9VOsJfG6OfW0gMR3aKeID8=
MIME-Version: 1.0
Received: by 10.236.190.170 with SMTP id e30mr1062145yhn.226.1308149182185; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
Received: by 10.147.83.20 with HTTP; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
In-Reply-To: <4DF8C0EE.1050404@cs.tcd.ie>
References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> <BANLkTinwfLDNdovh+_fYm3sX_QiZfE0Qzw@mail.gmail.com> <4DF8A45F.8020702@cs.tcd.ie> <BANLkTinPAyZVyZLs3tV0Z4mC8fomDAG8og@mail.gmail.com> <4DF8C0EE.1050404@cs.tcd.ie>
Date: Wed, 15 Jun 2011 16:46:22 +0200
Message-ID: <BANLkTin8=LpMcx22Az7OoQ4MuLi26J53ew@mail.gmail.com>
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-savi-threat-scope@tools.ietf.org, SAVI Mailing List <savi@ietf.org>
Subject: Re: [savi] Status of draft-ietf-savi-threat-scope
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 14:46:25 -0000

Hi again,

2011/6/15 Stephen Farrell <stephen.farrell@cs.tcd.ie>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.

Cheers.

JMC.

> Cheers,
> S.
>
>
>>
>> Cheers.
>>
>> JMC.
>>
>> 2011/6/15 Stephen Farrell <stephen.farrell@cs.tcd.ie>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>et>:
>>>>> 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
>>
>