Subject: [apps-discuss] Forwarded draft: registration policy

From: Mark Nottingham <[email-masked]>
Date: Sat, 13 Oct 2012 07:59:47 +1100

Draft -09 changed the registration policy for forwarded parameters:

> The "Forwarded" header field contains parameters for which IANA is to
>    create and maintain a new registry entitled "HTTP Forwarded
>    parameters".  Initial registrations are given below; for future
>    assignments, the registration procedure to be used is IETF review [RFC5226].

<http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-http-forwarded-09>

I *think* this change was based upon Stephen's comment:

> Section 9 says only that the expert should ensure that the
> specification "address the security and privacy implications of the
> requested parameter." So if I defined a parameter that passed on the
> precise location of the end-user or the most recent healthcare
> related URL they've accessed then would that be ok? I think
> additional instructions are needed as to the acceptable purposes to
> which such parameters can be put or else perhaps IETF review would
> in fact be better. Given the field of applicability I would not be
> surprised if very privacy-invasive parameters were defined in
> future.

<https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/>

For the record, I question whether IETF Review is necessary for this registry, because it sets it up as a gatekeeper, rather than a registry of deployed parameters. 

I strongly suspect vendors will give in to the temptation to deploy unregistered parameters here, meaning we'll be publishing yet another registry that's both disconnected from reality and failing to serve the purported purpose (protecting security and privacy).

Regards,

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

---

From: Barry Leiba <[email-masked]>
Date: Sat, 13 Oct 2012 10:37:51 -0400

> I *think* this change was based upon Stephen's comment:

I believe you're correct.  Andreas can confirm that.  (And I'm explicitly
adding Stephen to the CC list here, to be sure he sees and comments.)

> <
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
> >
>
> For the record, I question whether IETF Review is necessary for this
> registry, because it sets it up as a gatekeeper, rather than a registry of
> deployed parameters.

For the record, I agree with you.  But there's more history.  Untiil -05,
the policy was RFC Required.  I convinced the authors to change it to
Specification Required in -06, and later to add instructions to the
designated expert for leniency, erring toward registration rather than
gatekeeping.  And that is the version that got final working group approval
and went through IETF last call.

I'm actually quite disappointed that it's changed back (and is actually
even stricter than the original, and I agree with you in this:

> I strongly suspect vendors will give in to the temptation to deploy
> unregistered parameters here, meaning we'll be publishing yet another
> registry that's both disconnected from reality and failing to serve the
> purported purpose (protecting security and privacy).
>

I think we overdid this in an effort to make Stephen happier with the
document (and we did make him happier, if not "happy").  I suggest that
both the Apps community and the IESG have more discussion on this and sort
it out for AUTH48.  I suggest that we go back to the IANA Considerations
from the -08 draft.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Oct 2012 22:21:58 +0100

Hiya,

> adding Stephen to the CC list here, to be sure he sees and comments.)

As far as I know mine was the only comment on that part but
I don't recall discussing it specifically. though I've not
checked.

>> registry, because it sets it up as a gatekeeper, rather than a registry of

I believe this entire spec has bent way too much in the
direction of just documenting existing bad practice and
that the IETF haven't done a good job on quality control
this time. This is not a "purist" position but e.g. I
reckon that moving from XFF to this would be as hard as
moving from XFF to a more privacy friendly design, for
the stated goals. But there was no apparent willingness
to explore that route, or perhaps not all goals were
fully stated.

So I don't agree that making this privacy damaging spec
extensible at lowest cost is actually a good plan. I do
see that IETF review might be a pain, but I suspect there
would also be pain in actually writing down and agreeing
some sensible guidance for an expert, and I'm not sure
that doing that kind of change at AUTH-48 would be
reasonable. I personally don't think FCFS would be good
here either.

>> purported purpose (protecting security and privacy).

I do not believe anything related to this specification is aimed
at protecting security or privacy. Rather the opposite in the
case of privacy.

> document (and we did make him happier, if not "happy").  

Even "happier" is too much. A little less unhappy perhaps.

> I suggest that

Personally, I don't agree that specification required is
enough, unless there's some real guidance for an expert.

S

PS: I've not checked, but I think my comment that this also says
nothing about DNT wasn't addressed, but that's what I get for
abstaining I guess;-)

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 14 Oct 2012 08:51:25 +1100

> to explore that route, or perhaps not all goals were

Didn't that horse already bolt when the cookie spec was approved? Revealing the IP that would have been very apparent to the server had an intermediary been imposed pales in comparison to the issues there, surely?

I'd also point out that making this IETF Review raises the bar for a parameter in a header field higher than the bar for minting an entirely new header field (Specification Required, as per RFC3864). So I'm not sure what's really being accomplished.

> reasonable. I personally don't think FCFS would be good

Given that the document has normative references to HTTPbis p1 and p4, which realistically aren't going to be RFCs for a few months (i.e., just about to WGLC p1), I wonder if it makes sense to pull the doc back and have another go.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Oct 2012 22:57:52 +0100

> Didn't that horse already bolt when the cookie spec was approved? Revealing the IP that would have been very apparent to the server had an intermediary been imposed pales in comparison to the issue…

Partly. OTOH, there is at least UA control over cookies.

> I'd also point out that making this IETF Review raises the bar for a parameter in a header field higher than the bar for minting an entirely new header field (Specification Required, as per RFC3864…

That's a fair point.

S.

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 15 Oct 2012 12:06:00 +0200

On Sat, 13 Oct 2012 10:37:51 -0400

> adding Stephen to the CC list here, to be sure he sees and comments.)

After this draft was first discussed in the IESG, there was some
uncertainty whether this would go through at all.
Barry sent this e-mail to the apps-discuss list:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06907.html

It lead to some quite extensive discussion. To get to some result Barry
then sent this e-mail:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07056.html

The only concrete response (as far as I can remember) to this came from
Alissa.

One of her points was that she agrees with Stephen that "IETF review
seems more appropriate here".

My response to that was:

AP> I think this too much overhead. It will not stop people from doing
AP> stupid things, it will only stop implementors from specifying
AP> stuff, and the only effect will be less interoperability.
AP>
AP> As I understand it IETF review essentially requires a standards
AP> track RFC. [ note: I know now this assumption was wrong ]
AP>
AP> Can we make it "experts review" with one technical expert and one from
AP> say IESG security area that is explicitly instructed to look after the
AP> privacy issues?
AP> And require both persons to approve the specification.

Alissa asks Barry for an opinion, and the following response from Barry
was what made me change the procedure:

B> I think IETF Review is probably best here, because of the
B> controversy.
B> I actually like Andreas's two-level review idea, but IANA won't like
B> it.  And it's probably best not to have external SDOs and Independent
B> Stream docs doing registrations for this.  Let's go back to IETF
B> Review.

My personal opinion is that "specification required" would be enough,
especially considered Mark's point about it then would require more to
register a parameter for "Forwarded" than an entirely new header field.
However... at some point we have to settle for something.

Best regards,
 Andreas