Re: [saag] feedback for draft-mm-wg-effect-encrypt
"Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com> Tue, 20 October 2015 10:26 UTC
Return-Path: <Kevin.Smith@vodafone.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D31B3253 for <saag@ietfa.amsl.com>; Tue, 20 Oct 2015 03:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Iy94MvmXK1 for <saag@ietfa.amsl.com>; Tue, 20 Oct 2015 03:26:41 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA991B324E for <saag@ietf.org>; Tue, 20 Oct 2015 03:26:40 -0700 (PDT)
Received: from [85.158.138.179] by server-13.bemta-3.messagelabs.com id FA/A4-00536-ED616265; Tue, 20 Oct 2015 10:26:38 +0000
X-Env-Sender: Kevin.Smith@vodafone.com
X-Msg-Ref: server-13.tower-169.messagelabs.com!1445336797!28590088!1
X-Originating-IP: [195.232.244.136]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7362 invoked from network); 20 Oct 2015 10:26:37 -0000
Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-13.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Oct 2015 10:26:37 -0000
Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3ngB2P4S8CznTYd; Tue, 20 Oct 2015 12:26:37 +0200 (CEST)
Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3ngB2P2S33z16L3g; Tue, 20 Oct 2015 12:26:37 +0200 (CEST)
Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3ngB2P2Kxvz16Kb7; Tue, 20 Oct 2015 12:26:37 +0200 (CEST)
Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 20 Oct 2015 12:26:36 +0200
Received: from VOEXM17W.internal.vodafone.com ([169.254.1.63]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0224.002; Tue, 20 Oct 2015 12:26:36 +0200
From: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: [saag] feedback for draft-mm-wg-effect-encrypt
Thread-Index: AdEB3L2IVB4bc+CARb+CJn/cEegD/QIwJwUAACEOPUA=
Date: Tue, 20 Oct 2015 10:26:35 +0000
Message-ID: <A4BAAB326B17CE40B45830B745F70F10AC86E8F0@VOEXM17W.internal.vodafone.com>
References: <A4BAAB326B17CE40B45830B745F70F10A7B24477@VOEXM18W.internal.vodafone.com> <CAHbuEH4jOi5p7MxesYNjqkFOg+OH5v7vSrv1AAErihrQTRfO4w@mail.gmail.com>
In-Reply-To: <CAHbuEH4jOi5p7MxesYNjqkFOg+OH5v7vSrv1AAErihrQTRfO4w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/P7TsL9z33GA41C3-bRN8S_hYVoA>
Cc: "saag@ietf.org" <saag@ietf.org>, "MORTON, ALFRED C (AL)" <acmorton@att.com>
Subject: Re: [saag] feedback for draft-mm-wg-effect-encrypt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2015 10:26:43 -0000
Hi Kathleen and Al, Many thanks! I will update the Network Management I-D accordingly and notify the list. All best, Kevin -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] Sent: 19 October 2015 21:39 To: Smith, Kevin, (R&D) Vodafone Group Cc: saag@ietf.org; MORTON, ALFRED C (AL) Subject: Re: [saag] feedback for draft-mm-wg-effect-encrypt Hi Kevin, Thanks for your contribution to our draft. We added most of your text, but some overlap of existing text had us leave out a subsection. See inline. On Thu, Oct 8, 2015 at 11:37 AM, Smith, Kevin, (R&D) Vodafone Group <Kevin.Smith@vodafone.com> wrote: > Hi Kathleen, > > As discussed at MaRNEW[1] , here are two sections of draft-smith-encrypted-traffic-management-03[2] which can be added to 'Effect of Ubiquitous Encryption' [3] . Once agreed, I can remove the same text from [2] and simply point to the relevant section in [3]; and hence [2] will focus on solutions to persist traffic management for encrypted traffic (whilst maintaining privacy/security). > > Many thanks > Kevin > > [1] https://www.iab.org/activities/workshops/marnew/ > [2] > http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-03 > [3] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ > > ---------------------------------------------------------------------- > ----- Additions for draft-mm-wg-effect-encrypt > ---------------------------------------------------------------------- > ----- > {for section 2.1: new sub-section} Great, thanks for this, a new section was added in 2.1 to cover this helpful information. > > Access and policy enforcement > > Server load balancing > > Where network load balancers have been configured to route according > to application-layer semantics, an encrypted payload is effectively > invisible. This has resulted in practices of intercepting TLS in front > of load balancers to regain that visibility, but at a cost to > security and privacy. > > Network access > > Approved access to a network is a prerequisite to requests for > Internet traffic - hence network access, including any authentication > and authorisation, is not impacted encryption. > > Cellular networks often sell tariffs that allow free-data access to > certain sites, known as 'zero rating'. A session to visit such a > site incurs no additional cost or data usage to the user. This feature > may be impacted if encryption hides the domain from the network. > > Regulation and policy enforcement > > Mobile networks (and usually ISPs) operate under the regulations of their > licencing government authority. These regulations include Lawful Intercept, > adherence to Codes of Practice on content filtering, and application of court order filters. > These functions are impacted by encryption, typically > by allowing a less granular means of implementation. The enforcement > of any Net Neutrality regulations is unlikely to be affected by > content being encrypted. > > SPAM and malware filtering > > This has typically required full access to application data to filter > various keywords, fraudulent headers and virus attachments. > > > {New top level section} This has been added just after the security monitoring section since both may apply across network types that we used as groupings. > > Flow information visible to a network The word application was added in front of the section header as that made sense once IP 5-tuple was removed. We cover that already in section 3.1.1, which also covers 2-tuple. The 2-tuple and 5-tuple are used in multiple network types, so we may want to think about bumping this to another section. > > IP 5-tuple > > This indicates source and destination IP addresses/ports and the > transport protocol. This information is available during TLS, TCP- > layer encryption (except ports), and IP-layer encryption (IPSec); > although it may be obscured in Tunnel mode IPSec. > > This allows network management at a coarse IP-source level, which > makes it of limited value where the origin server supports a blend of > service types. > Thank you for the rest of the text for this section, it's very helpful. > TLS Server Name Indication > > When initiating the TLS handshake, the Client may provide an > extension field (server_name) which indicates the server to which it > is attempting a secure connection. TLS SNI was standardized in 2003 > to enable servers to present the "correct TLS certificate" to clients > in a deployment of multiple virtual servers hosted by the same server > infrastructure and IP-address. Although this is an optional > extension, it is today supported by all modern browsers, web servers > and developer libraries. Notable exceptions are Android 2.2 and > Internet Explorer 6 on Windows XP. It should be noted that HTTP/2 > introduces the Alt-SVC method for upgrading the connection from > HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial > HTTP/1 request is unencrypted, the destination alternate service name > can be identified before the communication is potentially upgraded to > encrypted HTTP/2 transport. HTTP/2 implementations MUST support the > Server Name Indication (SNI) extension. > > This information is only visible if the client is populating the > Server Name Indication extension. This need not be done, but may be > done as per TLS standard. Therefore, even if existing network > filters look out for seeing a Server Name Indication extension, they > may not find one. The per-domain nature of SNI may not reveal the > specific service or media type being accessed, especially where the > domain is of a provider offering a range of email, video, Web pages > etc. For example, certain blog or social network feeds may be deemed > 'adult content', but the Server Name Indication will only indicate > the server domain rather than a URL path to be blocked. > > Application Layer Protocol Negotiation (ALPN) > > ALPN is a TLS extension which may be used to indicate the application > protocol within the TLS session. This is likely to be of more value > to the network where it indicates a protocol dedicated to a > particular traffic type (such as video streaming) rather than a > multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will > not indicate the traffic types which may make up streams within an > HTTP/2 multiplex. > > Content length, bitrate and pacing > > The content length of encrypted traffic is effectively the same as > the cleartext. Although block ciphers utilise padding this makes a > negligible difference. Bitrate and pacing are generally application > specific, and do not change when the content is encrypted. Multiplexed > formats (such as HTTP/2 and QUIC) may however incorporate several application streams > over one connection, which makes the bitrate/pacing no longer application-specific. > > > Best regards, Kathleen & Al > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen
- [saag] feedback for draft-mm-wg-effect-encrypt Smith, Kevin, (R&D) Vodafone Group
- Re: [saag] feedback for draft-mm-wg-effect-encrypt Kathleen Moriarty
- Re: [saag] feedback for draft-mm-wg-effect-encrypt Smith, Kevin, (R&D) Vodafone Group