Re: [secdir] secdir review of draft-ietf-alto-protocol

"Dan Harkins" <dharkins@lounge.org> Mon, 17 February 2014 14:26 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796991A01FA; Mon, 17 Feb 2014 06:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKVtf17RKp_0; Mon, 17 Feb 2014 06:26:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC21A01D8; Mon, 17 Feb 2014 06:26:05 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C232710224008; Mon, 17 Feb 2014 06:26:02 -0800 (PST)
Received: from 129.192.185.164 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 17 Feb 2014 06:26:03 -0800 (PST)
Message-ID: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net>
In-Reply-To: <CADOmCZU7uxA8RyK7LUy2D1Op4nhVEt_Y1JxGHNCzRvpFgGbh+g@mail.gmail.com>
References: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <CADOmCZU7uxA8RyK7LUy2D1Op4nhVEt_Y1JxGHNCzRvpFgGbh+g@mail.gmail.com>
Date: Mon, 17 Feb 2014 06:26:03 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Richard Alimi" <ralimi@google.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k_jR1JWpFTJVew6RbEU7YCFZkK8
Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" <draft-ietf-alto-protocol.all@tools.ietf.org>, iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 17 Feb 2014 14:26:07 -0000

  Hi Richard,

On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote:
> Thank you very much for the review!
>
> Responses inline...
>
>
> On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <dharkins@lounge.org>; wrote:
>
>>
[snip]
>>   - 6.1.2, while a particular Cost Map may contain only one of the
>>      two cost modes, servers MUST implement support for both,
>>      right? It's not clear from the text.
>>
>
> Servers only need to implement at least one, but not necessarily both.
>  Section 6.1.2 states the following:
>
>
>    An ALTO Server MUST support at least one of 'numerical' and 'ordinal'
>    modes.
>
>
> Can you suggest which text was misleading so that we can address it?

  It's not clear to me how this interoperates unless it's possible to infer
one from the other and if that's the case then why are there two things
to choose to support?

[snip]
>>
>>   - 15.3.2, the Security Considerations section seems an odd
>>      place for normative language-- "HTTP Digest authentication
>>      MUST be supported". I suggest finding a more appropriate
>>      place, perhaps 8.3.5, to spell out normative requirements.
>>      Also, authenticating the client in the TLS exchange would
>>      be much preferable and I think mention should be made
>>      on that option. I think differentiated authorization (see
>>      my previous comment) would be easier this way too.
>>
>
> Good point - we will move the normative requirement for HTTP digest
> authentication to 8.3.5.  The existing text in 8.3.5 states
>
>    When server and/or client authentication, encryption, and/or
>    integrity protection are required, an ALTO Server MUST support SSL/
>    TLS [RFC5246 <http://tools.ietf.org/html/rfc5246>] as a mechanism.
>
>
> Should I interpret your comment to say that we should suggest TLS client
> authentication over HTTP digest authentication, or to reword to make it
> more explicit that TLS client authentication is an option?

  Well I think client authentication is mandatory, it's just whether it's
provided as part of the TLS exchange or using HTTP digest auth. And
yes I suggest making TLS client auth preferred over HTTP digest auth.

  regards,

  Dan.