Subject: Re: [alto] alto Digest, Vol 53, Issue 2

From: Wendy Roome <[email-masked]>
Date: Mon, 04 Mar 2013 13:18:41 -0500

Can anyone explain why every ALTO server is now *required* to provide an
https interface, and encryption, and client authentication? That seems to
be a rather onerous requirement. The basics aren't bad, but doing it the
right way -- using a properly signed certificate from a recognized
authority, keeping the keys and user info protected, etc -- is a lot of
work.

Or does that just mean that if an ALTO server choses to do
encryption/authentication, it must do it via ssl/tls, rather than some ad
hoc scheme?

	- Wendy Roome

>Date: Fri, 1 Mar 2013 22:26:49 -0500
>From: "Y. Richard Yang" <[email-masked]>
>Subject: [alto] Summary of draft-ietf-alto-protocol changes between
>	-13 and	-14
	......
>
>  - Changed from MAY to MUST: An ALTO Server MUST support SSL/TLS
>[RFC5246]
>to implement server and/or client authentication ... (Sec. 7.3.5 in -14;
>Sec. 6.3.5 in -13)
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 4 Mar 2013 18:23:10 +0000

Agreed. It would be good if we added wording such as:

"An ALTO Server MUST support TLS/SSL unless there is an implicit trust
relationship between client and server.."

Implicit trust could mean that client and server are operated by same
entity, or sit in some trusted network, etc.

On 3/4/13 3:18 PM, "Wendy Roome" <[email-masked]> wrote:

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

---

From: Wendy Roome <[email-masked]>
Date: Mon, 04 Mar 2013 13:47:05 -0500

I suggest just putting it back the way it was -- "An ALTO server MAY use
ssl/tls ..." Let the market decide. Providers who want to protect their
data will only provide secure ALTO servers. Fine! But if someone wants to
provide ALTO as a public service, and they don't care who uses it, why
should they be required to use ssl/tls?

Also, ssl/tls is independent of the ALTO protocol spec. It's not like the
protocol defines client ids, how to authenticate clients, etc.

Finally, wasn't one of our goals to allow proxy servers to cache full cost
maps, to cut the load on ALTO servers? Wouldn't the ssl/tls requirement
prevent that?

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 4 Mar 2013 14:35:55 -0500

Hi Wendy,

The context of the change is the following AD Review:

" What security mechanism to use in what scenario. The considerations
elaborate on the use of SSL/TLS, but it is not clear when to use it. In
general, it seems to be really good, at least by today, to mandate the use
of HTTPS in almost any scenario where the traffic crosses a publicly
available infrastructure, e.g., the general Internet, wireless access
networks, etc. Conversely, it can be good to always mandate the use of
HTTPS and to list exceptional cases where it is required, i.e., CDNI
peering point."

How about the following revision:

"When server and/or client authentication, encryption, and/or
integrity protection
are required, ALTO Server MUST support SSL/TLS [RFC5246] as a mechanism.
For cases such as a public ALTO service or there is an implicit trust
relationship between the client and the server, SSL/TLS may not be
necessary."

Richard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 5 Mar 2013 07:44:01 +0000

I think we should separate authentication from encryption/integrity more explicitly as I think there may be cases where one is required but not the other.

So how about:

"When one or more of server or client authentication, encryption or integrity protection are required, an ALTO Server MUST support SSL/TLS [RFC5246] as a mechanism. For cases such as a public ALTO service or where there exists an implicit trust relationship between the client and the server, SSL/TLS may not be necessary."

Ben

On 4 Mar 2013, at 19:35, Y. Richard Yang wrote:

> " What security mechanism to use in what scenario. The considerations elaborate on the use of SSL/TLS, but it is not clear when to use it. In general, it seems to be really good, at least by today, to mandate the use of HTTPS in almost any scenario where the traffic crosses a publicly available infrastructure, e.g., the general Internet, wireless access networks, etc. Conversely, it can be good to always mandate the use of HTTPS and to list exceptional cases where it is required, i.e., CDNI peering point."
> 
> "When server and/or client authentication, encryption, and/or integrity protection are required, ALTO Server MUST support SSL/TLS [RFC5246] as a mechanism. For cases such as a public ALTO service or there is an implicit trust relationship between the client and the server, SSL/TLS may not be necessary."
> 
> Richard
> 
> On Mon, Mar 4, 2013 at 1:47 PM, Wendy Roome <[email-masked]> wrote:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 05 Mar 2013 09:57:40 +0000

This definitely makes sense to me...

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 5 Mar 2013 13:47:52 +0100

Hi,

On Tue, Mar 05, 2013 at 07:44:01AM +0000, Ben Niven-Jenkins wrote:
> I think we should separate authentication from encryption/integrity
> more explicitly as I think there may be cases where one is required
> but not the other.

