- From: Francois Daoust <fd@w3.org>
- Date: Tue, 16 Dec 2008 17:41:45 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2008/12/16-bpwg-minutes.html
... and copied as text below.
There will be no call next 2 weeks. Next call will be on Tuesday 6
January 2008.
- On links rewriting, ISSUE-285 was created, and will be brought to the
attention of the main body of the working group on Thursday. Rob was
actioned to start compiling a set of guidelines that address security in
that case.
- On the definition of X-Device-* headers, there is strong support
within the task force to keep the "X-" on the grounds that it is an
existing header, so properly defining yet another header field would
just add to the mess. I will propose a resolution that goes in that
direction at the beginning of next call.
Francois.
-----
16 Dec 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0032.html
See also: [3]IRC log
[3] http://www.w3.org/2008/12/16-bpwg-irc
Attendees
Present
tomhume, SeanP, Francois, rob, jo, EdC
Regrets
Chair
francois
Scribe
SeanP
Contents
* [4]Topics
1. [5]HTTP/HTTPS Links Rewriting
2. [6]LC-2040 - On properly defining the X-Device-* headers
* [7]Summary of Action Items
_________________________________________________________
HTTP/HTTPS Links Rewriting
<francois> [8]comment from Thomas
[8]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008OctDec/0007.html
Francois: There was a discussion by Thomas Roessler. He makes the
point that rewriting HTTPS links changes the origin from the
standpoint of the origin server.
... The new origin becomes the host name of the CT proxy.
... There could be a security problem with cross site scripting with
the change of origin.
... An attack could steal user information.
... This is a new use case brought by Thomas.
Rob: It's a valid concern every time you change the URL to point to
a different server, whether you use HTTP or HTTPS.
... We don't allow any scripts to get to the handset at all.
Francois: That's what I thought since there is hardly any support
for scripts on old devices.
<Zakim> jo, you wanted to ask how we reconcile and approach of
preventing scripts at all with the need to send script to meet the
requirements of mobile Web apps
Rob: No script at all is sent to the handset. That should prevent
scripts running in one window from access data from another window.
Francois: So what should we do with the guidelines?
Jo: I suppose the same thing applies to cookies.
Jo: The working group would like to promote the use of scripts. How
do we reconcile these?
Rob: The same thing is true for cookies. If the content is mobile
friendly, then we don't change things. If it is adapted, then no
script is sent to the client.
EdC: Aren't we devoting a lot of time to what we shouldn't do: link
rewriting?
Jo: we are wondering whether it is technically possible to rewrite
links safely
Sean: Our CT proxy does not send JavaScript to the client if the
content is transformed.
EdC: Not sure that we should be going to this level of detail in the
guidelines.
... Shouldn't we instead have a session on security considerations
and mention things like HTTPS link rewriting, cookies, referer, etc.
<Zakim> jo, you wanted to say we should not include details of the
internal operation of the proxy but we can refer to externally
measurable properties
Francois: We need to understand how it will work and how to put it
in the guidelines.
Jo: We probably need at this point about what we want to do going
forward on this point.
... We have at least 2 choices: 1) Link rewriting is not condoned
because it has unintended consequences. 2) We could say that link
rewriting should be avoided in certain circumstances.
... I think I could do 1 but not 2. Sean and/or Rob and/or EdC would
need to write something else.
Jo: I think we wouldn't have a useful document if we did 1, so if we
are to continue with the document then someone needs to do 2.
EdC: We could say there are a certain number of transformations that
have security implications. I wouldn't put all the details of link
rewriting in the body of the document.
<Zakim> jo, you wanted to respond that the issue goes broader than
just the server and the user concerned in any one request
EdC: In general URL rewriting will happen, so it is hard to stop
some transformations and not others.
Jo: The issue is that some servers may allow it and some may not
allow it. We have ruled out the signaling that Eduardo has
mentioned. We won't be able to put that in *this* document. It will
need to be in another document.
Francois: I wonder what real difference is between the two choices.
Jo: If we put in anything like this it needs to be normative.
... and needs to have conformance implications.
<Zakim> rob, you wanted to support Jo's (2) i.e. to include
Eduardo's "Security Considerations" chapter in a normative way
Rob: We've already mentioned that URLs do get rewritten. So I think
we should say the conditions that this should be done.
Sean: I agree with Rob. I could help him out with the text.
Francois: I agree with the direction and would like to see some
text.
Jo: I think we need to bring this up in the BPWG. I think the entire
group needs to give its opinion on.
... The BPWG needs to give its opinion on whether we can actually
make a BP on link rewriting.
... I think we need to be perfectly clear that we are issuing
something close to a best practice.
<Zakim> tomhume, you wanted to wonder if there are issues beyond
scripting and cookies that need to be considered here. origin of
http requests changing?
Jo: We need to say something that is very clear. If we can't be
clear enough on those issues, we need to be willing to abandon the
CT guidelines.
<Zakim> rob, you wanted to say there must be value in expressing
best practices in a sensitive area (egsecurity)
<EdC> not so fast...Sean seems to have lost track...
Francois: I would suggest that we action Rob to come up with
something that we be valuable on rewriting links.
<tomhume> I wondered whether it'd be worth - now or shortly after
the call - enumerating the problem areas we can see wrt security -
partic. given that the list seems to grow steadily
<jo> [jo notes that dealing with this issue is key - we need a
complete and definitive description - the CT doc stands or falls by
this question]
Francois: Second we should go to the BPWG to get the approval on
whether we should issue a best practice on this.
Sean: Not sure I understand why the doc stands or falls on this.
Jo: Link rewriting is central to CT. If there is any question about
security, then we can't make a best practice on link rewriting.
Sean: It is not necessary to do link rewriting if the CT proxy is in
"proxy mode".
<francois> ACTION: robert to start putting together a set of
guidelines that could help address the security issues triggered by
links rewriting. [recorded in
[9]http://www.w3.org/2008/12/16-bpwg-minutes.html#action01]
<trackbot> Created ACTION-893 - Start putting together a set of
guidelines that could help address the security issues triggered by
links rewriting. [on Robert Finean - due 2008-12-23].
<EdC> There may be (1) circumstances where security can conclusively
never be enforced, ever (2) circumstances where security can be
conclusively enforced if very specific conditions are fulfilled (3)
the whole rest of unclear situations.
Francois: What about when a page is broken into segments?
Sean: There are toolbars that have links that point to the CT proxy
for moving between the segments.
<francois> ISSUE: does BPWG feel it can write Best Practices on
links rewriting in the CT guidelines? Or that it cannot be a best
practice?
<trackbot> Created ISSUE-285 - Does BPWG feel it can write Best
Practices on links rewriting in the CT guidelines? Or that it cannot
be a best practice? ; please complete additional details at
[10]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285/edit .
[10] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285/edit
<francois> ACTION-860?
<trackbot> ACTION-860 -- Jo Rabin to add clarification to HTTPS
rewriting to make it clear that the via header MUST be added -- due
2008-10-13 -- CLOSED
<trackbot>
[11]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860
[11] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860
Francois: There are a couple old issues that can be closed.
<francois> close ACTION-860
<trackbot> ACTION-860 Add clarification to HTTPS rewriting to make
it clear that the via header MUST be added closed
<francois> ACTION-864?
<trackbot> ACTION-864 -- Jo Rabin to redraft HTTPS section for
discussion on list -- due 2008-10-20 -- CLOSED
<trackbot>
[12]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864
[12] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864
<francois> close ACTION-864
<trackbot> ACTION-864 Redraft HTTPS section for discussion on list
closed
<francois> ACTION-859
<francois> ACTION-859?
<trackbot> ACTION-859 -- François Daoust to contact IETF TLS group
and advise them of what we are thinking and ask for guidance on what
to recommend to Content Provider about detecting the presence of a
man-in-the-middle proxy -- due 2008-10-14 -- CLOSED
<trackbot>
[13]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859
[13] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859
LC-2040 - On properly defining the X-Device-* headers
Francois: The problem is that "X-" is supposed to be experimental
and we are saying that these headers should be used.
... The proper way of doing it is to register the header fields in
the IETF. It's not that hard. The problem is that in practice, there
is already a mess around these headers.
... We probably will have a hard time getting all the way to rec
with "X-" in the guidelines.
Francois: If we do it properly we might want to create a proper
header field.
EdC: There are standards out there that define "X-" header fields.
One example is the UA-Prof standard.
... There are already implementations out there that use the
"X-Device" header fields, so implementation will need to deal with
both types of headers if we changed it.
Francois: Did UAProf register the "X-" header fields with the IETF?
<jo> how about inbound-*
EdC: No.
Francois: We could possibly get away with what we have since it is
existing practice.
... There are 2 registries--a temporary one and a permanent one.
<Zakim> tomhume, you wanted to clarify what we're recommending as
best practice today
Francois: Addressing the temporary one is defining it in the
guidelines and putting it in an email.
Tom: What are we talking about recommending?
<Zakim> jo, you wanted to answer tom
Francois: Add the new header and then say that you need to handle
both.
Sean: Don't really understand why we need to change this given what
Eduardo said.
<Zakim> rob, you wanted to support Eduardo's pragmatic point that
X-Device- is already in use and so probably always has to be
supported (like x-wap-profile is still in use today)
<Zakim> tomhume, you wanted to find it a bit weird to recommend
doing something which will deliver little value today
Jo: The HTTP RFC says you can use any header you want and
implementions should ignore what they don't understand.
Rob: Agree with Sean and Eduardo.
Tom: Aren't we trying to be somewhat pragmatic and make things work
with what's out there?
Francois: We may at some point get a red flag if we keep things like
they are now. Not sure.
... We will cancel the next two calls. Next call will be Jan. 6.
... Will bring up the links rewriting issue with the BPWG on
Thursday.
... Not sure if there will be a resolution.
Summary of Action Items
[NEW] ACTION: robert to start putting together a set of guidelines
that could help address the security issues triggered by links
rewriting. [recorded in
[14]http://www.w3.org/2008/12/16-bpwg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [15]scribe.perl version 1.133
([16]CVS log)
$Date: 2008/12/16 16:32:40 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 December 2008 16:42:20 UTC