Hi Sebastian, Please see below.
> > > 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. > > Added this as an example as well. > > > > potential communication partners. For a more comprehensive > > > classification of risk scenarios, see cases 4, 5, and 6 in [RFC > 6708], > > > Section 5.2. > > > > > > 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. > Good idea. Added a reference to AR-14 for more considerations. > > > > 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. > > > Agreed. Revised to this structure. Thanks a lot! Richard > > > > > Thanks > Sebastian > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
