Re: [W3C Web Security IG] securing the web fonding by the W3C TAG

Hiya,

On 12/01/15 12:04, GALINDO Virginie wrote:
> FYI, updated draft of the TAG finding about 'securing the web' is
> available here : https://w3ctag.github.io/web-https/ 

I'm not sure of the right process/forum for comment so I'll just
use this and hope it gets somewhere useful:-)

I think this is a fine statement, as far as it goes. But I'd
personally (*) love it more if it went a bit further.

The "bit further" I would like is to regard confidentiality as
being an essential tool (though not the only one) that needs to
be available all the time, in order to meet the challenge of
RFC 7258. For the web, I think that means that more than "more
https" is needed. Given the gigantic deployment of http URIs,
and the difficulty many would have in changing scheme for their
content, the implication is that enormous amounts of http
schemed traffic will continue to flow (as cleartext) for many
years even with fine efforts like letsencrypt.org etc.

There is also the issue that "more https" alone may not usefully
mitigate the PM threat unless mixed-content is also largely
eliminated from the web. That issue is implicitly recognised in
the statement (though I'm not sure where "[[mixed-content]]" is
pointing) but I think the logical consequence here is simply that
confidentiality is more than desirable, and that in fact is
really required to be available (even if not always used) for
all web traffic, including http schemed traffic.

>From that I conclude that opportunistic security [1] mechanisms
and, for the web, something specifically like [2] will be needed
and their standardisation ought be encouraged. And I think
explicitly including a recognition of that in this TAG statement
would be logical and could be valuable. (And btw, I'd have no
problem if any reference to [2] has plenty of caveats as it's
controversial and a work-in-progress, but [1] is done so now
quite usable.)

Note that I'm not (here:-) going as far as saying that something
like [2] should be used everywhere all the time, but just that
standardising something like that ought be recognised as being
necessary as a part of the overall mitigation for PM and in this
statement. And also just to be clear, I fully agree that server-
authentication for the web is almost always a lot better than
unauthenticated server endpoints as allowed by [2].

I'd also argue that regarding confidentiality as only being
desirable seems to me to conflict with and not build upon the
issued IAB statement already quoted in the draft TAG statement.
But as I'm a member of neither body, I'm sure you can figure
that out via some arm wrestling or something:-)

If the TAG wanted to modify their statement as per the above,
that'd be great. But even if not, I'd be surprised if they
hadn't debated this, and I don't see any indication that this
was considered in the current text. Given the discrepency
between this draft and the IAB statement, I think at the least
such an indication is needed. (But again, far better to really
build on the IAB statement and say confidentiality is more then
merely desirable.)

As a separate thing, I'd also be interested in references that
support the part of the statement that says that "Shared caching
has a limited role on the Web today..." That argument comes up
a lot and if there is good evidence publicly available, I'd love
to know about it and maybe it'd be good to include in the
statement as well.

Lastly, I really like that you clearly say "The end-to-end nature
of TLS encryption must not be compromised on the Web, in order
to preserve trust." That's a fine thing. (As a total quibble,
the unqualified use of the word "trust" is always a bit dodgy,
and I think what's meant is the trust that users have in the
web generally, which might be worth saying.)

Cheers,
S.

(*) While I am currently an IETF security area director, the
"bit further" above is purely my opinion and I make no claim that
it has IETF consensus nor any standing within the IETF. The RFCs
quoted above are IETF consensus documents, but I'm going beyond
what they say in this mail, and my take on [2] might also end
up in the rough within the IETF. Caveat lector basically:-)

[1] https://tools.ietf.org/html/rfc7435
[2] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption


> Regards, 
> Virginie
> 
> ________________________________ This message and any attachments are
> intended solely for the addressees and may contain confidential
> information. Any unauthorized use or disclosure, either whole or
> partial, is prohibited. E-mails are susceptible to alteration. Our
> company shall not be liable for the message if altered, changed or
> falsified. If you are not the intended recipient of this message,
> please delete it and notify the sender. Although all reasonable
> efforts have been made to keep this transmission free from viruses,
> the sender will not be liable for damages caused by a transmitted
> virus.
>

Received on Monday, 12 January 2015 13:45:45 UTC