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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 15 June 2011 12:24 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 56EBB11E80F8 for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jW5M04KV3pJc for <savi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:24:27 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7C11E80F0 for <savi@ietf.org>; Wed, 15 Jun 2011 05:24:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 07765171C1E; Wed, 15 Jun 2011 13:24:03 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308140642; bh=d6giFMSy7xEFZT wUNh0AFc9UiiOF8JHZXkoJudkwOvU=; b=xazsnY8PSRnvQKDrslAeVfgfgHnPxn DYGycqZwLyOkRVGBcrxZesLCtlmqUOmMayMTPGcA9Vuj//w2RLpI3hB/CByv9QKo 9ySNYgapSVhvH57qCcm9Z8QJp2ejWUgKc3Ttyb8F3bdRg1jGKQdubbWB1G54oq5g jWmb/2/SB2AsioAdAXW9EDscXp6F8hVRpPywtIzcAG5JoNS/doP0M6Z2nGj82WPN CblGmBmiKeCLNky2BnQrYArHDSKYGZ6mcQvgV/QZKHGn3zmLF9K8aKYkK7rVIojd cW+Rn5aoHaAEZ32iJRk+nqHRJGcJHTQsGzaFTBSd2UW5UJ++Fp/N+zHA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id QeJbY-YuJYP0; Wed, 15 Jun 2011 13:24:02 +0100 (IST)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C54B1171BFE; Wed, 15 Jun 2011 13:23:59 +0100 (IST)
Message-ID: <4DF8A45F.8020702@cs.tcd.ie>
Date: Wed, 15 Jun 2011 13:23:59 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
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>
In-Reply-To: <BANLkTinwfLDNdovh+_fYm3sX_QiZfE0Qzw@mail.gmail.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 12:24:28 -0000

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.