From nobody Mon Aug 10 19:02:03 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFD63A0EBE; Mon, 10 Aug 2020 19:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 30qNYDsTwdFu; Mon, 10 Aug 2020 19:02:00 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 BCB723A0EC2; Mon, 10 Aug 2020 19:02:00 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id w9so8389825qts.6; Mon, 10 Aug 2020 19:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=W5uaon0Y0pV9sa9EDulUh5O8TCMwjGoVjbu60tPjFLg=; b=uMPaief3JZDz6BIjAQwQyA11Xzf/S5CRfeysdYyl5g8w37o8jU5epKP6RB+4bzjtEl U+1c65NZMljItnovk96NPWTwQ6SwW/3v1xmNUi7TECyyVfO2yb7b2Ro8dnZEk5Ikbz9s c3S+ACxzMkpj9Hsiy+gq3irNbIq8Oim3J51VDR7jk0GV4bpW6GU5ZlsKU2UDbMRr6xup rBPYvzPZBpd4hTDAibI1Cu/0fGSdYajsGGJrZCYtXPzotiK9/9bIE4EZHwPzGmal+p+T VIDeozl2rYQFxY6y9lUKEHeQYVJt/V/0wMQ3iXHXEWFREuLEeJDDD9ItevUah7IZL/Cp HNfw== 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:cc; bh=W5uaon0Y0pV9sa9EDulUh5O8TCMwjGoVjbu60tPjFLg=; b=BPlhzKYalP4eYPztT0NAgF/ls5iDFtkQpSQs0v5eHHSeICJxu1PHFBzRHfnP8v4kHR kK2OjtVA30KjRDyu02sTFb7xvJtxxx4j/7CIrvOVPw3McMJ29xsOPfX7qzw1Eo+MT8BV X0k62lK3zjGm9uttm7UI70s3ijIgLCGyb2D0XMYQzj3h8A3ABwtXpTmo7Co+eXLPUF3d h/YPJcKTbB8PACl0aKLQMVD83nFHLb+BPIkzvw/CgJ1cjFG/lMqYyAFBSqJkuCVKsiNK wVJoDyoPeJoqeOXmRNHMKsz7E6FkHzB5d9IxbXUFBgCo8OIy7Gnn5xVF9MIFfmmfCzGD JeLw== X-Gm-Message-State: AOAM5319PWCxDItfuheUA6VMjL1ldznNu/viSjjwnqac2LT+XsBU9eO9 Bz/vIrPTn44vaJ6SYKY4gUgO3gpQzf5s7F6LDbajxiNh X-Google-Smtp-Source: ABdhPJy7V8wFIOQksxHlYLCb2ZfBd85QFoyrXGts874IlSUuxUGfWSm6ACW35xmDlltVmfInU4kcvBdn34dqF4lHEvk= X-Received: by 2002:aed:3263:: with SMTP id y90mr29131078qtd.94.1597111319613; Mon, 10 Aug 2020 19:01:59 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Tue, 11 Aug 2020 12:01:48 +1000 Message-ID: To: opsec WG Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OPSEC] Conclusion of the Adoption Call for draft-wang-opsec-tls-proxy-bp X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:02:02 -0000 The call for adoption for draft-wang-opsec-tls-proxy-bp has ended. The chairs believe that there is insufficient support and no consensus to adopt this document as a OpSec WG document. During the adoption call there were a number of comments on the document scope and technical details the document describes. Overall, we think these issues need to be addressed before the working group can consider adopting this document. Thanks to everyone who has reviewed the document and provided the feedback. -- SY, Jen Linkova aka Furry From nobody Wed Aug 19 11:45:58 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5C3A094B; Wed, 19 Aug 2020 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Oa2PQEOt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mOZaxKYj 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 YaU5mEt2FlNj; Wed, 19 Aug 2020 11:45:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7714E3A096B; Wed, 19 Aug 2020 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1597862748; x=1599072348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KK5P8tz4MWRdsN3mEqP4osoqweFInoVuy8HDn0IzyRE=; b=Oa2PQEOtD6pV5bcOjfd6+IboqAzV6sNTQVzCfKBLIvw6jYybqGgnUqtn qhSfaZa22DoUK2ZGZu3kW5l8c1ij6j5YEMKYNjTK0NsskYbH3SKTuSem8 sS5AQU9+fndrMwOH4iC1P05EY0Ziurmn55sZn+NoxDhLsQIw+ssuPOxpm k=; IronPort-PHdr: =?us-ascii?q?9a23=3AZlIQNBMIVzkFchljPeMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3kPNR4DLrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtJHNz7dxvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DICQDWcT1f/4gNJK1ZBoEJgxwjLgd?= =?us-ascii?q?wWC8sCoQtg0YDjV2YbIFCgREDVQsBAQEMAQEYCwoCBAEBhEwCF4IaAiQ4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBG2FXAyFcgEBAwEBARAREQwBASwLAQ8CAQgODAImAgI?= =?us-ascii?q?CJQsVEAIEAQ0FIoMEAYJLAw4gAQ6mXQKBOYhhdoEygwEBAQWCSoJmGIIOCYE?= =?us-ascii?q?OKoJxg2KGLx0bggCBESccgk0+glwBAYFFAggQgxczgi2QCw+Ca5IOMpByCoJ?= =?us-ascii?q?iiGSGTIpyAx6DAYEjiDuILIsckj+fRAIEAgQFAg4BAQWBaiOBV3AVOyoBgj4?= =?us-ascii?q?JRxcCDY4rF4NOhRSBcINSdDcCBgEJAQEDCXyPMgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,332,1592870400"; d="scan'208";a="794906597" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2020 18:45:46 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07JIjkuW014493 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2020 18:45:46 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 13:45:46 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 13:45:46 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 19 Aug 2020 14:45:45 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Du5yF6e/8mpZbvcroZgdaeoWZbVH8uQ5Xx7l3oKw4LFpUCGT717bZb7zR5KZ9y63pagpRS1mZNqmRRCVAgXHt9/Tt5lQxCQEIm50SN7YVdAY63ifVj1oOoaPPClXDk1XxhctUfVobee+LV5ZdRaSVc+Gbcfk9B0QVPHPRxkrWWmwKpHQjFQ3qRPajqfkbCgQYSpx+GR989u1IoNwB4e2aagQ8Qnj0GWKmf7xXERa26HZvzULZcwBv0sFWy2AuOOaS4LUjLI4Pf9S/7MgLJRhIBWixrvO097u0P//mx0jNIY+me6keYqcu10mirzCH9loKyV1SYtBnsbYMYSjhhJHqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KK5P8tz4MWRdsN3mEqP4osoqweFInoVuy8HDn0IzyRE=; b=j1g/0iH7cJTLmnNhuRkBnPEs+qMpgtUe0oyiB6j/QNQ5mqS5dmLXsEsK/Y5ZEgkxSVAqihWagj3ZsXm/nedUO9w/MC1QPE4c+5HgJZNLdQWQAgCIDaOrsDANNgQhbvOCqqe462tYJRfXtkqXeS9tOv/hOjdFvvxtdQSXmscAX290K7tv52JweYKmee+C3mA6hojAmNk0sapX9YS98awYNLaHy4vMMPrc1T0HH2x4aAClqKwGUquXyoFvYJuPdf1HwUqyd0Yz7uvtkmzvxTYKkZ11fE1rkwiBB3jw7OrNMegr46T5sHJcSlG0xq2xckCqY8erLPjIDlPGfQLyCmmjPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KK5P8tz4MWRdsN3mEqP4osoqweFInoVuy8HDn0IzyRE=; b=mOZaxKYjgp0FzopqX98FD8o4eblD0fkMEjwaAh3+yDy2vY7FZWADjJDnTKLDMx/St1QPBGsuE7KlVt+h6B2EEbaTzV+DZll3Qa63a62m1ntU0DFB1zM9FI0pF2QtZ4tpPk41ME+AGBEpAu/y7xDzdRjMGFbzU4wVyEN8JKYGceU= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BYAPR11MB3158.namprd11.prod.outlook.com (2603:10b6:a03:1c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.27; Wed, 19 Aug 2020 18:45:44 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::6945:e1a2:7eff:5f4c]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::6945:e1a2:7eff:5f4c%7]) with mapi id 15.20.3305.025; Wed, 19 Aug 2020 18:45:44 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Nick Lamb , "tls@ietf.org" CC: "opsec@ietf.org" Thread-Topic: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact Thread-Index: AQHWdKy3EuzQbe4YYUORvBwC+sTNmak/UzCA Date: Wed, 19 Aug 2020 18:45:44 +0000 Message-ID: <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> References: <20200817163938.07580cee@totoro.tlrmx.org> In-Reply-To: <20200817163938.07580cee@totoro.tlrmx.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: tlrmx.org; dkim=none (message not signed) header.d=none;tlrmx.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 152f7ff4-b1e0-4c66-edc6-08d8447014c6 x-ms-traffictypediagnostic: BYAPR11MB3158: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9hXv/KRu/LvLFxTm536njZUFvqY/jcq21xQxOpBOWSEp35ZylCiEe9rtumyuWe2a2cRFknlqOQ8SN7HTG7JmLhe70R85VsGEhc8NaFL2MYDJT3d32EsPdcEA0ZIVYzwUYNJTEwY3l2t1E27dLd9OZR6Zzh/9giineN1FsRJN3J+bQZ/AXwOqP807kCCWywVMRM++ar6BqDsTrsDUxQvyktdwMhLWisO1Bv/5/M/YJILwtBs1peDvYfr/mAqBkWmA7BE9GtXoG/9AuQaSwG6G323fC5xeoGtLP95GUFFg6c8727Uc4hWrmCDrdGdVQ4GjwNQo5nXvGibMpeI9mbTyqjT6Jk1t6ch9YzBx7xHoWomyFqIH6yeuSMeaDs+yMINo6vaB21C4sDpPNepnHDfBJw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(6029001)(4636009)(376002)(346002)(136003)(396003)(39860400002)(366004)(66446008)(66556008)(66476007)(110136005)(66946007)(71200400001)(76116006)(36756003)(316002)(2906002)(5660300002)(83380400001)(86362001)(2616005)(33656002)(8936002)(4326008)(478600001)(64756008)(6512007)(8676002)(966005)(26005)(6486002)(6506007)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: frMzIh0jEPtKPrLNqK9kXOJP8Zb0cSV3T/X3bVeHqWW0BpjCiNK6aZqJo4NDzrVQiLnFe1rJ6fJXk26dBcEt+pf1MP6RquHoj1NzFm8R9PKeVra1ivY47FXCGAP3DtHyGwEPMyEBPZPkrf8JWg8vLRFOORVwTp94GjMG4xOsUqaADL1Axi+5B2CjcEMtyCn7Ws2dvLxiVnAzgAj6PmM41oViD7pkz9PD0tys1eP+JNBhFMyWnyj4I1ci6uBwH0cZVQuX9pzudTddxTPDhQU1gnrSR3Z2IQfNlwntJwu9OIqcjyxjNsl3u5pjd5jzXmcuzE7dC5tYgBDfcNDaBJRE9bS/wTnlSiTuVV0R1dPYIiAaANTxr7bDaGOhDN4UR930NULFEol5wt0AnAn3O7IgNlCoz5dMFEVf9VrnBviNOqxCmke01UXLVDST7s88NV9QepMMmREjNeQKwICaAoQS1UtPl7rNIT/0kWrV4Df2wLcAHzY89lXT+RxdtZVvMjVhASfwzM9dVj8gkuiBVBmVrL1WRbbWeZjjA9gj47HKqgSBUY3q3ffFu/2wEdKlxX7EkiJ/iLwHQyqttZXUPvyRIYAszL0l6Tx5xrkokZCNg0RtLBAHqsYhGDOSiaCWDfQQfRTqTmpRWu01PNqan0hwgA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0DFB3BBD104305438FF6B3B19B45C4EF@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 152f7ff4-b1e0-4c66-edc6-08d8447014c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 18:45:44.6803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 85ulvsZ0is1cQreQS93eOq5yrZ3/tMh0S0SeqNRWsoB35BcZqt2KGe1vBsJ8FSvpQmZhJfXOeTXlWvSK/uhSIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3158 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 18:45:52 -0000 SGkgTmljaywNClRoYW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBkb2MsIHBsZWFzZSBzZWUgZnVydGhl ciByZXNwb25zZXMvY29tbWVudHMgYmVsb3c6DQoNCu+7v09uIDgvMTcvMjAsIDg6NDAgQU0sICJU TFMgb24gYmVoYWxmIG9mIE5pY2sgTGFtYiIgPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBuamxAdGxybXgub3JnPiB3cm90ZToNCg0KICAgIEkgYW0gbm90IHZlcnkgZmFtaWxpYXIg d2l0aCBJRVRGIHdvcmtpbmcgZ3JvdXAgcHJhY3RpY2VzLCBob3dldmVyIGl0DQogICAgc3RyaWtl cyBtZSBhcyBzdXJlbHkgdW51c3VhbCB0byBoYXZlIGEgZG9jdW1lbnQgZW50ZXIgTGFzdCBDYWxs DQogICAgKHN1cHBvc2VkbHkgYmVsaWV2ZWQgYnkgaXRzIG93bmVycyB0byBiZSByZWFkeSBmb3Ig cHVibGljYXRpb24pIGFuZCB5ZXQNCiAgICBpbW1lZGlhdGVseSB0aGVuIGJlIHJldmlzZWQgc2hv d2luZyBpdCB3YXMgaW4gZmFjdCBub3QgcmVhZHkgYXQgYWxsLg0KW05DV10gSXQgd2FzIGFuIHVu Zm9ydHVuYXRlIG92ZXJzaWdodCBvbiBteSBwYXJ0IGFzIEkgc29tZWhvdyBkaWQgbm90IGNhdGNo DQpUb20ncyBmZWVkYmFjayB3aGVuIEkgdXBkYXRlZCB0aGUgZHJhZnQgdW50aWwgaGUgcG9pbnRl ZCBpdCBvdXQgYW5kIEkgaGFkIHRvDQpnbyB0byB0aGUgb3BzZWMgbWFpbGFyY2hpdmUgdG8gcmV0 cmlldmUgaGlzIGluaXRpYWwgY29tbWVudHMuICAgDQpJIGRvbid0IGJlbGlldmUsIHdlIHRoZSBh dXRob3JzIG1hZGUgYW55IG5vdGlvbiB0aGF0IHdlIHdlcmUgcmVhZHkgZm9yIHB1YmxpY2F0aW9u Ow0KSSBiZWxpZXZlIHRoZSBsYXN0IGNhbGwgcHJvY2VzcyBpcyB0byBlbnN1cmUgdGhlcmUgaXMg bW9yZSByZXZpZXcgYmVmb3JlIHB1YmxpY2F0aW9uLg0KICAgIA0KICAgIEhvd2V2ZXIgdGhpcyBz ZWVtcyB0byBiZSB3aGF0IGhhcHBlbmVkIHRvIGRyYWZ0LWlldGYtb3BzZWMtbnMtaW1wYWN0Lg0K ICAgIFRoZSBiZWxvdyBjb21tZW50cyBjb25jZXJuIGRyYWZ0LWlldGYtb3BzZWMtbnMtaW1wYWN0 LTAyLCB0aGUgbmV3ZXINCiAgICBkb2N1bWVudC4NCiAgICANCiAgICBTZWN0aW9uIDQuMSBQZXJm ZWN0IEZvcndhcmQgU2VjcmVjeSBlbmRzOg0KICAgIA0KICAgID4gVExTIHNlc3Npb24gZGF0YS5z cw0KICAgIA0KICAgIEkgdGhpbmsgdGhpcyBpcyBhIHR5cG9ncmFwaGljYWwgZXJyb3IgYW5kIHRo ZSB0cmFpbGluZyAic3MiIHNob3VsZCBiZQ0KICAgIHJlbW92ZWQgZnJvbSB0aGUgZG9jdW1lbnQu IElmIG5vdCBpdCBzaG91bGQgYmUgZXhwbGFpbmVkLg0KICAgIFtOQ1ddIFRoYW5rcyBmb3IgY2F0 Y2hpbmcgaXQsIGEgZm9ybWF0dGluZyByZW1uYW50IHdoaWNoIHdpbGwgYmUgcmVtb3ZlZC4NCiAg ICANCiAgICANCiAgICBTZWN0aW9uIDQuMiBFbmNyeXB0ZWQgU2VydmVyIENlcnRpZmljYXRlIGRl c2NyaWJlcyBhIHByYWN0aWNlIHdoaWNoIGlzDQogICAgaW5oZXJlbnRseSB1bnNvdW5kLiBQYXNz aXZlIGluc3BlY3Rpb24gb2YgdGhlIENlcnRpZmljYXRlIG1lc3NhZ2UgZnJvbQ0KICAgIFRMUyAx LjIgb3IgZWFybGllciBpc24ndCBhIHJlbGlhYmxlIHNvdXJjZSBvZiBpbmZvcm1hdGlvbiBiZWNh dXNlIGENCiAgICBwYXNzaXZlIGVhdmVzZHJvcHBlciBpc24ndCBhYmxlIHRvIGRpc2Nlcm4gd2hl dGhlciB0aGUgWC41MDkgZG9jdW1lbnQNCiAgICBwcmVzZW50ZWQgY29ycmVzcG9uZHMgdG8gdGhp cyBzZXJ2ZXIgb3Igbm90LiBUaGUgQ2xpZW50IGNhbiBjb25maXJtDQogICAgdGhpcyB1c2luZyB0 aGUgVExTIHByb3RvY29sIGJ1dCBhbiBlYXZlc2Ryb3BwZXIgY2FuJ3QuIFNvIHRoZSBjaGFuZ2Ug aW4NCiAgICBUTFMgMS4zIGRvZXMgbm90IGltcGFjdCB0aGUgcHJhY3RpY2FsIHNlY3VyaXR5IHBv bGljeSBhdmFpbGFibGUsIG9ubHkgYW4NCiAgICBhcHBlYXJhbmNlIGlzIGFsdGVyZWQuDQpbTkNX XSBUaGUgZG9jdW1lbnQgZGVzY3JpYmVzIHdoYXQgaXMgaW4gcHJhY3RpY2UgdG9kYXkgd2l0aCBU TFMgMS4yIGFuZCAxLjENCndoZXRoZXIgd2UgYmVsaWV2ZSBpdCBpcyB1bnNvdW5kIG9yIG90aGVy d2lzZSwgaXQgaXMgd2hhdCBpcyBkb25lIHRvZGF5Lg0KICAgIA0KICAgIFBhc3NpdmUgc3lzdGVt cyBkZXNjcmliZWQgdGhyb3VnaG91dCBTZWN0aW9uIDUuMSBmYWxsIHRvIHRoaXMgc2FtZQ0KICAg IGVycm9yLCB1c2luZyB0aGUgcGhyYXNlICJyZWR1Y2VkIGVmZmVjdGl2ZW5lc3MiIHdoaWNoIHRo ZSBkb2N1bWVudA0KICAgIGRlZmluZXMgYXMgbm90IGJlaW5nICJhcyBlZmZlY3RpdmUgb24gVExT IDEuMyB0cmFmZmljIiBidXQgaW4gZmFjdA0KICAgIHNpbmNlIHRoaXMgcHJhY3RpY2UgZGlkbid0 IHdvcmssIGl0IHdpbGwgcmVtYWluIGV4YWN0bHkgYXMgZWZmZWN0aXZlDQogICAgKG5vdCBhdCBh bGwpIGFzIGJlZm9yZS4NCltOQ1ddIEFnYWluLCB0aGUgZG9jdW1lbnQgaXMgZGVzY3JpYmluZyB3 aGF0IGlzIGluIHByYWN0aWNlIHRvZGF5Lg0KICAgIA0KICAgIEEgcmVsYXRlZCBjb25zZXF1ZW5j ZSBwYXNzZXMgaW50byBTZWN0aW9uIDUuMi4gU2luY2UgdGhlIENlcnRpZmljYXRlDQogICAgbWVz c2FnZSBpcyBvbmx5IHJlbGlhYmxlIGZvciBhIENsaWVudCwgaXQgaGFzIGluIGZhY3QgYWx3YXlz IGJlZW4NCiAgICBuZWNlc3NhcnkgdG8gZnVsbHkgcHJveHkgdGhlIFRMUyBzZXNzaW9uIGluIG9y ZGVyIHRvIHJlbHkgb24gdGhpcyBkYXRhLA0KICAgIHNvIHRoaXMgaXMgbm90IGluIGZhY3QgYW4g aW1wYWN0IGZyb20gVExTIDEuMyBidXQgKGlmIGl0IHdhc24ndCBkb25lDQogICAgcHJldmlvdXNs eSBmb3IgYWxsIHZlcnNpb25zKSBhIHZ1bG5lcmFiaWxpdHkgaW4gc3VjaCBwcm9kdWN0cy4NCltO Q1ddIFdpdGggVExTIDEuMiB0aGUgb2JzZXJ2ZXIgY2FuIHNlZSB0aGUgaGFuZHNoYWtlIHRocnUg Y29tcGxldGlvbg0Kd2l0aCB0aGUgRmluaXNoZWQgbWVzc2FnZSBiZWZvcmUgYWZmZWN0aW5nIGEg cG9saWN5IGRlY2lzaW9uLg0KICAgIA0KICAgIA0KICAgIEFzIGl0IHN0YW5kcyB0aGVuLCB0aGlz IGRvY3VtZW50IGlzIG1pc2xlYWRpbmcuDQogICAgDQogICAgTmljay4NCiAgICANCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWls aW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Wed Aug 19 16:42:58 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014E13A0DB2; Wed, 19 Aug 2020 16:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 68ziUBdEkfXH; Wed, 19 Aug 2020 16:42:55 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 C5F3E3A0C33; Wed, 19 Aug 2020 16:42:55 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id j187so98100qke.11; Wed, 19 Aug 2020 16:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Ls3qmgNM5hX0qlpTo5dYmIgdvuzqe5CnphOFNUffd8U=; b=BrsYiDU8sF4uGFKBh6ttPXacBUOyTG+gMwHSMe1fvuMmHf8uXKiJp4IFaNzrh4Sb9C 78mYHphCH1vvg2IOtfay/42QntlwMpKw3m1eOsBMELocjLhXnhzmyRRQqzCSJqQ59dux nXTsSGGcwl/V0NeZaelrLuH5OeIaKRxEXxWRtaglgCPw5zBykR3FicDnLuQGkZqvxLwb x/Y56sxhpHJy50eRRBhU1qpUtQ0yZXXU/Xly/bFNrkIda5Z1a+ozj8/icIhemSmQiGHx JC58xXwRxtcYrl55ijL+v8nB1qcWIxsOxUVF6WUbf/FZ9XrzKYK/ODQlCK7/MUy7Ru6x 0Ncg== 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:cc; bh=Ls3qmgNM5hX0qlpTo5dYmIgdvuzqe5CnphOFNUffd8U=; b=pdXmgMEkKk58WIfq0psMrDZ5LnJX1yeMsO7kyErzl7CQ8zxAOoT7inBAFrLRUV9+v5 4I/UoEGV3t4jSdbR7FZfpxBMketI+r5ukvzPqnuGJZa0AJ8as8qyGSVyoa3G64g2XOMW 3+bqA0DwAuOEWu3nF8OcnU6sUVowNctgksmEI+KOXUOt3vIWG1OrIZiGuaegIakig6DR BgYhIzArq2jtIj8pxPhMDz35wCl7pebQmkP12Vg6cCidWu5GGM/wwqtoiH5ZW/06gGZa GLjnV1SGijSYH085+cRreIEcvGhClEGXReBl9+89WjXMxxnMh861DCjuVJGA5OF3NdB3 PioA== X-Gm-Message-State: AOAM530LBFPMnMXuNNShqqu562h9EqHaVJoTb1wHgtCy1r6Ka3e2LB4w peGLIfJotx9sCFR/pBar7shP35OPacjbiloKZkelZXyUkGM= X-Google-Smtp-Source: ABdhPJzNg0RLb2hA07l6Svyj12CDPoU9fQS5HevTa0TFUpr493bSuAFVrAygd/1EtjRT5EVbfMX25c3eOAJtsQSR0Z8= X-Received: by 2002:a37:a354:: with SMTP id m81mr394297qke.277.1597880574611; Wed, 19 Aug 2020 16:42:54 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Thu, 20 Aug 2020 09:42:43 +1000 Message-ID: To: opsec WG , draft-ietf-opsec-ns-impact.authors@ietf.org Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OPSEC] Conclusion of the OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 23:42:57 -0000 The WGLC for draft-ietf-opsec-ns-impact ended on Aug 18th. During the WGLC serious technical objections were raised and some statements the document made were questioned. The chairs believe that there is insufficient support and no consensus to advance the document. The chairs would like to thank both OpSec and TLS working groups for reviewing the document. -- SY, Jen Linkova aka Furry on behalf of the OpSec WG chairs. From nobody Thu Aug 20 06:59:25 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2F3A0B5E; Thu, 20 Aug 2020 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 JU-LWT2_zrB5; Thu, 20 Aug 2020 06:59:09 -0700 (PDT) Received: from sender4-of-o54.zoho.com (sender4-of-o54.zoho.com [136.143.188.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764B13A0B3F; Thu, 20 Aug 2020 06:59:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597931945; cv=none; d=zohomail.com; s=zohoarc; b=mAii3b7EYyJKhfylGnrqgpeyyzWlRg6+LsFpkjPCmP812GNSGgdTIJqVpxNjK8BFk7KF2vKpPcfcp6/I9pMJBVJIQRLbTZ1YlhaWzubD2d2Yg66HkF9EZXpBWA9IVzcqn+C11vX4jbkCOogLeELHbN1aWWIg6KDlExjlRgfgJv8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1597931945; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=NC9Rsszsk3WGBbl+HOKUxJe8PiyksXH/fEY8pUk+Igk=; b=JreDLZ1ZULSh7DMyhD2ed7O6w5OY/XjinfOAruOW8eFfhAdSxTjuMk5loTqiF2qepZL6H4vzp50S2yWAjJh00JSLyyvNSflIFQqbzeIS83AY2RNBJj6Ow6KEzraenYN+nn0+AGSk0DmTZZ+IIAHYI3QpWDXGkwaYEOPmUpLlr00= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1597931945; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; bh=NC9Rsszsk3WGBbl+HOKUxJe8PiyksXH/fEY8pUk+Igk=; b=po3bBT6WhNgI/m+jWo3t9gS6RX9/jJhweinpTtFR4Lz4e2UEpJ37Vtmksdj8be/H uPkyAgLFDMDEb/e9EdMTVhunQOVGJ0ubt57ieUTybliOCF5A3clax9ZHc018n0pAw2s FWjjXsZYly92NBYHOtfCuTXSLFn12SfiJFxNABvI= Received: from [192.168.123.155] (dynamic-acs-24-112-241-136.zoominternet.net [24.112.241.136]) by mx.zohomail.com with SMTPS id 1597931941340423.92304621580763; Thu, 20 Aug 2020 06:59:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Roelof DuToit In-Reply-To: <20200819234314.29c3bbdc@totoro.tlrmx.org> Date: Thu, 20 Aug 2020 09:58:58 -0400 Cc: "Nancy Cam-Winget (ncamwing)" , "opsec@ietf.org" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja> References: <20200817163938.07580cee@totoro.tlrmx.org> <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> <20200819234314.29c3bbdc@totoro.tlrmx.org> To: Nick Lamb X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ZohoMailClient: External Archived-At: Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 13:59:18 -0000 As co-author I am not a proponent of passive TLS inspection - not least = because of the ossification implications. It cannot be labeled as = ineffective though (see further comments below), even if the document = strongly hints at not using passive TLS inspection in a post-TLS-1.2 = world. > On Aug 19, 2020, at 6:43 PM, Nick Lamb wrote: >=20 > The passive eavesdropper can indeed see the handshake in TLS 1.2, but > since they were not a participant they don't actually know what it > means even though it wasn't encrypted. >=20 > For example, suppose an RSA certificate is sent and the handshake = seems > to agree RSA key exchange and Client sends an = EncryptedPreMasterSecret. > The passive eavesdropper has no idea if that's actually encrypted to = the > RSA public key from the certificate, it's just an opaque blob. >=20 >=20 > Thus it's easily possible for an eavesdropper to witness a handshake = in > which the eavesdropper believes what happened is: >=20 > Client proposed to do RSA key exchange > Server showed a certificate for www.local-hospital.example > Client sent an EncryptedPreMasterSecret to the local hospital > both agreed this all worked fine and continue encrypted >=20 > The eavesdropper's "Don't eavesdrop on people's medical stuff" policy > kicks in and it allows the connection unmolested. Unfortunately what > really happened is: >=20 > Client proposed to do RSA key exchange > Server showed a certificate for www.local-hospital.example > Client sent an EncryptedPreMasterSecret for the GRU data exfiltration > server ignoring the bogus certificate > $5Bn of stolen commercial documents are uploaded to the server Advanced passive TLS inspection devices use a combination of techniques = to defend against those attacks for TLS 1.2 (and below): 1. Policy-based control over the use of RSA key exchange. It should not = be allowed. 2. Checking the signature in the ServerKeyExchange message when (EC)DHE = key exchange is used. 3. Not trusting the destination IP address. The hostname from the SNI = is resolved and compared. None of those techniques are perfect given an advanced adversary that = controls the client + DNS in the enterprise + the flow of traffic on the = server side of the TLS inspection device. (Side note: If I=E2=80=99m an attacker that has control over DNS then I = would not bother with TLS-based attacks for data exfiltration). In other words, nation state attacks might succeed but it does not mean = that passive TLS inspection devices are not effective against other = attacks. =E2=80=94Roelof= From nobody Thu Aug 20 12:14:32 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3723A12E9 for ; Thu, 20 Aug 2020 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 fqwTAt2-qrMG for ; Thu, 20 Aug 2020 12:14:25 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 9C4793A12ED for ; Thu, 20 Aug 2020 12:14:24 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id t23so3350245ljc.3 for ; Thu, 20 Aug 2020 12:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bMTXMwfq5tFlnZ0xzonGdtOtYOU+OW/qI6iRdMXFZt0=; b=OMMjTC0Xh4rsRemlfuNKmGkvgSY4RYzxIrgWn2jAJXW+y5/mHg7MYoY72EbR4PegfK vReBqtlSui5l7LxYMe/jAKDATJtBOrHV6pegxhBksm5yvwxNiZvD6j/771jXvfIQEQtx PT9oXRgFcxSMejTfNxPZoERGShJuJXdTAS6NIV234x4p8tkeGscfu3fSACOHMbN9holo 4tlkdhSGimBx8vtL7TW0yER1o+u24Nq2kGAEk7p/VyMkHR/hntph40QIXUZ4VfNwOPaP Myve/xU1KtiHcPUDTRpQ0GMZY6nncFK/1ZHOgl2aKNRYwYOOhCpgCbEWAz/T29n03nPs NVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bMTXMwfq5tFlnZ0xzonGdtOtYOU+OW/qI6iRdMXFZt0=; b=I/Sbf9BExsfrLA9XFJd2odsFKTmUKb4aE9ZZZBfIDAmVELyuXSOEK5Vi3jpC21TGTz WiKNBH7j0ChGcuRUr0Ke8LY9WPa+oyaX6zx5Ku8ijUjFa4Pbra2KE0hF/0WrjX8kVynv 0W/agaHfLGrml6M14IVE/JyS+ylOXOOXsX3ndx8UhKy/F209JnsHfZD/M8gaXB3uzGYx UVPy3ZWt4ro7xdeOsV+iRk9YWUJAWjh+DmdbZV/35Ds9IE8Qnmynr8Co8trUv6h5r458 cUoVETRP1GAKOkcEHtpVhxiSaHnRkxlPAaJnw617UJ3PZ65kwD7nOlAwmoYZvryRVAuF KPxw== X-Gm-Message-State: AOAM532yDjg5TSHVjyp1LYRCtW0HLKgHYM85QrVIn1WCOoQG2p06ardn o2SIgUJicqMolJDuJh4gOOCL0ErPnYi2r7y4M+4uqZat/Na3ow== X-Google-Smtp-Source: ABdhPJywNhh62PEAdKpjAe0N4TPehgVrUmQZHqB893NR3NDJBr+Iion//cEbhrzlcPAk2Ir4RbjqhTR9jMXRBPIEXbA= X-Received: by 2002:a2e:3609:: with SMTP id d9mr2040394lja.17.1597950862600; Thu, 20 Aug 2020 12:14:22 -0700 (PDT) MIME-Version: 1.0 References: <20200817163938.07580cee@totoro.tlrmx.org> <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> <20200819234314.29c3bbdc@totoro.tlrmx.org> <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja> In-Reply-To: <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja> From: Eric Rescorla Date: Thu, 20 Aug 2020 12:13:45 -0700 Message-ID: To: Roelof DuToit Cc: Nick Lamb , "opsec@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000088c47705ad53ed92" Archived-At: Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 19:14:27 -0000 --00000000000088c47705ad53ed92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2020 at 7:01 AM Roelof DuToit wrote: > As co-author I am not a proponent of passive TLS inspection - not least > because of the ossification implications. It cannot be labeled as > ineffective though (see further comments below), even if the document > strongly hints at not using passive TLS inspection in a post-TLS-1.2 worl= d. > > > On Aug 19, 2020, at 6:43 PM, Nick Lamb wrote: > > > > The passive eavesdropper can indeed see the handshake in TLS 1.2, but > > since they were not a participant they don't actually know what it > > means even though it wasn't encrypted. > > > > For example, suppose an RSA certificate is sent and the handshake seems > > to agree RSA key exchange and Client sends an EncryptedPreMasterSecret. > > The passive eavesdropper has no idea if that's actually encrypted to th= e > > RSA public key from the certificate, it's just an opaque blob. > > > > > > Thus it's easily possible for an eavesdropper to witness a handshake in > > which the eavesdropper believes what happened is: > > > > Client proposed to do RSA key exchange > > Server showed a certificate for www.local-hospital.example > > Client sent an EncryptedPreMasterSecret to the local hospital > > both agreed this all worked fine and continue encrypted > > > > The eavesdropper's "Don't eavesdrop on people's medical stuff" policy > > kicks in and it allows the connection unmolested. Unfortunately what > > really happened is: > > > > Client proposed to do RSA key exchange > > Server showed a certificate for www.local-hospital.example > > Client sent an EncryptedPreMasterSecret for the GRU data exfiltration > > server ignoring the bogus certificate > > $5Bn of stolen commercial documents are uploaded to the server > > > Advanced passive TLS inspection devices use a combination of techniques t= o > defend against those attacks for TLS 1.2 (and below): > 1. Policy-based control over the use of RSA key exchange. It should not > be allowed. > 2. Checking the signature in the ServerKeyExchange message when (EC)DHE > key exchange is used. > 3. Not trusting the destination IP address. The hostname from the SNI is > resolved and compared. > > None of those techniques are perfect given an advanced adversary that > controls the client + DNS in the enterprise + the flow of traffic on the > server side of the TLS inspection device. > (Side note: If I=E2=80=99m an attacker that has control over DNS then I w= ould not > bother with TLS-based attacks for data exfiltration). > In other words, nation state attacks might succeed but it does not mean > that passive TLS inspection devices are not effective against other attac= ks. > It seems to me that the conditions under which this kind of inspection works and does not work are quite subtle. If you want to proceed with this document, it would probably be good to document them, -Ekr --00000000000088c47705ad53ed92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 20, 2020 at 7:01 AM Roelo= f DuToit <r@nerd.ninja> wrote:
As co-author I am not a proponent of passive TLS inspe= ction - not least because of the ossification implications.=C2=A0 It cannot= be labeled as ineffective though (see further comments below), even if the= document strongly hints at not using passive TLS inspection in a post-TLS-= 1.2 world.

