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

Richard Alimi <ralimi@google.com> Mon, 17 February 2014 21:10 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 F06CD1A029B for <secdir@ietfa.amsl.com>; Mon, 17 Feb 2014 13:10:53 -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=unavailable
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 ipYACaInLEr0 for <secdir@ietfa.amsl.com>; Mon, 17 Feb 2014 13:10:51 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D09891A028F for <secdir@ietf.org>; Mon, 17 Feb 2014 13:10:50 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id tp5so765049ieb.27 for <secdir@ietf.org>; Mon, 17 Feb 2014 13:10:48 -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=wH5LQIaamuy14n4pE9v0MFD/z5Gyn5o11NYfjLsEoo4=; b=ft6fr5H22sJZ6OUf7HX1Q8kz//7F+SkfpF8K18RF2E5rB0jdl+sinNxpQz7Vyt1BLk pLVxEabBIdFLSbzm06lwZT1fF1f+/4MHwEWMCAvJIV/PIvmljDyJpJppJjKHu4BG5zsK xi9nrJ1zkk0mkG8o8pF6vAZcL/KebNsM6Jo719aerFCo+IONtSldOJGQSuFgxOUUjAIH yWeDLKYyAhpzo9Z9u2SHmNsvW3f+7/QPU5h8B8aoZWtpwW4GsKiHVurD4k/njr6s8sUC Tf4288WUvJMo/iM2zcg7AMyHzMV1P7OAsJ5Lk0WiCguAiBgLK+1J1ujOKQY50CqaMt5Q bMkQ==
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=wH5LQIaamuy14n4pE9v0MFD/z5Gyn5o11NYfjLsEoo4=; b=VSbwym8V8Vnck7+As9i9ilY/VWKLZXQuDwp5R2cOUtwODvyfReDknT8cnyZ3VzF6N0 20wT88JTaICt4UTuCgxOZuv+y9ZkbiI9Xv0nq6jVRc4pU3zXSnKgZvjdIHnwsQLROwTP /6vggec/CzD9kQC0iCE8X9rV+j9cX/ww5J9iNHROMkI5ZJU3QSt8D74XZ7wwB1zV4yKk 3391CHEsGjKnnfzg/ssCXebbU/A4CmwVOBvwcVB0rmEbI5T+uh1YmmRSjEhtHmbvw4+j zzDakk8ht76OcfG1pSp9Lzm0GE5VnLStiPM7GSE4Z0j1s7ABz2WQivfA/B3nErHUX4pv Ppfg==
X-Gm-Message-State: ALoCoQlIDeRaK5ue+Y1wgISWloikc97sbPugQfdqQ2CTDrJ8F5tRaozl3BJ839Rxq6MvKJRkTQJR4ysxP8HX8vC9FiPn65HwA9LHLanUwe5LbVKdyYsDwsQXnAKE7VxwuRVigXzicFxPSVYPWmAqbHXaXEOMWifOrlomHPk0EYbDyICtHBNZ930QiSbBqubT03r7bClFQYI9
X-Received: by 10.42.97.193 with SMTP id p1mr19494186icn.32.1392671448012; Mon, 17 Feb 2014 13:10:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.56.228 with HTTP; Mon, 17 Feb 2014 13:10:17 -0800 (PST)
In-Reply-To: <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net>
References: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <CADOmCZU7uxA8RyK7LUy2D1Op4nhVEt_Y1JxGHNCzRvpFgGbh+g@mail.gmail.com> <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net>
From: Richard Alimi <ralimi@google.com>
Date: Mon, 17 Feb 2014 13:10:17 -0800
Message-ID: <CADOmCZWK80noyc83GrDSWVw6TKyHxW8z_K5QBoSxDiAc7pBXKA@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=20cf30363965f2d3fb04f2a0964f
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8MSLcmcHoLXkp_EwKbaMQEH27ZQ
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, 17 Feb 2014 21:10:54 -0000

On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins <dharkins@lounge.org>; wrote:

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

The key is that the client needs to handle both types, not the server.
 During working group discussions, it was not clear that a server would
always wish to provide both and may opt to expose one or the other.

For example, one cited reason for a server not exposing numerical costs was
concerns over revealing too many details of internal network topology.

It is possible to derive ordinal costs from numerical costs.  Thus, we
could require servers to provide ordinal costs and optionally provide
numerical costs.  We opted to put this logic in the client-side, though, in
the interest of keeping the server simpler.

Richard/Reinaldo: do you believe this is still a reasonable tradeoff and am
I missing any other rationale for this?  I'm typically on the side of
keeping servers simpler, but we could reconsider if necessary.


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

I've added the following text to Section 8.3.5:

  For deployment scenarios where client authentication is desired,
  HTTP Digest Authentication MUST be supported.  TLS Client Authentication
  is the preferred mechanism if it is available.

There was extensive discussion at an earlier point on the list about
whether or not we should require TLS in all implementations, so unless you
feel it is absolutely necessary I'd prefer to not revisit that and add a
requirement that TLS client authentication be supported.

I've also made the language in 15.3.2 non-normative.


>   regards,
>
>   Dan.
>
>
>