On 03/06/2013 01:08 PM, Scharf, Michael (Michael) wrote:
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.
It is a good indication of running code and a deployment of TLS at very
large scales.
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.
This isn't a topic to avoid IESG pushback, it is rather a topic of
having a protocol that allows secured deployments across an untrusted
network. And it should be up to the operator of the server to decide how
much security is needed.
This is currently reflected in the draft (-14).
Martin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
