Subject: [apps-discuss] [Technical Errata Reported] RFC7239 (4137)

From: RFC Errata System <[email-masked]>
Date: Tue, 21 Oct 2014 02:13:05 -0700 (PDT)

The following errata report has been submitted for RFC7239,
"Forwarded HTTP Extension".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7239&eid=4137

--------------------------------------
Type: Technical
Reported by: Craig Taylor <[email-masked]>

Section: Parameters

Original Text
-------------

Corrected Text
--------------

Notes
-----
Firstly let me apologise for not submitting anything above, but I don't want submit possible duplicate effort without testing the water.

One of the issues that we have always had with Forwarded: is highlighted perfectly by Section 8.1, I essentially can't trust it. I am happy to honour (in principle) Forwarded: set by trusted third parties where:

1) I know that they have set it
2) I know that they have clean up anything they don't trust or can't verify.

Without this, I could never honour Forwarded: for Internet third parties, something that has been requested by Opera, Google etc. in the past.

Were signing/validation schemes considered?
Scaling concerns aside, without such things this will likely be relegated to corporate LAN use for many CSPs.

Regards,
CraigT

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7239 (draft-ietf-appsawg-http-forwarded-10)
--------------------------------------
Title               : Forwarded HTTP Extension
Publication Date    : June 2014
Author(s)           : A. Petersson, M. Nilsson
Category            : PROPOSED STANDARD
Source              : Applications Area Working Group
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Oct 2014 08:35:16 -0400

Hi, Craig, and thanks for the questions/comments.  It's too bad that there
isn't a clear place for having these discussions that people who aren't
already "in the know" can find.

The right place to ask and discuss this is the apps-discuss mailing list, <
[email-masked]>: https://www.ietf.org/mailman/listinfo/apps-discuss

Craig, please take these questions there.

RFC Editor, please remove this report from the errata system.

Thanks,
Barry

On Tuesday, October 21, 2014, RFC Errata System <[email-masked]>
wrote:

> Reported by: Craig Taylor <[email-masked] <javascript:;>>
>
> Section: Parameters
>
> Original Text
> -------------
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> Firstly let me apologise for not submitting anything above, but I don't
> want submit possible duplicate effort without testing the water.
>
> One of the issues that we have always had with Forwarded: is highlighted
> perfectly by Section 8.1, I essentially can't trust it. I am happy to
> honour (in principle) Forwarded: set by trusted third parties where:
>
> Without this, I could never honour Forwarded: for Internet third parties,
> something that has been requested by Opera, Google etc. in the past.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Oct 2014 11:02:42 -0400

Oh, no apology necessary, and I look forward to the discussion on
apps-discuss.

Barry

On Tuesday, October 21, 2014, Craig Taylor <[email-masked]> wrote:

>  My apologies. I'm slightly embarrassed I didn't think of that myself.
>
>  Dear 'list',
>
>  Please see my initial statement at the tail of the email...
> Many thanks,
> CraigT
>
>
>

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 21 Oct 2014 17:11:35 +0200

On Tue, 21 Oct 2014 11:13:05 +0200, RFC Errata System  
<[email-masked]> wrote:

> Without this, I could never honour Forwarded: for Internet third  
> parties, something that has been requested by Opera, Google etc. in the  
> past.
>
> Scaling concerns aside, without such things this will likely be  
> relegated to corporate LAN use for many CSPs.

We did see a lot of issues with XFF, since it was poorly defined and had a  
lot of edge cases that caused problems. As we published our first draft we  
got a lot of feedback from reverse proxy users, where we identified some  
more problem areas. We ended up with roughly this list of objectives

- properly describe the existing behavior
- extend syntax to support IPv6, ports and secret tokens
- describe the security implications
- address the synchronization issue of having multiple headers

We did not set out to make something semantically different than the  
pre-existing headers. I imagine that you can create some sort of encrypted  
or signed extension on top of our specification. I don't know how it would  
look like though to be generic enough and at the same time compact. It's  
also a question of what security margin you think you need.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/

---

From: Megan Ferguson <[email-masked]>
Date: Tue, 21 Oct 2014 10:05:49 -0400

Barry,

This record has been deleted as requested.

