Subject: [alto] Protocol update -16: Security Consideration Section

From: Jan Seedorf <[email-masked]>
Date: Wed, 19 Jun 2013 12:48:56 +0000

Dear all,

I read the latest version of the draft (-16), and I think it really is in good shape (apart from the open issues we will discuss in the interim meeting later today). I had a closer look at the latest security considerations section, and --- thanks to Sebastian and Hannes --- it is much better structured than before and reads quite well. Below are some minor comments, all of these are small things and could probably be addressed by adding a single sentence each to help make clearer to the reader what the security considerations are:

-- 14.1.3. Limitations to Authenticity and Integrity
The text only talks about the URI of the IRD being compromised, which is (as discussed on this list) more a problem of ALTO service discovery. But what about cases where the URI domain name is correct, but the ALTO server itself has been compromised by malware? In that case, even TLS might not help. Is this an obvious threat or should it be explicitly mentioned?

-- 14.3.2. Protection Strategies for Confidentiality
The previous section "risk scenarios" mentions 3 types of risks, but protection strategies are only suggested for type 1 and type 2

-- 14.4.2 Protection Strategies for Privacy
Apart from using obfuscation techniques as suggested in the text, the ALTO client could also consider to alternate between several ALTO server when querying for ALTO information (in cases where possible, i.e. more than one ALTO server has the info and these ALTO servers are not expected to collude). This would not help against an intercepting third party, but it would help somewhat against tracking at a single ALTO server. Additionally, the classic solution of a mix-net-type solution comes to mind, where an ALTO privacy service would act on behalf of many clients, hiding their identity. Should we add text on these considerations (again, if obvious we should probably not mention it)?

-- 14.5.2 Protection Strategies for Availability
Against a DDoS attack with spoofed source IPs, a simple cookie mechanism (as used in IPSec to prevent complex server computations caused by forged requests) could help. Of course, this would also need to be specified in an extension document.

 	- Jan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Y.
> Richard Yang
> Sent: Wednesday, May 22, 2013 3:28 AM
> To: IETF ALTO
> Subject: [alto] Protocol update
> 
> Hi all,
> 
> We just posted a version to seek feedback. A diff of the changes can be
> found at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-protocol-16
> 
> 
> Here are major changes:
> 
> 1. Network Map Version Tags
>    Changed Sec. 6.3 to mention the consistency discussions
> 
> 2. Mention cross Cost Map
>   Added a short section Sec. 6.4
> 
> 3. Add a short guideline section Sec. 8.3.6 on Refresh
> 
> 4. Changed to single media-type
>   Please see Sec. 8.5
> 
> 5. Other changes suggested per the mailing list.
> 
> Your feedback is greatly appreciated!
> 
> Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 19 Jun 2013 16:13:02 +0200

Jan, all,

On Wed, Jun 19, 2013 at 12:48:56PM +0000, Jan Seedorf wrote:
> Dear all,
> 
> I read the latest version of the draft (-16), and I think it really is
> in good shape (apart from the open issues we will discuss in the
> interim meeting later today). I had a closer look at the latest
> security considerations section, and --- thanks to Sebastian and
> Hannes --- it is much better structured than before and reads quite
> well. Below are some minor comments, all of these are small things and
> could probably be addressed by adding a single sentence each to help
> make clearer to the reader what the security considerations are:
> 
> -- 14.1.3. Limitations to Authenticity and Integrity The text only
> talks about the URI of the IRD being compromised, which is (as
> discussed on this list) more a problem of ALTO service discovery. But
> what about cases where the URI domain name is correct, but the ALTO
> server itself has been compromised by malware? In that case, even TLS
> might not help. Is this an obvious threat or should it be explicitly
> mentioned?

I think we should not open that can of worms.

On an architectural level there is no problem.  If you start thinking
what could happen if entities did not behave as specified, there will be
no end of things that could happen.

After short thinking not a single (protocol specification) RFC comes to
my mind that discusses the possibility of compromized implementations.
Do you know any?

> -- 14.3.2. Protection Strategies for Confidentiality The previous
> section "risk scenarios" mentions 3 types of risks, but protection
> strategies are only suggested for type 1 and type 2

I think the first sentence of 14.3.2 should read:

old:

To address risk type (1), the Provider of an ALTO Server must ...

new

To address risk types (1) and (3), the Provider of an ALTO Server must ...

> -- 14.4.2 Protection Strategies for Privacy Apart from using
> obfuscation techniques as suggested in the text, the ALTO client could
> also consider to alternate between several ALTO server when querying
> for ALTO information (in cases where possible, i.e. more than one ALTO
> server has the info and these ALTO servers are not expected to
> collude). This would not help against an intercepting third party, but
> it would help somewhat against tracking at a single ALTO server.
> Additionally, the classic solution of a mix-net-type solution comes to
> mind, where an ALTO privacy service would act on behalf of many
> clients, hiding their identity. Should we add text on these
> considerations (again, if obvious we should probably not mention it)?

That approach is nice, but IMO it makes many assumptions. For example,
there should be many and really non-collaborating operators of ALTO
servers with identical (or equvalent) content, and the client must be
able to discover them.

Adding this as a vague idea to a standards track document is IMO not
adequate (maybe it could go to the deployment considerations document).
And for a full specification it is probably a bit late now, unless many
people say we really need this ...

> -- 14.5.2 Protection Strategies for Availability Against a DDoS attack
> with spoofed source IPs, a simple cookie mechanism (as used in IPSec
> to prevent complex server computations caused by forged requests)
> could help. Of course, this would also need to be specified in an
> extension document.

We already have an example (hashcash) for more advanced protection
schemes that are outside of the scope fo this core document. Adding
a seocnd example does not add anything.

Furthermore I believe that operators of HTTP based services nowadays
have significant experience in protecting them against DoS attacks (not
necessarily by mechanisms from a network security textbook ;-) ), so
I don't think we should go too far.

Just my $0.02

Thanks
Sebastian