Hi all,

> Further, there are a number of large services, e.g., to name 
> a few Google Maps, Facebook, etc, that use TLS by default and 
> the apps and the server haven't melted down.

I don't think that major web sites are a good criteria.

If so, we should have a look at the security requirements of protocols somehow 
related to ALTO. For instance a quick check results in (not all references are 
standards-track, and I am no expert for those protocols):

* RFC 4743 (NETCONF over SOAP over HTTP) states "At a miniumum, all conforming 
NETCONF over SOAP implementations MUST support TLS".

* RFC 5810 for ForCES has a "SHOULD" for TLS or IPsec

* RFC 3989 and RFC 4540 mandate either TLS or IPsec

* RFC 5101 for IPFIX has a "MUST" for TLS if TCP is the transport, but Section 
11.5 states (somehow contradicting the former):  "The use of DTLS or TLS might 
not be possible in some cases due to performance issues or other operational 
concerns. Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 
and Collecting Processes can fall back on using IP source addresses to 
authenticate their peers. [...] Again, completely segregating IPFIX traffic on 
a dedicated network, where possible, can improve security even further."

The first three examples are configuration protocols that inherently have 
higher security requirements than ALTO. The last example is similar to ALTO a 
network export protocol, even though with a different use case and not running 
over HTTP.

I think that there are use cases of ALTO where "performance issues or 
operational concerns" similar to IPFIX can occur, e. g., if the ALTO client and 
the ALTO server are interconnected over a dedicated physical network to 
accommodate a potentially very high ALTO query load.

Having said this, I could imagine that a "MUST" for TLS for the ALTO base 
protocol spec could avoid IESG pushback from the security area. If so, I think 
a statement similar to IPFIX would be useful.

Michael






_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to