Thank you.

RFC Editor/mf

On Oct 21, 2014, at 8:35 AM, Barry Leiba wrote:

> Hi, Craig, and thanks for the questions/comments.  It's too bad that there isn't a clear place for having these discussions that people who aren't already "in the know" can find.
> 
> The right place to ask and discuss this is the apps-discuss mailing list, <[email-masked]>: https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> On Tuesday, October 21, 2014, RFC Errata System <[email-masked]> wrote:

---

From: Craig Taylor <[email-masked]>
Date: Tue, 21 Oct 2014 14:48:05 +0000

Dear 'list',

Regards,
CraigT

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Oct 2014 11:57:28 +1100

On 22 Oct 2014, at 2:11 am, Martin Nilsson <[email-masked]> wrote:
> 
> On Tue, 21 Oct 2014 11:13:05 +0200, RFC Errata System <[email-masked]> wrote:
> 
>> 
> We did see a lot of issues with XFF, since it was poorly defined and had a lot of edge cases that caused problems. As we published our first draft we got a lot of feedback from reverse proxy users, where we identified some more problem areas. We ended up with roughly this list of objectives
> 
> We did not set out to make something semantically different than the pre-existing headers. I imagine that you can create some sort of encrypted or signed extension on top of our specification. I don't know how it would look like though to be generic enough and at the same time compact. It's also a question of what security margin you think you need.

I always thought that a sig mechanism was necessary for Forwarded (a few of my employers have done that as a one-off); however, we probably weren't ready to do it back then.

Anyone want to pick up the ball? :)

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Nilsson" <[email-masked]>
Date: Wed, 22 Oct 2014 03:54:18 +0200

On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham <[email-masked]> wrote:

>
> I always thought that a sig mechanism was necessary for Forwarded (a few  
> of my employers have done that as a one-off); however, we probably  
> weren't ready to do it back then.
>

What is the actual use case though?

If you don't trust the IP number as an identifier of a third party, you  
should use TLS. I can see that you would want to substitute identification  
of third parties through IP with signatures as an abstraction for  
practical reasons.

I assume that providing integrity isn't the point (again, if you think  
someone is tampering with the content without affecting the IP endpoints,  
you need TLS). There is also the case where headers are set by a trusted  
third party that then passes an untrusted (non-transparent) party, but I  
can't think of when that would that happen?

/Martin Nilsson

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Oct 2014 14:32:19 +1100

> On 22 Oct 2014, at 12:54 pm, Martin Nilsson <[email-masked]> wrote:
> 
> If you don't trust the IP number as an identifier of a third party, you should use TLS. I can see that you would want to substitute identification of third parties through IP with signatures as an abstraction for practical reasons.
> 
> I assume that providing integrity isn't the point (again, if you think someone is tampering with the content without affecting the IP endpoints, you need TLS). There is also the case where headers are set by a trusted third party that then passes an untrusted (non-transparent) party, but I can't think of when that would that happen?

It's useful to have integrity / authentication for this info within your own infrastructure. True, you could do this with client certs on the TLS hop, but lots of software doesn't support that (and AIUI won't easily; think proxies, etc). It's also useful to have a spec so that middleware authors have something to shoot for; think load balancers, CDNs, etc. Persisting the information is also a good thing, but there's not yet any stadard way to do that in a HTTP message for TLS certs.

The other way you could go about this is having a generic mechanism for signing headers full stop -- many have discussed that (and still are). However, in this use case, you need to sign just one header value (amongst potentially many) that represents a hop; most of the mechanisms I've seen don't have that kind of granularity.

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 11:14:15 +0100

On 22/10/14 04:32, Mark Nottingham wrote:
>>> I always thought that a sig mechanism was necessary for Forwarded
>>> (a few of my employers have done that as a one-off); however, we
>>> probably weren't ready to do it back then.
>>> 
>> If you don't trust the IP number as an identifier of a third party,
>> you should use TLS. I can see that you would want to substitute
>> identification of third parties through IP with signatures as an
>> abstraction for practical reasons.
>> 
>> I assume that providing integrity isn't the point (again, if you
>> think someone is tampering with the content without affecting the
>> IP endpoints, you need TLS). There is also the case where headers
>> are set by a trusted third party that then passes an untrusted
>> (non-transparent) party, but I can't think of when that would that
>> happen?
> 
> It's useful to have integrity / authentication for this info within
> your own infrastructure. True, you could do this with client certs on
> the TLS hop, but lots of software doesn't support that (and AIUI
> won't easily; think proxies, etc). It's also useful to have a spec so
> that middleware authors have something to shoot for; think load
> balancers, CDNs, etc. Persisting the information is also a good
> thing, but there's not yet any stadard way to do that in a HTTP
> message for TLS certs.
> 
> The other way you could go about this is having a generic mechanism
> for signing headers full stop -- many have discussed that (and still
> are). However, in this use case, you need to sign just one header
> value (amongst potentially many) that represents a hop; most of the
> mechanisms I've seen don't have that kind of granularity.

