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

[Richard Alimi <[e-mail]>]

On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins <[e-mail]> 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 <[e-mail]>
> 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.
>
>
>