> On Aug 19, 2020, at 6:43 PM, Nick Lamb <njl@tlrmx.org> wrote:
>
> The passive eavesdropper can indeed see the handshake in TLS 1.2, but<= br> > since they were not a participant they don't actually know what it=
> means even though it wasn't encrypted.
>
> For example, suppose an RSA certificate is sent and the handshake seem= s
> to agree RSA key exchange and Client sends an EncryptedPreMasterSecret= .
> The passive eavesdropper has no idea if that's actually encrypted = to the
> RSA public key from the certificate, it's just an opaque blob.
>
>
> Thus it's easily possible for an eavesdropper to witness a handsha= ke in
> which the eavesdropper believes what happened is:
>
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret to the local hospital
> both agreed this all worked fine and continue encrypted
>
> The eavesdropper's "Don't eavesdrop on people's medic= al stuff" policy
> kicks in and it allows the connection unmolested. Unfortunately what > really happened is:
>
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret for the GRU data exfiltration<= br> > server ignoring the bogus certificate
> $5Bn of stolen commercial documents are uploaded to the server


Advanced passive TLS inspection devices use a combination of techniques to = defend against those attacks for TLS 1.2 (and below):
1. Policy-based control over the use of RSA key exchange.=C2=A0 It should n= ot be allowed.
2. Checking the signature in the ServerKeyExchange message when (EC)DHE key= exchange is used.
3. Not trusting the destination IP address.=C2=A0 The hostname from the SNI= is resolved and compared.

