Re: [secdir] Review of draft-ietf-repute-query-http-09

Shawn M Emery <shawn.emery@oracle.com> Wed, 28 August 2013 05:20 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091211E8140 for <secdir@ietfa.amsl.com>; Tue, 27 Aug 2013 22:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMFL2qaXUgXB for <secdir@ietfa.amsl.com>; Tue, 27 Aug 2013 22:20:50 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 139DD11E8128 for <secdir@ietf.org>; Tue, 27 Aug 2013 22:20:50 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7S5Kc3R028640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 05:20:39 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S5Kbxv029613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 05:20:38 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7S5KbS5028004; Wed, 28 Aug 2013 05:20:37 GMT
Received: from [10.159.72.16] (/10.159.72.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 22:20:36 -0700
Message-ID: <521D88D8.7020603@oracle.com>
Date: Tue, 27 Aug 2013 23:21:28 -0600
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <51CAA254.6040303@oracle.com> <52158CF5.4050001@oracle.com> <521591FA.20601@dcrocker.net> <52198E83.7050406@oracle.com> <CAL0qLwY43MX8TgM2zFdw5hDF0qj3RsotqA22raKeTWNx7U6=UA@mail.gmail.com>
In-Reply-To: <CAL0qLwY43MX8TgM2zFdw5hDF0qj3RsotqA22raKeTWNx7U6=UA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050709070309020805090707"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: draft-ietf-repute-query-http.all@tools.ietf.org, Dave Crocker <dhc@dcrocker.net>, Dave Crocker <dcrocker@bbiw.net>, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-repute-query-http-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 05:20:56 -0000

On 08/26/13 11:10 PM, Murray S. Kucherawy wrote:
> Hi Shawn, thanks for the review.
>
> On Sat, Aug 24, 2013 at 9:56 PM, Shawn M Emery <shawn.emery@oracle.com 
> <mailto:shawn.emery@oracle.com>> wrote:
>
>     On 08/21/13 10:22 PM, Dave Crocker wrote:
>
>         On 8/21/2013 9:00 PM, Shawn M Emery wrote:
>
>             However, none of the
>             referenced RFCs and draft directly talk about the various
>             attacks and
>             how to mitigate against said attacks.
>
>
>
>         Shawn, some clarification please:
>
>            This is a simple query protocol, ableit yes one where the
>         data is
>         making trust assertions.
>
>            A possible implication of your above comment is that all IETF
>         protocols should carry a threat analysis.  Have I misunderstood?
>
>
>     Hi Dave,
>
>     Sorry for not being specific.  I will try to clarify my concerns:
>
>     This draft references the reputation considerations draft when
>     providing or using reputation services, I assume in a security
>     context given that it is referenced in the security considerations
>     section.  When I looked at the referenced draft's security
>     considerations section it stated that there are threats discussed
>     in the operation text above.  I think that these types of
>     discussions deserve a separate section.  If the topic is mostly
>     security it would be helpful to have a summary of the various
>     threats and how to mitigate.  In any case, when looking through
>     the entire draft I do see some suggestions for clients and their RSPs.
>
>
>
> I'm still a little unclear about what the suggestion is here.  Since 
> this review is specific to query-http, I take your feedback to mean 
> that query-http itself is fine, but it's desirable that the 
> considerations document go into more detail about what it's 
> discussing.  I think that's fine and probably true, and I'll do so for 
> that document, but I don't think there's anything outstanding for this 
> one.  Do you agree?

Yes, that's pretty much it; that this draft or the referenced draft 
should have a consolidated list of the various security issues and 
guidance to counter them.

Thanks,

Shawn.
--