If someone does do more work on this, please consider privacy
this time around. There's no reason that this has to be done
as badly as XFF.

S.

> 
> Cheers,
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________ apps-discuss mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Oct 2014 06:15:03 -0400

Could folks who want to discuss this topic further _please_
change the subject line so that those of us to try to prioritize
RFC Errata reports won't be disrupted by a topic that is not one
of those?

thanks
   john

---

From: "c^" <[email-masked]>
Date: Wed, 22 Oct 2014 11:28:08 +0100

A few use cases:

1) CDNs, as Mark says. CDNs are typically used on a per hostname basis.
Within one host we will distribute truly static assets (majority) and pass
though assets that are dynamic (minority 1) or vary by other logic e.g. Geo
Location (minority 2). This minority use cases do not preclude using CDNs,
nor there benefits for Geographical reach on the global scale, but they do
present a problem of no standardised way to return 'trusted' geo location
data. Moving to SSL is orthogonal to this, as the termination point would
either be the CDN (still no standard trusted method) or if changing the
hostname to something locally terminated would lose the benefit of
employing the CDN services for global optimisation.

2) Third party proxies
In the first use case, we can expect the CSP to have a very close working
relationship, customer/supplier. This makes something 'bespoke' a little
easier. However in this relationship, third party organisations with no
commercial relationship with the CSP, but a relationship with the client
wish to broker this data on the clients behalf without diminishing the
client experience. Examples of this are Googles Mobile Android proxy and
Opera Mobile proxies. In this scenario, the CSP requires to protect the
user experience and also any potential rights concerns using Geo data. The
client and the third party proxy wish to, cache, transform, switch
protocols etc etc. in a separate relationship for the benefit of the
client. As it stands, SSL is typically used to bypass these, but it would
be feasible that a non-commercial relationship could be brokered to protect
the integrity of the client IP data where the risk was considered
acceptable.

3) Multi-tiered distribution platforms
Many commercial load balancers, random Apache modules, nginx etc. all mark
up this data today. All default to XFF, custom headers or are configurable,
none validate the headers added by default. A standard approach to this
would just aid interoperability and stop everyone solving the same problems
over and over.

_sorry drowning in BAU at the moment_

CraigT

On 22 October 2014 04:32, Mark Nottingham <[email-masked]> wrote:

> >> I always thought that a sig mechanism was necessary for Forwarded (a
> few of my employers have done that as a one-off); however, we probably
> of third parties through IP with signatures as an abstraction for practical
> reasons.
> >
> It's useful to have integrity / authentication for this info within your
> own infrastructure. True, you could do this with client certs on the TLS
> hop, but lots of software doesn't support that (and AIUI won't easily;
> think proxies, etc). It's also useful to have a spec so that middleware
> authors have something to shoot for; think load balancers, CDNs, etc.
> Persisting the information is also a good thing, but there's not yet any
> stadard way to do that in a HTTP message for TLS certs.
>
> The other way you could go about this is having a generic mechanism for
> signing headers full stop -- many have discussed that (and still are).
> However, in this use case, you need to sign just one header value (amongst
> potentially many) that represents a hop; most of the mechanisms I've seen
> don't have that kind of granularity.
>
> Cheers,
>
> --
> _______________________________________________
> apps-discuss mailing list
> [email-masked]