None of those techniques are perfect given an advanced adversary that contr= ols the client + DNS in the enterprise + the flow of traffic on the server = side of the TLS inspection device.
(Side note: If I=E2=80=99m an attacker that has control over DNS then I wou= ld not bother with TLS-based attacks for data exfiltration).
In other words, nation state attacks might succeed but it does not mean tha= t passive TLS inspection devices are not effective against other attacks.

It seems to me that the conditions under= which this kind of inspection works and does not work are quite subtle. If= you want to proceed with this document, it would probably be good to docum= ent them,

-Ekr

--00000000000088c47705ad53ed92-- From nobody Fri Aug 21 08:26:36 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C753A0CCD; Mon, 17 Aug 2020 08:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tlrmx.org 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 FzSrnp2iCA-y; Mon, 17 Aug 2020 08:39:46 -0700 (PDT) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B983A0B94; Mon, 17 Aug 2020 08:39:46 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 545252209A; Mon, 17 Aug 2020 15:39:45 +0000 (UTC) Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-5-126.trex.outbound.svc.cluster.local [100.96.5.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DC22121CAF; Mon, 17 Aug 2020 15:39:44 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from pdx1-sub0-mail-a31.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Mon, 17 Aug 2020 15:39:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org X-MailChannels-Auth-Id: dreamhost X-Skirt-Abiding: 69fcdad9221ad991_1597678785141_490892859 X-MC-Loop-Signature: 1597678785141:1491327578 X-MC-Ingress-Time: 1597678785141 Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 8D91B7F0EE; Mon, 17 Aug 2020 08:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:mime-version:content-type :content-transfer-encoding; s=tlrmx.org; bh=rosz/lqeIliYoYjVf7Ci 9pGFTQk=; b=XPiMbYH4t5d31Pud/+xQpqtEHhfvsfDEIu0e/XwGcXUPd09LHdcG DNX47ZUrYq1bKIWLBNFb6uL+3lqmAR+K/amAOpDJ5XuLkw0x7+L2D7+Tfact4Gcx 8rpcAHhDHJ1X/Z8SccGc3Sh555ovsrwmrICwa2Dm7cYWXpof+Te3N0g= Received: from totoro.tlrmx.org (124.89.2.81.in-addr.arpa [81.2.89.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9B2627F0F4; Mon, 17 Aug 2020 08:39:43 -0700 (PDT) Date: Mon, 17 Aug 2020 16:39:38 +0100 X-DH-BACKEND: pdx1-sub0-mail-a31 From: Nick Lamb To: tls@ietf.org Cc: opsec@ietf.org Message-ID: <20200817163938.07580cee@totoro.tlrmx.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddtfedgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkofggtgfgsehtjeertdertddvnecuhfhrohhmpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqnecuggftrfgrthhtvghrnhepfeekteeigeejvdfgvedtffffieekudekfeelhffhfeefieeigfekheegffehveefnecukfhppeekuddrvddrkeelrdduvdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepthhothhorhhordhtlhhrmhigrdhorhhgpdhinhgvthepkedurddvrdekledruddvgedprhgvthhurhhnqdhprghthheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqedpmhgrihhlfhhrohhmpehnjhhlsehtlhhrmhigrdhorhhgpdhnrhgtphhtthhopehophhsvggtsehivghtfhdrohhrgh Archived-At: X-Mailman-Approved-At: Fri, 21 Aug 2020 08:26:35 -0700 Subject: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 15:39:48 -0000 I am not very familiar with IETF working group practices, however it strikes me as surely unusual to have a document enter Last Call (supposedly believed by its owners to be ready for publication) and yet immediately then be revised showing it was in fact not ready at all. However this seems to be what happened to draft-ietf-opsec-ns-impact. The below comments concern draft-ietf-opsec-ns-impact-02, the newer document. Section 4.1 Perfect Forward Secrecy ends: > TLS session data.ss I think this is a typographical error and the trailing "ss" should be removed from the document. If not it should be explained. Section 4.2 Encrypted Server Certificate describes a practice which is inherently unsound. Passive inspection of the Certificate message from TLS 1.2 or earlier isn't a reliable source of information because a passive eavesdropper isn't able to discern whether the X.509 document presented corresponds to this server or not. The Client can confirm this using the TLS protocol but an eavesdropper can't. So the change in TLS 1.3 does not impact the practical security policy available, only an appearance is altered. Passive systems described throughout Section 5.1 fall to this same error, using the phrase "reduced effectiveness" which the document defines as not being "as effective on TLS 1.3 traffic" but in fact since this practice didn't work, it will remain exactly as effective (not at all) as before. A related consequence passes into Section 5.2. Since the Certificate message is only reliable for a Client, it has in fact always been necessary to fully proxy the TLS session in order to rely on this data, so this is not in fact an impact from TLS 1.3 but (if it wasn't done previously for all versions) a vulnerability in such products. As it stands then, this document is misleading. Nick. From nobody Fri Aug 21 08:26:39 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216343A043E; Wed, 19 Aug 2020 15:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tlrmx.org 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 hyNJFSbEpYpH; Wed, 19 Aug 2020 15:43:25 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3C33A0EBF; Wed, 19 Aug 2020 15:43:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2A9577E176A; Wed, 19 Aug 2020 22:43:24 +0000 (UTC) Received: from pdx1-sub0-mail-a90.g.dreamhost.com (100-96-19-54.trex.outbound.svc.cluster.local [100.96.19.54]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 831B07E11F9; Wed, 19 Aug 2020 22:43:23 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from pdx1-sub0-mail-a90.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 19 Aug 2020 22:43:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org X-MailChannels-Auth-Id: dreamhost X-Reaction-Supply: 60ab95094bf34615_1597877003996_3731062712 X-MC-Loop-Signature: 1597877003996:1742534597 X-MC-Ingress-Time: 1597877003995 Received: from pdx1-sub0-mail-a90.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a90.g.dreamhost.com (Postfix) with ESMTP id 191537E73D; Wed, 19 Aug 2020 15:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=tlrmx.org; bh=Ogdxwi/ EaeZm1ee3VUn9fCmsP2Q=; b=OqwkVLJTpxk8b9+DEcG64cUhOFmIUas4i2G14Ls vyTG6BKUfqn0lSp0gW5OJ1D8eM79aP3W3S9AFp/plhAPVDAOWjG4CQwca5VOmoTI QhnPNDYAATUoxmaLWjEOdP+uWydXiCYQ86XYM3XV2QXhmD3HVpbPxDE5eQNft4hm 3P18= Received: from totoro.tlrmx.org (124.89.2.81.in-addr.arpa [81.2.89.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 477C47ED64; Wed, 19 Aug 2020 15:43:18 -0700 (PDT) Date: Wed, 19 Aug 2020 23:43:14 +0100 X-DH-BACKEND: pdx1-sub0-mail-a90 From: Nick Lamb To: "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" , "opsec@ietf.org" Message-ID: <20200819234314.29c3bbdc@totoro.tlrmx.org> In-Reply-To: <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> References: <20200817163938.07580cee@totoro.tlrmx.org> <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddtledgudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfesthejredtredtvdenucfhrhhomheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqeenucggtffrrghtthgvrhhnpeetjeeludefvddtkeffgffgudfgveffffegtdeuleffkedvvedvfedvjedvleelueenucfkphepkedurddvrdekledruddvgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehtohhtohhrohdrthhlrhhmgidrohhrghdpihhnvghtpeekuddrvddrkeelrdduvdegpdhrvghtuhhrnhdqphgrthhhpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqpdhmrghilhhfrhhomhepnhhjlhesthhlrhhmgidrohhrghdpnhhrtghpthhtohepohhpshgvtgesihgvthhfrdhorhhg Archived-At: X-Mailman-Approved-At: Fri, 21 Aug 2020 08:26:35 -0700 Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 22:43:27 -0000 On Wed, 19 Aug 2020 18:45:44 +0000 Nancy Cam-Winget (ncamwing)" wrote: > Section 4.2 Encrypted Server Certificate describes a practice > which is inherently unsound. Passive inspection of the Certificate > message from TLS 1.2 or earlier isn't a reliable source of > information because a passive eavesdropper isn't able to discern > whether the X.509 document presented corresponds to this server or > not. The Client can confirm this using the TLS protocol but an > eavesdropper can't. So the change in TLS 1.3 does not impact the > practical security policy available, only an appearance is altered. > [NCW] The document describes what is in practice today with TLS 1.2 > and 1.1 whether we believe it is unsound or otherwise, it is what is > done today. It's not a problem for the document to describe today's practices but it's a mistake to label them "effective" if we know they are not. > Passive systems described throughout Section 5.1 fall to this same > error, using the phrase "reduced effectiveness" which the document > defines as not being "as effective on TLS 1.3 traffic" but in fact > since this practice didn't work, it will remain exactly as > effective (not at all) as before. > [NCW] Again, the document is describing what is in practice today. Describing something as "effective" when it is not effective isn't a matter of today's practice but of a misunderstanding of what's possible at all. > A related consequence passes into Section 5.2. Since the > Certificate message is only reliable for a Client, it has in fact > always been necessary to fully proxy the TLS session in order to rely > on this data, so this is not in fact an impact from TLS 1.3 but (if > it wasn't done previously for all versions) a vulnerability in such > products. [NCW] With TLS 1.2 the observer can see the handshake thru > completion with the Finished message before affecting a policy > decision. The passive eavesdropper can indeed see the handshake in TLS 1.2, but since they were not a participant they don't actually know what it means even though it wasn't encrypted. For example, suppose an RSA certificate is sent and the handshake seems to agree RSA key exchange and Client sends an EncryptedPreMasterSecret. The passive eavesdropper has no idea if that's actually encrypted to the RSA public key from the certificate, it's just an opaque blob. Thus it's easily possible for an eavesdropper to witness a handshake in which the eavesdropper believes what happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret to the local hospital both agreed this all worked fine and continue encrypted The eavesdropper's "Don't eavesdrop on people's medical stuff" policy kicks in and it allows the connection unmolested. Unfortunately what really happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret for the GRU data exfiltration server ignoring the bogus certificate $5Bn of stolen commercial documents are uploaded to the server Nick. From nobody Fri Aug 21 08:26:41 2020 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF63A149D; Thu, 20 Aug 2020 16:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tlrmx.org 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 IGzgB-gXZg6y; Thu, 20 Aug 2020 16:39:58 -0700 (PDT) Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158053A149C; Thu, 20 Aug 2020 16:39:57 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DE9E2541193; Thu, 20 Aug 2020 23:39:56 +0000 (UTC) Received: from pdx1-sub0-mail-a69.g.dreamhost.com (100-96-9-79.trex.outbound.svc.cluster.local [100.96.9.79]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 15F54541676; Thu, 20 Aug 2020 23:39:56 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org Received: from pdx1-sub0-mail-a69.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Thu, 20 Aug 2020 23:39:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org X-MailChannels-Auth-Id: dreamhost X-Fumbling-Attack: 7851003129eb71e1_1597966796562_3946682550 X-MC-Loop-Signature: 1597966796561:1992449385 X-MC-Ingress-Time: 1597966796561 Received: from pdx1-sub0-mail-a69.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTP id A0BA28431B; Thu, 20 Aug 2020 16:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=tlrmx.org; bh=BhUX+Yg Bj8xZjQp2+T3IRJdyAR0=; b=joq36NUMWqurH9N4tQyH2GMAu74YrU3Z+n0c/rn IxvCR6BbX0gMm/4ijI9/78I8gQ+sBrE/HqDBixDsl8GPdQuPdpgwNI3NMtmEJmDK 444DSrZ+GUZM6BGAxwiQYO70Qstro5TWBroLSNAKv8PldgXZFyem79coFa5pALB0 1QCk= Received: from totoro.tlrmx.org (124.89.2.81.in-addr.arpa [81.2.89.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTPSA id 0B1AE7FF29; Thu, 20 Aug 2020 16:39:52 -0700 (PDT) Date: Fri, 21 Aug 2020 00:39:48 +0100 X-DH-BACKEND: pdx1-sub0-mail-a69 From: Nick Lamb To: Roelof DuToit Cc: "Nancy Cam-Winget (ncamwing)" , "opsec@ietf.org" , "tls@ietf.org" Message-ID: <20200821003948.04bc5308@totoro.tlrmx.org> In-Reply-To: <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja> References: <20200817163938.07580cee@totoro.tlrmx.org> <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> <20200819234314.29c3bbdc@totoro.tlrmx.org> <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudduuddgvdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfesthejredtredtvdenucfhrhhomheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqeenucggtffrrghtthgvrhhnpeetjeeludefvddtkeffgffgudfgveffffegtdeuleffkedvvedvfedvjedvleelueenucfkphepkedurddvrdekledruddvgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehtohhtohhrohdrthhlrhhmgidrohhrghdpihhnvghtpeekuddrvddrkeelrdduvdegpdhrvghtuhhrnhdqphgrthhhpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqpdhmrghilhhfrhhomhepnhhjlhesthhlrhhmgidrohhrghdpnhhrtghpthhtohepthhlshesihgvthhfrdhorhhg Archived-At: X-Mailman-Approved-At: Fri, 21 Aug 2020 08:26:35 -0700 Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:40:00 -0000 On Thu, 20 Aug 2020 09:58:58 -0400 Roelof DuToit wrote: > As co-author I am not a proponent of passive TLS inspection - not > least because of the ossification implications. It cannot be labeled > as ineffective though (see further comments below), even if the > document strongly hints at not using passive TLS inspection in a > post-TLS-1.2 world. Mostly I endorse Ekr's comment that a document like this should actually spell out any convolutions and conditions necessary to the effective use of passive inspection. I would try to find time to examine a revised document that did this. But I do want to address one such in particular now: > 1. Policy-based control over the use of RSA key exchange. It should > not be allowed. Qualys estimates that when TLS 1.3 was finalised RSA was required for about 5.7% of web sites (it had been larger previously). That's a pretty huge caveat. The same document we're discussing, draft-ietf-opsec-ns-impact-02 actually several times relies upon RSA key exchange (in section 5.3) for methods it says will now be impacted by TLS 1.3 because that doesn't allow RSA key exchange. As written there's no problem, but it seems to me that if you add a condition saying to disallow RSA key exchange in section 5.1, this has the effect of implicitly rebuking this approach from section 5.3. That would be a little bit silly in a single document but it's even sillier when you recall that actually products in this space straddle both categories. Nick.