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

Jean-Michel Combes <jeanmichel.combes@gmail.com> Wed, 15 June 2011 14:11 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 1C3DE9E8016 for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 07:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.33
X-Spam-Level:
X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 vHZz8mrrE6nl for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 07:11:17 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF219E8014 for <savi@ietf.org>; Wed, 15 Jun 2011 07:11:17 -0700 (PDT)
Received: by gxk19 with SMTP id 19so368661gxk.31 for <savi@ietf.org>; Wed, 15 Jun 2011 07:11:16 -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=Fhx2YE7NaExmeRm9lt4/FJxXVGlHzMPrr6aQriWbYw0=; b=rnihQ0kbLT/WII+pQQFyKios+wSNin9gn4M5HzdDAtm+diL0L8c8jyd4DOc4ZAgOHZ 0+soMmljFGRk7OqgzrPIqg5YxIX3Pw3OIVOF8Zgxr+Vz+4wN4itdq7tdyYOkiqV+PIWM U2D8LWbQLx1pgt+zjlbHOBHjtoIv1tcBoNhyA=
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=EQe7LvHXZILCmgkBfI44bpYX1H+gcz1DNYOVMwKuwj1ml6xMyI9eV07sYlmMig7xVl qOkxmY2Hwg7QdHabSkQCq0yHUMxoKpebApdudCsGxXgj4Lt6a6qPG+RoZEmeYV0oFaWQ N1RFPhHqMB9ixK0ZaQJSE96bQGFUmgHwkCbts=
MIME-Version: 1.0
Received: by 10.146.109.6 with SMTP id h6mr665440yac.6.1308147076498; Wed, 15 Jun 2011 07:11:16 -0700 (PDT)
Received: by 10.147.83.20 with HTTP; Wed, 15 Jun 2011 07:11:16 -0700 (PDT)
In-Reply-To: <4DF8A45F.8020702@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>
Date: Wed, 15 Jun 2011 16:11:16 +0200
Message-ID: <BANLkTinPAyZVyZLs3tV0Z4mC8fomDAG8og@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: SAVI Mailing List <savi@ietf.org>, draft-ietf-savi-threat-scope@tools.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:11:18 -0000

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

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