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

Richard Alimi <ralimi@google.com> Mon, 10 February 2014 06:58 UTC

Return-Path: <ralimi@google.com>
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 B07311A07B7 for <secdir@ietfa.amsl.com>; Sun, 9 Feb 2014 22:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_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 pKIen1Hi3TXe for <secdir@ietfa.amsl.com>; Sun, 9 Feb 2014 22:58:46 -0800 (PST)
Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC01A07B3 for <secdir@ietf.org>; Sun, 9 Feb 2014 22:58:45 -0800 (PST)
Received: by mail-vb0-f42.google.com with SMTP id i11so1341278vbh.1 for <secdir@ietf.org>; Sun, 09 Feb 2014 22:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=upisA1uX4yVAyscGeUuvnOR4GISZtAlorVvDfy+q72Q=; b=d/oC1VfyBcC2WTQuNOdlBQTB13JPv4AUfoND+a39uvFnErpm+3UOjRlF9IfljYgzH8 Quqf5zELXltgPu6G7+dUs6JcE8GkDuPnzPNNb+Ie2jo2+W80lWVEWGUVwcmdZFo+zgJo GKCZOxE9puKsjOg7vPPzZGdnGi8ZkUzX7pnYGtLsJZIcaZn4UriUBwJAuYJleWy9V28B iWu7e7odSo4I//yThbTcQb/N9Zwp2SKDlgueebo4n9twrd3SSp9KVdi++UUOY4q/hIYn Nj/oW9sm3o1KZVteJpiOGzIk31qOsHIPZJ6nMQVhdXrK2yjCFFxIurez0ggWPvlhpsXv GPsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=upisA1uX4yVAyscGeUuvnOR4GISZtAlorVvDfy+q72Q=; b=fBdxEZjR4FqGpwzPIEOZDdH+xTmGlMI5T0/BOf3MBv2+Szm6Mwvy1ESGeByw4Q9u8W OkT81B5xbK5wFBa9pN/KaQQohMsuQsPEyjeqML00ev1dZ/NLtEaLq4++tIcjAsozBM6n mm/20w3vX6nvkRl4P1pflhHoCW7cWsHPk8mSPoTb5HbVhrkpnNpjqFdfWn1Fwrw2va+R MutVwTikiBzqt16xT3XrAVZtfzvTe2ofN68L8fiIUfErfzPTip/0slO2wETjXeRF9IAt l/wN0vZke70/O69iDAsssavIBTKlE9RQsg4A7dzPyTLbdQzP1kH7uwysSGOx9mhDXNm2 i/PA==
X-Gm-Message-State: ALoCoQno2bhGx+5D1S47FR9InOQGnq1Y2RU/UKzdLN7ocQ3B8zAtyQTATa0jR0HOwvalJIaOAWku3uFwSKtxxdU7SpZQvdeYV+bpKZYTtq+hwQxflEl/HzApgAOVoKIdLzjm/PptNQQcx3gAR649aBTXY/dFrCjAGO+PLJ2A0v/dtC8mlt+Dl8M4YvNvvhv2/7rhrqbQDDAX
X-Received: by 10.52.171.39 with SMTP id ar7mr18779470vdc.5.1392015525104; Sun, 09 Feb 2014 22:58:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.38.193 with HTTP; Sun, 9 Feb 2014 22:58:15 -0800 (PST)
In-Reply-To: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net>
References: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net>
From: Richard Alimi <ralimi@google.com>
Date: Sun, 9 Feb 2014 22:58:15 -0800
Message-ID: <CADOmCZU7uxA8RyK7LUy2D1Op4nhVEt_Y1JxGHNCzRvpFgGbh+g@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=047d7bacb738e56c6904f207de98
X-Mailman-Approved-At: Mon, 10 Feb 2014 03:02:41 -0800
Cc: "draft-ietf-alto-protocol.all@tools.ietf.org" <draft-ietf-alto-protocol.all@tools.ietf.org>, iesg@ietf.org, secdir@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, 10 Feb 2014 06:58:49 -0000

Thank you very much for the review!

Responses inline...


On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <dharkins@lounge.org>; wrote:

>
>   Hello,
>
>   I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
>   This draft defines a protocol that allows a server to provide network
> location information, network structure and network cost/preference
> to a client which then can build an abstract view of the network in
> order to determine how best to use it.
>
>   This draft is "ready with nits" (per secdir review instructions). And
> those nits are:
>
>   - 6.1.1.1 mixes the idea of "cost" and "preference". While it's
>     natural for people to prefer lower cost I think it would be better
>     to say so explicitly: "A lower value indicates a lower cost" or
>     this field "conveys a generic measure indicating preference for
>     routing traffic from source to destination" or something like
>     that.
>

Agreed. We can clarify this section.


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


>   - 6.3, since the tag must not contain ASCII characters below
>      0x21 or above 0x7e you can't really construct one from the
>      hash of the contents of a Network Map. Also, given those
>      restrictions and the fact that a tag just has to be less than
>      or equal to 64 octets, the probability of identical tags being
>      used is not zero. I think the probability of the tag from
>      example 11.3.1.7 is 0.5 to collide with one of just 460
>      other Network Maps.
>
>      I suggest requiring a tag to be 64 octets. That will make
>      even money probability of collision among nearly 3000
>      other Network Maps, which is safer.
>

[will reply to this later in the thread]


>
>   - 8.3.5, encryption and integrity protection go hand-in-hand,
>      they cannot be "and/or". Suggest changing the sentence to
>      "When confidentiality and data integrity between client and
>      server are required, and server and/or client authentication
>      is required…." This section should refer to section 15 (Security
>      Considerations).
>

We'll resolve this by rewording to "integrity protection and/or encryption"
as you suggest below.


>
>   - 11.3.2.6, what does it mean for a Version Tag to be
>      "consistent with" another Version Tag? Do you mean that
>      they are "identical"? Same length and same value? Or would
>      "0004579342" be "consistent" with "4579342"?
>

We will reword to say "equal to" instead of "consistent with".

Section 10.3 defines equality as:

   Two values of the VersionTag are equal if and only if both the the
   'resource-id' attributes are byte-for-byte equal and the 'tag'
   attributes are byte-for-byte equal.



>
>   - 15.3.1, the ALTO data can be sensitive since it includes
>      things like endpoint addresses (useful for those who like
>      to monitor the Internet). I think risk (2) here should include
>      mention of that. There may be classes of ALTO data for
>      which certain clients are authorized to receive and others
>      are not.
>

That sounds good. Does the following sound reasonable?

... Disclosure of the ALTO service provider's data (e.g., network topology
information or endpoint addresses) to an unauthorized third party ...


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



>   - 15.4.2, authorization of an authenticated client is another
>      useful protection strategy here-- some client's may get
>      obfuscated data, and some may get the raw data.
>

Good point. We will explicitly mention authorization here as well.


>
>   I think the Security Considerations are well done.
>

Thanks!


>
>   regards,
>
>   Dan.
>
>
>
>
>