Richard, please see inline
On Mon, Mar 18, 2013 at 12:20:53AM -0400, Y. Richard Yang wrote: > Sebastian, > > Thanks a lot! Please see below. > > On Sun, Mar 17, 2013 at 4:56 PM, Sebastian Kiesel <[email protected]>wrote: > > > Hi Richard, > > > > great job! This is a big step towards a structured security section. > > I really like it. Of course, I have some more comments and suggestions :) > > > > ----- > > > > In 13.3.2 the text about computational puzzles seems a bit too long > > given that this is just some idea we didn't analyze and specify in > > detail. I'm not an expert here but some googling suggests to me that > > the cited sip draft has expired quite some time ago. > > > > Maybe something like: > > > > ... The ALTO server can also indicate overload. More advanced protection > > schemes such as computational puzzles [I-D.jennings-sip-hashcash] could > > be used to guard expensive operations; however, no in-depth analysis and > > specification of such mechanisms has been undertaken by this document. > > > > > Agreed. Changed to > > The ALTO Server can also indicate overload. More advanced protection > schemes such as computational puzzles [I-D.jennings-sip-hashcash] may be > considered in an extension document. Very good. "We leave it open for the future" sounds even better than "so far we didn't bother" :-) > > I'm having difficulties parsing the subsection heading > > > 13.4. User Protection using ALTO Services > > > > Is ALTO to be used for protecting users (users of what?)? > > > > I guess the intention was something like: > > > > 13.4. Protection of users using ALTO services > > > > although this reads terribly. Before we try to rephrase that, let me > > propose to split 13.4. into two subsections, as two different aspects > > are in there. > > > > > The split is great, as the second did included two considerations and I > like the reordering (below) as well. > > > > > 13.4. Privacy Protection for ALTO Users > > > > 13.4.1. Risk Scenarios > > > > By analyzing the queries sent from an ALTO client, the ALTO server as > > well as a third-party intercepting the message exchange could track user > > behaviors and communication patterns. This is particularly true for the > > endpoint property service, to which the user sends the IP addresses of > > > > How about we say "endpoint property and endpoint cost services"? Right. It may also apply to the map filtering service, if you request very fine-grained filters. > > potential communication partners. For a more comprehensive > > classification of risk scenarios, see cases 4, 5, and 6 in [RFC 6708], > > Section 5.2. > > > > 13.4.2. Protection Mechanisms > > > > To protect user privacy, an ALTO Client should consider the > > possibility to rely only on Network Map for PIDs and Cost Map > > amongst PIDs to avoid passing IP addresses of other endpoints > > (e.g., peers) to the ALTO Server. > > > > [FIXME : RFC 6708 proposes a further option for > > the "target-aware query mode", which is the RFC 6708's name > > for the Endpoint Property Service: > > > > > > In the target-aware query mode, this issue can be > > addressed by ALTO clients through obfuscating the identity of > > candidate resource consumers, e.g., by specifying a broader > > address range (i.e., a shorter prefix length) than a group of > > hosts in question actually uses, or by zeroing out or randomizing > > the last few bits of IP addresses. However, there is the > > potential side effect of yielding inaccurate results. > > > > > > ... To my understanding the "zeroing out or randomizing the last > > few bits of IP addresses" would work with the Endpoint Property > > Service but not the idea of giving an address range instead of a > > single IP address - please correct me if I'm wrong. Could the map > > filtering service be used to emulate a blurred Endpoint Property > > Service? If so, please adapt this paragraph accordingly. ] > > > > Mentioning zeroing out or randomizing the last few bits can be helpful. > Yes. Filtered map can be used to emulate endpoint cost service. We will > adapt this paragraph. OK, great. > > 13.5. Undesirable results from an authenticated ALTO server > > > > How about "Undesirable Guidance from Authenticated ALTO Server"? OK, that's better. > > 13.5.1. Risk Scenarios > > > > The ALTO Service makes it possible for an ALTO Provider to > > influence the behavior of network applications. An ALTO Provider > > may be hostile to some applications and hence try to use ALTO > > Information Resources to achieve certain goals [RFC5693]: > > "redirecting applications to corrupted mediators providing > > malicious content, or applying policies in computing Cost Map based > > on criteria other than network efficiency." > > > > A related scenario is that an ALTO server could unintentionally > > give "bad" guidance. If too many ALTO clients follow the guidance > > without doing additional sanity checks and measurements, more > > preferrable hosts and/or links could get overloaded while less > > preferrable ones remain idle. Should we add a "(see alsoe AR-14 in RFC 6708)" at the end of the last sentence?! I think we can never say too often that ALTO is neither admission control nor centralized congestion control. > > 13.5.2. Protection Mechanisms > > > > Applications that are able to establish several connections to > > different resource providers at the same time (e.g., chunk-based > > peer-to-peer file sharing applications) may select those by a mix of > > ALTO-assisted and random selection. If throughput measurements do > > not show "better-than-random" results for the resource providers > > selected with ALTO support of if other evidence suggests misleading > > ALTO Information Resources, a user might want to disable ALTO usage > > or switch to another ALTO server provided by an "independent > > organization". This holds in particular if the first ALTO server is > > provided by the access network operator (see AR-20 and AR-21 in [RFC > > 6708]). An access network operator in turn might try to redirect > > queries to external ALTO servers to the operator's ALTO server or try > > to tamper with their responses. Authentication and integrity > > protection can at least detect such behavior (see > > xref-to "Authenticity and Integrity of ALTO Information Resources"). > > > > > > > > ----- > > > > > > > > Assuming that you like the section split I proposed above, I'd like > > to further propose re-ordering the sections: > > > > 13.1 Authenticity and Integrity of ALTO Information Resources > > 13.2. Undesirable results from an authenticated ALTO server > > 13.3. Confidentiality of ALTO Information Resources > > 13.4. Privacy Protection for ALTO Users > > 13.5. Availability of the ALTO Service > > > > > I think the ordering is good and will revise to it. > > > > Maybe we should also rename the 13.?.2 Sections from > > "Protection Mechanisms" to "Protection Strategies" as most of the > > text is still rather high-level recommendations. Or use a > > three-subsection design: > > 1. Risk secnarios (someone could be listening) > > 2. Protection Strategies (use encryption) > > 3. Protection Mechanisms and Guidelines (use TLS with cipher x and > > minimum key length y) > > > > Protection Strategies is a better term indeed. Let's change to it. > > As you mentioned TLS with cipher x and key length y, I assume that the > protocol spec will not specify it, as it will be a moving target and should > be handled by TLS negotiation according to best practices. What do you > think? What I wanted to say: In my first proposal, I had three subsections for every protection goal. Their headings were still worded clumsy but the idea was: 13.x.1 Risk Scenarios 13.x.2 Protection Strategy 13.x.3 Protection Mechanisms and Configuration Guidelines with "Protection Strategy" as a high-level discussion which mechansims (e.g., encryption) can solve the problems at which cost, leaving which issues open, etc. and "Protection Mechanisms and Configuration Guidelines" containing very specific guidance how to implement and configure these mechanisms. Most of the text we have so far goes into the "Risk Scenarios" and "Protection Strategy" subsections. So I'd like to propose now to rename our existing "Protection Mechanisms" sections to "Protection Strategy" Regarding "Protection Mechanisms and Configuration Guidelines" in general and TLS ciphersuites in particular: Maybe it is better to omit the 13.x.3 subsections completely, as this is indeed a moving target while RFCs last "forever". Given that our base protocol HTTP is extremely widespread I assume that there will be Best Current Practices how to secure it for very many years to come. So a rather generic reference to BCPs might be better in the long-term than a detailed elaboration of today's state of the art. What about: Software engineers developing and operators deploying ALTO must make themselves familar with up-to-date Best Current Practices how to secure HTTP against these types of attacks. This kind of sentence still could go in the respective "Protection Strategy" subsection, i.e., no need to open a separate "Protection Mechanisms" subsection. Thanks Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