I would rather distinguish between authentication/integrity protection
(i.e., ensuring that the client gets non-forged guidance) and 
encryption (i.e., keep the client's queries and/or the server's replies
secret from a third party).

Furthermore, we need to distinguiush between implementation, i.e., a
piece of software, and deployment of that software in a specific network
scenario.  

I'd say a RFC-compliant implementation MUST support TLS and an operator
setting up that software SHOULD enable it.

As this document is about standardizing the protocol, it might be wise
to omit the second half of that sentence and move recommendations
regarding the deployment to the deployment considerations draft.

   Thanks
   Sebastian

---

From: Wendy Roome <[email-masked]>
Date: Tue, 05 Mar 2013 10:39:00 -0500

Richard,

Your proposal sounds fine. After all, it's a "motherhood" statement. Who
could argue with, "If you need security, etc, use ssl/tls."?

However, I am surprised by the suddenly perceived need for security, and I'd
object to anything that implies that the default is to use ssl/tls. I think
that will kill the protocol. I'd always thought that ALTO was primarily
intended to be a public service that network operators provide to all
applications, not an exclusive service available only to a few trusted
components. A network operator would provide a public ALTO service because
it benefits the operator as well as the client. Sure, some operators might
restrict access, but most wouldn't bother. A few observations:

* An ALTO server just returns a limited view of the network statistics. It's
not like it gives out launch codes or banking data, or allows a client to
change anything. Why is it so important to keep that data secret? Especially
if a server can use ordinal mode to obscure the details?

* The only use case in draft 14 is a P2P tracker. By definition, P2P
trackers are distributed & anarchistic, and can be run by any Tom, Dick or
Sally. I don¹t think it's practical to authenticate thousands of P2P tracker
clients. Besides, most tracker operators wouldn't hesitate to post their
ALTO authentication credentials on the web. :-)

* I can see why an ALTO client might want to authenticate the server, to
prevent spoofing. Although that begs the question of why someone would
bother to spoof an ALTO server -- how would they benefit?

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Mon, March 4, 2013 14:35
To:  Bill Roome <[email-masked]>
Cc:  "Reinaldo Penno (repenno)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [alto] ALTO vs ssl/tls

Hi Wendy,

" What security mechanism to use in what scenario. The considerations
elaborate on the use of SSL/TLS, but it is not clear when to use it. In
general, it seems to be really good, at least by today, to mandate the use
of HTTPS in almost any scenario where the traffic crosses a publicly
available infrastructure, e.g., the general Internet, wireless access
networks, etc. Conversely, it can be good to always mandate the use of HTTPS
and to list exceptional cases where it is required, i.e., CDNI peering
point."

"When server and/or client authentication, encryption, and/or integrity
protection are required, ALTO Server MUST support SSL/TLS [RFC5246] as a
mechanism. For cases such as a public ALTO service or there is an implicit
trust relationship between the client and the server, SSL/TLS may not be
necessary."

Richard

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 17:14:23 +0100

Wendy,

would a 'MUST implement TLS/SSL' fix your concern? This does say that 
the implementation must have it, but it does not preclude to use it, 
e.g., if you operate the ALTO server in your data center only.

   Martin

On 03/05/2013 04:39 PM, Wendy Roome wrote:
> However, I am surprised by the suddenly perceived need for security, and
> I'd object to anything that implies that the default is to use ssl/tls.
> I think that will kill the protocol. I'd always thought that ALTO was
> primarily intended to be a public service that network operators provide
> to all applications, not an exclusive service available only to a few
> trusted components. A network operator would provide a public ALTO
> service because it benefits the operator as well as the client. Sure,
> some operators might restrict access, but most wouldn't bother. A few
> observations:
>
> * An ALTO server just returns a limited view of the network
> statistics. It's not like it gives out launch codes or banking data, or
> allows a client to change anything. Why is it so important to keep that
> data secret? Especially if a server can use ordinal mode to obscure the
> details?
>
> trackers are distributed & anarchistic, and can be run by any Tom, Dick
> or Sally. I don’t think it's practical to authenticate thousands of P2P
> tracker clients. Besides, most tracker operators wouldn't hesitate to
> post their ALTO authentication credentials on the web. :-)
>
> From: "Y. Richard Yang" <[email-masked] <mailto:[email-masked]>>
> To: Bill Roome <[email-masked]
> <mailto:[email-masked]>>
> Cc: "Reinaldo Penno (repenno)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> general, it seems to be really good, at least by today, to mandate the
> use of HTTPS in almost any scenario where the traffic crosses a publicly
> integrity protection are required, ALTO Server MUST support SSL/TLS
> [RFC5246] as a mechanism. For cases such as a public ALTO service or
> there is an implicit trust relationship between the client and the
> server, SSL/TLS may not be necessary."
>
> Richard
>
>
>

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Mar 2013 18:31:01 +0200

I believe it would be good to state what version of TLS is mandatory to implement. I would suggest TLS 1.2. 
(I assume ALTO needs PK-based server side authentication) 

