See also: IRC log
francois: I presented guidelines
to W3C team to raise their attention to CT so they knew about
it
... no solutions to the problems, unfortunately - good because
it seems that we are heading in the right direction
... main concern is about security and breaking of https, much
concern about this
... similar frustration expressed as we have - want to write
something with more subtle control/communication but not
chartered to do this hence POWDER might be a good direction for
the future
... nothing further to report - they had no practical solutions
to add to what we have done
<francois> Tom's initial comments on HTTPS
<francois> Tom's further thoughts
francois: we got a lot of lc comments on this, and Tom summarised some thoughts
tom: broad agreement that it
breaks end to end security, need to make sure that users have
control, but how this is done is tricky
... also need to ensure that content providers are aware of
what is going on, but puts the burden on CPs to look out for
that
francois: so in the end, there is
no real way to forbid link re-writing
... we need to emphasise that we don't recommend it
jo: can we just confirm the views of those on call ref forbidding HTTPS rewriting
andrews: we currently allow our
proxy to re-write links, they generate an interstitial, and the
choice can be kept for future pages
... I agree that it is undesirable, but pragmatically speaking
a lot of services won't work if we don't do it. So the
important thing is to advice the user and give them the
choice
seanp: yes that how the
implementation works and we have done the same for other
customers
... not ideal, but there is more than just banking sites - e.g.
login to email, facebook etc.
... it's up to our customer (operator) to decide whether they
want it or not. Would not want to violate transformation
guidelines but if the customer wants it we'd have to do it
<Zakim> rob, you wanted to second what Andrew's just said
rob: agree with Andrew and Sean - if guidelines were to forbid it then all deployments would not conform to this one point
<Zakim> andrews, you wanted to say that Vodafone UK uses a "black list" of financial institutions that we will not intercept
andrew: we have an "exclude" list
and we do not intercept that traffic
... we don't want to expose ourselves to potential
problems
... the ones we do allow we explain to the customer what we are
doing and give them a choice
tom: do we have any figures for what percentage of customers that make the choice to proceed as opposed to those who don't?
seanp: don't think we keep track of it I could try to find out
rob: we don't track it as we don't know what the choices are
francois: why would that help Tom?
tom: if a lot [bubble bubble]
francois: paraphrasing what I think Tom was trying to say:
<tomhume> +1
francois: if a lot of users refused it then we could forbid it, whereas if a lot followed the link then it seems to be a "desirable" feature
<scribe> ACTION: patterson to find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page [recorded in http://www.w3.org/2008/10/07-bpwg-minutes.html#action01]
<trackbot> Created ACTION-858 - Find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page [on Sean Patterson - due 2008-10-14].
francois: a couple of extra
points
... ref opera mini, [although we know it is out of scope], it
can't be secure as it needs to be decrypted in their server, so
can't be end to end
... secondly, there is a fear that parties are trying to push
client certificates for secure connections and these kind of
certificates are supposed to ensure the end to endedness of the
connection
... and so in order to continue the proxy might ask the client
to supply their certificate which would be even worse
rob: pushing client certificate - it won't work for the Web site to push it
francois: link rewriting can't
work with client certificates
... but if the proxy possesses the client certificate then it
can act on behalf of the end user
... and the fear is that they might do that
... afaik client certificates are not commonly deployed
jo: what are the more general guidelines for servers to assess whether they are talking to who they think they are talking to in any case
francois: maybe I should take an action to write something on this
andrews: the nature of the
security is just that the end user can check the server
certificate, so there is nothing to stop a man-in-the-middle
attack
... user still thinks they are connected to a secure
service
jo: suggest that francois writes to wsc wg to see if they have some preferred text
andrews: ref client certificates - user must have given permission and should not do that for some types of transaction - and for that reason we do not want to interfere with transactions of this kind because of the liability issues
francois: thomas (WSC)
recommended that we talk to the IETF TLS working group
... so I could send them an email
<scribe> ACTION: 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 [recorded in http://www.w3.org/2008/10/07-bpwg-minutes.html#action02]
<trackbot> Created ACTION-859 - 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 [on François Daoust - due 2008-10-14].
rob: there is no way for a Via header to appear unless the HTTPS session has been intercepted
francois: there is a tiny
difference between a proxy being used in proxy mode vs linked
mode
... we need to be clear that although the Proxy is actually the
client when intercepting https it must still insert via
headers
<scribe> ACTION: JO to add clarification to HTTPS rewriting to make it clear that the via header MUST be added [recorded in http://www.w3.org/2008/10/07-bpwg-minutes.html#action03]
<trackbot> Created ACTION-860 - Add clarification to HTTPS rewriting to make it clear that the via header MUST be added [on Jo Rabin - due 2008-10-14].
ACTION-860 [this especially ref HTTPS]
francois: there is no other way
to encrypt data for responses
... so should we put something in scope for future work, we
need something more fine-grained to allow transformation and
secure links. XML encryption and signature could be something
in the future
+1 to something in the future in some possible world :-)
francois: to summarise, I am going to contact IETF and Jo will add some clarification ref the via header
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on this, and editor to make sure that the wording is beefed up to make it clear that this is a horrible bad thing but if you _must_ do it the user MUST know and MUST have a choice
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that this is a horrible bad thing but if you _must_ do it the user MUST know and MUST have a choice
<rob> +1
<tomhume> +1
<francois> +1
seanp: understand the reasoning,
what we have already seems fairly close to sufficient, we seem
to be saying we realise you need to do this, but don't do it,
which looks odd
... we already have warnings etc.
... stronger warning would not hurt
andrews: I think the current wording is right, perhaps we could add a para before the existing wording emphasising the seriousness of doing this - i.e. breaking the trusted link. the current wording is right and precise and would not want to change existing phraseology
francois: I think we are all
going in the same direction - we don't propose to say don't do
it, but if you do ...
... we did get a lot of LCC that we should not ignore, so it is
not being read the way we wrote it so more clarification is
needed
... we might add a few normative statements e.g. about invalid
certificates
<SeanP> +1 to "editorial magic"
francois: maybe Jo can find some wording to make it clearer to the public at the same time as satisfying us as to what we want to say
andrews: yes, all for editorial magic, bring it on!
<andrews> +1
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that if you _must_ do it the user MUST know and MUST have a choice
+1
<francois> +1
<rob> +1
<tomhume> +1
<SeanP> +1 to the resolution + Francois' comments
<andrews> +1
RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that if you _must_ do it the user MUST know and MUST have a choice
<francois> List of comments on HTTPS: LC-2026, LC-2027, LC-2085, LC-2028, LC-2029,
<francois> LC-2030, LC-2015, LC-2031, LC-2016, LC-2032
<francois> LC-2001, LC-2033, LC-2004, LC-2024
<francois> fd's comment on LC-2078
francois: comments about what
claim of conformance is constituted by including this in a via
header
... I think the main use case is to advertise transforming
functionality, conformace is not implied
+1 to rewriting to clarify this
scribe: I realise that you are unlikely to include such a comment if you are wildly unconformant
PROPOSED RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy is "non-transparent" or can be so
PROPOSED RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy may restructure or otherwise modify content
<francois> +1
<rob> +1
<tomhume> +1
<andrews> +1
<SeanP> +1
RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy may restructure or otherwise modify content
francois: thanks and au revoir
[meeting adjourned]
<Bryan> sorry I have been on another cll
<Bryan> I tried to follow but was not able