W3C home > Mailing lists > Public > public-web-security@w3.org > November 2014

Re: Fwd: IAB Statement on Internet Confidentiality

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 14 Nov 2014 23:03:48 +0000
Message-ID: <54668A54.5090209@cs.tcd.ie>
To: Wendy Seltzer <wseltzer@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>


On 14/11/14 19:50, Wendy Seltzer wrote:
> The IETF IAB issued this statement today:
> ...
>> Newly designed protocols should prefer encryption to cleartext operation.
> ...
>> We recommend that encryption be deployed throughout the protocol stack
>> since there is not a single place within the stack where all kinds of
>> communication can be protected.
> ...
> 
> Should W3C make a similar effort to support pervasive encryption?
> (I supported this statement as part of the IAB PrivSec program.)

It's of course up to w3c, but I think that'd be great.

S.


> 
> --Wendy
> 
> 
> 
> -------- Forwarded Message --------
> Subject: IAB Statement on Internet Confidentiality
> Date: Fri, 14 Nov 2014 04:26:02 -0500
> From: IAB Chair <iab-chair@iab.org>
> To: IETF Announce <ietf-announce@ietf.org>
> CC: IAB <iab@iab.org>, IETF <ietf@ietf.org>
> 
> Please find this statement issued by the IAB today.
> 
> On behalf of the IAB,
>   Russ Housley
>   IAB Chair
> 
> = = = = = = = = = = = = =
> 
> IAB Statement on Internet Confidentiality
> 
> In 1996, the IAB and IESG recognized that the growth of the Internet
> depended on users having confidence that the network would protect
> their private information.  RFC 1984 documented this need.  Since that
> time, we have seen evidence that the capabilities and activities of
> attackers are greater and more pervasive than previously known.  The IAB
> now believes it is important for protocol designers, developers, and
> operators to make encryption the norm for Internet traffic.  Encryption
> should be authenticated where possible, but even protocols providing
> confidentiality without authentication are useful in the face of
> pervasive surveillance as described in RFC 7258.
> 
> Newly designed protocols should prefer encryption to cleartext operation.
> There may be exceptions to this default, but it is important to recognize
> that protocols do not operate in isolation.  Information leaked by one
> protocol can be made part of a more substantial body of information
> by cross-correlation of traffic observation.  There are protocols which
> may as a result require encryption on the Internet even when it would
> not be a requirement for that protocol operating in isolation.
> 
> We recommend that encryption be deployed throughout the protocol stack
> since there is not a single place within the stack where all kinds of
> communication can be protected.
> 
> The IAB urges protocol designers to design for confidential operation by
> default.  We strongly encourage developers to include encryption in their
> implementations, and to make them encrypted by default.  We similarly
> encourage network and service operators to deploy encryption where it is
> not yet deployed, and we urge firewall policy administrators to permit
> encrypted traffic.
> 
> We believe that each of these changes will help restore the trust users
> must have in the Internet.  We acknowledge that this will take time and
> trouble, though we believe recent successes in content delivery networks,
> messaging, and Internet application deployments demonstrate the
> feasibility of this migration.  We also acknowledge that many network
> operations activities today, from traffic management and intrusion
> detection to spam prevention and policy enforcement, assume access to
> cleartext payload.  For many of these activities there are no solutions
> yet, but the IAB will work with those affected to foster development of
> new approaches for these activities which allow us to move to an Internet
> where traffic is confidential by default.
> 
> 
> 
> 
> 
> 
> 
Received on Friday, 14 November 2014 23:04:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:22 UTC