On Mar 5, 2013, at 6:14 PM, Martin Stiemerling wrote:

> Wendy,
> 
> would a 'MUST implement TLS/SSL' fix your concern? This does say that the implementation must have it, but it does not preclude to use it, e.g., if you operate the ALTO server in your data center only.
> 
>  Martin
>

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 5 Mar 2013 17:30:45 +0100

Hi,

On Tue, Mar 05, 2013 at 10:39:00AM -0500, Wendy Roome wrote:
> However, I am surprised by the suddenly perceived need for security, 

I don't believe that this came suddenly.  Please have a look at our
requirements document, RFC 6708, Section 3.3.  The requirements have
been discussed and written down quite some time ago, then the doc has
been kept open to allow modifications and it has been finalized only
some months ago.

> and I'd
> that will kill the protocol.

Can you please be more specific.

Would it be too painful to write an ALTO server and client software that
has TLS support?

Or do you fear that operators would refrain from installing an ALTO
server if they read that they SHOULD enable TLS?

The IETF usually standardizes protocols, not use cases.  Assuming that
TLS support is not too painful at software implementation level, I'd
prefer to see it mandatory (MUST).  Regarding the second aspect we could
use a rather weak statement such as the "Note:" preamble of Sec. 3.3 in
RFC 6708  or maybe make no statement at all.

Thanks
Sebastian

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 5 Mar 2013 17:49:29 +0100

All,

>From a high-level perspective, I think there are three different aspects:

1) ALTO client may want to confirm that ALTO server is not spoofed.

2) ALTO servers may want to authenticate clients to ensure that only allowed clients get guidance.

3) ALTO servers may want that communication is encrypted, since ALTO information is possibly sensitive

At first sight, these three goals seem orthogonal to me. For instance:

1) This requirement may not be a significant issue of an ALTO server discovery method is used that is tightly coupled with the access network, because spoofing the discovery result is then pretty difficult. In such cases, the additional protection by TLS/SSL seems limited.

2) For guidance of unstructured P2P networks, this seems unrealistic with any credential-based method. In my opinion, it is more likely that the ALTO server will be protected by firewalls that only allow intra-domain access. For P2P tracker guidance, client authentication might be possible for a well-defined number of P2P systems. It also seems possible that an ALTO server could expose more detailed maps to well-known users than to random P2P clients. Client authentication is certainly very relevant for many non-P2P use cases.

3) This depends on whether client and server communicate over a possibly untrusted network. For instance, if ALTO client and server are in the same physical network, encryption is not a major issue. Also, if the ALTO maps are very simple and provide simple information only (e. g., inside-AS vs. outside-AS address ranges), encryption might not be needed even if ALTO clients are spread over the whole Internet.

In summary, I think there are several cases where enabling of TLS/SSL is not really needed. Also, I might be wrong, but if an operator only has requirement 2), maybe HTTP authentication (RFC 2617) without using TLS/SSL encryption would be just sufficient.

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Stiemerling
> Sent: Tuesday, March 05, 2013 5:14 PM
> To: Roome, W D
> Cc: [email-masked]
> would a 'MUST implement TLS/SSL' fix your concern? This does 
> say that the implementation must have it, but it does not 
> preclude to use it, e.g., if you operate the ALTO server in 
> your data center only.
> 
>    Martin
> 
> > Your proposal sounds fine. After all, it's a "motherhood" 
> statement. 
> > Who could argue with, "If you need security, etc, use ssl/tls."?
> >
> > and I'd object to anything that implies that the default is 
> to use ssl/tls.
> > primarily intended to be a public service that network operators 
> > provide to all applications, not an exclusive service 
> available only 
> > to a few trusted components. A network operator would 
> provide a public 
> > ALTO service because it benefits the operator as well as 
> the client. 
> > Sure, some operators might restrict access, but most 
> wouldn't bother. 
> > A few
> > observations:
> >
> > statistics. It's not like it gives out launch codes or 
> banking data, 
> > or allows a client to change anything. Why is it so 
> important to keep 
> > that data secret? Especially if a server can use ordinal mode to 
> > obscure the details?
> >
> > trackers are distributed & anarchistic, and can be run by any Tom, 
> > Dick or Sally. I don't think it's practical to authenticate 
> thousands 
> > of P2P tracker clients. Besides, most tracker operators wouldn't 
> > hesitate to post their ALTO authentication credentials on 
> the web. :-)
> >
> > * I can see why an ALTO client might want to authenticate 
> the server, 
> > to prevent spoofing. Although that begs the question of why someone 
> > would bother to spoof an ALTO server -- how would they benefit?
> >
> > - Wendy Roome
> >
> > elaborate on the use of SSL/TLS, but it is not clear when 
> to use it. 
> > In general, it seems to be really good, at least by today, 
> to mandate 
> > the use of HTTPS in almost any scenario where the traffic crosses a 
> > publicly available infrastructure, e.g., the general Internet, 
> > wireless access networks, etc. Conversely, it can be good to always 
> > mandate the use of HTTPS and to list exceptional cases where it is 
> > required, i.e., CDNI peering point."
> >
> Athene, Odyssey Business Park, West End  Road, London, HA4 
> 6QE, GB Registered in England 2832014

