From nobody Fri Jan 13 01:45:19 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9691270B4 for ; Fri, 13 Jan 2017 01:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com 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 2j1T-bYVNF2n for ; Fri, 13 Jan 2017 01:45:10 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D0212943B for ; Fri, 13 Jan 2017 01:45:09 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r144so62737514wme.1 for ; Fri, 13 Jan 2017 01:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=FsQi3QLCLmUVwKi0TqWC5kdSVkMT8iubcOeBIPHRmLE=; b=iEx3ldHSXeyzz50eKQJF6j3v5tsyTwvSBvF2wOF6rD7N0t0LHJ0VGLoabre59BT0Hy PYfgppAhY3MfaJAeV3S5wLwR4lGF2XZvcUx8CksV6z9IGzcjQn0PBuuQCYycNcmlE4KM sLfc46CUSYdgchDbodmGfUEK8H4OKOXaDV0Dk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FsQi3QLCLmUVwKi0TqWC5kdSVkMT8iubcOeBIPHRmLE=; b=tHBDMIqpozbJLwnC/6m1AlSnmbQ8Jza7UYRPSw5gI2uuHA4c8lDLO037jOQlBYeplI bfQTgYRPXZCv90aoeSNR9l2Og4By5AGRcYp3/sCTQnDnRi+V54xLwKQNVtWFVmtej9q/ cwI91rjuPDjXWRKcvoKd6laubvJADj6aKkBDHG669vo0H0p3SdXquToiAxIJblqAi9NL /vThXk5QgaQ+QzBU2VTPrOmKUGzCymkIKxoOdJE/nlAMdDDOGitLw/cKsWjStHlVckW3 +TcoQszWjcGDfOjTFmwHC91wyosLyW4fxDS+1fv1gZ7vQ2wryGVldN0WTtjb6IZLWOuU b85w== X-Gm-Message-State: AIkVDXLQDkS8uykYIxq2fKfLtsUyzYC2k+E6tCtkmHgyzK1D4Tmu1MA+fswIpxa9FNmUUBP4poVnWGieqQ2Y/Q== X-Received: by 10.223.134.68 with SMTP id 4mr11251240wrw.49.1484300707967; Fri, 13 Jan 2017 01:45:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.248.137 with HTTP; Fri, 13 Jan 2017 01:45:07 -0800 (PST) From: Adrian Hope-Bailie Date: Fri, 13 Jan 2017 11:45:07 +0200 Message-ID: To: saag , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=001a1149243a7050400545f6b06e Archived-At: Subject: [saag] Published draft-thomas-crypto-conditions-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:45:13 -0000 --001a1149243a7050400545f6b06e Content-Type: text/plain; charset=UTF-8 Hi SAAG, Ledger, We have published a significant update to the Crypto-conditions specification in draft 02 taking into account the feedback from IETF in Seoul as well as others. https://tools.ietf.org/html/draft-thomas-crypto-conditions-02 Notable: * Clearer explanations as to what crypto-conditions are and how they can be used. * Switched to DER as the canonical encoding * Changed ASN.1 definitions to use CHOICE for unions * Adopted ni: URI for URI encoding Adrian --001a1149243a7050400545f6b06e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi SAAG, Ledger,
We have published a significant update to the Crypto-conditions= specification in draft 02 taking into account the feedback from IETF in Se= oul as well as others.

https://tools.ietf.org/html/draft-thomas-crypt= o-conditions-02

Notable:
* Clearer explanations a= s to what crypto-conditions are and how they can be used.
* Switch= ed to DER as the canonical encoding
* Changed ASN.1 definitions to= use CHOICE for unions
* Adopted ni: URI for URI encoding

Adrian
--001a1149243a7050400545f6b06e-- From nobody Fri Jan 20 04:38:16 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D706129B64 for ; Fri, 20 Jan 2017 04:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 BiGG4poujrsm for ; Fri, 20 Jan 2017 04:38:12 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6F7129B46 for ; Fri, 20 Jan 2017 04:38:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8748BE49; Fri, 20 Jan 2017 12:38:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ShtjOQWVaD; Fri, 20 Jan 2017 12:38:07 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20E71BE3E; Fri, 20 Jan 2017 12:38:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484915887; bh=sdyEiASq0+Rv3jqLjH7VLEvAb1oJ2Ob+rrzehOmdJR8=; h=To:From:Subject:Cc:Date:From; b=he/76e/7bcpqFoAJNUHiJKGby412TJcmAYGZHH+llNQtkylsWHWa3FfxOxc/jj6Oe FEReQMljMR0mdjjMXlTwE24RgAp7CcOK3bNwPQ3ypc8PVNiTahUjHZcxbMGTIMuhni i744DkP2PKKy2bj7NzlEIBWU1qAjzjTlhEPts/7M= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 20 Jan 2017 12:38:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060207000109070206020803" Archived-At: Subject: [saag] AD sponsoring metadata insertion draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 12:38:14 -0000 This is a cryptographically signed message in MIME format. --------------ms060207000109070206020803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, A while back we discussed how to process [1]. We pondered the option to include that in planned revision of RFC3552 but given that 3552bis seems to be progressing slowly Ted asked me to proceed now with AD sponsoring his draft. (When 3552bis does get done, then the relevant advice could of course be included there too, by reference if that's better.) I've done my AD review of the draft (it's below) and plan to start an IETF LC for that shortly. Any comments are most welcome of course. The only thing I'd like to ask about before IETF LC is that Ted has asked for publication as an informational RFC which is fine. But if folks thought that this really ought be a BCP then hearing that now would be good so we don't have to re-do the IETF LC. My plan is to wait a couple of days and if nobody says they want this to be a BCP, then I'll start IETF LC aiming at an informational RFC. If anyone does have a reasonable argument that this ought be a BCP, then I'll start the IETF LC for that target, and we can discuss the right outcome during the IETF LC itself. (It being fine to "downgrade" something like this from BCP to informational if that's what the LC indicates has rough consensus.) If someone would like to be the document shepherd for this please let me know off-list in the next day or so. Thanks, S. [1] https://tools.ietf.org/html/draft-hardie-privsec-metadata-insertion-0= 4 - Is info or BCP best? I'm fine with info but wondered. Other than this question, any changes for the comments below can be done after IETF LC. - section 4, last para: the "it" in "it provides" is a bit ambiguous, I think you mean RFC7871, right? Maybe consider re-phrasing the sentence. - section 5, 1st para: "Forward-for" seems wrong. Do you mean X-Forwarded-For (the pre-stds deployed thing) or "Forwarded" (the new name in RFC7239)? If you mean both, maybe say "RFC7239" instead of using the name of a http header field, or if using a header field name, please ensure it's correct. (For all I know, there could also be deployment of the name you mention I guess;-) - section 5, 1st para: is the "long tail of browser deployments" still a significant factor? I thought most were automatically updated these days. And I'd have thought that proxies were less often updated in fact. I'm not sure the text correctly captures the reasons for the speed-of-deployment difference. - title of section 8 is odd. --------------ms060207000109070206020803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjAx MjM4MDZaMC8GCSqGSIb3DQEJBDEiBCAZdTXSvXeP1yxdiI6gGwzRycaZbnA5e4avPn45kjDM wzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCZL7yhpYbyxQBIFLoUw5ZtsJRYB51sVDnwFknUejomab4ifxKMbQTq qojMBv5FRDpvVFMGnf/x7rbcRCQmFi89/xjPLdAMHUmaThLqdYA7lSg0qWdEeGKErEjkEAXG lMd8LGCFdzLHRd8YFjvrKkLM+0u6ossBYf8TDaDmSchw+UWHt11ym57Y2EKVyNSV5CPURZ9P n0KEqpdo/wQRmQ7Xef2WrNWwlmS9DTXY0WlrrvEwhNopROkGAwhCc0mi5XxfE7l+t1PPCjGB RfzPQofIYKV3dfaQj4SKlr7p/QbSlfFjDdtYf21LzK1GirDGh/yG3AmNWIUKHFF5CZSVKG5X AAAAAAAA --------------ms060207000109070206020803-- From nobody Fri Jan 20 08:13:56 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D7129C0F for ; Fri, 20 Jan 2017 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 mBqn6i-XdywJ for ; Fri, 20 Jan 2017 08:13:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6996129C06 for ; Fri, 20 Jan 2017 08:13:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41D6FBE2F for ; Fri, 20 Jan 2017 16:13:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMaxXi4vg47A for ; Fri, 20 Jan 2017 16:13:47 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0ED0BE2D for ; Fri, 20 Jan 2017 16:13:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484928827; bh=QaucLJwDkg45vYw8BUK5+5YYLyeOxDoShRGKrPQwb48=; h=To:From:Subject:Date:From; b=tIKDZyQcI6y3ohrorYPO+Uotr/m4nt+/onB92A26Ru2gnjRIWFOkipT/JTk2HsfJk zIfLX2HaOBl2vLp5JSzbZyxj+REx/YZUwGYYTUafXNE/bnbI2vaz6QVvrskHiM+iaI 5fcQo19xt34xzYVlNB4x83hkxCjwuvHM5PYM9KOg= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> Date: Fri, 20 Jan 2017 16:13:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060508090208060504000108" Archived-At: Subject: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 16:13:55 -0000 This is a cryptographically signed message in MIME format. --------------ms060508090208060504000108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Al and Kathleen have asked me to AD sponsor this draft. [1] I think we mentioned this a couple of times at IETF meetings and on this list. I plan to do my AD review of this shortly and then start an IETF last call. If you have comments in the meantime please do send them here. If you're willing to be document shepherd for this one please send me an offlist email in the next day or two. Thanks, S. [1] https://tools.ietf.org/html/draft-mm-wg-effect-encrypt-04 --------------ms060508090208060504000108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjAx NjEzNDZaMC8GCSqGSIb3DQEJBDEiBCDHdfuexjlIM746xo7lUCdz5ChiCo/JsXwM6PnUp6QI cTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCipaRMmPgtV6s9Tp+gk3DBE+ovnYaOJ+ufjT25Th1C2NQJtM2pqZnU 85tg0WlxrDddchlLWOGai24wvFCDeIrZ1VDkw1Mj9zKb1jR4oUZFTgBPtGAsuvJLX/MoqPLC P9NX8/s8kLaXC7/P3OvdCdNqmob5YUbzV2sWzpkOUrtMbEV8OamvIcfqV+vWQkXy5T0rbBOr sNSV3BM4TepXTC7ry/KVrpzktW3lYf/yHTjHkeI7ML68o+HVKNKncQk8an13KgdzgQ2bTLob 6JNG+HLnyc7VtDmGAS16QDdP8YY5i+ykE/612IvjN2lgsXCfNQMQ9URRA0f8Z/kmHLcYnTiF AAAAAAAA --------------ms060508090208060504000108-- From nobody Fri Jan 20 09:03:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8393129629 for ; Fri, 20 Jan 2017 09:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FeI3d1C87wNT for ; Fri, 20 Jan 2017 09:03:36 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9910912968B for ; Fri, 20 Jan 2017 09:03:36 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id w194so62139827ybe.0 for ; Fri, 20 Jan 2017 09:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l9VaX1WrSn9Y4VWpS89hwZ+zMRSpevgSVAvTcfaMT5c=; b=VYht5qmWQ/exh92Ucu6ELG0dgfW6YCk/KQcRKaBxQAOIcGkW8xFNzyPnMP/qFNync2 xxJV/T0vKH6fgTha8QqB5HXKd+6hSMhTYa+XKa0HpumCtmndD/4cQ4+vnx+aH6NobfR3 6nwD/QN2HbmXSZcDNd1VOabMGMjiFTR932fRex64Wa4YcTGXiuawrzN1f/LN4Nki2Ivc HIleCgU33ChkreQx3hvsQgirfZ6Gv9Ryds8f63+NO9qhBIT56at/U6b5kHVZgfYFNNMy eVm7SDD1tYlMMvTMFRRJR/a0lWoWXLo3Atv9+SuGCiwy87W32j+Hy8EhPLKBh2TLWpFa sF3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l9VaX1WrSn9Y4VWpS89hwZ+zMRSpevgSVAvTcfaMT5c=; b=tmDXqDbHp5BCxzh4ns61adkwp27iTq6APILHBWxNNZP0zH/DYSVRPFDuhsi0197mS4 YkGX+zIa/ZrpFv4gF3m7dMPjGtHqA2Q8ArbeapbGDICTg6ZVfsmuGtthocGb4i2S+ZPG kVqOZft3wbxtHzB+972Hteyv2jvizmiRsfGXT8xwstcul1fKzUUvzSPoY4ocaZLyL0Iv C3KL4ShgcGXZbZIjaddxGOkvVVpD1Hcd20EMluPc8QOeS13PfAXvDiTowxZe27iPUnRC yWmzlVdqpY7kbzbs1coF/IdbjiFLeWnYTVANJJufb9gjrcT++4bX93ik4T3GB0OZeb5S rkEQ== X-Gm-Message-State: AIkVDXJI1Yru/YmN0bb6DhHpF5bHeuqa8ZpnuHJd4zvvluxSetw8Pte5hO0Cu9So94sVvl3yp9RLBE7+tqKfaA== X-Received: by 10.237.35.130 with SMTP id j2mr13699591qtc.45.1484931815700; Fri, 20 Jan 2017 09:03:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.226 with HTTP; Fri, 20 Jan 2017 09:03:05 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Fri, 20 Jan 2017 09:03:05 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1139144263fcc9054689a180 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring metadata insertion draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 17:03:39 -0000 --001a1139144263fcc9054689a180 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2017 at 4:38 AM, Stephen Farrell wrote: > > > [1] https://tools.ietf.org/html/draft-hardie-privsec-metadata-insertion-04 > > - Is info or BCP best? I'm fine with info but wondered. > Other than this question, any changes for the comments > below can be done after IETF LC. > > It was originally going to be an IAB document, which meant it could not be a BCP; I'm fine with either now that it is IETF stream. > - section 4, last para: the "it" in "it provides" is a bit > ambiguous, I think you mean RFC7871, right? Maybe consider > re-phrasing the sentence. > > Yes, that's right. I will try to rephrase. > - section 5, 1st para: "Forward-for" seems wrong. Do you mean > X-Forwarded-For (the pre-stds deployed thing) or "Forwarded" > (the new name in RFC7239)? If you mean both, maybe say "RFC7239" > instead of using the name of a http header field, or if using a > header field name, please ensure it's correct. (For all I know, > there could also be deployment of the name you mention I > guess;-) > Okay, will fix to reference RFC7239. > > - section 5, 1st para: is the "long tail of browser deployments" > still a significant factor? I thought most were automatically > updated these days. And I'd have thought that proxies were less > often updated in fact. I'm not sure the text correctly captures > the reasons for the speed-of-deployment difference. > > There's still a long tail of browsers that aren't in the class "get updated every 6 weeks.", but there has been evolution here. > - title of section 8 is odd. > > > Sorry, that's a doc bug; will fix. Ted --001a1139144263fcc9054689a180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 20, 2017 at 4:38 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


[1] https://tools.ietf.org/htm= l/draft-hardie-privsec-metadata-insertion-04

- Is info or BCP best? I'm fine with info but wondered.
Other than this question, any changes for the comments
below can be done after IETF LC.

It was originally going to be an IAB document, which = meant it could not be a BCP; I'm fine with either now that it is IETF s= tream.
=C2=A0
- section 4, last para: the "it" in "it provides" is a = bit
ambiguous, I think you mean RFC7871, right? Maybe consider
re-phrasing the sentence.

Yes, that's right.=C2=A0 I will try to rephrase.<= br>
=C2=A0
- section 5, 1st para: "Forward-for" seems wrong. Do you mean
X-Forwarded-For (the pre-stds deployed thing) or "Forwarded"
(the new name in RFC7239)? If you mean both, maybe say "RFC7239"<= br> instead of using the name of a http header field, or if using a
header field name, please ensure it's correct. (For=C2=A0 all I know, there could also be deployment of the name you mention I
guess;-)

Okay, will fix to reference RF= C7239.
=C2=A0

- section 5, 1st para: is the "long tail of browser deployments"<= br> still a significant factor? I thought most were automatically
updated these days.=C2=A0 And I'd have thought that proxies were less often updated in fact.=C2=A0 I'm not sure the text correctly captures the reasons for the speed-of-deployment difference.

There's still a long tail of browsers that aren&#= 39;t in the class "get updated every 6 weeks.", but there has bee= n evolution here.

=C2=A0
- title of section 8 is odd.


Sorry, that's a doc bug; will fix.

<= div>Ted

