W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > October 2008

[minutes] CT Call Tuesday 7 October 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 07 Oct 2008 17:29:34 +0200
Message-ID: <48EB805E.2010106@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

Hi,

Minutes of today's call are available at:
  http://www.w3.org/2008/10/07-bpwg-minutes.html
... and copied as text below


We had an extensive and useful discussion on HTTPS links re-writing, 
ending up in a few actions and the following 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

... and a short discussion on the comment on the Via header (LC-2078):
- 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]W3C

       [1] http://www.w3.org/

         Mobile Web Best Practices Working Group Teleconference

07 Oct 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0011.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/07-bpwg-irc

Attendees

    Present
           tomhume, jo, Francois, rob, SeanP, andrews, Bryan[IRC_Only]

    Regrets
    Chair
           francois

    Scribe
           jo

Contents

      * [4]Topics
          1. [5]Report from W3C Project Review
          2. [6]HTTPS Link Rewriting
          3. [7]LC-2078: claim of conformance in a Via HTTP header
      * [8]Summary of Action Items
      _________________________________________________________

Report from W3C Project Review

    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

HTTPS Link Rewriting

    <francois> [9]Tom's initial comments on HTTPS

       [9] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0013.html

    <francois> [10]Tom's further thoughts

      [10] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0012.html

    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
    [11]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
    [12]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
    [13]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

LC-2078: claim of conformance in a Via HTTP header

    <francois> [14]fd's comment on LC-2078

      [14] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0009.html

    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

Summary of Action Items

    [NEW] 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
    [15]http://www.w3.org/2008/10/07-bpwg-minutes.html#action02]
    [NEW] ACTION: JO to add clarification to HTTPS rewriting to make it
    clear that the via header MUST be added [recorded in
    [16]http://www.w3.org/2008/10/07-bpwg-minutes.html#action03]
    [NEW] ACTION: patterson to find out if novarra has figures on
    whether users choose to proceed at the HTTPS interstitial page
    [recorded in
    [17]http://www.w3.org/2008/10/07-bpwg-minutes.html#action01]

    [End of minutes]
Received on Tuesday, 7 October 2008 15:30:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 October 2008 15:30:10 GMT