---

From: Wendy Roome <[email-masked]>
Date: Tue, 05 Mar 2013 13:52:55 -0500

First, TLS is much more overhead, both network & server. It requires
several handshakes between the client & server. Granted, once a client &
server have established a TLS connection, they can reuse that TLS
connection for subsequent requests -- for a while. That's fine if a client
sends an ALTO request every few seconds, but not if it's minutes between
requests. And, of course, full cost maps can easily be megabytes, so the
encryption eats cpu cycles on the server.

Second, if I'm running a server, I have to get a properly signed
certificate. That usually means I must prove to an authority that I
legally represent some company, and pay for it. Yes, I can self-sign a
cert for testing, but that's useless for a production system.

Third, the server has to keep that cert in an encrypted file, and give the
password to the ALTO web server. The latter can be an interesting
challenge. The simple way is to put the password in a startup shell. Of
course, that's not very secure. A better way is to require a human to
enter the password each time the ALTO server starts. That has a different
set of problems.

Finally, on the client side, basic access is easier than it used to be.
But if a client needs to authenticate itself to a server, then the client
also has to get a certificate, keep it encrypted, and give the password to
the ALTO client application securely.

I think that if an ALTO server operator feels they need that level of
security, fine, let them use SSL/TLS. But I think the operator should make
that decision. Why should we say that ALTO data is so inherently sensitive
that any valid ALTO server MUST encrypt it? Particularly since a server
can use PIDs and ordinal costs to hide critical details of their network?

Put it another way, consider the arguments for why ALTO data *must* be
encrypted. Then apply those arguments to (say) google maps. I suspect
you'll conclude that google maps must be encrypted as well. After all,
clients give google maps their current locations, which is sensitive data.
And some creep who spoofs a google maps server can do a lot of harm --
probably more than someone who spoofs an ALTO server!

	- Wendy Roome

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 5 Mar 2013 20:56:19 +0000

> you'll conclude that google maps must be encrypted as well.

I used my browser to go to maps.google.com, and the URL used is
http://maps.google.com.

So it seems Google already concluded that maps must be encrypted. :)

You'll find that more than a few public web services (search, social nets)
use TLS/SSL to protect the client side.

You should consider the ALTO client's request to be sensitive information,
not just the server's response.

-- Rich

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Mar 2013 11:55:11 +0100

Wendy,

> encryption eats cpu cycles on the server.

The last part assumes that you tear down the TCP connection after you 
have received the map. That is not necessarily true.

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.

> cert for testing, but that's useless for a production system.

This all assumes that your deployment is using TLS/SSL. However, the 
ALTO protocol itself must support TLS/SSL even if it is not used in 
certain deployments.

I see that you mix the need to have it in the protocol and the actual 
usage in deployments.

> enter the password each time the ALTO server starts. That has a different

What's the issue here?
Apparently there are deployments using TLS with proper certs...

> the ALTO client application securely.

That is a different story, isn't it?
TLS is mainly used to check if the server is the server it claims to be 
and to setup an encrypted connection to it. Sure there is the 
possibility to also authenticate the client to the server, but that is 
rarely used.
This is a very nice example to show what the protocol must implemented 
but what is not used in deployments!

> that decision. Why should we say that ALTO data is so inherently sensitive

Right.

> can use PIDs and ordinal costs to hide critical details of their network?

Nobody is saying this.

Section 7.3.5 of draft-ietf-alto-protocol-14 says
"An ALTO Server MUST support SSL/TLS [RFC5246] to implement server
and/or client authentication, encryption, and/or integrity
protection."

> probably more than someone who spoofs an ALTO server!

Have you recently used and checked what Google Maps is doing?

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 6 Mar 2013 12:48:44 +0100

> the ALTO client application securely.

I more or less agree with all these points.

> that decision. 

I fully agree. The operator should make that decision. But the operator
is able to make a choice only if the software has a switch to turn on
(or off) TLS usage.