--001a1139144263fcc9054689a180-- From nobody Sun Jan 22 12:42:23 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02B120726 for ; Sun, 22 Jan 2017 12:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 SGrBn3swN3vY for ; Sun, 22 Jan 2017 12:42:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A81127ABE for ; Sun, 22 Jan 2017 12:42:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A154BE2E; Sun, 22 Jan 2017 20:42:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WeMdrv9rX66; Sun, 22 Jan 2017 20:42:13 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41F67BDF9; Sun, 22 Jan 2017 20:42:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485117732; bh=2DCYu6qpe1h8vRgm1sZ0K2TCnPaq6HcDyYOeJnjGMM4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RpG5oK8enj7TOLOORUMOb4it9Bqt0xhOQJcn6XUO+jVX+Xe2NocmQwHL4WYOvmDV2 fHHLNZBa+W/IC6OJnM701ObxFddEu9z+ZMur2ronrmLz7zufDgjuleMAjSfAwG9fDX PKcXQKeRY5xaFOTSOsDZjLDgDDzwkEsgy4/Fkb3c= To: "saag@ietf.org" References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> Date: Sun, 22 Jan 2017 20:42:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000000070409060600080205" Archived-At: Cc: Al Morton Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 20:42:22 -0000 This is a cryptographically signed message in MIME format. --------------ms000000070409060600080205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi again, First, thanks to Paul Hoffman for being willing to be the document shepherd for this. And to the authors for what will be a fine RFC when it's done. Second, I've done my AD review of this and there are a set of things that need fixing before we'll be ready for IETF last call. At minimum there are still a few placeholder sections of text (2.3,2.3.1,3.2,2), but I also have many comments that cumulatively raise to the level where we should address a bunch of those before IETF LC, even though many (but not all) of my comments are relatively nitty. I think that almost all of those should be pretty easy to resolve, so we should still be able to get this done before IETF98 I hope. My AD review is below. Cheers, S. general: I wonder if we're dealing with all possible effects or only with those relevant to network management, security ad privacy? For example, more encryption does prevent some advertising insertion, but whether or not that is in scope here is unclear to me. Should it be? - title: I wonder would "Effects of Much More Common Encryption" be a better title? Ubiquitous is never actually going to happen, nor is it required for many of the effects to be seen. (And there is defo. >1 effect to be seen.) Or, you could keep the title, but explain in the text that you really mean "much more common." - abstract: "solve these problems" is a tad one-sided in that it doesn't recognise the valid reasons for more confidentiality. I think it's important that the abstract recognise that we're here documenting one set of consequences of what is a valid set of trade-offs and not describing a set of problems caused for no good reason. I think that it's important to set the right tone early for this one - if we don't then some readers who want better privacy may be more likely to be dismissive, which'd be a shame. - abstract: "will impact" is maybe no longer the correct tense - we've seen some of these impacts already I think, so maybe "are impacting" or just "impact" is better? - abstract: "more drastic" seems unfounded - what do you really want to say there? - intro: I'm not sure "primarily a passive attack" is right. Maybe easiest to just delete that clause as I don't think it's needed here. You could add a reference to RFC7624 for those who'd like more detail. - intro, 2nd para: I'm not sure what you mean referring to "many attackers"? That sentence doesn't seem to make sense as-is. - intro: the UTA document references need to be updated - intro: the 30% figure is probably out of date, please check again (or add a date as done with the others). - intro: "for corporate users" would be better removed - we care as much about non-corporate users after all - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP" - intro: "Although this does provide..." - that sentence isn't right, passive is not the opposite of e2e, I think you want s/passive wiretapping/transport layer attacks/ - intro: You mention OTR, but the cooler kids these days use signal/telegram (though I don't for platform reasons;-). Might be worth checking out what to say about those, or just say "e.g. OTR" instead of making it seem like OTR is the only way to do IM e2e. - intro, 2nd last para: that one is very good - intro, last para: you don't mention enterprise networks here, worth a mention? - section 2, 2nd para: I think you could do with a forward reference or example to the "opterational practices that require cleartext" or maybe better is to s/require/previously depended on/ - 2: "TLS over SMTP" - backwards again - 2: "The EFF reported..." that needs a reference - 2: I'm not at all sure encryption "prevents" load balancing, in fact I'm pretty sure it does not prevent that - 2: "on the decline now that they are exposed through the media" - I think it'd be better to remove that sentence - it doesn't add much and there are more details better described later I'm sure. - 2.1: this sections seems mixed between middleboxes and mobile, probably as a result of iterative editing. Not sure how best to fix. - 2.1, last para: Is that really a middlebox function? I thought most of the examples given were cases of end systems (web servers) impinging on privacy and not middleboxes (and the naughty web servers are not affected by encryption so aren't really in scope) - 2.1.3: I don't think DPI aims to improve "features and efficiency" - 2.1.3: "must be known" is overstated - again I think we want to always phrase it as "has previously been assumed to be required" or similar - 2.1.4: I think compression could (and maybe should) be separated out - one of the things CRIME has shown us is that we had more to learn about how to combine compression and encryption. I also think most compression is not done/undone at middleboxes, nor does it relate to monitoring so compression doesn't seem to fit well in 2.1. (Transcoding however might fit in some middlebox section, but is not compression.) - 2.1.5: s/law agencies/law enforcement agencies/ is the usual term, and LEAs are not the only entities that insist on this kind of thing - considering censorship. - 2.1.5: "sites promoting anorexia" seems like an odd example, but I think in any case it'd be better to generalise the examples a bit - 2.1.5: DNS queries do not "reveal" URLs. And the described mechanism seems quite odd. - 2.1.5: The 3rd last para about "TLS proxies" and "future versions of HTTP and TCP" is not clear to me. Is that really needed? - 2.1.5: Parental controls might deserve it's own subsection - it differs in that the endopints are involved, which I think means that the effects of e.g. TLS on the changes required to the service are different from cases where an external party (govt/SP/whoever) imposes the filtering. - 2.1.6.3: I think you need a reference to RFC2804 here. The IETF does not to LI in standards, for the (good) reasons stated therin. So this may be a case where the effects of crypto do enhance existing IETF policy but also counter existing policies of other entities. But we should not ignore the former (IETF) policy - we ought not claim here that one or the other are better, but just ack the tussle. - 2.1.6.4: MTAs do trypically have cleartext access, so what kind of spam/malware filtering do you mean there? How does that relate to the mail architecture? (There's an RFC for that that ought be ref'd.) If section 5 does cover this well, then I'd say removing this section would be good as it add nothing much that I can see. - 2.2: Do we have evidence that the decrease of measurement accuracy has actually lead to a decrease in repair efficiency? I'm not convinced - it doesn't seem like a crazy proposition, but nor does it seem like a tautology. (What metric for efficiency of repair is there that could be mapped to visibility of different protocol layers?) - 2.2, 2nd para: This is repetitive. Making the point once is enough. - 2.3 and 2.3.1: What is the intent here? These sections seem to be content free. Looks like a placeholder that never got filled in? (Not unreasonable as it's hard to see real downsides to encryption of inter-DC traffic.) These need to be fixed or deleted. Probably deleted is better. (Certainly easier.) That needs fixing before IETF LC. 3.1.1, 1st para: I'm not clear how session monitoring of cleartext is needed for SLA evaluation. Maybe an example of some specific thing needed would helpa but I'm not seeing an input to SLA evaluation here. (I do see how logs can be useful there.) 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some of thie text relates to the marnew w/s, it ought only specify mobile clients where those are specifically relevant, an in this case, and others, they're not. 3.1.2: "cyber-security" and "cyber-attack" please avoid thosse ill-defined marketing terms unless you really need and can justify them 3.1.1: Is "malware explosion" a generally known term? I think detection is sufficient and searing for "malware explosion" doesn't turn up what I think you mean. (I'm guessing you mean unzipping etc.) 3.1.2, last para: I'm not clear how this para fits here or in this document in general. Not sure if that's just me or if some better linkage is needed, or even if the text would be better moved or deleted. 3.2.1: I'm not sure I agree with this, at least as stated. Wouldn't passive monitoring of ciphertext be just as effective for the SLA metrics mentioned in almost all cases? 3.2.2: "[Need descriptions for..." The rest of that para seems like placeholder text that needs fixing before IETF LC. 3.2.2: I think it'd be worth saying somewhere here that STARTTLS ought have zero effect on anti-SPAM etc. for SMTP traffic but is only an issue in corner-cases for e.g. hosters who want to scan outbound port 25 traffic in case their cusomters have suffered breaches and start sending spam. (At least that's my understanding.) PGP or S/MIME do of course. 3.2.2: What header encryption efforts are meant here? I'm not familiar with anything doing exactly that. Or maybe it's just a phrasing issue? Or perhaps this text is a bit old and OBE? (I mean that initial hopes that we initiate work to to encrypt e.g. Subject seem to be currently moribund.) 3.2.2: I'm not sure the bullet list here is a good idea. E.g. it omits DKIM related things and SPF related things. Maybe check with some anti-spam folks if keeping this list? 3.3: I wondered if this section would be better reorganised into a structure based on where the keys are located. Not sure but that might be a clearer way to distinguish the various kinds of encrypted storage. (Feel free to ignore this suggestion if it doesn't resonate.) 3.3.1: I found this sub-section confusing and not useful. Would suggest simplifying it a lot. The term "burst data" isn't that clear. - section 4: Is "for Enterprise Users" right here? - 4: "harder to break" is not relevant here - at least in terms of algorithms, which is what that'd be interpreted as far as to mean. If you mean that non FS mechanisms (e.g. RSA key transport) provide more opportunity for decryption at places other than the endpoint at which the applications calls for decryption, but that we increasingly do want to see more use of FS mechanisns, and that that's a tension, then maybe say that. - 4.1: Not sure "static" is quire right - I think what you mean is replicated TLS server RSA private keys. - 4.1.1: "Enterprise users are subject to the policies of their organization." That is jurisdiction-dependent - at least in some countries (e.g. Ireland) the enterprise cannot breach employment laws that can touch on employee privacy. Such jurisdictional issues can work both ways of course, either re-inforcing privacy or calling for privacy to be eroded even more than the enterprise would wish. Suggest adding "... and the jurisdictions in which the enterprise operates" to cover both;-) - 4.1.1: "These functions are critical to security and fraud monitoring." I don't accept that this is true of all the numbered elements in the list. Supposed countermeasures for IP leakage for example are often ineffective (though vendors who sell such things will doubtless disagree;-). I'd say toning that down a bit would be right, e.g. s/are criticial/ are often consided important/. - 4.1.2: Mention of PDM reminds me that that has had a pretty thorough discussion related to the secdir review and issues relevant to this draft. Incorporating a description of that history would maybe be useful so that we have less pain when we re-do that in future for other protocols. - 4.1.3: I don't accept "impossible" is correct. If we wanted to say that, we'd need evidence, e.g. via a set of references. "More onerous" would be fine if that's all we need to say. A number of other similar changes are needed for the text in 4.1.3.x as well, e.g.: - 4.1.3.1: "requires" is overstated, and what evidence is there for "frequently used"? I don't accept either assertion without evidence. - 4.1.3.x: there are more of the above that need fixing - 4.2, 2nd para: A lot of this is duplicative of earlier text. - 4.2: "unique and efficient vantage point" that's sales language and doesn't belong here. - 5.1: "TLS over SMTP" again a couple of times - 5.2: Is I-D.teague.. the right reference here? I'd have thought there was an ipfix RFC already that'd be good here. - 5.6: "has quickly reacted to" is sales language and doesn't belong. - 5.6: What is "[not BCP84]" as a reference? And I'm not sure why RFC2504 is a good reference here either. Are we talking about BCP38 but someone forgot to update text written from memory or something? :-) - 5.6: SAVI was only chartered for enterprise networks iirc. - 5.7: THe [SACM] reference is odd and has no entry in section 12. - 6.1: Are those "notable exceptions" still relevant? I'd say maybe not. - 6.1: Is the Alt-SVC description correct? I'm not sure. I suggest you ask an HTTP person maybe. That could also do with some references. - 6.1: "... to be blocked" makes some assumptions about what's ok/right that are not needed, "being requested" would be better. - section 7: "efforts to prevent it" - which it? And I don't think prevent is what you mean, unless you're moving into the "what the spooks want" territory and away from "what network managers need" which'd seem out of scope. I think that needs rephrasing. - section 7: "National surveillance programs" is not the right phrase. Maybe just "Law enforcement agencies..." - 7: please drop the various uses of "cyber" again;-) - 7: David Cameron seems to no longer act in that role. - 7: "avoid the fears of terrorism" is wrong - fears will exiat and be propogated by various actors regardless. And understanding technology won't help there. I think the fear you mean is that technolgoy will be abused by bad actors. - 7: The text seems to assume that all governments are equally ok and that they all like one another equally. I dont believe that is the case, so there are additional categories of bad actor that are missing here. I also find the frequency of the occurrence of "terror" to be higher than needed. (That is a scare-word best omitted when not needed.) - 7: I think a reference to the workshop held in Wash. DC last year (maybe June?) on whether or not magic solutions for LEAs can exist here may be useful. Some IETFers attended, and it covered these issues in a lot more depth than could be fitted here but I don't have the reference to hand. (Spoiler: there is no magic;-) - 7, last para; I'd recommend deleting this. When and if PIR methods are usable they will create as many issues as the solve, from the perspective of this document. - section 11: Is this useful? If not, it ought be deleted. If so, then it should be a section of its own on mobile networks and not an appendix. (I'll comment assuming that keeping the text is better, but I'm not sure it is, given the amount of context it may need.) - 11.1: What is an ACK stream? A reference or description is needed. "Prevents" needs justification (possibly via reference) - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM needs describing or a reference. What is a "sector"? And (in this context) what is "a server"? APN needs a reference. - 11.1: "trusted parties" is unclear - you need to say what is trusted by whom for what actions for this to be useful. - 11.1: DRM/QOE need expansion and a reference to justify the claim wrt *maximising* QOE. - 11.1: "Trusted proxy" - see above wrt term trusted. But in this case, the term is misleading and ought not be used as there seems to be no way in which the entity who needs to trust the proxy can know that that proxy exists. Please drop that term entirely. (Call it a TLS-MitM attacker if you must, as that is what it is and that is how such things were referred to earlier in this document.) There are two occurrences of that misldeading marketing term to remove. - 11.1: RAN needs expansion and "RAN-aware pacing" needs explanation and/or reference. - 11.2: What is meant here by "Transport header"? TCP mostly doesn't have this issue, so I assume this is looking forward to QUIC. I'd argue that if so, this text should be deleted as we now have a WG for QUIC which is specifically chartered to address these issues. If this is not about QUIC, then please elaborate. - 11.2: ANDSF needs a reference - 11.2: SON and MLB need references - 11.2: UPCON needs a reference, off-peak acceleration and outbound roamers need explanation and/or reference - 11.2: DSCP needs a reference - 11.3: RCS, QCI, LTE need rererences - 11.3: eMBMS needs a reference, see above wrt "trusted" - 11.3: Asserting that TLS is not necessary for DRM'd content is arguable and not blatently true, as asserted here. - 11.4: see above wrt "trusted." - 11.4: QAM, CS-Voice need references - 11.4: PGW, GGSN need references - 11.4; "GW" needs explanation and/or a reference - 11.4: "Decreasing Client-Server control loop requires deploying CDNs/Cloud functions that terminate encryption closer to the edge." I don't accept that "requires" is clearly true. Please justify e.g. via reference. Or maybe re-phrase so that the statement is clearly true but doesn't have gigantic implications for who is allowed to deploy what. (Or maybe I'm confused by what is meant here?) - 11.4: s/de-encryt/decrypt/ - 11.4: MEC needs a reference, see above wrt "trusted proxy" - 12.1: I agree with the shepherd that all the references here can be informative and you don't need 2119. - 12.2: URLs like that used for CAIDA aren't great for RFCs - better to find a better reference where that's easy (which it is in that case). I'm less sure about how best to deal with the Intercept and EFF, but if you search in scholar.google.com you may find other references for that content that are easier to use. (The issue here being reference stability.) - 12.2: [homomophic] needs a better reference if it stays, e.g. Gentry's PhD or something. - 12.2: various references need to be updated. I-D nits will help you there - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-) --------------ms000000070409060600080205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjIy MDQyMTFaMC8GCSqGSIb3DQEJBDEiBCDV29LbTHlsp4NDkKn719Vt4tympyRF9VfWNN1jeRYU 6jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBu2rzYBaSxNVZ0tCRxUiFKrLo8/khMEyUvIRrGbuHsGaH5grgENhxy YpJ9JHGCLp2UfAyumcYpx8OyCzTfouzplOHbWWi9VyUfycbyFuIt1NQyXyNFTSy1QKgpD1hP DXlDwPQPTxyqi3vqSe/TxvwsFFnic7nNcPszclWoSwgFvypJF5cumRF2Z/wepRL+ggFOMebo FWRyXRouLwG1oqOLbxXLk1D9piXDrDvUCXN/pgR/0mci9r2G6hoG+zrG5tZs54/fp39kNaeL fi4HjiSh+euKmu9i3rgtbI7vqpzhs58qKJckaUxvOAohK5CfJ78Pa6tfwo+BkTrEakbeEGwe AAAAAAAA --------------ms000000070409060600080205-- From nobody Wed Jan 25 11:33:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB7D129B48 for ; Wed, 25 Jan 2017 11:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 36WWsVFH6bEP for ; Wed, 25 Jan 2017 11:33:30 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18635129B3F for ; Wed, 25 Jan 2017 11:33:30 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id v23so34559075qtb.0 for ; Wed, 25 Jan 2017 11:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wz9X9D9eQV4F3ami71SUkFSb2+t+lx6JIFI60ytfeKY=; b=Y0JsCQPe0Bn5qoFSoHgOOxmBCKLgNm5m76TH3Tgb8k3gBikaizUewetpEe02FSEr2t YVuR45cxHE4OdTRlrXD+LiKRlT3aFeDwxHM/2Xw6MeT5fnFzGwErnQHE3OoctJfhQj+8 PSPogoghwWSYAI6THIrWWRQMOvbwh2G7UFTxsxUYSB0kyJfUhRQzAMBX+yHOvlDnlNlX eYGwUP9uWmN6qTFBNaM/TU51GOsvJKtofk7Gp5K95oay3lLhMHBWtz6UwY5rHUgBUExB uMDmEs/DKv3xhO9E0pqyFQ0G7Qk6Uh2HmySVp2BlCf+vzZkneW3+wvA+RxI4WkH58mst mpTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wz9X9D9eQV4F3ami71SUkFSb2+t+lx6JIFI60ytfeKY=; b=rFLD1AfvpjW7Z96h8MQCMeIq1+rTMuQcmMsJYhpWGae3Jw5ArfLYWw656rbwLaNRGS m0izvAMuNqn0kkTHXTcsuRqAzSE1B5JQykrupCQelyg2MhUg0GQpFKRZ2p4mNY6fTSPF +gSVi17yuwlaVnftKEuYouh5ETFV8F7N27exHcu/jB2lbwaZGlfZYeeFxbSkUIk9jwHO ZInQ9q224h3q8AskJecqdHvKgt4kl2h89nK53RxfOtI/ElMXpbh2piz1HYvGGrFbplIt 7Nncm66zqcEGvP48v3cDKZcrx/uFxvPJjWUptM9NTCzAkyWaepVEf18MUNBv6I/qFxRF Ln2g== X-Gm-Message-State: AIkVDXJP4W5w/5CjRkHuezmlx3J0GCeHDFj/LiiOc1mN37TEN7nDRES3xDvpqfgUBZy5Ake98dFz0TF/rvUckQ== X-Received: by 10.237.45.229 with SMTP id i92mr35309620qtd.226.1485372807847; Wed, 25 Jan 2017 11:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Wed, 25 Jan 2017 11:33:27 -0800 (PST) In-Reply-To: <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> From: Kathleen Moriarty Date: Wed, 25 Jan 2017 14:33:27 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" , Al Morton Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:33:37 -0000 Hi Stephen, First, thank you for your detailed review, this is very helpful to improve the document. Al's on vacation, so I will respond in-line for us and take the blame later if needed :-) On Sun, Jan 22, 2017 at 3:42 PM, Stephen Farrell wrote: > > > Hi again, > > First, thanks to Paul Hoffman for being willing to be the > document shepherd for this. And to the authors for what > will be a fine RFC when it's done. Thank you, Paul! > > > Second, I've done my AD review of this and there are a set > of things that need fixing before we'll be ready for IETF > last call. At minimum there are still a few placeholder > sections of text (2.3,2.3.1,3.2,2), but I also have many > comments that cumulatively raise to the level where we > should address a bunch of those before IETF LC, even > though many (but not all) of my comments are relatively > nitty. I think that almost all of those should be pretty > easy to resolve, so we should still be able to get this > done before IETF98 I hope. > > My AD review is below. > > Cheers, > S. > > general: I wonder if we're dealing with all possible effects > or only with those relevant to network management, security > ad privacy? For example, more encryption does prevent some > advertising insertion, but whether or not that is in scope > here is unclear to me. Should it be? I'd constrain it a little further to what we and others contributed. We certainly could have missed some items in network management, operation, security and privacy. I'll look at the introduction to see if the text can make it more clear on what the document covers. We encouraged the security and operator communities to contribute as best we could. > > - title: I wonder would "Effects of Much More Common > Encryption" be a better title? Ubiquitous is never actually > going to happen, nor is it required for many of the effects > to be seen. (And there is defo. >1 effect to be seen.) Or, > you could keep the title, but explain in the text that you > really mean "much more common." Let me think on this a bit to see if I can come up with an another title or we'll just note exactly what is meant in the introduction as suggested. > > > - abstract: "solve these problems" is a tad one-sided in that > it doesn't recognise the valid reasons for more > confidentiality. I think it's important that the abstract > recognise that we're here documenting one set of consequences > of what is a valid set of trade-offs and not describing a set > of problems caused for no good reason. I think that it's > important to set the right tone early for this one - if we > don't then some readers who want better privacy may be more > likely to be dismissive, which'd be a shame. How about, "This draft seeks only to record the current state to assist in the development of alternate options to achieve the intended purpose of the documented practices. > > - abstract: "will impact" is maybe no longer the correct > tense - we've seen some of these impacts already I think, so > maybe "are impacting" or just "impact" is better? I think just impacts works, thanks. > > > - abstract: "more drastic" seems unfounded - what do you > really want to say there? This is thinking from the operators perspective. I do think this is drastic for some and that we should recognize the large change in their world. Do you have another suggestion that conveys this understanding? Bringing both sides of this together is really the goal. > > > - intro: I'm not sure "primarily a passive attack" is right. > Maybe easiest to just delete that clause as I don't think > it's needed here. You could add a reference to RFC7624 for > those who'd like more detail. Sure there can be active attacks that lead to pervasive monitoring, and I'm fine with that change. > > > - intro, 2nd para: I'm not sure what you mean referring to > "many attackers"? That sentence doesn't seem to make sense > as-is. > Thanks, I see what you mean. The text isn't as straightforward as it could be. I think we were avoiding saying terrorists, but should just said bad actors. Old: Many attackers and those that pose a greater threat are already using strong encryption and tools like TOR to prevent active attacks on their data streams New: Bad actors, for example criminals or terrorists, could easily employ the use of strong encryption with tools like TOR to prevent active attacks on their data streams, which are possible with OS. > > - intro: the UTA document references need to be updated Done, thanks. > > > - intro: the 30% figure is probably out of date, please check > again (or add a date as done with the others). Changed to spring 2015. Will try to get a new figure if possible. > > > - intro: "for corporate users" would be better removed - we > care as much about non-corporate users after all Hmm, this is referring to the statistic for encrypted content, which was specific to corporate users. While we may care about non-corporate users more, this is an easier statistic to get since they are behind a firewall and corporate network used to gather this statistic. Non-corporate users might result in a different statistic, so I'd prefer to leave this as-is. > > - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP" Odd, thanks for catching this. > > - intro: "Although this does provide..." - that sentence > isn't right, passive is not the opposite of e2e, I think you > want s/passive wiretapping/transport layer attacks/ Updated, thanks. > > > - intro: You mention OTR, but the cooler kids these days use > signal/telegram (though I don't for platform reasons;-). > Might be worth checking out what to say about those, or just > say "e.g. OTR" instead of making it seem like OTR is the only > way to do IM e2e. Hmm, signal seems to be for SMS on Andriod only... or does it have a wider reach? If so, I'd rather not mention that. Telegram seems to be an app that relies on SMS and it's own messaging format, so it doesn't provide encryption for XMPP. If I add this, I'd have to add other messaging apps as well. I think it's fine to leave as-is with standards mentioned only. https://en.wikipedia.org/wiki/Telegram_(software) > > > - intro, 2nd last para: that one is very good Thanks :-) It's the goal of the draft. > > > - intro, last para: you don't mention enterprise networks > here, worth a mention? *Hmm, let me think about that a bit and we can come back to this one. > > > - section 2, 2nd para: I think you could do with a forward > reference or example to the "opterational practices that > require cleartext" or maybe better is to s/require/previously > depended on/ Took your suggested text, thanks. > > > - 2: "TLS over SMTP" - backwards again Odd. Fixed, thanks. > > > - 2: "The EFF reported..." that needs a reference added informative https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > > - 2: I'm not at all sure encryption "prevents" load > balancing, in fact I'm pretty sure it does not prevent that This was on the content. Would you prefer to see it reworded/expanded? > > > - 2: "on the decline now that they are exposed through the > media" - I think it'd be better to remove that sentence - it > doesn't add much and there are more details better described > later I'm sure. I cut out the first part, leaving the explanation... > > > - 2.1: this sections seems mixed between middleboxes and > mobile, probably as a result of iterative editing. Not sure > how best to fix. Sure, the first part mixes multiple ways fingerprinting is used and one is not middle boxes at all, but I'm not sure I want to separate that out and make the document longer... but if needed we can. *For the rest of the section, we are running into the many contributor problem and it's not clear how to make this better, but I'll think about it more. > > > - 2.1, last para: Is that really a middlebox function? I > thought most of the examples given were cases of end systems > (web servers) impinging on privacy and not middleboxes (and > the naughty web servers are not affected by encryption so > aren't really in scope) *No, same as the last part of the subsection on fingerprint analysis. We could remove it or break it out into another section. If we break it out into another section, the content may feel repetitive. > > > - 2.1.3: I don't think DPI aims to improve "features and > efficiency" That was an operator's perspective. Somehow we need to have both a security and operators perspective seen so we can help each other. The sentence says they are augmented, not improved, is there really an issue keeping this text? > > > - 2.1.3: "must be known" is overstated - again I think we > want to always phrase it as "has previously been assumed to > be required" or similar This was contributed text, so the functions they were performing, in the way they were being performed, might require the the traffic type to be known. I agree the text around this does not make that clear. I am hesitant to change the intended meaning without what seems like the additional context needed. How about, "has been required to date". I'd really like to respect the operators views and have them documented as they see it. > > - 2.1.4: I think compression could (and maybe should) be > separated out - one of the things CRIME has shown us is that > we had more to learn about how to combine compression and > encryption. I also think most compression is not done/undone > at middleboxes, nor does it relate to monitoring so > compression doesn't seem to fit well in 2.1. (Transcoding > however might fit in some middlebox section, but is not > compression.) OK, I see your perspective, but will try to shed light on the context of this section. This was contributed from GSMA. They have been using compression in this way and see a change in operations as a result of the use of encryption on the wire. I believe it is used in gateway situations from previous discussions. The point in this section is to note the practice and that encryption presents a problem for this operational practice. It's not suggesting encryption with compression as a solution, rather saying that some operators may resort to attempts to prevent/break encryption to allow for the compression they see as necessary to deliver services. It's going to break/is breaking and this just acks that point. > > > - 2.1.5: s/law agencies/law enforcement agencies/ is the > usual term, and LEAs are not the only entities that insist on > this kind of thing - considering censorship. updated, thanks. > > > - 2.1.5: "sites promoting anorexia" seems like an odd > example, but I think in any case it'd be better to generalise > the examples a bit Deleted that text. > > > - 2.1.5: DNS queries do not "reveal" URLs. And the described > mechanism seems quite odd. > Sure, looks like some flowery language inaccurately describing what was intended. I changed it to the following: Although filtering can be done by many methods one common method occurs when a DNS lookup of a hostname in a URL which appears on a government or recognized block-list. > - 2.1.5: The 3rd last para about "TLS proxies" and "future > versions of HTTP and TCP" is not clear to me. Is that really > needed? Hmm, I'm guessing this was referring to TCPInc work, but I think deleting the paragraph should be fine (scream now if you were the contributor and disagree) since the text concludes with a statement that this is not the case and has not been standardized. > > > - 2.1.5: Parental controls might deserve it's own subsection > - it differs in that the endopints are involved, which I > think means that the effects of e.g. TLS on the changes > required to the service are different from cases where an > external party (govt/SP/whoever) imposes the filtering. Done as a subsection of this section for now. Thanks. > > > - 2.1.6.3: I think you need a reference to RFC2804 here. The > IETF does not to LI in standards, for the (good) reasons > stated therin. So this may be a case where the effects of > crypto do enhance existing IETF policy but also counter > existing policies of other entities. But we should not ignore > the former (IETF) policy - we ought not claim here that one > or the other are better, but just ack the tussle. Done, thanks. > > > - 2.1.6.4: MTAs do trypically have cleartext access, so what > kind of spam/malware filtering do you mean there? How does > that relate to the mail architecture? (There's an RFC for > that that ought be ref'd.) If section 5 does cover this well, > then I'd say removing this section would be good as it add > nothing much that I can see. Deleted. > > > - 2.2: Do we have evidence that the decrease of measurement > accuracy has actually lead to a decrease in repair > efficiency? I'm not convinced - it doesn't seem like a crazy > proposition, but nor does it seem like a tautology. (What > metric for efficiency of repair is there that could be mapped > to visibility of different protocol layers?) *This is from Al (I believe), so I suspect it is backed up from operational testing. > > - 2.2, 2nd para: This is repetitive. Making the point once is > enough. Hmm, I deleted the last sentence, but think the example may be helpful within the operator community. > > > - 2.3 and 2.3.1: What is the intent here? These sections seem > to be content free. Looks like a placeholder that never got > filled in? (Not unreasonable as it's hard to see real > downsides to encryption of inter-DC traffic.) These need to > be fixed or deleted. Probably deleted is better. (Certainly > easier.) That needs fixing before IETF LC. Yes, deleted. > > > 3.1.1, 1st para: I'm not clear how session monitoring of > cleartext is needed for SLA evaluation. Maybe an example of > some specific thing needed would helpa but I'm not seeing an > input to SLA evaluation here. (I do see how logs can be > useful there.) I can't figure it out either, but changed the text to: The use of session encryption to access hosted environments limits access restrictions to the metadata described below. It goes on to describe 2-tuples and 5-tuples below. > > 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some > of thie text relates to the marnew w/s, it ought only specify > mobile clients where those are specifically relevant, an in > this case, and others, they're not. Done here and I'll have to look elsewhere as well. > > > 3.1.2: "cyber-security" and "cyber-attack" please avoid > thosse ill-defined marketing terms unless you really need and > can justify them Agreed, changed to security. > > > 3.1.1: Is "malware explosion" a generally known term? I think > detection is sufficient and searing for "malware explosion" > doesn't turn up what I think you mean. (I'm guessing you mean > unzipping etc.) That may be what was meant, but I just deleted explosion for now. I think this came from Nalini and it must have slipped through my edit pass & Al's. If something else was intended here that is important, she can chime in. > > > 3.1.2, last para: I'm not clear how this para fits here or in > this document in general. Not sure if that's just me or if > some better linkage is needed, or even if the text would be > better moved or deleted. *Hmm, I see how this relates to SPs, but not to this subsection. I'm not sure of the contributor as it may be tied to application content, but you are right - this text doesn't flow and that is not clear from the paragraph, > > > 3.2.1: I'm not sure I agree with this, at least as stated. > Wouldn't passive monitoring of ciphertext be just as > effective for the SLA metrics mentioned in almost all cases? Hmm, so I'm trying to decipher the text as well. What I can surmise is that the impediments to performance and availability are the "interferences". Some things that interfere with traffic might be seen outside of 2-tuples and 5-tuples more easily. For the metrics themselves, I agree with you. However, they may know the cause of the "interference" with visibility into the traffic. Perhaps adding the sentence: "The actual SLA metrics may not be effected by encryption, however visibility of interferences may be limited." > > 3.2.2: "[Need descriptions for..." The rest of that para > seems like placeholder text that needs fixing before IETF LC. deleted this paragraph. The rest flowed well enough and this was a placeholder for contributions. > > > 3.2.2: I think it'd be worth saying somewhere here that > STARTTLS ought have zero effect on anti-SPAM etc. for SMTP > traffic but is only an issue in corner-cases for e.g. hosters > who want to scan outbound port 25 traffic in case their > cusomters have suffered breaches and start sending spam. (At > least that's my understanding.) PGP or S/MIME do of course. OK, consider yourself the contributor for the above removed paragraph. I edited the above slightly. > > 3.2.2: What header encryption efforts are meant here? I'm not > familiar with anything doing exactly that. Or maybe it's just > a phrasing issue? Or perhaps this text is a bit old and OBE? > (I mean that initial hopes that we initiate work to to > encrypt e.g. Subject seem to be currently moribund.) This is old from the list that we started a while back on the topic that I don't think went anywhere. I'll delete it, but think we should have something in there about some of the other efforts - just mentioning dark mail and proprietary solutions. > > 3.2.2: I'm not sure the bullet list here is a good idea. > E.g. it omits DKIM related things and SPF related things. > Maybe check with some anti-spam folks if keeping this list? I removed the whole section as it didn't make sense without the email header thing that has gone away... > > > 3.3: I wondered if this section would be better reorganised > into a structure based on where the keys are located. Not > sure but that might be a clearer way to distinguish the > various kinds of encrypted storage. (Feel free to ignore this > suggestion if it doesn't resonate.) Yeah, it's more complicated than that as even on similar platforms, the solutions can differ. If KMIP is used, then you have a standard t go off of, but that's not always the case. > > > 3.3.1: I found this sub-section confusing and not useful. > Would suggest simplifying it a lot. The term "burst data" > isn't that clear. Hmm, I removed the word burst, but essentially, you could have a burst of data of a certain size and the size could dictate where the burst of data is stored. The same application might have some data stored locally, then some off to an external service. I reworded to remove the word burst and explain it better. > > > - section 4: Is "for Enterprise Users" right here? No, it should probably just be enterprises. updating, thanks. > > > - 4: "harder to break" is not relevant here - at least in > terms of algorithms, which is what that'd be interpreted as > far as to mean. If you mean that non FS mechanisms (e.g. RSA > key transport) provide more opportunity for decryption at > places other than the endpoint at which the applications > calls for decryption, but that we increasingly do want to see > more use of FS mechanisns, and that that's a tension, then > maybe say that. I agree with you and deleted that clause. Later in the paragraph, I changed "need" to "desire". > > > - 4.1: Not sure "static" is quire right - I think what you > mean is replicated TLS server RSA private keys. Yes, updated. > > > - 4.1.1: "Enterprise users are subject to the policies of > their organization." That is jurisdiction-dependent - at > least in some countries (e.g. Ireland) the enterprise cannot > breach employment laws that can touch on employee privacy. > Such jurisdictional issues can work both ways of course, > either re-inforcing privacy or calling for privacy to be > eroded even more than the enterprise would wish. Suggest > adding "... and the jurisdictions in which the enterprise > operates" to cover both;-) Updated, thanks for the text. > > > - 4.1.1: "These functions are critical to security and fraud > monitoring." I don't accept that this is true of all the > numbered elements in the list. Supposed countermeasures for > IP leakage for example are often ineffective (though vendors > who sell such things will doubtless disagree;-). I'd say > toning that down a bit would be right, e.g. s/are criticial/ > are often consided important/. Hmm, in reading this contributed text, I would change it even more than what you are suggesting. The functions aren't critical to monitoring, but rather detecting these functions are important to effective monitoring and mitigation of malicious traffic that is not limited to malware. How about: OLD: A significant portion of malware hides its activity within TLS or other encrypted protocols. This includes lateral movement, Command and Control, and Data Exfiltration. These functions are critical to security and fraud monitoring. NEW: A significant portion of malware hides its activity within TLS or other encrypted protocols. This includes lateral movement, Command and Control, and Data Exfiltration. Detecting these functions are important to effective monitoring and mitigation of malicious traffic, not limited to malware. > > - 4.1.2: Mention of PDM reminds me that that has had a pretty > thorough discussion related to the secdir review and issues > relevant to this draft. Incorporating a description of that > history would maybe be useful so that we have less pain when > we re-do that in future for other protocols. * Will have to go back to this as I'm not recalling this off hand and will have to review the discussion. > > > - 4.1.3: I don't accept "impossible" is correct. If we wanted > to say that, we'd need evidence, e.g. via a set of > references. "More onerous" would be fine if that's all we > need to say. A number of other similar changes are needed for > the text in 4.1.3.x as well, e.g.: The problem here (IMO) is that vendors need to step up their logging game. Many of the errors could be seen if logs better identified issues that I have been shown or that we've seen in presentations from enterprise representatives in the IETF. From their perspective, the problem seems insurmountable as they don't know how they will contact and so many vendors to increase logging and they no longer have visibility into packet streams to detect even simple issues like incorrect passwords.. I think we need to help (and are trying to do so) in standards documentation calling for logging of errors. The sentence is limited to finding things in network traces, so with encryption, they are right... they need other methods like log analysis. We need to ack the problems in this draft, so how about adding this sentence instead of changing the last one: Alternate methods, such as log analysis need improvement to fill this gap. > > > - 4.1.3.1: "requires" is overstated, and what evidence is > there for "frequently used"? I don't accept either assertion > without evidence. Hmm, my read of this part of the NAT section is that they use identifier information to trace traffic, which is normal. Up to this point in the text, I am reading it in a way that they can do this through logs. I have more of an issue with the following paragraphs. Requires just means that if they are going to follow a trace, they need some identifiers to do so - 2-tuples, 5-tuples and how they change (logs) through a device that performs NAT. I propose changing this instead: OLD: Combine this with the fact that users are often allocated randomly by load balancers to all these devices, the network troubleshooter is often left with no option in today's environment except to trace all packets at a particular layer, decrypt them all, and look at the payload to find a user session. NEW: Combine this with the fact that users are often allocated randomly by load balancers to all these devices, the network troubleshooter is often left with very few options in today's environment due to poor logging implementations in applications. As such, network troubleshooting is used to trace packets at a particular layer, decrypt them, and look at the payload to find a user session. and OLD: Endpoints typically don't have the capacity to handle this level of network packet capture, so out-of-band networks of robust packet brokers and network sniffers that depend on static RSA private keys accomplish this task today. NEW: Endpoints typically don't have the capacity to handle this level of network packet capture, so out-of-band networks of robust packet brokers and network sniffers that use techniques such as copies of TLS RSA private keys accomplish this task today. > > > - 4.1.3.x: there are more of the above that need fixing **Additional cleanup, but I'm making a leap that the logs for this are inadequate, so this needs to be confirmed. OLD: When TCP Pipelining/Session Multiplexing is used, usually by Middle boxes today, multiple end user sessions share the same TCP connection. Today's network troubleshooter often relies upon session decryption to tell which packet belongs to which end user. NEW: TCP Pipelining/Session Multiplexing used mainly by middle boxes today allow for multiple end user sessions to share the same TCP connection. Today's network troubleshooter often relies upon session decryption to tell which packet belongs to which end user as the logs are currently inadequate for the analysis needed. In HTTP Service Call subsection... OLD: It must be possible to match up the user request above with the HTTP service call below. Today, this is done by decrypting the TLS packet and inspecting the payload. NEW: Troubleshooting via network trace involves matching up the user request with the HTTP service call. Some organizations do this today by decrypting the TLS packet and inspecting the payload. Logging has not been adequate for their purposes. ** Again making the leap that logging has not been adequate for their purposes and the IETF should be able to help with that in HTTP standards documentation. **I am finding I need to replace the text in 4.1.3.4 and this will need to be reviewed by the contributor. OLD: Modern applications often use XML structures in the payload of the data to store application level information. When the network and application teams must work together, each has a different view of the transaction failure. It is important to be able to correlate the network packet with the actual problem experienced by an application. NEW: Many applications use text formats such as XML to transport data or application level information. When transaction failures occur and the logs are inadequate to determine the cause, network and application teams work together, each having a different view of the transaction failure. Using this troubleshooting method, the network packet is correlated with the actual problem experienced by an application to find a root cause. The inability to access the payload prevents this method of troubleshooting. - removed 'modern' as other formats have taken over. > > - 4.2, 2nd para: A lot of this is duplicative of earlier > text. 1st paragraph - I think the following needs to be tweaked too. OLD: In some cases, alternate options are available when encryption is in use, but techniques like that of data leakage prevention tools at a proxy would not be possible if encrypted traffic can not be intercepted, thus creating a gap and encouraging alternate options. NEW: In some cases, alternate options are available when encryption is in use, but techniques like that of data leakage prevention tools at a proxy would not be possible if encrypted traffic can not be intercepted, encouraging alternate options such as performing these functions at the edge. > > - 4.2: "unique and efficient vantage point" that's sales > language and doesn't belong here. Removed. > > - 5.1: "TLS over SMTP" again a couple of times Ha. fixed. > > - 5.2: Is I-D.teague.. the right reference here? I'd have > thought there was an ipfix RFC already that'd be good here. This was DOTS and they haven't published anything yet. I removed the reference as it hasn't been adopted yet and just referred to the WG as that will have lots more information in time. > > - 5.6: "has quickly reacted to" is sales language and doesn't > belong. Removed quickly. Would need to rework the text to change it more. > > - 5.6: What is "[not BCP84]" as a reference? And I'm not sure > why RFC2504 is a good reference here either. Are we talking > about BCP38 but someone forgot to update text written from > memory or something? :-) RFC2827 is BCP 38, so I don't know what was meant by the [not BCP84]. I am guessing the contributor did want both referenced, but I'll remove the not BCP84 as that's confusing. > > - 5.6: SAVI was only chartered for enterprise networks iirc. > > - 5.7: THe [SACM] reference is odd and has no entry in > section 12. I don't think it's odd as it should help. > > - 6.1: Are those "notable exceptions" still relevant? I'd say > maybe not. Deleted that sentence, thanks. > > - 6.1: Is the Alt-SVC description correct? I'm not sure. I > suggest you ask an HTTP person maybe. That could also do with > some references. *Will have to come back to this one. > > - 6.1: "... to be blocked" makes some assumptions about > what's ok/right that are not needed, "being requested" would > be better. I'm deleting the ending clause all together as I think that's clearer and adding "being requested" isn't the intent. > > - section 7: "efforts to prevent it" - which it? And I don't > think prevent is what you mean, unless you're moving into the > "what the spooks want" territory and away from "what network > managers need" which'd seem out of scope. I think that needs > rephrasing. Just deleting the first sentence clears this up as the other 2 sentences cover what was intended well enough. > > - section 7: "National surveillance programs" is not the > right phrase. Maybe just "Law enforcement agencies..." *Hmm, let's come back to this one. I'm not sure LEA is right as it's not the same as a government surveillance program. > > - 7: please drop the various uses of "cyber" again;-) Done. Agreed. > > - 7: David Cameron seems to no longer act in that role. removed. > > - 7: "avoid the fears of terrorism" is wrong - fears will > exiat and be propogated by various actors regardless. And > understanding technology won't help there. I think the fear > you mean is that technolgoy will be abused by bad actors. Changed that part of the first paragraph to address a few of your comments: NEW: Governments vary on their balance between their need for monitoring versus the protection of user privacy, data, and assets. Those that favor unencrypted access to data ignore the real need to protect users identity, financial transactions and intellectual property, which requires security and encryption to prevent crime. A clear understanding of technology, encryption, and monitoring needs will aid in the development of solutions to appropriately balance the need of privacy. As this understanding increases, hopefully the discussions will improve and this draft is meant to help further the discussion. > > - 7: The text seems to assume that all governments are > equally ok and that they all like one another equally. I don't > believe that is the case, so there are additional categories > of bad actor that are missing here. I also find the frequency > of the occurrence of "terror" to be higher than needed. (That > is a scare-word best omitted when not needed.) It's there once now as that is the motivator for many of the surveillance programs. > > - 7: I think a reference to the workshop held in Wash. DC > last year (maybe June?) on whether or not magic solutions for > LEAs can exist here may be useful. Some IETFers attended, and > it covered these issues in a lot more depth than could be > fitted here but I don't have the reference to hand. (Spoiler: > there is no magic;-) We are open to contributions! > > - 7, last para; I'd recommend deleting this. When and if PIR > methods are usable they will create as many issues as the > solve, from the perspective of this document. I made it less optimistic. I think if left out, it would become a talking point that could detract from the purpose of this document. I'd like it to be clear that this was thought about, but isn't practical. > > - section 11: Is this useful? If not, it ought be deleted. > If so, then it should be a section of its own on mobile > networks and not an appendix. (I'll comment assuming that > keeping the text is better, but I'm not sure it is, given the > amount of context it may need.) > > - 11.1: What is an ACK stream? A reference or description is > needed. "Prevents" needs justification (possibly via > reference) > > - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM > needs describing or a reference. What is a "sector"? And (in > this context) what is "a server"? APN needs a reference. > > - 11.1: "trusted parties" is unclear - you need to say what > is trusted by whom for what actions for this to be useful. > > - 11.1: DRM/QOE need expansion and a reference to justify the > claim wrt *maximising* QOE. > > - 11.1: "Trusted proxy" - see above wrt term trusted. But in > this case, the term is misleading and ought not be used as > there seems to be no way in which the entity who needs to > trust the proxy can know that that proxy exists. Please drop > that term entirely. (Call it a TLS-MitM attacker if you must, > as that is what it is and that is how such things were > referred to earlier in this document.) There are two > occurrences of that misldeading marketing term to remove. > > - 11.1: RAN needs expansion and "RAN-aware pacing" needs > explanation and/or reference. > > - 11.2: What is meant here by "Transport header"? TCP mostly > doesn't have this issue, so I assume this is looking forward > to QUIC. I'd argue that if so, this text should be deleted as > we now have a WG for QUIC which is specifically chartered to > address these issues. If this is not about QUIC, then please > elaborate. > > - 11.2: ANDSF needs a reference > > - 11.2: SON and MLB need references > > - 11.2: UPCON needs a reference, off-peak acceleration and > outbound roamers need explanation and/or reference > > - 11.2: DSCP needs a reference > > - 11.3: RCS, QCI, LTE need rererences > > - 11.3: eMBMS needs a reference, see above wrt "trusted" > > - 11.3: Asserting that TLS is not necessary for DRM'd content > is arguable and not blatently true, as asserted here. > > - 11.4: see above wrt "trusted." > > - 11.4: QAM, CS-Voice need references > > - 11.4: PGW, GGSN need references > > - 11.4; "GW" needs explanation and/or a reference > > - 11.4: "Decreasing Client-Server control loop requires > deploying CDNs/Cloud functions that terminate encryption > closer to the edge." I don't accept that "requires" is > clearly true. Please justify e.g. via reference. Or maybe > re-phrase so that the statement is clearly true but doesn't > have gigantic implications for who is allowed to deploy what. > (Or maybe I'm confused by what is meant here?) > > - 11.4: s/de-encryt/decrypt/ > > - 11.4: MEC needs a reference, see above wrt "trusted proxy" > > - 12.1: I agree with the shepherd that all the references > here can be informative and you don't need 2119. Sure, that makes sense. It is an informative document. > > - 12.2: URLs like that used for CAIDA aren't great for RFCs - > better to find a better reference where that's easy (which it > is in that case). I'm less sure about how best to deal with > the Intercept and EFF, but if you search in > scholar.google.com you may find other references for that > content that are easier to use. (The issue here being > reference stability.) *Yes, I'll have to follow up on this one, but have the URLs in the current version. Al and I both knew we would have to fix this later and should have done it prior to AD review. > > - 12.2: [homomophic] needs a better reference if it stays, > e.g. Gentry's PhD or something. * Yes, I'll find something. > > - 12.2: various references need to be updated. I-D nits will > help you there *Yes, I thin there is just one id left and it's actually in my queue ahead of this document. > > - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-) *Yes, will fix. > > > Thanks so much for your review. Anything with a * is one that either needs my attention, that of a contributor, or my co-author to go back and look at. -- Best regards, Kathleen From nobody Wed Jan 25 14:00:36 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F469129C53 for ; Wed, 25 Jan 2017 14:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 XI8rrCeb_O-Q for ; Wed, 25 Jan 2017 14:00:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3109124281 for ; Wed, 25 Jan 2017 14:00:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CFFFBBE2F; Wed, 25 Jan 2017 22:00:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2b02NlnURi9; Wed, 25 Jan 2017 22:00:07 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC0FEBE2D; Wed, 25 Jan 2017 22:00:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485381607; bh=glSL3SwP85IK5EMrDH7n3KFHA7p50pAQynheSt/HQoM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=sHXhKl2VWTqCxW6BFTpx0Za+gkfccw12/8JHLAvAKm8Uo8gXOXqEXvU2RYkxvSAoX txu65+oQoBs8j2dNopUdwqUN9UZBAtGhBF5f6HluZQ8AjUjtaPhmVYg7e1E8CxamZH lr4j6GCwDdxnB2LIiEhw4NyjxlMbgNL+jLMNYg2A= To: Kathleen Moriarty References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> Date: Wed, 25 Jan 2017 22:00:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010007000708040102090604" Archived-At: Cc: "saag@ietf.org" , Al Morton Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 22:00:25 -0000 This is a cryptographically signed message in MIME format. --------------ms010007000708040102090604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Mostly grand. A few responses inline. I'd say whack out a rev whenever you're ready and we can go from there. There is one remaining thing below I'd like to bottom out before starting IETF LC which is what to do about section 11 - if we're keeping it then it needs work - that'd be easy enough for someone familiar with the mobile n/w stuff (as it's mostly clarifying or referencing) but a good bit of work for others maybe. Other than section 11, any remaining comments of mine should be fine to be handled as IETF LC comments I figure. Cheers, S. On 25/01/17 19:33, Kathleen Moriarty wrote: > Hi Stephen, >=20 > First, thank you for your detailed review, this is very helpful to > improve the document. Al's on vacation, so I will respond in-line for > us and take the blame later if needed :-) >=20 > On Sun, Jan 22, 2017 at 3:42 PM, Stephen Farrell > wrote: >> >> >> Hi again, >> >> First, thanks to Paul Hoffman for being willing to be the >> document shepherd for this. And to the authors for what >> will be a fine RFC when it's done. >=20 >=20 > Thank you, Paul! >> >> >> Second, I've done my AD review of this and there are a set >> of things that need fixing before we'll be ready for IETF >> last call. At minimum there are still a few placeholder >> sections of text (2.3,2.3.1,3.2,2), but I also have many >> comments that cumulatively raise to the level where we >> should address a bunch of those before IETF LC, even >> though many (but not all) of my comments are relatively >> nitty. I think that almost all of those should be pretty >> easy to resolve, so we should still be able to get this >> done before IETF98 I hope. >> >> My AD review is below. >> >> Cheers, >> S. For clarity: where I don't respond I'm fine with your response. >> >> general: I wonder if we're dealing with all possible effects >> or only with those relevant to network management, security >> ad privacy? For example, more encryption does prevent some >> advertising insertion, but whether or not that is in scope >> here is unclear to me. Should it be? >=20 >=20 > I'd constrain it a little further to what we and others contributed. > We certainly could have missed some items in network management, > operation, security and privacy. I'll look at the introduction to see > if the text can make it more clear on what the document covers. >=20 > We encouraged the security and operator communities to contribute as > best we could. >=20 >> >> - title: I wonder would "Effects of Much More Common >> Encryption" be a better title? Ubiquitous is never actually >> going to happen, nor is it required for many of the effects >> to be seen. (And there is defo. >1 effect to be seen.) Or, >> you could keep the title, but explain in the text that you >> really mean "much more common." >=20 >=20 > Let me think on this a bit to see if I can come up with an another > title or we'll just note exactly what is meant in the introduction as > suggested. >=20 >> >> >> - abstract: "solve these problems" is a tad one-sided in that >> it doesn't recognise the valid reasons for more >> confidentiality. I think it's important that the abstract >> recognise that we're here documenting one set of consequences >> of what is a valid set of trade-offs and not describing a set >> of problems caused for no good reason. I think that it's >> important to set the right tone early for this one - if we >> don't then some readers who want better privacy may be more >> likely to be dismissive, which'd be a shame. >=20 >=20 > How about, > "This draft seeks only to record the current state to assist in th= e > development of alternate options to achieve the intended purpose = of the > documented practices. >=20 >> >> - abstract: "will impact" is maybe no longer the correct >> tense - we've seen some of these impacts already I think, so >> maybe "are impacting" or just "impact" is better? >=20 >=20 > I think just impacts works, thanks. >=20 >> >> >> - abstract: "more drastic" seems unfounded - what do you >> really want to say there? >=20 >=20 > This is thinking from the operators perspective. I do think this is > drastic for some and that we should recognize the large change in > their world. Do you have another suggestion that conveys this > understanding? Bringing both sides of this together is really the > goal. Perhaps s/In more drastic circumstances/In the limit/ and s/may be/could be/? >=20 >> >> >> - intro: I'm not sure "primarily a passive attack" is right. >> Maybe easiest to just delete that clause as I don't think >> it's needed here. You could add a reference to RFC7624 for >> those who'd like more detail. >=20 >=20 > Sure there can be active attacks that lead to pervasive monitoring, > and I'm fine with that change. >=20 >> >> >> - intro, 2nd para: I'm not sure what you mean referring to >> "many attackers"? That sentence doesn't seem to make sense >> as-is. >> >=20 > Thanks, I see what you mean. The text isn't as straightforward as it > could be. I think we were avoiding saying terrorists, but should just > said bad actors. >=20 > Old: > Many attackers and those > that pose a greater threat are already using strong encryption an= d tools > like TOR to prevent active attacks on thei= r data > streams > New: > Bad actors, for example criminals or terrorists, could easily > employ the use of strong encryption with tools like TOR target=3D"TOR"/> to prevent active attacks on their data streams, which= > are possible with OS. I still think that's out of context. Maybe mention it elsewhere? >=20 >> >> - intro: the UTA document references need to be updated >=20 >=20 > Done, thanks. >=20 >> >> >> - intro: the 30% figure is probably out of date, please check >> again (or add a date as done with the others). >=20 >=20 > Changed to spring 2015. Will try to get a new figure if possible. >=20 >> >> >> - intro: "for corporate users" would be better removed - we >> care as much about non-corporate users after all >=20 >=20 > Hmm, this is referring to the statistic for encrypted content, which > was specific to corporate users. While we may care about non-corporate > users more, this is an easier statistic to get since they are behind a > firewall and corporate network used to gather this statistic. > Non-corporate users might result in a different statistic, so I'd > prefer to leave this as-is. Still not clear to me that this is correct as stated, but not a huge deal. >=20 >> >> - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP" >=20 >=20 > Odd, thanks for catching this. >=20 >> >> - intro: "Although this does provide..." - that sentence >> isn't right, passive is not the opposite of e2e, I think you >> want s/passive wiretapping/transport layer attacks/ >=20 >=20 > Updated, thanks. >> >> >> - intro: You mention OTR, but the cooler kids these days use >> signal/telegram (though I don't for platform reasons;-). >> Might be worth checking out what to say about those, or just >> say "e.g. OTR" instead of making it seem like OTR is the only >> way to do IM e2e. >=20 >=20 > Hmm, signal seems to be for SMS on Andriod only... or does it have a > wider reach? If so, I'd rather not mention that. Telegram seems to > be an app that relies on SMS and it's own messaging format, so it > doesn't provide encryption for XMPP. If I add this, I'd have to add > other messaging apps as well. I think it's fine to leave as-is with > standards mentioned only. Problem is, OTR is not a standard, same as the rest. "e.g. OTR" is maybe the way to do it. > https://en.wikipedia.org/wiki/Telegram_(software) >=20 >> >> >> - intro, 2nd last para: that one is very good >=20 >=20 > Thanks :-) It's the goal of the draft. >> >> >> - intro, last para: you don't mention enterprise networks >> here, worth a mention? >=20 >=20 > *Hmm, let me think about that a bit and we can come back to this one. >=20 >> >> >> - section 2, 2nd para: I think you could do with a forward >> reference or example to the "opterational practices that >> require cleartext" or maybe better is to s/require/previously >> depended on/ >=20 >=20 > Took your suggested text, thanks. >=20 >> >> >> - 2: "TLS over SMTP" - backwards again >=20 >=20 > Odd. Fixed, thanks. >> >> >> - 2: "The EFF reported..." that needs a reference >=20 > added informative > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks >> >> >> - 2: I'm not at all sure encryption "prevents" load >> balancing, in fact I'm pretty sure it does not prevent that >=20 >=20 > This was on the content. Would you prefer to see it reworded/expanded?= Yeah, I think saying prevents is just wrong. Encrypting does prevent some methods of load-balancing from working but not all methods. Ditto for other features that get changed. I do think it's important to not overstate the effects, just as it is to not understate them. >=20 >> >> >> - 2: "on the decline now that they are exposed through the >> media" - I think it'd be better to remove that sentence - it >> doesn't add much and there are more details better described >> later I'm sure. >=20 >=20 > I cut out the first part, leaving the explanation... >> >> >> - 2.1: this sections seems mixed between middleboxes and >> mobile, probably as a result of iterative editing. Not sure >> how best to fix. >=20 > Sure, the first part mixes multiple ways fingerprinting is used and > one is not middle boxes at all, but I'm not sure I want to separate > that out and make the document longer... but if needed we can. >=20 > *For the rest of the section, we are running into the many contributor > problem and it's not clear how to make this better, but I'll think > about it more. >=20 >> >> >> - 2.1, last para: Is that really a middlebox function? I >> thought most of the examples given were cases of end systems >> (web servers) impinging on privacy and not middleboxes (and >> the naughty web servers are not affected by encryption so >> aren't really in scope)=20 >=20 >=20 > *No, same as the last part of the subsection on fingerprint analysis. > We could remove it or break it out into another section. If we break > it out into another section, the content may feel repetitive. >> >> >> - 2.1.3: I don't think DPI aims to improve "features and >> efficiency" >=20 >=20 > That was an operator's perspective. Somehow we need to have both a > security and operators perspective seen so we can help each other. > The sentence says they are augmented, not improved, is there really an > issue keeping this text? >=20 >> >> >> - 2.1.3: "must be known" is overstated - again I think we >> want to always phrase it as "has previously been assumed to >> be required" or similar >=20 >=20 > This was contributed text, so the functions they were performing, in > the way they were being performed, might require the the traffic type > to be known. I agree the text around this does not make that clear. I > am hesitant to change the intended meaning without what seems like the > additional context needed. >=20 > How about, "has been required to date". I'd really like to respect > the operators views and have them documented as they see it. I don't think adding the caveats that are needed has anything to do with respect. When we've been doing a thing one way for ages, there's a natural tendency to not consider that there were also other ways to crack the nut;-) The key point here and in many places is I think to ack that encryption does affect what has been done to date, and will force us to find other ways to meet the same goals. But in most cases, there will be other ways available, which means that "required" (or "must be known") isn't correct for those features. (In this case, it could be that any measure that distinguishes video from other things would be good enough for many situations for example and that doesn't require plaintext.) >=20 >> >> - 2.1.4: I think compression could (and maybe should) be >> separated out - one of the things CRIME has shown us is that >> we had more to learn about how to combine compression and >> encryption. I also think most compression is not done/undone >> at middleboxes, nor does it relate to monitoring so >> compression doesn't seem to fit well in 2.1. (Transcoding >> however might fit in some middlebox section, but is not >> compression.) >=20 >=20 > OK, I see your perspective, but will try to shed light on the context > of this section. This was contributed from GSMA. They have been > using compression in this way and see a change in operations as a > result of the use of encryption on the wire. I believe it is used in > gateway situations from previous discussions. The point in this > section is to note the practice and that encryption presents a problem > for this operational practice. It's not suggesting encryption with > compression as a solution, rather saying that some operators may > resort to attempts to prevent/break encryption to allow for the > compression they see as necessary to deliver services. It's going to > break/is breaking and this just acks that point. Isn't that usually transcoding and not compression? >=20 >> >> >> - 2.1.5: s/law agencies/law enforcement agencies/ is the >> usual term, and LEAs are not the only entities that insist on >> this kind of thing - considering censorship. >=20 > updated, thanks. >> >> >> - 2.1.5: "sites promoting anorexia" seems like an odd >> example, but I think in any case it'd be better to generalise >> the examples a bit >=20 >=20 > Deleted that text. >=20 >> >> >> - 2.1.5: DNS queries do not "reveal" URLs. And the described >> mechanism seems quite odd. >> >=20 > Sure, looks like some flowery language inaccurately describing what > was intended. I changed it to the following: >=20 > Although filtering can be > done by many methods one common method occurs when a DNS look= up > of a hostname in a URL which appears on a government or recog= nized > block-list. >=20 >> - 2.1.5: The 3rd last para about "TLS proxies" and "future >> versions of HTTP and TCP" is not clear to me. Is that really >> needed? >=20 >=20 > Hmm, I'm guessing this was referring to TCPInc work, but I think > deleting the paragraph should be fine (scream now if you were the > contributor and disagree) since the text concludes with a statement > that this is not the case and has not been standardized. >=20 >> >> >> - 2.1.5: Parental controls might deserve it's own subsection >> - it differs in that the endopints are involved, which I >> think means that the effects of e.g. TLS on the changes >> required to the service are different from cases where an >> external party (govt/SP/whoever) imposes the filtering. >=20 >=20 > Done as a subsection of this section for now. Thanks. >=20 >> >> >> - 2.1.6.3: I think you need a reference to RFC2804 here. The >> IETF does not to LI in standards, for the (good) reasons >> stated therin. So this may be a case where the effects of >> crypto do enhance existing IETF policy but also counter >> existing policies of other entities. But we should not ignore >> the former (IETF) policy - we ought not claim here that one >> or the other are better, but just ack the tussle. >=20 >=20 > Done, thanks. >> >> >> - 2.1.6.4: MTAs do trypically have cleartext access, so what >> kind of spam/malware filtering do you mean there? How does >> that relate to the mail architecture? (There's an RFC for >> that that ought be ref'd.) If section 5 does cover this well, >> then I'd say removing this section would be good as it add >> nothing much that I can see. >=20 >=20 > Deleted. >> >> >> - 2.2: Do we have evidence that the decrease of measurement >> accuracy has actually lead to a decrease in repair >> efficiency? I'm not convinced - it doesn't seem like a crazy >> proposition, but nor does it seem like a tautology. (What >> metric for efficiency of repair is there that could be mapped >> to visibility of different protocol layers?) >=20 >=20 > *This is from Al (I believe), so I suspect it is backed up from > operational testing. Consider a request for more info (via ref is fine) as a LC comment. >=20 >> >> - 2.2, 2nd para: This is repetitive. Making the point once is >> enough. >=20 >=20 > Hmm, I deleted the last sentence, but think the example may be helpful > within the operator community. >=20 >> >> >> - 2.3 and 2.3.1: What is the intent here? These sections seem >> to be content free. Looks like a placeholder that never got >> filled in? (Not unreasonable as it's hard to see real >> downsides to encryption of inter-DC traffic.) These need to >> be fixed or deleted. Probably deleted is better. (Certainly >> easier.) That needs fixing before IETF LC. >=20 >=20 > Yes, deleted. >=20 >> >> >> 3.1.1, 1st para: I'm not clear how session monitoring of >> cleartext is needed for SLA evaluation. Maybe an example of >> some specific thing needed would helpa but I'm not seeing an >> input to SLA evaluation here. (I do see how logs can be >> useful there.) >=20 >=20 > I can't figure it out either, but changed the text to: >=20 > The use of session encryption to access hosted > environments limits access restrictions to the metadata > described below. > =20 > It goes on to describe 2-tuples and 5-tuples below. >=20 >> >> 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some >> of thie text relates to the marnew w/s, it ought only specify >> mobile clients where those are specifically relevant, an in >> this case, and others, they're not. >=20 >=20 > Done here and I'll have to look elsewhere as well. >=20 >> >> >> 3.1.2: "cyber-security" and "cyber-attack" please avoid >> thosse ill-defined marketing terms unless you really need and >> can justify them >=20 >=20 > Agreed, changed to security. >=20 >> >> >> 3.1.1: Is "malware explosion" a generally known term? I think >> detection is sufficient and searing for "malware explosion" >> doesn't turn up what I think you mean. (I'm guessing you mean >> unzipping etc.) >=20 >=20 > That may be what was meant, but I just deleted explosion for now. I > think this came from Nalini and it must have slipped through my edit > pass & Al's. If something else was intended here that is important, > she can chime in. >=20 >> >> >> 3.1.2, last para: I'm not clear how this para fits here or in >> this document in general. Not sure if that's just me or if >> some better linkage is needed, or even if the text would be >> better moved or deleted. >=20 >=20 > *Hmm, I see how this relates to SPs, but not to this subsection. I'm > not sure of the contributor as it may be tied to application content, > but you are right - this text doesn't flow and that is not clear from > the paragraph, >=20 >> >> >> 3.2.1: I'm not sure I agree with this, at least as stated. >> Wouldn't passive monitoring of ciphertext be just as >> effective for the SLA metrics mentioned in almost all cases? >=20 >=20 > Hmm, so I'm trying to decipher the text as well. What I can surmise > is that the impediments to performance and availability are the > "interferences". Some things that interfere with traffic might be > seen outside of 2-tuples and 5-tuples more easily. For the metrics > themselves, I agree with you. However, they may know the cause of the > "interference" with visibility into the traffic. >=20 > Perhaps adding the sentence: >=20 > "The actual SLA metrics may not be effected by > encryption, however visibility of interferences may be limite= d." >=20 >> >> 3.2.2: "[Need descriptions for..." The rest of that para >> seems like placeholder text that needs fixing before IETF LC. >=20 >=20 > deleted this paragraph. The rest flowed well enough and this was a > placeholder for contributions. >> >> >> 3.2.2: I think it'd be worth saying somewhere here that >> STARTTLS ought have zero effect on anti-SPAM etc. for SMTP >> traffic but is only an issue in corner-cases for e.g. hosters >> who want to scan outbound port 25 traffic in case their >> cusomters have suffered breaches and start sending spam. (At >> least that's my understanding.) PGP or S/MIME do of course. >=20 >=20 > OK, consider yourself the contributor for the above removed paragraph. > I edited the above slightly. >=20 >> >> 3.2.2: What header encryption efforts are meant here? I'm not >> familiar with anything doing exactly that. Or maybe it's just >> a phrasing issue? Or perhaps this text is a bit old and OBE? >> (I mean that initial hopes that we initiate work to to >> encrypt e.g. Subject seem to be currently moribund.) >=20 >=20 > This is old from the list that we started a while back on the topic > that I don't think went anywhere. I'll delete it, but think we should > have something in there about some of the other efforts - just > mentioning dark mail and proprietary solutions. >=20 >> >> 3.2.2: I'm not sure the bullet list here is a good idea. >> E.g. it omits DKIM related things and SPF related things. >> Maybe check with some anti-spam folks if keeping this list? >=20 >=20 > I removed the whole section as it didn't make sense without the email > header thing that has gone away... >=20 >> >> >> 3.3: I wondered if this section would be better reorganised >> into a structure based on where the keys are located. Not >> sure but that might be a clearer way to distinguish the >> various kinds of encrypted storage. (Feel free to ignore this >> suggestion if it doesn't resonate.) >=20 >=20 > Yeah, it's more complicated than that as even on similar platforms, > the solutions can differ. If KMIP is used, then you have a standard t > go off of, but that's not always the case. >=20 >> >> >> 3.3.1: I found this sub-section confusing and not useful. >> Would suggest simplifying it a lot. The term "burst data" >> isn't that clear. >=20 >=20 > Hmm, I removed the word burst, but essentially, you could have a burst > of data of a certain size and the size could dictate where the burst > of data is stored. The same application might have some data stored > locally, then some off to an external service. I reworded to remove > the word burst and explain it better. >=20 >> >> >> - section 4: Is "for Enterprise Users" right here? >=20 > No, it should probably just be enterprises. updating, thanks. >=20 >> >> >> - 4: "harder to break" is not relevant here - at least in >> terms of algorithms, which is what that'd be interpreted as >> far as to mean. If you mean that non FS mechanisms (e.g. RSA >> key transport) provide more opportunity for decryption at >> places other than the endpoint at which the applications >> calls for decryption, but that we increasingly do want to see >> more use of FS mechanisns, and that that's a tension, then >> maybe say that. >=20 >=20 > I agree with you and deleted that clause. Later in the paragraph, I > changed "need" to "desire". >=20 >> >> >> - 4.1: Not sure "static" is quire right - I think what you >> mean is replicated TLS server RSA private keys. >=20 >=20 > Yes, updated. >> >> >> - 4.1.1: "Enterprise users are subject to the policies of >> their organization." That is jurisdiction-dependent - at >> least in some countries (e.g. Ireland) the enterprise cannot >> breach employment laws that can touch on employee privacy. >> Such jurisdictional issues can work both ways of course, >> either re-inforcing privacy or calling for privacy to be >> eroded even more than the enterprise would wish. Suggest >> adding "... and the jurisdictions in which the enterprise >> operates" to cover both;-) >=20 >=20 > Updated, thanks for the text. >> >> >> - 4.1.1: "These functions are critical to security and fraud >> monitoring." I don't accept that this is true of all the >> numbered elements in the list. Supposed countermeasures for >> IP leakage for example are often ineffective (though vendors >> who sell such things will doubtless disagree;-). I'd say >> toning that down a bit would be right, e.g. s/are criticial/ >> are often consided important/. >=20 >=20 > Hmm, in reading this contributed text, I would change it even more > than what you are suggesting. The functions aren't critical to > monitoring, but rather detecting these functions are important to > effective monitoring and mitigation of malicious traffic that is not > limited to malware. How about: >=20 > OLD: > A significant portion of malware hides its activity within > TLS or other encrypted protocols. This includes lateral movem= ent, > Command and Control, and Data Exfiltration. These functions a= re > critical to security and fraud monitoring. > NEW: > A significant portion of malware hides its activity within > TLS or other encrypted protocols. This includes lateral movem= ent, > Command and Control, and Data Exfiltration. Detecting these > functions are important to effective monitoring and mitigatio= n of > malicious traffic, not limited to malware. >=20 >> >> - 4.1.2: Mention of PDM reminds me that that has had a pretty >> thorough discussion related to the secdir review and issues >> relevant to this draft. Incorporating a description of that >> history would maybe be useful so that we have less pain when >> we re-do that in future for other protocols. >=20 >=20 > * Will have to go back to this as I'm not recalling this off hand and > will have to review the discussion. Most of it was between Tero and Nalini so maybe one of them can summarise the issues, which were quite relevant for this. OTOH, that might be too much work to get to text that fairly covers both aspects (unless there's stuff that can be just copied from the discussion or the pdm draft). >=20 >> >> >> - 4.1.3: I don't accept "impossible" is correct. If we wanted >> to say that, we'd need evidence, e.g. via a set of >> references. "More onerous" would be fine if that's all we >> need to say. A number of other similar changes are needed for >> the text in 4.1.3.x as well, e.g.: >=20 >=20 > The problem here (IMO) is that vendors need to step up their logging > game.=20 If stepping up their logging game is enough then we agree that "impossible" is wrong:-) > Many of the errors could be seen if logs better identified > issues that I have been shown or that we've seen in presentations from > enterprise representatives in the IETF. From their perspective, the > problem seems insurmountable as they don't know how they will contact > and so many vendors to increase logging and they no longer have > visibility into packet streams to detect even simple issues like > incorrect passwords.. I think we need to help (and are trying to do > so) in standards documentation calling for logging of errors. >=20 > The sentence is limited to finding things in network traces, so with > encryption, they are right... they need other methods like log > analysis. We need to ack the problems in this draft, so how about > adding this sentence instead of changing the last one: >=20 > Alternate methods, such as log analysis need > improvement to fill this gap. That's a fine addition, but "impossible" remains incorrect. >> >> >> - 4.1.3.1: "requires" is overstated, and what evidence is >> there for "frequently used"? I don't accept either assertion >> without evidence. >=20 >=20 > Hmm, my read of this part of the NAT section is that they use > identifier information to trace traffic, which is normal. Up to this > point in the text, I am reading it in a way that they can do this > through logs. I have more of an issue with the following paragraphs. > Requires just means that if they are going to follow a trace, they > need some identifiers to do so - 2-tuples, 5-tuples and how they > change (logs) through a device that performs NAT. >=20 > I propose changing this instead: > OLD: > Combine this with the fact that users are often allocated > randomly by load balancers to all these devices, the networ= k > troubleshooter is often left with no option in today's envi= ronment > except to trace all packets at a particular layer, decrypt = them > all, and look at the payload to find a user session. > NEW: > Combine this with the fact that users are often allocated > randomly by load balancers to all these devices, the networ= k > troubleshooter is often left with very few options in today= 's > environment due to poor logging implementations in applicat= ions. > As such, network troubleshooting is used to trace packets a= t a > particular layer, decrypt them, and look at the payload to = find a > user session. >=20 > and > OLD: > Endpoints > typically don't have the capacity to handle this level of network= > packet capture, so out-of-band networks of robust packet brokers = and > network sniffers that depend on static RSA private keys accomplis= h > this task today. >=20 > NEW: >=20 > Endpoints typically don't have the capacity to handle > this level of network packet capture, so out-of-band networks of > robust packet brokers and network sniffers that use techniques su= ch > as copies of TLS RSA private keys accomplish this task today. >> >> >> - 4.1.3.x: there are more of the above that need fixing >=20 > **Additional cleanup, but I'm making a leap that the logs for this are > inadequate, so this needs to be confirmed. > OLD: > When TCP Pipelining/Session Multiplexing is used, usually b= y > Middle boxes today, multiple end user sessions share the sa= me TCP > connection. Today's network troubleshooter often relies upo= n > session decryption to tell which packet belongs to which en= d > user. > NEW: > TCP Pipelining/Session Multiplexing used mainly by middle b= oxes > today allow for multiple end user sessions to share the sam= e TCP > connection. Today's network troubleshooter often relies upo= n > session decryption to tell which packet belongs to which en= d > user as the logs are currently inadequate for the analysis > needed. >=20 > In HTTP Service Call subsection... > OLD: > It must > be possible to match up the user request above with the HTT= P > service call below. Today, this is done by decrypting the T= LS > packet and inspecting the payload. > NEW: > Troubleshooting via network trace involves matching up the = user > request with the HTTP service call. Some organizations do t= his > today by decrypting the TLS packet and inspecting the paylo= ad. > Logging has not been adequate for their purposes. >=20 > ** Again making the leap that logging has not been adequate for their > purposes and the IETF should be able to help with that in HTTP > standards documentation. >=20 > **I am finding I need to replace the text in 4.1.3.4 and this will > need to be reviewed by the contributor. >=20 > OLD: > Modern applications often use XML structures in the payload of the > data to store application level information. When the network and > application teams must work together, each has a different view of > the transaction failure. It is important to be able to correlate th= e > network packet with the actual problem experienced by an application= =2E > NEW: > Many applications use text formats such as XML to transport= > data or application level information. When transaction fai= lures > occur and the logs are inadequate to determine the cause, n= etwork > and application teams work together, each having a differen= t > view of the transaction failure. Using this troubleshooting= > method, the network packet is correlated with the actual pr= oblem > experienced by an application to find a root cause. The > inability to access the payload prevents this method of > troubleshooting. >=20 > - removed 'modern' as other formats have taken over. >=20 >> >> - 4.2, 2nd para: A lot of this is duplicative of earlier >> text. >=20 > 1st paragraph - I think the following needs to be tweaked too. > OLD: > In some cases, alternate options are available when > encryption is in use, but techniques like that of data leakage > prevention tools at a proxy would not be possible if encrypted = traffic > can not be intercepted, thus creating a gap and encouraging alt= ernate > options. > NEW: > In some cases, alternate options are available when > encryption is in use, but techniques like that of data leakage > prevention tools at a proxy would not be possible if encrypted = traffic > can not be intercepted, encouraging alternate options such as > performing these functions at the edge. >> >> - 4.2: "unique and efficient vantage point" that's sales >> language and doesn't belong here. >=20 > Removed. >=20 >> >> - 5.1: "TLS over SMTP" again a couple of times >=20 > Ha. fixed. >=20 >> >> - 5.2: Is I-D.teague.. the right reference here? I'd have >> thought there was an ipfix RFC already that'd be good here. >=20 > This was DOTS and they haven't published anything yet. I removed the > reference as it hasn't been adopted yet and just referred to the WG as > that will have lots more information in time. >=20 >> >> - 5.6: "has quickly reacted to" is sales language and doesn't >> belong. >=20 > Removed quickly. Would need to rework the text to change it more. >=20 >> >> - 5.6: What is "[not BCP84]" as a reference? And I'm not sure >> why RFC2504 is a good reference here either. Are we talking >> about BCP38 but someone forgot to update text written from >> memory or something? :-) >=20 > RFC2827 is BCP 38, so I don't know what was meant by the [not BCP84]. > I am guessing the contributor did want both referenced, but I'll > remove the not BCP84 as that's confusing. >=20 >> >> - 5.6: SAVI was only chartered for enterprise networks iirc. >> >> - 5.7: THe [SACM] reference is odd and has no entry in >> section 12. >=20 > I don't think it's odd as it should help. >=20 >> >> - 6.1: Are those "notable exceptions" still relevant? I'd say >> maybe not. >=20 > Deleted that sentence, thanks. >=20 >> >> - 6.1: Is the Alt-SVC description correct? I'm not sure. I >> suggest you ask an HTTP person maybe. That could also do with >> some references. >=20 > *Will have to come back to this one. >> >> - 6.1: "... to be blocked" makes some assumptions about >> what's ok/right that are not needed, "being requested" would >> be better. >=20 > I'm deleting the ending clause all together as I think that's clearer > and adding "being requested" isn't the intent. >> >> - section 7: "efforts to prevent it" - which it? And I don't >> think prevent is what you mean, unless you're moving into the >> "what the spooks want" territory and away from "what network >> managers need" which'd seem out of scope. I think that needs >> rephrasing. >=20 > Just deleting the first sentence clears this up as the other 2 > sentences cover what was intended well enough. >=20 >> >> - section 7: "National surveillance programs" is not the >> right phrase. Maybe just "Law enforcement agencies..." >=20 > *Hmm, let's come back to this one. I'm not sure LEA is right as it's > not the same as a government surveillance program. >=20 >> >> - 7: please drop the various uses of "cyber" again;-) > Done. Agreed. >=20 >> >> - 7: David Cameron seems to no longer act in that role. >=20 > removed. Cameron certainly was removed:-) >> >> - 7: "avoid the fears of terrorism" is wrong - fears will >> exiat and be propogated by various actors regardless. And >> understanding technology won't help there. I think the fear >> you mean is that technolgoy will be abused by bad actors. >=20 > Changed that part of the first paragraph to address a few of your comme= nts: >=20 > NEW: > Governments vary on their > balance between their need for monitoring versus the protection > of user privacy, data, and assets. Those that favor unencrypted > access to data ignore the real need to protect users > identity, financial transactions and intellectual property, which= > requires security and encryption to prevent crime. A clear > understanding of technology, encryption, and monitoring needs wil= l aid > in the development of solutions to appropriately balance the need= of > privacy. As this understanding increases, hopefully the discussio= ns > will improve and this draft is meant to help further the discussi= on. >> >> - 7: The text seems to assume that all governments are >> equally ok and that they all like one another equally. I don't >> believe that is the case, so there are additional categories >> of bad actor that are missing here. I also find the frequency >> of the occurrence of "terror" to be higher than needed. (That >> is a scare-word best omitted when not needed.) >=20 > It's there once now as that is the motivator for many of the > surveillance programs. >> >> - 7: I think a reference to the workshop held in Wash. DC >> last year (maybe June?) on whether or not magic solutions for >> LEAs can exist here may be useful. Some IETFers attended, and >> it covered these issues in a lot more depth than could be >> fitted here but I don't have the reference to hand. (Spoiler: >> there is no magic;-) >=20 > We are open to contributions! >=20 >> >> - 7, last para; I'd recommend deleting this. When and if PIR >> methods are usable they will create as many issues as the >> solve, from the perspective of this document. >=20 > I made it less optimistic. I think if left out, it would become a > talking point that could detract from the purpose of this document. > I'd like it to be clear that this was thought about, but isn't > practical. >=20 >> >> - section 11: Is this useful? If not, it ought be deleted. >> If so, then it should be a section of its own on mobile >> networks and not an appendix. (I'll comment assuming that >> keeping the text is better, but I'm not sure it is, given the >> amount of context it may need.) >> >> - 11.1: What is an ACK stream? A reference or description is >> needed. "Prevents" needs justification (possibly via >> reference) >> >> - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM >> needs describing or a reference. What is a "sector"? And (in >> this context) what is "a server"? APN needs a reference. >> >> - 11.1: "trusted parties" is unclear - you need to say what >> is trusted by whom for what actions for this to be useful. >> >> - 11.1: DRM/QOE need expansion and a reference to justify the >> claim wrt *maximising* QOE. >> >> - 11.1: "Trusted proxy" - see above wrt term trusted. But in >> this case, the term is misleading and ought not be used as >> there seems to be no way in which the entity who needs to >> trust the proxy can know that that proxy exists. Please drop >> that term entirely. (Call it a TLS-MitM attacker if you must, >> as that is what it is and that is how such things were >> referred to earlier in this document.) There are two >> occurrences of that misldeading marketing term to remove. >> >> - 11.1: RAN needs expansion and "RAN-aware pacing" needs >> explanation and/or reference. >> >> - 11.2: What is meant here by "Transport header"? TCP mostly >> doesn't have this issue, so I assume this is looking forward >> to QUIC. I'd argue that if so, this text should be deleted as >> we now have a WG for QUIC which is specifically chartered to >> address these issues. If this is not about QUIC, then please >> elaborate. >> >> - 11.2: ANDSF needs a reference >> >> - 11.2: SON and MLB need references >> >> - 11.2: UPCON needs a reference, off-peak acceleration and >> outbound roamers need explanation and/or reference >> >> - 11.2: DSCP needs a reference >> >> - 11.3: RCS, QCI, LTE need rererences >> >> - 11.3: eMBMS needs a reference, see above wrt "trusted" >> >> - 11.3: Asserting that TLS is not necessary for DRM'd content >> is arguable and not blatently true, as asserted here. >> >> - 11.4: see above wrt "trusted." >> >> - 11.4: QAM, CS-Voice need references >> >> - 11.4: PGW, GGSN need references >> >> - 11.4; "GW" needs explanation and/or a reference >> >> - 11.4: "Decreasing Client-Server control loop requires >> deploying CDNs/Cloud functions that terminate encryption >> closer to the edge." I don't accept that "requires" is >> clearly true. Please justify e.g. via reference. Or maybe >> re-phrase so that the statement is clearly true but doesn't >> have gigantic implications for who is allowed to deploy what. >> (Or maybe I'm confused by what is meant here?) >> >> - 11.4: s/de-encryt/decrypt/ >> >> - 11.4: MEC needs a reference, see above wrt "trusted proxy" I guess we need to figure out what to do about section 11. >> >> - 12.1: I agree with the shepherd that all the references >> here can be informative and you don't need 2119. >=20 > Sure, that makes sense. It is an informative document. >=20 >> >> - 12.2: URLs like that used for CAIDA aren't great for RFCs - >> better to find a better reference where that's easy (which it >> is in that case). I'm less sure about how best to deal with >> the Intercept and EFF, but if you search in >> scholar.google.com you may find other references for that >> content that are easier to use. (The issue here being >> reference stability.) >=20 > *Yes, I'll have to follow up on this one, but have the URLs in the > current version. Al and I both knew we would have to fix this later > and should have done it prior to AD review. >=20 >> >> - 12.2: [homomophic] needs a better reference if it stays, >> e.g. Gentry's PhD or something. >=20 > * Yes, I'll find something. >> >> - 12.2: various references need to be updated. I-D nits will >> help you there >=20 > *Yes, I thin there is just one id left and it's actually in my queue > ahead of this document. >> >> - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-) >=20 > *Yes, will fix. >> >> >> >=20 > Thanks so much for your review. Anything with a * is one that either > needs my attention, that of a contributor, or my co-author to go back > and look at. >=20 --------------ms010007000708040102090604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjUy MjAwMDZaMC8GCSqGSIb3DQEJBDEiBCCsB8IJd43lbnP4J2X4wi2HtNhBLvfijAbUpmfQU79r 7DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQApqpxD81xpVtdajcRSNUGSwY5Fb29gdErRGlml6ESO95yNUJIp/+9U Asfq0x+5fxlOqf4a7ABJYjyRkF9z2xy/8R/vdUm6/gvWv/F+cwYd/N/smDp2sdUr9M6r+k7k BvgaMRvkxOfrvtmVnLaoMPJ1SwWlETIMsDhv0uA1o62A5V9nrUCouB0STJn9ju8/mIsVuaJR YncTLKM4WCk04GSjCRdKepfEq137hUhtJEVN08HDJ3F1HxFwCvwTL91RcB4LSlL1p1HMstPq IARjGveho1T0sQUu+SuYNjg2Ab3jPSuexNPfcqi+A8nENKM7/9P/GQhXZqNTIom/etA89qqf AAAAAAAA --------------ms010007000708040102090604-- From nobody Wed Jan 25 18:55:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18C212944B for ; Wed, 25 Jan 2017 18:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M1mAPzsrddsa for ; Wed, 25 Jan 2017 18:55:37 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2F4129430 for ; Wed, 25 Jan 2017 18:55:37 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id v23so52824803qtb.0 for ; Wed, 25 Jan 2017 18:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RaDNwlMKcDxJuzSqSe8AbS1HfM9AX62icZv4irKQ0I8=; b=kqNos2EsgGnTDAP5b/Gx3ciqnJiCpvq2t10StFB0oVgnlZQ5ZIiTfro5iAZc+FFe1/ kqD6RT4/3KOqrjKO1O/UinYhWW8jOwpJLegO6ofJl5bS0bZbS2ucl7Mw179T3pDnrB11 nMdeLG4QNUrSZQXvIp6/wxEl/iTN4XeguX5TcpKuEdsCV+KTfTEvDA20dOT1TfhmUPOL KOLpn2PrbLmmJgQukFE/6VrXJ3EvSzYgUTbFYFU0xHda72UadbfW6NQ63aqQILjhY45g H/OHip/uah4aXDDEEE93vJW9nBV+JLlYx7erxdzFAPY6Pp05zOWwpc+idFrKX8HD+rDD XVEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RaDNwlMKcDxJuzSqSe8AbS1HfM9AX62icZv4irKQ0I8=; b=o9OURg6nMEPuxgh1IzFCPq0OxjRtI5MG/U7IN7NfkMqSMH3zYbZRwH6bYnyGTJtlSE YhsNQoH8d4xk1WUnetvzSzR/17V5F+tamSir7EyOFYEj6s/QskivvhIjYO/DX74xDIXd b5tKURHmeKugO3W33aa4+zt5rw3tUhEDC0vQIQ85PIzXY7QU+2xWUoyVvT/129OBpWnQ eIh7mGp6d5AvMaWla/bLT8wRaPBdPkGMa5pRMMY2431lBOwuGi8QAoyibFsyDqOTP8t8 yuQhYDgH/MnvHKdzaWBLIGmTcgWrR6C7gVTKAYW64Di5EbMKNUek8skZ0+cM1eGhOfhP hUMQ== X-Gm-Message-State: AIkVDXLujnuY6AW9litLW0RqQMUNtQQySH7tr4Gqr/EMN+02b5+oDJxt5UnrmiMXk4u+vmPIUK36M7GgxdxLzw== X-Received: by 10.55.81.194 with SMTP id f185mr506186qkb.153.1485399335356; Wed, 25 Jan 2017 18:55:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Wed, 25 Jan 2017 18:55:34 -0800 (PST) In-Reply-To: <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie> <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie> <92fa2af5-91ca-8da3-d268-adcd2846af25@cs.tcd.ie> From: Kathleen Moriarty Date: Wed, 25 Jan 2017 21:55:34 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" , Al Morton Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 02:55:40 -0000 Hi Stephen, Thanks again, I'll post a new version shortly and may have addressed some of your comments already, but wasn't clear enough in my response last time, so I'll try to rectify that and you can take a look at the uploaded document once I may sure the XML is as expected. inline. On Wed, Jan 25, 2017 at 5:00 PM, Stephen Farrell wrote: > > Hiya, > > Mostly grand. A few responses inline. I'd say whack out a > rev whenever you're ready and we can go from there. There > is one remaining thing below I'd like to bottom out before > starting IETF LC which is what to do about section 11 - if > we're keeping it then it needs work - that'd be easy enough > for someone familiar with the mobile n/w stuff (as it's > mostly clarifying or referencing) but a good bit of work > for others maybe. > > Other than section 11, any remaining comments of mine should > be fine to be handled as IETF LC comments I figure. > > Cheers, > S. > > On 25/01/17 19:33, Kathleen Moriarty wrote: >> Hi Stephen, >> >> First, thank you for your detailed review, this is very helpful to >> improve the document. Al's on vacation, so I will respond in-line for >> us and take the blame later if needed :-) >> >> On Sun, Jan 22, 2017 at 3:42 PM, Stephen Farrell >> wrote: >>> >>> >>> Hi again, >>> >>> First, thanks to Paul Hoffman for being willing to be the >>> document shepherd for this. And to the authors for what >>> will be a fine RFC when it's done. >> >> >> Thank you, Paul! >>> >>> >>> Second, I've done my AD review of this and there are a set >>> of things that need fixing before we'll be ready for IETF >>> last call. At minimum there are still a few placeholder >>> sections of text (2.3,2.3.1,3.2,2), but I also have many >>> comments that cumulatively raise to the level where we >>> should address a bunch of those before IETF LC, even >>> though many (but not all) of my comments are relatively >>> nitty. I think that almost all of those should be pretty >>> easy to resolve, so we should still be able to get this >>> done before IETF98 I hope. >>> >>> My AD review is below. >>> >>> Cheers, >>> S. > > For clarity: where I don't respond I'm fine with your response. Thanks. > >>> >>> general: I wonder if we're dealing with all possible effects >>> or only with those relevant to network management, security >>> ad privacy? For example, more encryption does prevent some >>> advertising insertion, but whether or not that is in scope >>> here is unclear to me. Should it be? >> >> >> I'd constrain it a little further to what we and others contributed. >> We certainly could have missed some items in network management, >> operation, security and privacy. I'll look at the introduction to see >> if the text can make it more clear on what the document covers. >> >> We encouraged the security and operator communities to contribute as >> best we could. >> >>> >>> - title: I wonder would "Effects of Much More Common >>> Encryption" be a better title? Ubiquitous is never actually >>> going to happen, nor is it required for many of the effects >>> to be seen. (And there is defo. >1 effect to be seen.) Or, >>> you could keep the title, but explain in the text that you >>> really mean "much more common." Ben Kaduk suggests, "Effects of Pervasive Encryption", which sounds good to me. Agreed? >> >> >> Let me think on this a bit to see if I can come up with an another >> title or we'll just note exactly what is meant in the introduction as >> suggested. >> >>> >>> >>> - abstract: "solve these problems" is a tad one-sided in that >>> it doesn't recognise the valid reasons for more >>> confidentiality. I think it's important that the abstract >>> recognise that we're here documenting one set of consequences >>> of what is a valid set of trade-offs and not describing a set >>> of problems caused for no good reason. I think that it's >>> important to set the right tone early for this one - if we >>> don't then some readers who want better privacy may be more >>> likely to be dismissive, which'd be a shame. >> >> >> How about, >> "This draft seeks only to record the current state to assist in the >> development of alternate options to achieve the intended purpose of the >> documented practices. >> >>> >>> - abstract: "will impact" is maybe no longer the correct >>> tense - we've seen some of these impacts already I think, so >>> maybe "are impacting" or just "impact" is better? >> >> >> I think just impacts works, thanks. >> >>> >>> >>> - abstract: "more drastic" seems unfounded - what do you >>> really want to say there? >> >> >> This is thinking from the operators perspective. I do think this is >> drastic for some and that we should recognize the large change in >> their world. Do you have another suggestion that conveys this >> understanding? Bringing both sides of this together is really the >> goal. > > Perhaps s/In more drastic circumstances/In the limit/ and > s/may be/could be/? I'll change the first to, "in other cases", which should get at your point. I changed may to could, I don't see any issue with that. Thanks. > >> >>> >>> >>> - intro: I'm not sure "primarily a passive attack" is right. >>> Maybe easiest to just delete that clause as I don't think >>> it's needed here. You could add a reference to RFC7624 for >>> those who'd like more detail. >> >> >> Sure there can be active attacks that lead to pervasive monitoring, >> and I'm fine with that change. >> >>> >>> >>> - intro, 2nd para: I'm not sure what you mean referring to >>> "many attackers"? That sentence doesn't seem to make sense >>> as-is. >>> >> >> Thanks, I see what you mean. The text isn't as straightforward as it >> could be. I think we were avoiding saying terrorists, but should just >> said bad actors. >> >> Old: >> Many attackers and those >> that pose a greater threat are already using strong encryption and tools >> like TOR to prevent active attacks on their data >> streams >> New: >> Bad actors, for example criminals or terrorists, could easily >> employ the use of strong encryption with tools like TOR > target="TOR"/> to prevent active attacks on their data streams, which >> are possible with OS. > > I still think that's out of context. Maybe mention it elsewhere? I read the proceeding and following sections again and combined the first sentence of this same paragraph into the previous paragraph. The point is kinda made already, so I'll let this sentence get dropped. That lets us drop the TOR reference too. > >> >>> >>> - intro: the UTA document references need to be updated >> >> >> Done, thanks. >> >>> >>> >>> - intro: the 30% figure is probably out of date, please check >>> again (or add a date as done with the others). >> >> >> Changed to spring 2015. Will try to get a new figure if possible. >> >>> >>> >>> - intro: "for corporate users" would be better removed - we >>> care as much about non-corporate users after all >> >> >> Hmm, this is referring to the statistic for encrypted content, which >> was specific to corporate users. While we may care about non-corporate >> users more, this is an easier statistic to get since they are behind a >> firewall and corporate network used to gather this statistic. >> Non-corporate users might result in a different statistic, so I'd >> prefer to leave this as-is. > > Still not clear to me that this is correct as stated, but > not a huge deal. > >> >>> >>> - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP" >> >> >> Odd, thanks for catching this. >> >>> >>> - intro: "Although this does provide..." - that sentence >>> isn't right, passive is not the opposite of e2e, I think you >>> want s/passive wiretapping/transport layer attacks/ >> >> >> Updated, thanks. >>> >>> >>> - intro: You mention OTR, but the cooler kids these days use >>> signal/telegram (though I don't for platform reasons;-). >>> Might be worth checking out what to say about those, or just >>> say "e.g. OTR" instead of making it seem like OTR is the only >>> way to do IM e2e. >> >> >> Hmm, signal seems to be for SMS on Andriod only... or does it have a >> wider reach? If so, I'd rather not mention that. Telegram seems to >> be an app that relies on SMS and it's own messaging format, so it >> doesn't provide encryption for XMPP. If I add this, I'd have to add >> other messaging apps as well. I think it's fine to leave as-is with >> standards mentioned only. > > Problem is, OTR is not a standard, same as the rest. "e.g. OTR" is > maybe the way to do it. Right, I was referring to XMPP as the standard in this response. I changed to encryption (e.g. OTR) for XMPP. > >> https://en.wikipedia.org/wiki/Telegram_(software) >> >>> >>> >>> - intro, 2nd last para: that one is very good >> >> >> Thanks :-) It's the goal of the draft. >>> >>> >>> - intro, last para: you don't mention enterprise networks >>> here, worth a mention? >> >> >> *Hmm, let me think about that a bit and we can come back to this one. >> >>> >>> >>> - section 2, 2nd para: I think you could do with a forward >>> reference or example to the "opterational practices that >>> require cleartext" or maybe better is to s/require/previously >>> depended on/ >> >> >> Took your suggested text, thanks. >> >>> >>> >>> - 2: "TLS over SMTP" - backwards again >> >> >> Odd. Fixed, thanks. >>> >>> >>> - 2: "The EFF reported..." that needs a reference >> >> added informative >> https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks >>> >>> >>> - 2: I'm not at all sure encryption "prevents" load >>> balancing, in fact I'm pretty sure it does not prevent that >> >> >> This was on the content. Would you prefer to see it reworded/expanded? > > Yeah, I think saying prevents is just wrong. Encrypting does > prevent some methods of load-balancing from working but not > all methods. Ditto for other features that get changed. I do > think it's important to not overstate the effects, just as > it is to not understate them. OK, how about if the wording is changed to: The use of encryption prevents middle boxes from performing functions that range from some methods of load balancing to monitoring for attacks or enabling "lawful intercept", such that described in... > >> >>> >>> >>> - 2: "on the decline now that they are exposed through the >>> media" - I think it'd be better to remove that sentence - it >>> doesn't add much and there are more details better described >>> later I'm sure. >> >> >> I cut out the first part, leaving the explanation... >>> >>> >>> - 2.1: this sections seems mixed between middleboxes and >>> mobile, probably as a result of iterative editing. Not sure >>> how best to fix. >> >> Sure, the first part mixes multiple ways fingerprinting is used and >> one is not middle boxes at all, but I'm not sure I want to separate >> that out and make the document longer... but if needed we can. >> >> *For the rest of the section, we are running into the many contributor >> problem and it's not clear how to make this better, but I'll think >> about it more. >> >>> >>> >>> - 2.1, last para: Is that really a middlebox function? I >>> thought most of the examples given were cases of end systems >>> (web servers) impinging on privacy and not middleboxes (and >>> the naughty web servers are not affected by encryption so >>> aren't really in scope) >> >> >> *No, same as the last part of the subsection on fingerprint analysis. >> We could remove it or break it out into another section. If we break >> it out into another section, the content may feel repetitive. >>> >>> >>> - 2.1.3: I don't think DPI aims to improve "features and >>> efficiency" >> >> >> That was an operator's perspective. Somehow we need to have both a >> security and operators perspective seen so we can help each other. >> The sentence says they are augmented, not improved, is there really an >> issue keeping this text? >> >>> >>> >>> - 2.1.3: "must be known" is overstated - again I think we >>> want to always phrase it as "has previously been assumed to >>> be required" or similar >> >> >> This was contributed text, so the functions they were performing, in >> the way they were being performed, might require the the traffic type >> to be known. I agree the text around this does not make that clear. I >> am hesitant to change the intended meaning without what seems like the >> additional context needed. >> >> How about, "has been required to date". I'd really like to respect >> the operators views and have them documented as they see it. > > I don't think adding the caveats that are needed has anything > to do with respect. When we've been doing a thing one way for > ages, there's a natural tendency to not consider that there > were also other ways to crack the nut;-) > > The key point here and in many places is I think to ack that > encryption does affect what has been done to date, and will > force us to find other ways to meet the same goals. But in > most cases, there will be other ways available, which means > that "required" (or "must be known") isn't correct for those > features. (In this case, it could be that any measure that > distinguishes video from other things would be good enough > for many situations for example and that doesn't require > plaintext.) I think there will be cases where the goal can't be met. Things will change as a result and new solutions will evolve (that may be better), but the same goal won't always be met. > >> >>> >>> - 2.1.4: I think compression could (and maybe should) be >>> separated out - one of the things CRIME has shown us is that >>> we had more to learn about how to combine compression and >>> encryption. I also think most compression is not done/undone >>> at middleboxes, nor does it relate to monitoring so >>> compression doesn't seem to fit well in 2.1. (Transcoding >>> however might fit in some middlebox section, but is not >>> compression.) >> >> >> OK, I see your perspective, but will try to shed light on the context >> of this section. This was contributed from GSMA. They have been >> using compression in this way and see a change in operations as a >> result of the use of encryption on the wire. I believe it is used in >> gateway situations from previous discussions. The point in this >> section is to note the practice and that encryption presents a problem >> for this operational practice. It's not suggesting encryption with >> compression as a solution, rather saying that some operators may >> resort to attempts to prevent/break encryption to allow for the >> compression they see as necessary to deliver services. It's going to >> break/is breaking and this just acks that point. > > Isn't that usually transcoding and not compression? *We should get the GSMA folks to answer this one. I could be wrong in my example, they may have uses if compression where they have not combined it with encryption in the past that better explain this text. > >> >>> >>> >>> - 2.1.5: s/law agencies/law enforcement agencies/ is the >>> usual term, and LEAs are not the only entities that insist on >>> this kind of thing - considering censorship. >> >> updated, thanks. >>> >>> >>> - 2.1.5: "sites promoting anorexia" seems like an odd >>> example, but I think in any case it'd be better to generalise >>> the examples a bit >> >> >> Deleted that text. >> >>> >>> >>> - 2.1.5: DNS queries do not "reveal" URLs. And the described >>> mechanism seems quite odd. >>> >> >> Sure, looks like some flowery language inaccurately describing what >> was intended. I changed it to the following: >> >> Although filtering can be >> done by many methods one common method occurs when a DNS lookup >> of a hostname in a URL which appears on a government or recognized >> block-list. >> >>> - 2.1.5: The 3rd last para about "TLS proxies" and "future >>> versions of HTTP and TCP" is not clear to me. Is that really >>> needed? >> >> >> Hmm, I'm guessing this was referring to TCPInc work, but I think >> deleting the paragraph should be fine (scream now if you were the >> contributor and disagree) since the text concludes with a statement >> that this is not the case and has not been standardized. >> >>> >>> >>> - 2.1.5: Parental controls might deserve it's own subsection >>> - it differs in that the endopints are involved, which I >>> think means that the effects of e.g. TLS on the changes >>> required to the service are different from cases where an >>> external party (govt/SP/whoever) imposes the filtering. >> >> >> Done as a subsection of this section for now. Thanks. >> >>> >>> >>> - 2.1.6.3: I think you need a reference to RFC2804 here. The >>> IETF does not to LI in standards, for the (good) reasons >>> stated therin. So this may be a case where the effects of >>> crypto do enhance existing IETF policy but also counter >>> existing policies of other entities. But we should not ignore >>> the former (IETF) policy - we ought not claim here that one >>> or the other are better, but just ack the tussle. >> >> >> Done, thanks. >>> >>> >>> - 2.1.6.4: MTAs do trypically have cleartext access, so what >>> kind of spam/malware filtering do you mean there? How does >>> that relate to the mail architecture? (There's an RFC for >>> that that ought be ref'd.) If section 5 does cover this well, >>> then I'd say removing this section would be good as it add >>> nothing much that I can see. >> >> >> Deleted. >>> >>> >>> - 2.2: Do we have evidence that the decrease of measurement >>> accuracy has actually lead to a decrease in repair >>> efficiency? I'm not convinced - it doesn't seem like a crazy >>> proposition, but nor does it seem like a tautology. (What >>> metric for efficiency of repair is there that could be mapped >>> to visibility of different protocol layers?) >> >> >> *This is from Al (I believe), so I suspect it is backed up from >> operational testing. > > Consider a request for more info (via ref is fine) as a LC > comment. *Great. > >> >>> >>> - 2.2, 2nd para: This is repetitive. Making the point once is >>> enough. >> >> >> Hmm, I deleted the last sentence, but think the example may be helpful >> within the operator community. >> >>> >>> >>> - 2.3 and 2.3.1: What is the intent here? These sections seem >>> to be content free. Looks like a placeholder that never got >>> filled in? (Not unreasonable as it's hard to see real >>> downsides to encryption of inter-DC traffic.) These need to >>> be fixed or deleted. Probably deleted is better. (Certainly >>> easier.) That needs fixing before IETF LC. >> >> >> Yes, deleted. >> >>> >>> >>> 3.1.1, 1st para: I'm not clear how session monitoring of >>> cleartext is needed for SLA evaluation. Maybe an example of >>> some specific thing needed would helpa but I'm not seeing an >>> input to SLA evaluation here. (I do see how logs can be >>> useful there.) >> >> >> I can't figure it out either, but changed the text to: >> >> The use of session encryption to access hosted >> environments limits access restrictions to the metadata >> described below. >> >> It goes on to describe 2-tuples and 5-tuples below. >> >>> >>> 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some >>> of thie text relates to the marnew w/s, it ought only specify >>> mobile clients where those are specifically relevant, an in >>> this case, and others, they're not. >> >> >> Done here and I'll have to look elsewhere as well. >> >>> >>> >>> 3.1.2: "cyber-security" and "cyber-attack" please avoid >>> thosse ill-defined marketing terms unless you really need and >>> can justify them >> >> >> Agreed, changed to security. >> >>> >>> >>> 3.1.1: Is "malware explosion" a generally known term? I think >>> detection is sufficient and searing for "malware explosion" >>> doesn't turn up what I think you mean. (I'm guessing you mean >>> unzipping etc.) >> >> >> That may be what was meant, but I just deleted explosion for now. I >> think this came from Nalini and it must have slipped through my edit >> pass & Al's. If something else was intended here that is important, >> she can chime in. >> >>> >>> >>> 3.1.2, last para: I'm not clear how this para fits here or in >>> this document in general. Not sure if that's just me or if >>> some better linkage is needed, or even if the text would be >>> better moved or deleted. >> >> >> *Hmm, I see how this relates to SPs, but not to this subsection. I'm >> not sure of the contributor as it may be tied to application content, >> but you are right - this text doesn't flow and that is not clear from >> the paragraph, >> >>> >>> >>> 3.2.1: I'm not sure I agree with this, at least as stated. >>> Wouldn't passive monitoring of ciphertext be just as >>> effective for the SLA metrics mentioned in almost all cases? >> >> >> Hmm, so I'm trying to decipher the text as well. What I can surmise >> is that the impediments to performance and availability are the >> "interferences". Some things that interfere with traffic might be >> seen outside of 2-tuples and 5-tuples more easily. For the metrics >> themselves, I agree with you. However, they may know the cause of the >> "interference" with visibility into the traffic. >> >> Perhaps adding the sentence: >> >> "The actual SLA metrics may not be effected by >> encryption, however visibility of interferences may be limited." >> >>> >>> 3.2.2: "[Need descriptions for..." The rest of that para >>> seems like placeholder text that needs fixing before IETF LC. >> >> >> deleted this paragraph. The rest flowed well enough and this was a >> placeholder for contributions. >>> >>> >>> 3.2.2: I think it'd be worth saying somewhere here that >>> STARTTLS ought have zero effect on anti-SPAM etc. for SMTP >>> traffic but is only an issue in corner-cases for e.g. hosters >>> who want to scan outbound port 25 traffic in case their >>> cusomters have suffered breaches and start sending spam. (At >>> least that's my understanding.) PGP or S/MIME do of course. >> >> >> OK, consider yourself the contributor for the above removed paragraph. >> I edited the above slightly. >> >>> >>> 3.2.2: What header encryption efforts are meant here? I'm not >>> familiar with anything doing exactly that. Or maybe it's just >>> a phrasing issue? Or perhaps this text is a bit old and OBE? >>> (I mean that initial hopes that we initiate work to to >>> encrypt e.g. Subject seem to be currently moribund.) >> >> >> This is old from the list that we started a while back on the topic >> that I don't think went anywhere. I'll delete it, but think we should >> have something in there about some of the other efforts - just >> mentioning dark mail and proprietary solutions. >> >>> >>> 3.2.2: I'm not sure the bullet list here is a good idea. >>> E.g. it omits DKIM related things and SPF related things. >>> Maybe check with some anti-spam folks if keeping this list? >> >> >> I removed the whole section as it didn't make sense without the email >> header thing that has gone away... >> >>> >>> >>> 3.3: I wondered if this section would be better reorganised >>> into a structure based on where the keys are located. Not >>> sure but that might be a clearer way to distinguish the >>> various kinds of encrypted storage. (Feel free to ignore this >>> suggestion if it doesn't resonate.) >> >> >> Yeah, it's more complicated than that as even on similar platforms, >> the solutions can differ. If KMIP is used, then you have a standard t >> go off of, but that's not always the case. >> >>> >>> >>> 3.3.1: I found this sub-section confusing and not useful. >>> Would suggest simplifying it a lot. The term "burst data" >>> isn't that clear. >> >> >> Hmm, I removed the word burst, but essentially, you could have a burst >> of data of a certain size and the size could dictate where the burst >> of data is stored. The same application might have some data stored >> locally, then some off to an external service. I reworded to remove >> the word burst and explain it better. >> >>> >>> >>> - section 4: Is "for Enterprise Users" right here? >> >> No, it should probably just be enterprises. updating, thanks. >> >>> >>> >>> - 4: "harder to break" is not relevant here - at least in >>> terms of algorithms, which is what that'd be interpreted as >>> far as to mean. If you mean that non FS mechanisms (e.g. RSA >>> key transport) provide more opportunity for decryption at >>> places other than the endpoint at which the applications >>> calls for decryption, but that we increasingly do want to see >>> more use of FS mechanisns, and that that's a tension, then >>> maybe say that. >> >> >> I agree with you and deleted that clause. Later in the paragraph, I >> changed "need" to "desire". >> >>> >>> >>> - 4.1: Not sure "static" is quire right - I think what you >>> mean is replicated TLS server RSA private keys. >> >> >> Yes, updated. >>> >>> >>> - 4.1.1: "Enterprise users are subject to the policies of >>> their organization." That is jurisdiction-dependent - at >>> least in some countries (e.g. Ireland) the enterprise cannot >>> breach employment laws that can touch on employee privacy. >>> Such jurisdictional issues can work both ways of course, >>> either re-inforcing privacy or calling for privacy to be >>> eroded even more than the enterprise would wish. Suggest >>> adding "... and the jurisdictions in which the enterprise >>> operates" to cover both;-) >> >> >> Updated, thanks for the text. >>> >>> >>> - 4.1.1: "These functions are critical to security and fraud >>> monitoring." I don't accept that this is true of all the >>> numbered elements in the list. Supposed countermeasures for >>> IP leakage for example are often ineffective (though vendors >>> who sell such things will doubtless disagree;-). I'd say >>> toning that down a bit would be right, e.g. s/are criticial/ >>> are often consided important/. >> >> >> Hmm, in reading this contributed text, I would change it even more >> than what you are suggesting. The functions aren't critical to >> monitoring, but rather detecting these functions are important to >> effective monitoring and mitigation of malicious traffic that is not >> limited to malware. How about: >> >> OLD: >> A significant portion of malware hides its activity within >> TLS or other encrypted protocols. This includes lateral movement, >> Command and Control, and Data Exfiltration. These functions are >> critical to security and fraud monitoring. >> NEW: >> A significant portion of malware hides its activity within >> TLS or other encrypted protocols. This includes lateral movement, >> Command and Control, and Data Exfiltration. Detecting these >> functions are important to effective monitoring and mitigation of >> malicious traffic, not limited to malware. >> >>> >>> - 4.1.2: Mention of PDM reminds me that that has had a pretty >>> thorough discussion related to the secdir review and issues >>> relevant to this draft. Incorporating a description of that >>> history would maybe be useful so that we have less pain when >>> we re-do that in future for other protocols. >> >> >> * Will have to go back to this as I'm not recalling this off hand and >> will have to review the discussion. > > Most of it was between Tero and Nalini so maybe one of them > can summarise the issues, which were quite relevant for this. > OTOH, that might be too much work to get to text that fairly > covers both aspects (unless there's stuff that can be just > copied from the discussion or the pdm draft). *OK, we'll see if it helps or not. > >> >>> >>> >>> - 4.1.3: I don't accept "impossible" is correct. If we wanted >>> to say that, we'd need evidence, e.g. via a set of >>> references. "More onerous" would be fine if that's all we >>> need to say. A number of other similar changes are needed for >>> the text in 4.1.3.x as well, e.g.: >> >> >> The problem here (IMO) is that vendors need to step up their logging >> game. > > If stepping up their logging game is enough then we agree that > "impossible" is wrong:-) > >> Many of the errors could be seen if logs better identified >> issues that I have been shown or that we've seen in presentations from >> enterprise representatives in the IETF. From their perspective, the >> problem seems insurmountable as they don't know how they will contact >> and so many vendors to increase logging and they no longer have >> visibility into packet streams to detect even simple issues like >> incorrect passwords.. I think we need to help (and are trying to do >> so) in standards documentation calling for logging of errors. >> >> The sentence is limited to finding things in network traces, so with >> encryption, they are right... they need other methods like log >> analysis. We need to ack the problems in this draft, so how about >> adding this sentence instead of changing the last one: >> >> Alternate methods, such as log analysis need >> improvement to fill this gap. > > That's a fine addition, but "impossible" remains incorrect. OK, I read it again and changed impossible to difficult. > >>> >>> >>> - 4.1.3.1: "requires" is overstated, and what evidence is >>> there for "frequently used"? I don't accept either assertion >>> without evidence. >> >> >> Hmm, my read of this part of the NAT section is that they use >> identifier information to trace traffic, which is normal. Up to this >> point in the text, I am reading it in a way that they can do this >> through logs. I have more of an issue with the following paragraphs. >> Requires just means that if they are going to follow a trace, they >> need some identifiers to do so - 2-tuples, 5-tuples and how they >> change (logs) through a device that performs NAT. >> >> I propose changing this instead: >> OLD: >> Combine this with the fact that users are often allocated >> randomly by load balancers to all these devices, the network >> troubleshooter is often left with no option in today's environment >> except to trace all packets at a particular layer, decrypt them >> all, and look at the payload to find a user session. >> NEW: >> Combine this with the fact that users are often allocated >> randomly by load balancers to all these devices, the network >> troubleshooter is often left with very few options in today's >> environment due to poor logging implementations in applications. >> As such, network troubleshooting is used to trace packets at a >> particular layer, decrypt them, and look at the payload to find a >> user session. >> >> and >> OLD: >> Endpoints >> typically don't have the capacity to handle this level of network >> packet capture, so out-of-band networks of robust packet brokers and >> network sniffers that depend on static RSA private keys accomplish >> this task today. >> >> NEW: >> >> Endpoints typically don't have the capacity to handle >> this level of network packet capture, so out-of-band networks of >> robust packet brokers and network sniffers that use techniques such >> as copies of TLS RSA private keys accomplish this task today. >>> >>> >>> - 4.1.3.x: there are more of the above that need fixing >> >> **Additional cleanup, but I'm making a leap that the logs for this are >> inadequate, so this needs to be confirmed. >> OLD: >> When TCP Pipelining/Session Multiplexing is used, usually by >> Middle boxes today, multiple end user sessions share the same TCP >> connection. Today's network troubleshooter often relies upon >> session decryption to tell which packet belongs to which end >> user. >> NEW: >> TCP Pipelining/Session Multiplexing used mainly by middle boxes >> today allow for multiple end user sessions to share the same TCP >> connection. Today's network troubleshooter often relies upon >> session decryption to tell which packet belongs to which end >> user as the logs are currently inadequate for the analysis >> needed. >> >> In HTTP Service Call subsection... >> OLD: >> It must >> be possible to match up the user request above with the HTTP >> service call below. Today, this is done by decrypting the TLS >> packet and inspecting the payload. >> NEW: >> Troubleshooting via network trace involves matching up the user >> request with the HTTP service call. Some organizations do this >> today by decrypting the TLS packet and inspecting the payload. >> Logging has not been adequate for their purposes. >> >> ** Again making the leap that logging has not been adequate for their >> purposes and the IETF should be able to help with that in HTTP >> standards documentation. >> >> **I am finding I need to replace the text in 4.1.3.4 and this will >> need to be reviewed by the contributor. >> >> OLD: >> Modern applications often use XML structures in the payload of the >> data to store application level information. When the network and >> application teams must work together, each has a different view of >> the transaction failure. It is important to be able to correlate the >> network packet with the actual problem experienced by an application. >> NEW: >> Many applications use text formats such as XML to transport >> data or application level information. When transaction failures >> occur and the logs are inadequate to determine the cause, network >> and application teams work together, each having a different >> view of the transaction failure. Using this troubleshooting >> method, the network packet is correlated with the actual problem >> experienced by an application to find a root cause. The >> inability to access the payload prevents this method of >> troubleshooting. >> >> - removed 'modern' as other formats have taken over. >> >>> >>> - 4.2, 2nd para: A lot of this is duplicative of earlier >>> text. >> >> 1st paragraph - I think the following needs to be tweaked too. >> OLD: >> In some cases, alternate options are available when >> encryption is in use, but techniques like that of data leakage >> prevention tools at a proxy would not be possible if encrypted traffic >> can not be intercepted, thus creating a gap and encouraging alternate >> options. >> NEW: >> In some cases, alternate options are available when >> encryption is in use, but techniques like that of data leakage >> prevention tools at a proxy would not be possible if encrypted traffic >> can not be intercepted, encouraging alternate options such as >> performing these functions at the edge. >>> >>> - 4.2: "unique and efficient vantage point" that's sales >>> language and doesn't belong here. >> >> Removed. >> >>> >>> - 5.1: "TLS over SMTP" again a couple of times >> >> Ha. fixed. >> >>> >>> - 5.2: Is I-D.teague.. the right reference here? I'd have >>> thought there was an ipfix RFC already that'd be good here. >> >> This was DOTS and they haven't published anything yet. I removed the >> reference as it hasn't been adopted yet and just referred to the WG as >> that will have lots more information in time. >> >>> >>> - 5.6: "has quickly reacted to" is sales language and doesn't >>> belong. >> >> Removed quickly. Would need to rework the text to change it more. >> >>> >>> - 5.6: What is "[not BCP84]" as a reference? And I'm not sure >>> why RFC2504 is a good reference here either. Are we talking >>> about BCP38 but someone forgot to update text written from >>> memory or something? :-) >> >> RFC2827 is BCP 38, so I don't know what was meant by the [not BCP84]. >> I am guessing the contributor did want both referenced, but I'll >> remove the not BCP84 as that's confusing. >> >>> >>> - 5.6: SAVI was only chartered for enterprise networks iirc. >>> >>> - 5.7: THe [SACM] reference is odd and has no entry in >>> section 12. >> >> I don't think it's odd as it should help. >> >>> >>> - 6.1: Are those "notable exceptions" still relevant? I'd say >>> maybe not. >> >> Deleted that sentence, thanks. >> >>> >>> - 6.1: Is the Alt-SVC description correct? I'm not sure. I >>> suggest you ask an HTTP person maybe. That could also do with >>> some references. >> >> *Will have to come back to this one. >>> >>> - 6.1: "... to be blocked" makes some assumptions about >>> what's ok/right that are not needed, "being requested" would >>> be better. >> >> I'm deleting the ending clause all together as I think that's clearer >> and adding "being requested" isn't the intent. >>> >>> - section 7: "efforts to prevent it" - which it? And I don't >>> think prevent is what you mean, unless you're moving into the >>> "what the spooks want" territory and away from "what network >>> managers need" which'd seem out of scope. I think that needs >>> rephrasing. >> >> Just deleting the first sentence clears this up as the other 2 >> sentences cover what was intended well enough. >> >>> >>> - section 7: "National surveillance programs" is not the >>> right phrase. Maybe just "Law enforcement agencies..." >> >> *Hmm, let's come back to this one. I'm not sure LEA is right as it's >> not the same as a government surveillance program. >> >>> >>> - 7: please drop the various uses of "cyber" again;-) >> Done. Agreed. >> >>> >>> - 7: David Cameron seems to no longer act in that role. >> >> removed. > > Cameron certainly was removed:-) > >>> >>> - 7: "avoid the fears of terrorism" is wrong - fears will >>> exiat and be propogated by various actors regardless. And >>> understanding technology won't help there. I think the fear >>> you mean is that technolgoy will be abused by bad actors. >> >> Changed that part of the first paragraph to address a few of your comments: >> >> NEW: >> Governments vary on their >> balance between their need for monitoring versus the protection >> of user privacy, data, and assets. Those that favor unencrypted >> access to data ignore the real need to protect users >> identity, financial transactions and intellectual property, which >> requires security and encryption to prevent crime. A clear >> understanding of technology, encryption, and monitoring needs will aid >> in the development of solutions to appropriately balance the need of >> privacy. As this understanding increases, hopefully the discussions >> will improve and this draft is meant to help further the discussion. >>> >>> - 7: The text seems to assume that all governments are >>> equally ok and that they all like one another equally. I don't >>> believe that is the case, so there are additional categories >>> of bad actor that are missing here. I also find the frequency >>> of the occurrence of "terror" to be higher than needed. (That >>> is a scare-word best omitted when not needed.) >> >> It's there once now as that is the motivator for many of the >> surveillance programs. >>> >>> - 7: I think a reference to the workshop held in Wash. DC >>> last year (maybe June?) on whether or not magic solutions for >>> LEAs can exist here may be useful. Some IETFers attended, and >>> it covered these issues in a lot more depth than could be >>> fitted here but I don't have the reference to hand. (Spoiler: >>> there is no magic;-) >> >> We are open to contributions! >> >>> >>> - 7, last para; I'd recommend deleting this. When and if PIR >>> methods are usable they will create as many issues as the >>> solve, from the perspective of this document. >> >> I made it less optimistic. I think if left out, it would become a >> talking point that could detract from the purpose of this document. >> I'd like it to be clear that this was thought about, but isn't >> practical. >> >>> >>> - section 11: Is this useful? If not, it ought be deleted. >>> If so, then it should be a section of its own on mobile >>> networks and not an appendix. (I'll comment assuming that >>> keeping the text is better, but I'm not sure it is, given the >>> amount of context it may need.) >>> >>> - 11.1: What is an ACK stream? A reference or description is >>> needed. "Prevents" needs justification (possibly via >>> reference) >>> >>> - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM >>> needs describing or a reference. What is a "sector"? And (in >>> this context) what is "a server"? APN needs a reference. >>> >>> - 11.1: "trusted parties" is unclear - you need to say what >>> is trusted by whom for what actions for this to be useful. >>> >>> - 11.1: DRM/QOE need expansion and a reference to justify the >>> claim wrt *maximising* QOE. >>> >>> - 11.1: "Trusted proxy" - see above wrt term trusted. But in >>> this case, the term is misleading and ought not be used as >>> there seems to be no way in which the entity who needs to >>> trust the proxy can know that that proxy exists. Please drop >>> that term entirely. (Call it a TLS-MitM attacker if you must, >>> as that is what it is and that is how such things were >>> referred to earlier in this document.) There are two >>> occurrences of that misldeading marketing term to remove. >>> >>> - 11.1: RAN needs expansion and "RAN-aware pacing" needs >>> explanation and/or reference. >>> >>> - 11.2: What is meant here by "Transport header"? TCP mostly >>> doesn't have this issue, so I assume this is looking forward >>> to QUIC. I'd argue that if so, this text should be deleted as >>> we now have a WG for QUIC which is specifically chartered to >>> address these issues. If this is not about QUIC, then please >>> elaborate. >>> >>> - 11.2: ANDSF needs a reference >>> >>> - 11.2: SON and MLB need references >>> >>> - 11.2: UPCON needs a reference, off-peak acceleration and >>> outbound roamers need explanation and/or reference >>> >>> - 11.2: DSCP needs a reference >>> >>> - 11.3: RCS, QCI, LTE need rererences >>> >>> - 11.3: eMBMS needs a reference, see above wrt "trusted" >>> >>> - 11.3: Asserting that TLS is not necessary for DRM'd content >>> is arguable and not blatently true, as asserted here. >>> >>> - 11.4: see above wrt "trusted." >>> >>> - 11.4: QAM, CS-Voice need references >>> >>> - 11.4: PGW, GGSN need references >>> >>> - 11.4; "GW" needs explanation and/or a reference >>> >>> - 11.4: "Decreasing Client-Server control loop requires >>> deploying CDNs/Cloud functions that terminate encryption >>> closer to the edge." I don't accept that "requires" is >>> clearly true. Please justify e.g. via reference. Or maybe >>> re-phrase so that the statement is clearly true but doesn't >>> have gigantic implications for who is allowed to deploy what. >>> (Or maybe I'm confused by what is meant here?) >>> >>> - 11.4: s/de-encryt/decrypt/ >>> >>> - 11.4: MEC needs a reference, see above wrt "trusted proxy" > > I guess we need to figure out what to do about section 11. *Yes. > >>> >>> - 12.1: I agree with the shepherd that all the references >>> here can be informative and you don't need 2119. >> >> Sure, that makes sense. It is an informative document. >> >>> >>> - 12.2: URLs like that used for CAIDA aren't great for RFCs - >>> better to find a better reference where that's easy (which it >>> is in that case). I'm less sure about how best to deal with >>> the Intercept and EFF, but if you search in >>> scholar.google.com you may find other references for that >>> content that are easier to use. (The issue here being >>> reference stability.) >> >> *Yes, I'll have to follow up on this one, but have the URLs in the >> current version. Al and I both knew we would have to fix this later >> and should have done it prior to AD review. *This remains as an outstanding item for the next version. >> >>> >>> - 12.2: [homomophic] needs a better reference if it stays, >>> e.g. Gentry's PhD or something. >> >> * Yes, I'll find something. >>> >>> - 12.2: various references need to be updated. I-D nits will >>> help you there >> >> *Yes, I thin there is just one id left and it's actually in my queue >> ahead of this document. >>> >>> - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-) >> >> *Yes, will fix. Can remove it now :-) >>> >>> >>> >> >> Thanks so much for your review. Anything with a * is one that either >> needs my attention, that of a contributor, or my co-author to go back >> and look at. >> > -- Best regards, Kathleen