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

From: "Dan Harkins" <[email-masked]>
Date: Sat, 1 Feb 2014 10:54:05 -0800 (PST)

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.

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

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

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

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

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

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

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

  I think the Security Considerations are well done.

  regards,

  Dan.

---

From: Richard Alimi <[email-masked]>
Date: Sun, 9 Feb 2014 22:58:15 -0800

Thank you very much for the review!

Responses inline...

>     routing traffic from source to destination" or something like

Agreed. We can clarify this section.

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

>      other Network Maps, which is safer.

[will reply to this later in the thread]

>      is required…." This section should refer to section 15 (Security

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

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

>      which certain clients are authorized to receive and others

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

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

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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 17 Feb 2014 06:26:03 -0800 (PST)

Hi Richard,

> On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <[email-masked]> wrote:
[snip]
> 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]
> 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.

---

From: Richard Alimi <[email-masked]>
Date: Mon, 17 Feb 2014 13:10:17 -0800

> one from the other and if that's the case then why are there two things

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.

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 17 Feb 2014 17:17:14 -0500

Dan, Richard A.

On Mon, Feb 17, 2014 at 4:10 PM, Richard Alimi <[email-masked]> wrote:
> For example, one cited reason for a server not exposing numerical costs
> was concerns over revealing too many details of internal network topology.
>
> 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

I remember extensive discussions on the two modes. Given the dependency
between the numerical and the ordinal modes (one can derive the ordinal
from numerical but not the other way around), we can say that the ordinal
mode is always provided, either implicitly (only numerical) or explicitly
(when both are provided). This will allow interop.

At the same time, the discussion was that we do not enforce the explicit
approach to keep the Server simple, as Richard A. mentioned. Also, the less
redundancy at the source (maintaining both numerical and ordinal), the less
likely we encounter inconsistency.

Richard

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Feb 2014 13:39:49 -0800 (PST)

Hi Richard (Y),

> (when both are provided). This will allow interop.

  That is a good suggestion.

> likely we encounter inconsistency.

  That makes sense, one side would have to do both. If you want to keep
the server simple I guess that's the way to do it.

  thanks,

  Dan.