We are currently working towards a standards track RFC with the title
"ALTO Protocol".  My interpretation is that the primary goal of this
document is NOT to give guidance to ALTO server operators whether/when
to use TLS or not (this kind of information might become a side note,
but I think it would better fit in our separate "ALTO deployment
considerations" document, which admittedly still needs much work).

Instead, I belive the primary goal of the "ALTO protocol" RFC will be,
that when a software vendor offers ALTO software to an operator, they
can claim "our software is RFCxxxx-compliant" and then the operator
(i.e., software buyer) can expect interoperability with
RFCxxxx-compliant software from other software vendors, as well as a
well-defined set of properties to be fulfilled. The ability to switch on
TLS if desired should be one such property.

> Why should we say that ALTO data is so inherently sensitive
> that any valid ALTO server MUST encrypt it?

We don't want to say that.

We want to say: "any piece of software that claims to be
RFCxxxx-compliant MUST be linked against a SSL lib and have config file
options where the operator can put the certificates, etc. Furthermore,
there must be adequate mechanisms that kick in when certificate
verification failed." 

More formal, as we do not know whether future operation system platforms
will have libraries and config files: "Any ALTO implementation MUST
support SSL/TLS [RFC5246]"

Of course, there may be a config file option to disable TLS.

Does this make sense to you?

Thanks
Sebastian

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 6 Mar 2013 13:08:37 +0100

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Mar 2013 14:03:26 +0100

On 03/06/2013 01:08 PM, Scharf, Michael (Michael) wrote:
>> Google Maps, Facebook, etc, that use TLS by default and the apps
>> and the server haven't melted down.
>

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 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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 6 Mar 2013 14:32:21 +0100

> 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.
> 

For what it is worth, the exact phrasing in -14 confuses me: "An ALTO Server MUST support SSL/TLS [RFC5246] to implement server and/or client authentication, encryption, and/or integrity protection."  I could read this in a way that the ALTO server MUST announce all services on HTTPS URIs, and this is certainly not what we want. (And, having "and/or" in a MUST statement might not be perfect.)

If the consensus is the MUST, I'd at least prefer Sebastian's wording: "Any ALTO implementation MUST support SSL/TLS [RFC5246]".

Michael

---

From: Wendy Roome <[email-masked]>
Date: Wed, 06 Mar 2013 09:25:50 -0500

Thanks, Michael. That's why I brought this up in the first place: I didn't
know what that statement in -14 meant, and I wanted clarification. I can
think of at least three interpretations:

1. If an ALTO server chooses to do authentication/encryption, it must do
it with SSL/TLS. That is, an ALTO server may choose to offer just an
unsecured/unauthenticated http: interface, or just a secure https:
interface, or both.

2. A server must provide an encrypted/secure SSL/TLS interface as well as
an unencrypted interface. That is, a compliant ALTO server must support
both http: and https: requests.

3. A server is only allowed to provide an encrypted/secure SSL/TLS
interface. That is, a compliant ALTO server cannot accept unsecured http:
requests.

I prefer #1. I can live with #2, but I don't think it's necessary. And I
strongly oppose #3.

	- Wendy Roome

On 03/06/2013 08:32, "Scharf, Michael (Michael)"
<[email-masked]> wrote:

>For what it is worth, the exact phrasing in -14 confuses me: "An ALTO
>Server MUST support SSL/TLS [RFC5246] to implement server and/or client
>authentication, encryption, and/or integrity protection."  I could read
>this in a way that the ALTO server MUST announce all services on HTTPS
>URIs, and this is certainly not what we want. (And, having "and/or" in a
>MUST statement might not be perfect.)
>
>If the consensus is the MUST, I'd at least prefer Sebastian's wording:
>"Any ALTO implementation MUST support SSL/TLS [RFC5246]".
>
>Michael

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2013 16:29:33 +0200

Minor correction: 

"Any ALTO implementation MUST support TLS 1.2 [RFC5246]."

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2013 16:34:52 +0200

> For what it is worth, the exact phrasing in -14 confuses me: "An ALTO Server MUST support SSL/TLS [RFC5246] to implement server and/or client authentication, encryption, and/or integrity protection…

Btw, client authentication in TLS is a bit more difficult (from an operational point of view) since you have to issue certificates to clients. If you on the other hand want a different credential to be used (for example shared secrets) then you will have to say that by choosing a different ciphersuite. The sentence above seems to indicate that you may want to want to support client authentication in TLS as well. 

A separate question is whether you actually use TLS.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 6 Mar 2013 15:44:00 +0100

I'm in favor of option 2.  Let's find a wording that is unambiguous.

Thanks
Sebastian

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 6 Mar 2013 07:02:45 -0800

> I prefer #1. I can live with #2, but I don't think it's necessary. And I

Speaking as a network security and network measurement person, I have the opposite reaction.  #3 is optimal, #2 I can live with, and I strongly advise against #1.

For server authentication, TLS imposes four costs.  

Three are trivial: the amount of CPU usage for key exchange, the cost for a certificate (GoDaddy claims $6/year), and the need to use a distinct IP for the hostname if you can't support Server Name Identification.  

One is real: making sure you don't screw up on installing and rolling the certificate.

Both #2 and #3 have the same cost.

But TLS offers a huge advantage:  Proxies abound, and HTTP proxies even moreso.  The result is there are an amazing number of network devices which think they are smarter than the traffic, but well, they aren't.  E.g. half of the in-path HTTP caches cache data incorrectly.  Cellphone networks now experience image transcoding, etc.

If you want to avoid the headaches caused by these too-smart-for-their-own-good middleboxes, you have to use TLS on port 443, its just about the only port and protocol thats unmolested by the network.

For client authentication, TLS is a pain.  But it depends on context: if its new program to server, TLS client authentication is no worse than ANY other authentication mechanism, as you still have the exchange/pairing problem no matter what.  If its User to Server, its an utter abominable failure.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 6 Mar 2013 16:29:26 +0100

> Three are trivial: the amount of CPU usage for key exchange, 

Plus potential handshake delay - note that an ALTO query could be part of a latency-sensitive operation, and ALTO server and clients could be geographically distributed.

> the cost for a certificate (GoDaddy claims $6/year), and the 
> need to use a distinct IP for the hostname if you can't 
> support Server Name Identification.  
> 
> But TLS offers a huge advantage:  Proxies abound, and HTTP 
> proxies even moreso.  The result is there are an amazing 
> number of network devices which think they are smarter than 
> the traffic, but well, they aren't.  E.g. half of the in-path 
> HTTP caches cache data incorrectly.  Cellphone networks now 
> experience image transcoding, etc.

Why would such proxies be relevant if the ALTO client and the ALTO server run on two high-end servers inside the same data center rack, with a dedicated and isolated 1 or 10 Gbit/s network link in between them?

ALTO is a generic protocol. It can be deployed in very different ways.

Michael

> If you want to avoid the headaches caused by these 
> too-smart-for-their-own-good middleboxes, you have to use TLS 
> on port 443, its just about the only port and protocol thats 
> unmolested by the network.
> 
> For client authentication, TLS is a pain.  But it depends on 
> context: if its new program to server, TLS client 
> authentication is no worse than ANY other authentication 
> mechanism, as you still have the exchange/pairing problem no 
> matter what.  If its User to Server, its an utter abominable failure.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 6 Mar 2013 07:53:14 -0800

> Plus potential handshake delay - note that an ALTO query could be part of a latency-sensitive operation, and ALTO server and clients could be geographically distributed.

In that case, add 2 network RTTs on the connection setup for the handshake.

And hold the connection open, both costs (CPU and handshake latency) are only on connection establishment, so they should only affect the first query, not subsequent queries.

Finally, if you are so latency sensitive that you can't handle the extra 2 RTTs of network latency on connection establishment, do a protocol over DNS with DNSSEC validation, because that can get you single RTT cryptographically-authenticated query/response (if you also do a parallel query for the DS and DNSKEY RRSETs so you have all the cryptographic data at the same time.  You can also safely fall back to "DNS with no DNSSEC" if on a broken network which is blocking DNSSEC and the protocol is only used for host discovery, not key exchange.).

> Why would such proxies be relevant if the ALTO client and the ALTO server run on two high-end servers inside the same data center rack, with a dedicated and isolated 1 or 10 Gbit/s network link in…

And in that model, there is NO cost for TLS because you do the connection establishment once and the cost disappears.

> ALTO is a generic protocol. It can be deployed in very different ways.

At the same time, without at least #2, you are in huge trouble if there exists some supposedly "smart" middlebox....

There are NATs that inject responses into HTTP traffic, as well as ISPs.  There are transcoding proxies that convert 64 kB images into 4 kB blobs that would display poorly on a commodore 64.  There are web proxies that contain 3 year old! vulnerabilities.  If its possible for an HTTP middlebox to screw up traffic in some way, there probably is a deployed middlebox that does it already.

ALTO is something new, and if you really want it to work reliably, in as many contexts as possible, ESPECIALLY over port 80, you must account for the middleboxes.  

And the way to account for the middleboxes is to require support for TLS on port 443, so that the middleboxes are forced to go "hands off".

And once you mandate support for TLS, what reason is there to not always use it?

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 6 Mar 2013 17:33:58 +0100

> > Plus potential handshake delay - note that an ALTO query 
> could be part of a latency-sensitive operation, and ALTO 
> server and clients could be geographically distributed.
> 

In the world of signaling protocols (and, yes, ALTO can be seen as a signaling protocol), two RTTs can be a lot.
 
> And hold the connection open, both costs (CPU and handshake 
> latency) are only on connection establishment, so they should 
> only affect the first query, not subsequent queries.

This assumes that the ALTO client can maintaining a pool of persistent connections, that the HTTP server has enough resources to keep these connections open, etc. All this is about software engineering. I don't think that the ALTO base document should enforce specific ways how an ALTO client or server is designed internally.

> Finally, if you are so latency sensitive that you can't 
> handle the extra 2 RTTs of network latency on connection 
> establishment, do a protocol over DNS with DNSSEC validation, 
> because that can get you single RTT 
> cryptographically-authenticated query/response (if you also 
> do a parallel query for the DS and DNSKEY RRSETs so you have 
> all the cryptographic data at the same time.  You can also 
> safely fall back to "DNS with no DNSSEC" if on a broken 
> network which is blocking DNSSEC and the protocol is only 
> used for host discovery, not key exchange.).

ALTO is a protocol that provides am IT-friendly, RESTful network interface that can easily be integrated in whatever application. I doubt that many app developers would consider DNSSEC a reasonable alternative to HTTP/REST.

> >> But TLS offers a huge advantage:  Proxies abound, and HTTP proxies 
> >> even moreso.  The result is there are an amazing number of network 
> >> devices which think they are smarter than the traffic, but 
> well, they 
> >> aren't.  E.g. half of the in-path HTTP caches cache data 
> incorrectly.  
> >> Cellphone networks now experience image transcoding, etc.
> > 
> > Why would such proxies be relevant if the ALTO client and 
> the ALTO server run on two high-end servers inside the same 
> data center rack, with a dedicated and isolated 1 or 10 
> Gbit/s network link in between them?
> 
> And in that model, there is NO cost for TLS because you do 
> the connection establishment once and the cost disappears.
> 
> At the same time, without at least #2, you are in huge 
> trouble if there exists some supposedly "smart" middlebox....
> 
> There are NATs that inject responses into HTTP traffic, as 
> well as ISPs.  There are transcoding proxies that convert 64 
> kB images into 4 kB blobs that would display poorly on a 
> commodore 64.  There are web proxies that contain 3 year old! 
> vulnerabilities.  If its possible for an HTTP middlebox to 
> screw up traffic in some way, there probably is a deployed 
> middlebox that does it already.
> 
> 
> ALTO is something new, and if you really want it to work 
> reliably, in as many contexts as possible, ESPECIALLY over 
> port 80, you must account for the middleboxes.  
> 
> And the way to account for the middleboxes is to require 
> support for TLS on port 443, so that the middleboxes are 
> forced to go "hands off".
> 

I think that the root cause for this discussion is that we talk here about *very* different deployment cases.

I agree that TLS could help if a residential user runs an the ALTO client behind a broken middlebox, if this is what you care about. If that helps, I am fine with adding some recommendation in the base protocol spec that recommends enabling of TLS when the ALTO server is accessed by residential users (even though this might much better fit into the ALTO deployment draft).

But I disagree that this is the only relevant deployment scenario for the base protocol. And I strongly believe that we should not mandate what an ALTO server operator has to write into his configuration file.

Michael

---

From: Wendy Roome <[email-masked]>
Date: Wed, 06 Mar 2013 12:05:56 -0500

On 03/06/2013 10:53, "Nicholas Weaver" <[email-masked]> wrote:

>At the same time, without at least #2, you are in huge trouble if there
>exists some supposedly "smart" middlebox....
>
>There are NATs that inject responses into HTTP traffic, as well as ISPs.
>There are transcoding proxies that convert 64 kB images into 4 kB blobs
>that would display poorly on a commodore 64.  There are web proxies that
>contain 3 year old! vulnerabilities.  If its possible for an HTTP
>middlebox to screw up traffic in some way, there probably is a deployed
>ALTO is something new, and if you really want it to work reliably, in as
>many contexts as possible, ESPECIALLY over port 80, you must account for
>the middleboxes.  
>
>And the way to account for the middleboxes is to require support for TLS
>on port 443, so that the middleboxes are forced to go "hands off".

Clearly you've been burned by middleboxes! I have as well, although not
since the 1997.

But don't most of those problems come from middleboxes trying to "improve"
html -- simplify it, remove ads, reformat it, etc? Or compress images? And
don't those middleboxes base their transformations on the content type?
Since ALTO messages are new mime type, it's unlikely those boxes would
change them.

Also, I believe one of the reasons for switching to a more REST-ful
structure (around draft 8) was to make it easier for proxies to cache full
network and cost maps.

And although I haven't personally been burned by this, I've been told some
middleboxes block port 443. Eg, to prevent employees from shopping when
they should be working.

>And once you mandate support for TLS, what reason is there to not always

Here's the reason. Suppose the protocol spec states that an ALTO server
*cannot* use unencrypted http. That's telling a potential ALTO service
provider, "You're too stupid to make the right choice. We know best."

Yes, that is a very nasty way to put it. But that is the message that
requirement would send.

I prefer to assume that providers are smart enough to pick the appropriate
level of security for their environment, their client base, and the
sensitivity of their network data. That means you, as a potential ALTO
service provider, are perfectly free to have your ALTO server accept https
only. And as a potential client, you're free to refuse to use ALTO servers
that don't provide https. But other people can make other choices.

	- Wendy Roome

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 6 Mar 2013 10:07:58 -0800

> Since ALTO messages are new mime type, it's unlikely those boxes would

Its not just burned by middleboxes, but one of the few who really SEE lots of the middleboxes with Netalyzr and explicitly test them, since a lot of the tests are centered around finding middleboxes and making sure they actually work right.

(In fact, the original reason I started writing Netalyzr was suspicion that my (now dropped) home ISP had a malfunctioning in-path cache.)

> structure (around draft 8) was to make it easier for proxies to cache full

OH F#)@#*( NO.  Web caches are not that common, but when they are they are BROKEN half the time: caching data which should not be cached.  Seriously, about 1/2 the in-path HTTP caches observed with Netalyzr cache data marked as "oh, please don't cache", or "OH FOR THE LOVE OF PETE DON'T CACHE THIS"!

> middleboxes block port 443. Eg, to prevent employees from shopping when

Anyone blocking 443 is "breaking the web", because there are a huge # of sites which have absolute business need but also require TLS for at least sign-on.  

A better solution for such businesses is to put in their own root certificate into browsers and use one of the SSL middleboxes, which are nicely commercially available for these cases.

> Yes, that is a very nasty way to put it. But that is the message that

Unencrypted HTTP needs to die anyway.  

But I can see the point of "FORCE TLS" might be a problem in a few cases.

But MANDATING TLS support is essential for far more cases, and if you MANDATE TLS, it is the height of foolishness not to prefer TLS.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 7 Mar 2013 12:45:08 +0100

On 03/06/2013 02:32 PM, Scharf, Michael (Michael) wrote:
>>> base protocol spec could avoid IESG pushback from the security
>>> area. If so, I think a statement similar to IPFIX would be
>>> useful.
>>
>> 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.
>>
> Server MUST support SSL/TLS [RFC5246] to implement server and/or
> client authentication, encryption, and/or integrity protection."  I
> could read this in a way that the ALTO server MUST announce all
> services on HTTPS URIs, and this is certainly not what we want. (And,
> having "and/or" in a MUST statement might not be perfect.)
>
> If the consensus is the MUST, I'd at least prefer Sebastian's
> wording: "Any ALTO implementation MUST support SSL/TLS [RFC5246]".

Sebastian's proposal is better, indeed.

That's by the way the same proposal I have asked Wendy at some point, 
but didn't get response ;)

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 7 Mar 2013 12:46:57 +0100

> I prefer #1. I can live with #2, but I don't think it's necessary. And I

#1: no

#2: yes please but wit the wording that the 'ALTO server implementation 
MUST have it'. Otherwise it is again mixing what the protocol supports 
in implementations and what deployments can do.

#3: in an ideal world, but not in this world.

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Wendy Roome <[email-masked]>
Date: Thu, 07 Mar 2013 09:48:53 -0500

Sorry, Martin, I was trying to limit my comments. I felt bad enough that I
started this fire. I didn't want to pour more gas on it!

But that said, I wasn't sure what Sebastian meant by "support". It seemed
like that he meant that the underlying server package had to have the
*ability* to support SSL/TLS, but it didn't have to be enabled.

But if that's the requirement, then it seems to me that it's impossible to
determine whether an ALTO server satisfies it. To an outside observer,
what's the difference between "this computer has TLS software, but the
admin didn't configure a TLS listener on port 443" vs "there's no TLS
software there at all"?

It's like deciding whether a falling tree makes a noise if there's no way
to observe it. ;-)

