Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

"Eric Wang (ejwang)" <ejwang@cisco.com> Mon, 27 July 2020 21:21 UTC

Return-Path: <ejwang@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA63A07B9; Mon, 27 Jul 2020 14:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DJAL6wFA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Kp7Gma/0
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 h3vRRy_K0aAv; Mon, 27 Jul 2020 14:21:01 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7783A07B3; Mon, 27 Jul 2020 14:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34449; q=dns/txt; s=iport; t=1595884861; x=1597094461; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=DJAL6wFAhxAou1rXA4zKpGL26LybjxVcYg1rLKN2isBo7ggkFGknumEr D2U7HfrOGOmKxhwZ4TKF+iiGvpWJkOxssj4AQiPCqiXu21GgqdbQjiZ8Y Sf58CjFBAL7/rAidUE/eUpRZWfGpxx5ym7+yFHXXYFbHsyfakE+Buvz8c k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AXGWlzRP3FipJiEyWfjol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3lPMVJ/QrfNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHXq2e5qz8fBh?= =?us-ascii?q?u5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYCABtRB9f/5BdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy8jLgdvWC8sCoQqg0YDjTAlmGGBQoERA1ULAQEBDAEBGAEMCAI?= =?us-ascii?q?EAQGETAIXghACJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEEAQEQCwYdAQE?= =?us-ascii?q?jCQYFAQ8CAQgYIAcDAgICJQsUEQIEDgUigwQBgX5NAy4BDqRVAoE5iGF2gTK?= =?us-ascii?q?DAQEBBYUZGIIOAwaBOIJtg1mGNxqCAIERJwwQgk0+glwBAQIBgScBEgEJBhE?= =?us-ascii?q?YFoJpM4ItjyWDO4ZZi1KPXoEFCoJeiFaRGAMegnuJSJMhk36IRpEWg1YCBAI?= =?us-ascii?q?EBQIOAQEFgWojZ3BwFRohKgGCPj4SFwINjh6DcYUUhUEBdAI1AgYBBwEBAwl?= =?us-ascii?q?8jgIBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,403,1589241600"; d="scan'208,217";a="518095588"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 21:21:00 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 06RLKx3s006583 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 21:21:00 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 16:20:59 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 16:20:59 -0500
Received: from NAM04-BN3-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; Mon, 27 Jul 2020 17:20:59 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LiuaVLBvKmdRKBCOOYeN+tDj09Euhm2nT/X9NzEWI1ZAleYS1kDvcOMTwk8mliwa/W8oqVg70BYo0WQbb6M6AtHFINT80fmEThGmONeVyKJIihuShY8/LW7MBp8ysRZ0Gl6PQ9p8MCN/wMueoxLwFDc9yuDVSN4uHIGCx8lM0sCSEpV3LsMub1wfH4w2UTluUm2+2V4wa9Dh8ZN7eKADo4zXn0MuoVVtis4XXlLmX0iGFfIUa7yfT1SsJvXum80VsGppmvFkF3eF/8YWz9MurTcDwmCRCedPLo1AP/rL6Wrij3dElbFqAbYA7diAalJvR4TL27khyjXCIKQS+fVSIw==
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=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=hZmNmUAf5/kBYHiZTh+q7gJ9aTX7hKQvIUFQLfJ8qN4osLrIFsYUCorTYxwiAvckiUm06X1igB9Wt2YVFFDncU9ME3RUMa1sZ9vSHE/W70Lwwrw4jJx5BQJrntL08Xm1qsgi+vhOLQNUka6vwkMzTXpIau3oqecnB3ZvXg6qNVjGRJF7ccoudsXfMJnHugS94x+xdv0CNaTc+gbnm6Dy3xsHGgSTHMtZfTorqd+rYiuZRvAWulmIdWH68JtPToEJnow5MMAUjipXqsKYWRmjp7fGS7RMR1aJUbTYiRRYVWIcPOlhWyrU8zRP7naHMxiKSEyjHaw/w9rA0ouqUiftlw==
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=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=Kp7Gma/0xz8z93h4gxJ9EmcRI8fdXi0+oNj76TjGgKHRHmejvZmeWOhOMyPnE/ulQkdaoeMxkjl5CJnu7vTuR5jsKEUG1qevBgoAChoZ4gHgyuRucvTt/xV50lCk5oBfnZOUcISinvlQB27c0E3xWKHPHaWSYxVlW1uo+WpU/LU=
Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB3526.namprd11.prod.outlook.com (2603:10b6:a03:88::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Mon, 27 Jul 2020 21:20:57 +0000
Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 21:20:57 +0000
From: "Eric Wang (ejwang)" <ejwang@cisco.com>
To: Nick Harper <nharper=40google.com@dmarc.ietf.org>
CC: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, OpSec Chairs <opsec-chairs@ietf.org>, OPSEC <opsec@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp
Thread-Index: AQHWZBBX3s7yu2FQsE+4XY6AWPSf36kbYlAAgAAJxoCAAAuNgIAAd96A
Date: Mon, 27 Jul 2020 21:20:57 +0000
Message-ID: <5425303E-F86B-4D4C-9496-7F9E089D1BA5@cisco.com>
References: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com> <CAFU7BAS=ymUPTAGB_fOSrHTG0OajV1n5M1-yOBWxvGam-a89AA@mail.gmail.com> <d9d6d8c2-3916-be28-d01f-f040a28ce361@cs.tcd.ie> <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> <CAHbrMsC6AL=CrpponmJaab4DijY=mgqbUN6YFaC8eHYf-aeORQ@mail.gmail.com> <CACdeXiL1J-WzZM4XAudRbz7NZWOCquH=SXZL9BkRLO3NpsfTTg@mail.gmail.com>
In-Reply-To: <CACdeXiL1J-WzZM4XAudRbz7NZWOCquH=SXZL9BkRLO3NpsfTTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.15)
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [128.107.241.182]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1a233038-c5c4-40f4-71ff-08d83272f444
x-ms-traffictypediagnostic: BYAPR11MB3526:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3526621DEF5FC2160CE32042D0720@BYAPR11MB3526.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GGwU3PeWZDzgPQ+w6z7pj3VWhJCLVAOm15UjdU15pdF2SNrD1UtUc0BgJqIFyAOj79KYcjQsdmAdlKITMQTKqdCysWnUjh6Kq89bF6Hx7GxsBIegcru+fiBw6HifnfB/NT8ZVzwVSVCuCeVQmKTKXCFLaIm/3EtNE7y1D8p+xqRwiRzTCxIxQVpzGHC93c3jIxZ5/v1hbm0TNX0kBkSC2RyYK2ebkUgVxO51crIZS8Z3n/vuePKoD/zNEdQ6/zEQpd2KlDJpM8QL+GUZFYMS/KOJpZo4tYjNM6o1H1yotYueF5GStQVC6WxU7ad6es23HyoEX0VW2FN4rFyLd89D+MC0gCGd3Vf6aQxHmCdCvPddXlMxYVzMMsRu2Pig/isELZmLDrEUFGqJObkrdEoTmw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(4326008)(26005)(76116006)(2906002)(66446008)(66556008)(66476007)(8676002)(64756008)(6512007)(86362001)(66946007)(186003)(8936002)(2616005)(6486002)(166002)(33656002)(54906003)(6506007)(316002)(53546011)(478600001)(36756003)(966005)(83380400001)(71200400001)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: hbbyIHU4xOQLXrsrhRENi3dDkK8M5tEEG3pLvDNN0flxL4j4bPu/LqeDCVRTLtc4M9xNtUICXML/yvpAkz+dUpcTbylcWG5JhR07f6MBg+YAmUlELQwWvXBRnw0xpjFz3lDt+cAfbL8tx82uE3YVTrzT8md05mU1CEkFzyiTyJL0TO7MPe4bSy7d9X/dUgga09nMJBqcAFyudelhbxJfC6uK+PHmP4TOlOp2wdoPxx7YP+Ov+yZe8Kq5yLl7th6DzM1bInWzsQJV8UpZkJLdEMsL+iNuUz/6fxTjVIDfjuLG7WWKPrgbmAM30Px2bc4ALDCtS137DYcBvGVZOANcD5z8MF6U3bLLBOK+2cQk6gV8RYWoMvXHoPJ8kBYQwEF4YFjZXOfMDJg67ZgqEMnH9SlTWP4Jaiy9b+XIuIVfM/n5eFlUyDAT91KvgJndjtQKBZ8jj2krqTM0cmJbUgLg/Hl7ruf/CGK7AmlkEdmT7a4fLxH5OnCuBk1A7Cwur2No
Content-Type: multipart/alternative; boundary="_000_5425303EF86B4D4C94967F9E089D1BA5ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a233038-c5c4-40f4-71ff-08d83272f444
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 21:20:57.7532 (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: br0728Zt4Evnfh8vi/0u/yOwjv2UtA3log+kE62j81Vr97hY7uq+zcjUdMOWEcih7FEVE7Emzy9LRg7guHiS2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3526
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kk_r5wCweHl78ojf6MMuK2VLxUI>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 21:21:06 -0000

Hi Nick,

Many thanks for the detailed comments.

In general, the draft tried not to repeat the TLS RFCs.  From section 4.2, “Because a TLS proxy effectively builds two TLS sessions, one with a TLS client and one with a server respectively, … The TLS server and client stacks in the TLS proxy MUST be conformant to [RFC8446] and [RFC5246].”

It was the intention with Protocol Invariants as well, but it appears the text caused some confusion in S 4.2. We will clarify it, and it is worthwhile to capture points from the cited papers too.

Section 5.3<https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-5.3> describes selective decryption which is related to your last two points.  Will update it with your comments (there are techniques to “fail open” from proxy but only possible before certain stage of the handshake).

Best,
-Eric


On Jul 27, 2020, at 7:11 AM, Nick Harper <nharper=40google.com@dmarc.ietf.org<mailto:nharper=40google.com@dmarc.ietf.org>> wrote:

As currently written, this draft has multiple problems.

Section 4 decides not to repeat the Protocol Invariants described in section 9.3 of RFC 8446. However, further sections are written assuming that a proxy acts in a way contrary to those Protocol Invariants. One such example is section 4.2 in this draft. It describes how a proxy might generate its list of cipher suites by modifying the client's list. A proxy that copies the cipher suites from the client-initiated ClientHello into its own ClientHello is violating the 1st and 3rd points of the TLS 1.3 Protocol Invariants. For a best practices document, I think it would be reasonable to reiterate the Protocol Invariants.

In addition to reiterating the Protocol Invariants, it should also summarize the advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One of the problems pointed out by those papers is that TLS proxies will make connections to a server that presents a certificate the client wouldn't accept, but because of the proxy, the client isn't aware of the certificate issues. I don't see this issue addressed at all in the draft. (A similar issue with the server selecting a weak cipher suite is possibly implied by section 4.2, but it is not spelled out well.)

If this draft is adopted, it needs to say the following things, which it currently doesn't.

- When a TLS proxy generates its ClientHello, it should be created independently from the client-initiated ClientHello. The proxy MAY choose to omit fields from its ClientHello based on the client-initiated ClientHello, but it MUST NOT add fields to its ClientHello based on the client-initiated ClientHello. This is effectively a restatement of the 1st (a client MUST support all parameters it sends) and 3rd (it MUST generate its own ClientHello containing only parameters it understands) points of the TLS 1.3 Protocol Invariants.

- If a proxy chooses to conditionally proxy TLS connections and needs more information than what is contained in the client-initiated ClientHello, then the only way to make that decision is to send its own ClientHello to the server the client is connecting to and use information observed on that connection to make the decision to proxy the pending connection.

- If a proxy chooses to not proxy some TLS connections, the proxy will fail open. The only way to avoid failing open is to proxy all connections.

On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> wrote:
I'm concerned about this work happening outside the TLS working group.  For example, the question of proper handling of TLS extensions is not addressed at all in this draft, and has significant security and functionality implications.  There are various other tricky protocol issues (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock when buffers fill, ticket (non-)reuse, client certificate linkability pre-TLS-1.3, implications of SAN scope of synthesized certificates) that could arise and are going to be difficult to get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is possible to proxy TLS correctly, and that this document is the main source for how to do it.  I think the TLS WG is the right place to make those judgments..  For the OpSec group, I think a more appropriate draft would be something like "TLS Interception Pitfalls", documenting the operational experience on failure modes of TLS interception.

On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
The document is not imposing any standards but rather provide guidelines for those implementing TLS proxies;  given that proxies will continue to exist I'm not sure why there is a belief that the IETF should ignore this.

Warm regards, Nancy

On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" <opsec-bounces@ietf.org<mailto:opsec-bounces@ietf.org> on behalf of uri@ll.mit.edu<mailto:uri@ll.mit.edu>> wrote:

    I support Stephen and oppose adoption. IMHO, this is not a technology that IETF should standardize.


    On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> on behalf of stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote:


        I oppose adoption. While there could be some minor benefit
        in documenting the uses and abuses seen when mitm'ing tls,
        I doubt that the effort to ensure a balanced document is at
        all worthwhile. The current draft is too far from what it'd
        need to be to be adopted.

        Send to ISE.

        S.

        On 23/07/2020 02:30, Jen Linkova wrote:
        > One thing to add here: the chairs would like to hear active and
        > explicit support of the adoption. So please speak up if you believe
        > the draft is useful and the WG shall work on getting it published.
        >
        > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
        > <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
        >>
        >> Folks,
        >>
        >>
        >>
        >> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
        >>
        >>
        >>
        >> Please send comments to opsec@ietf.org<mailto:opsec@ietf.org> by August 3, 2020.
        >>
        >>
        >>
        >>                                                                 Ron
        >>
        >>
        >>
        >>
        >> Juniper Business Use Only
        >>
        >> _______________________________________________
        >> OPSEC mailing list
        >> OPSEC@ietf.org<mailto:OPSEC@ietf.org>
        >> https://www.ietf.org/mailman/listinfo/opsec
        >
        >
        >
        > --
        > SY, Jen Linkova aka Furry
        >
        > _______________________________________________
        > TLS mailing list
        > TLS@ietf.org<mailto:TLS@ietf.org>
        > https://www.ietf.org/mailman/listinfo/tls
        >


_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org<mailto:OPSEC@ietf.org>
https://www.ietf.org/mailman/listinfo/opsec