Dear all, I understand that prior to IETF-75 the authors of draft-penno-alto-protocol-03 where busy with merging the protocols. But I would like to point out that the security section is still far from done. Some points that immediately come to mind are:
-- 10.4.: "To fulfill these requirements, ALTO Information meant to be redistributable contains a digital signature which includes a hash of the ALTO information encrypted by the ALTO Server's private key." --> replace "encrypted by the ALTO Server's private key" with "signed by the ALTO Server's private key" [in asymmetric cryptography, you either _decrypt_ or _sign_ with a private key] -- 10.4. ALTO Information Redistribution --> you basically suggest to have the ALTO-server sign information it provides. While that is certainly a good idea, the problem of ALTO information redistribution may be more sophisticated. Martin wrote a draft on some potential issues (draft-stiemerling-alto-info-redist-00). -- "An ALTO Server may optionally use authentication and encryption to protect ALTO information. Authentication and encryption may be provided using HTTP Basic or Digest Authentication and/or SSL/TLS." --> I think this text is not specific enough. What needs to be authenticated are three things: a) the identity of the server, b) the identity of the client, and c) the ALTO information itself. TLS is a solution for a) and b), but for c) the ALTO information needs to be signed by other means, and not only on transport from client to server. Another thing the WG should discuss: is encryption necessary? Indeed, an ALTO-server should authenticate clients but the information it provides should not be confidential, especially if redistribution is specifically allowed. -- As I was mentioning during the ALTO session in Stockholm, I see the risk of Denial-of-Service attacks on ALTO servers. Even if the ALTO server has some pre-computed cost maps, an attacker could easily stress an ALTO server by simply querying all potential permutations of source-lists and destinations-lists. It is unlikely that the ALTO-server has all of them pre-computed. In security, it is always seen problematic (from a DoS perspective) if simple/small messages can generate large workload at a server. I think this is the case for ALTO if a Path Rating query has a list of multiple Source Network Locations. -- I think the security section has only very general text on privacy issues. This is strange since the draft says: "Two key design objectives of the ALTO Protocol are simplicity and extensibility. At the same time, it introduces additional techniques to address potential scalability and privacy issues." It would be nice to discuss these issues in the concrete scope of the proposed ALTO-protocol. Again, I know the authors were focusing on the merge, but I hope they agree that the security section needs much more work. I felt like giving it a start with some comments. - Jan ============================================================ Jan Seedorf Research Scientist NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 Fax: +49 (0)6221 4342-155 e-mail: [email protected] ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