I would understand a "MUST support SSL/TLS" requirement if it's treated as
a requirement on software packages marketed as ALTO servers. That is, if I
write a system and claim that it conforms to the ALTO RFC, then my
software package must support TLS. However, when deploying my ALTO server,
the purchaser may choose to turn the TLS option off.

That, at least, is decidable. But I thought RFCs were about the external
behavior of deployed systems, not about requirements on software
implementations of those specifications.

	- Wendy Roome

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 31 Mar 2013 16:08:06 +0100

Wendy, Colleagues,

On 5 Mar 2013, at 15:39, Wendy Roome wrote:

> Richard,
> 
> Your proposal sounds fine. After all, it's a "motherhood" statement. Who could argue with, "If you need security, etc, use ssl/tls."?
> 
> However, I am surprised by the suddenly perceived need for security, and I'd object to anything that implies that the default is to use ssl/tls. I think that will kill the protocol. I'd always thought that ALTO was primarily intended to be a public service that network operators provide to all applications, not an exclusive service available only to a few trusted components. A network operator would provide a public ALTO service because it benefits the operator as well as the client. Sure, some operators might restrict access, but most wouldn't bother.

I guess that's how ALTO started but for the use cases I'm considering it is the case that the services would be private (in the sense that the owner will not open them up to anyone to use) and authentication/encryption would likely be required by the ALTO server operator.

Having said that, it doesn't matter to me a great deal what the ALTO protocol specification says about TLS while all it says is something along the lines of "MUST implement TLS". If it started talking about requiring servers to validate client certificates that'd be a different matter (Basic Auth over HTTPS/TLS is sufficient IMO).

Ben