Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

"Ackermann, Michael" <MAckermann@bcbsm.com> Fri, 04 December 2020 20:35 UTC

Return-Path: <mackermann@bcbsm.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 14C0B3A0FB8 for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 12:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 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, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=MAckermann@bcbsm.com header.d=bcbsm.com; dkim=pass (1024-bit key) header.d=bcbsm.com header.b=XKvgYRpe; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com header.b=GmkEt0oX
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 NLpABBOFky6d for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 12:35:53 -0800 (PST)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 3A0F13A0FC3 for <tls@ietf.org>; Fri, 4 Dec 2020 12:35:52 -0800 (PST)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id CC8221C68C0 for <tls@ietf.org>; Fri, 4 Dec 2020 14:00:34 -0600 (CST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ZIXVPM1670e2ded26; d=bcbsm.com; h=From:To:Subject:Date; b=kwZnAQblMxapjoOs1Pxg0rKuG/MeyqW2jEqmp93TK16BwvC6ypTi6NOA1iJ8VcvU iVSs5bChs2XtK2KJv0N/czuwsJ5IACRuTihtKFjqzWGuWJWsB8BbT4sr5vDdgv 6GnWuP7UhaALBkeDpYkRC3jvlrb47zu7g0urMp/dNCO/Y=;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.com; s=ZIXVPM1670e2ded26; t=1607112034; bh=WRqI1PaOyl4qbBITfnz3F8ZuniauU2XtWsc0ThYfgxg=; h=From:To:Subject:Date; b=XKvgYRpeyzAsvCWiN2yhawxJf5Sn6RAAZcM8HdiwoZzYCi3XVA1zNhPFLOnTTkcmb dTCauvwQ8nIirwtk+r8F9XgFA0CMj8bmpar/7wlmqMIyS+SwKB9q8BAzhrcAD4NMYX YRbk/YbXuEpOQ6GTbwJvPn8/RaGxc6DUTw9O3BqE=
Received: from imsva2.bcbsm.com (inetmta04.bcbsm.com [12.107.172.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.z120.zixworks.com (Proprietary) with ESMTPS id EF1281C3B8A; Fri, 4 Dec 2020 14:00:31 -0600 (CST)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C8C4FE077; Fri, 4 Dec 2020 15:00:31 -0500 (EST)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 47570FE05C; Fri, 4 Dec 2020 15:00:31 -0500 (EST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (unknown [104.47.59.172]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 4 Dec 2020 15:00:31 -0500 (EST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UcfC8nOW2rS2DIOO1Y774AAKdNxvxhr32sXpAoHmBFj2PwLEAL6Z6+1dHHDivNfzsZ7VHH3rSs2Sobl1YamBHYUp6v8C2T7XKkEJ+P7PYoeRd6ZcxSb+x+wk8JIPBP5WeeiHP1FjU+bZLseSWCo8JFJNwEuZZgXDoB+LRJZfbrK1f/PU/KEgH9WEKjBDp+rdo/n2G0pB532vbMXKM0fy3frAI/6kqwKMFcA8PFl99PQCc8lgEbYKt9ZoxKlNVezrsMfIOtk/kkT0vPtqjXbbs0eCmrLWEuxdTWWUXeIUNmH1p8hkZRsKuyL52TQtBScUjx+fMwVCdWdmV26SJo0KdQ==
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=A1Qnp5xcImFlpdLl5ZpCK0T6g8dJEh2fpo5uvsol3/Q=; b=XzyewievniDit9Le3V/z++HtkmGpSvkn3XYmiElxOeBt1SGI1Ng0rlTgp9pPYHPKUkONszFYiqFFvhHJB7LR2jRQ5RaEmBV0J68C9i+fMSFKexsWEh06gRgzNvoj1b3cfnOOz0VVzXremmqCQztNry6kQExItnttbwsF9Rhdv92fq/e9GEZ6PKYcmqhkT3YlmNytc3SwNT68ORCRebIbAKJaSQs5qnusWJMU2q0CCpaV+FGDWmLxE/OxDRkSTiyBO4hTwqYy3iXG+ZIVxgFvKjdOWv3L5qXDtPPwu7rHqoU2AVHRf43JU3fNljiGu6Uu2tb09CTbHK1ycZNB8bwXfw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bcbsm.com; dmarc=pass action=none header.from=bcbsm.com; dkim=pass header.d=bcbsm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector2-bcbsm-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A1Qnp5xcImFlpdLl5ZpCK0T6g8dJEh2fpo5uvsol3/Q=; b=GmkEt0oXEs72nN7NDslOAbEXI+/HyOzPfSipdfMqf6kT2ULQC/G8BtkAeNyFi7R1AsexrXa4AJJ2tInGOOm2w/Iyyt4i+5x2uGZsoYGNBVudL9hQHtjCwGoLFYMFfFSBOg1I19u3sRSHkiCRYLQRwF5fd7BzrSA95EKVsl6anGs=
Received: from DM6PR14MB3178.namprd14.prod.outlook.com (2603:10b6:5:118::30) by DM6PR14MB4220.namprd14.prod.outlook.com (2603:10b6:5:1ee::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Fri, 4 Dec 2020 20:00:30 +0000
Received: from DM6PR14MB3178.namprd14.prod.outlook.com ([fe80::51c:67e0:e24e:d676]) by DM6PR14MB3178.namprd14.prod.outlook.com ([fe80::51c:67e0:e24e:d676%6]) with mapi id 15.20.3632.019; Fri, 4 Dec 2020 20:00:30 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Ted Lemon <mellon@fugue.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "BRUNGARD, DEBORAH A" <db3546@att.com>, Rob Sayre <sayrer@gmail.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Watson Ladd <watsonbladd@gmail.com>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "draft-ietf-tls-oldversions-deprecate@ietf.org" <draft-ietf-tls-oldversions-deprecate@ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Thread-Index: AQHWycFTA3hjjDCsPk6YnEmb4RjXcKnmJuswgABDRoCAAJNMgIAACfpggAAHbICAAAVbcIAAG8yAgAAXXZA=
Date: Fri, 4 Dec 2020 20:00:07 +0000
Deferred-Delivery: Fri, 4 Dec 2020 20:00:00 +0000
Message-ID: <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <SN6PR02MB4512B95842251AE4C04B199CC3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <BYAPR14MB31765FD24F4DFD90F81AEE2BD7F30@BYAPR14MB3176.namprd14.prod.outlook.com> <SN6PR02MB4512CBA9E4BF6AAC778BC674C3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR14MB31789349B737961728B7691ED7F30@DM6PR14MB3178.namprd14.prod.outlook.com> <CACsn0ckvoqZ5-JPRkOXp2Mw2zeTOdyCYLvX1NV1waJ-yidTwMQ@mail.gmail.com> <SN6PR02MB45129E647485BA5794D5CF4EC3F20@SN6PR02MB4512.namprd02.prod.outlook.com> <MWHPR02MB2464CD5D5B7568E9EAC58B26D6F20@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178EC0521427BF7C3523CACD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <CAChr6SzvQK+exfgYEwfVNknMjr-Y-UJ4A7k0DkOkL9wmLQ84aQ@mail.gmail.com> <MWHPR02MB246499F35613820D45EB55AAD6F10@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178A0C152A746E41C6A01C6D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <f8486514-9726-68d0-2bc8-dccd4293017e@cs.tcd.ie> <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com>
In-Reply-To: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=bcbsm.com;
x-originating-ip: [165.225.0.109]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0a231b56-4815-436d-bbe0-08d8988f406f
x-ms-traffictypediagnostic: DM6PR14MB4220:
x-microsoft-antispam-prvs: <DM6PR14MB4220512EFA2332AD125B0BB6D7F10@DM6PR14MB4220.namprd14.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vnN58rvmFaUscQWQ3Mn5WdQs3mP8L0MbbRG7HQBvaGy+lzQNrWYmWnNGO0WTjS+6N1nMFEyZzt2aAdyaiKtahQyaqw34eviNG55vfcfKDkKyhIrIN32SlgcQ1y9mCqLE3tDWnOwsWpJM2mb0esos+VXTMq+e3z/fg1CJ4BmG+ub577hVGunPaTTpNS4VOO5ufUvMTwJ/TKq5WBhY55tQE3jICJ82ZSGfqSBTIoc/WVvTd3W7VDvnsVsnmPUDxshHTaRYmrR5gTwpa5THo3O84g5/BfqYAdcBYJfn8K5tYdzm6JSuFENOMxOohWqeycjY
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR14MB3178.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(376002)(396003)(346002)(7416002)(7696005)(6506007)(66946007)(55236004)(66476007)(52536014)(478600001)(66556008)(5660300002)(76116006)(8676002)(64756008)(26005)(53546011)(186003)(4326008)(6916009)(8936002)(66446008)(71200400001)(2906002)(6666004)(9686003)(83380400001)(54906003)(55016002)(33656002)(86362001)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?p6gZrSft2MRTc7bqU+4w9aankhdRjAtmR8hF2uqWjM/if2+Kr7lECz2SwN4l?= =?us-ascii?Q?4M4Io95tZA43XiJv+UU5WVhcoHG99rm0bKitBQ1v28y7RzkujcvrS01eo2NY?= =?us-ascii?Q?78lc/BEP8g59QcLkk0KuF26Gm10cgofCRisVx5dAJeOwc/KSQ2Ou5G0kLLNP?= =?us-ascii?Q?E4ElhyDSafdbK61YAYr/4mUEECUqLlEF0Gdd6eiblsHuDacs3PkMbk5sF6eC?= =?us-ascii?Q?D4/JgN5T1SD6Sm8zxu6l0UgEkucw3MWjOCLFg9Z+eSGvrCL0rPFL1pHFOBbq?= =?us-ascii?Q?Y53tMVDrAoYRh9eXc+Z+FmqhwqkN0R77z0GMFBuKju+5eTPNnE3xjUBYzJoC?= =?us-ascii?Q?3TDHxvcBnjUevHYndJkcnDBMS+FQMutmfthXGLJqBmkeHnJm6rl8UC7faj/9?= =?us-ascii?Q?HX63M9uphW8i2SPHxKgLHgRBcL8tPvThqDUGiqK1jMPltQ9iiuHxDnnUaPC2?= =?us-ascii?Q?LpqiDP+ZQfZmlt96m0ANiUjRKntn7QVCxND/fiOUmpmNiVtBtgLTY1cCJe19?= =?us-ascii?Q?13QBaZlxcfQMdSoSUAQdL4+Ycn8+D0zYChiCDvdELN3KpKAJ/jeMdZS4GfmG?= =?us-ascii?Q?nNib6WzYYn9r3/ccPuuJII/xOsA3EqhL48hSrMTBJQavSlx+BgNL7EmvEMC1?= =?us-ascii?Q?Q+wAQc+p4obyfuaiiyxgzdk0aHvMhCiWPC6igEQe6POSpkh9c5ZWcm9MDv5W?= =?us-ascii?Q?BUEZAxuerKxQ6Nmf6irb5cuEOQwtg0lCXPCTpYyL4DjYU5xrq0VF0c+0pq6I?= =?us-ascii?Q?UI3mMmG/FBqim5aqVlS3b1vrMYnSmtZN4TdcJK/rk0b12wbKt9YqCXOMKtYp?= =?us-ascii?Q?KrZr1T44vifW4qUXKw39ZLYBAofpCXlx9gl03lIkngCaDdR8J5RlMaoFDbXy?= =?us-ascii?Q?KOJobw1DGDDiqFKGdoN6R/HNjqw2kQHAehgtj8h2ZbMVnPlD8hjes4bxwL3c?= =?us-ascii?Q?UzSPnQESF7EPGR35Yx8KSrfR45gtOpSN3lLKWY2op1nKentM70ufKBgYjKkm?= =?us-ascii?Q?odhk?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR14MB3178.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a231b56-4815-436d-bbe0-08d8988f406f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 20:00:30.0765 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yLeaYzvWTtrQXjpLG1z+NXtjZLfYU7bcY0sKKtoByOs5KRc+WfZf0xK7NVeFunr7rVljF0wBtcSeJlfbWgTPXw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB4220
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: fb94deb1-471a-4c8a-8de7-c78bedb8dfb3
X-VPM-MSG-ID: f8734804-849a-442f-a16c-a3387ae060f7
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Zt1wXoEiwxWewnQ2IItaXiUN3wg>
Subject: Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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: Fri, 04 Dec 2020 20:35:55 -0000

Thanks Ted
And no, I do not think that you do not take this seriously.   I think we all appreciate your  related thoughts and concerns and I thank you for expressing them.  

I do think you have misunderstood much of what has been said here.    Since that is likely my fault, let me try to clarify by responding to directly to many of your statements below: 

1. Enterprises do not expect nor want IETF to be responsible for their planning for changes in technology.    But when IETF decides to change protocols or deprecate existing technology of any sort,  it would be beneficial to all if our needs were considered and we were aware of related developments, in an effective and timely fashion.       
2. No one at any enterprise I am aware even remotely thinks that IETF is making changes to cause us or anyone else trouble.   Not even sure why you would say this.    The IETF is not as well understood by enterprises as many of us would like,  but in no way is it considered a troublemaker, adversary or any of the other things you say below that would make us seem at odds.   This area of understanding and communication is another area I hope we can collectively improve, by getting enterprises more engaged,  in some fashion or another.  
3. No one I am aware of is saying do not deprecate protocols that are obsolete..........    Not TLS or any others.    We understand and recognize this need and support it.    My comments in this thread were in regards to related timing and the realization that large organizations cannot always be as nimble as most of us technicians would like.   And to a small degree I described WHY most enterprises require more time for changes in many cases. 
4.  I don't think I or anyone else has said such changes will take 12 years as you stated.   However, 1-2 is usually a base due to budget and planning cycles at large orgs. 
5. I appreciate your advice on which vendors to deal with and how, but I do not view this as a vendor issue and do not have any current issues with any vendors on any related issues.    But I do agree, as stated several times in this Email chain,  that I would like to see enterprise requirements and engagement much earlier on in IETF processes.    You mention 12 years once again referring to how late we are and I am again not sure where that comes from, but I very much hope for earlier on involvement, in the future. 
6. Once again, in NO way am I or anyone else saying that the IETF should back off and not say these protocols or any others are not obsolete, not problematic or should not be deprecated.     

I hope the above makes sense and clarifies much of what I was trying to say.     IMHO we have taken this as far as we can or should on this list topic,  but hopefully improving enterprise and IETF communication/involvement discussions can be continued on other lists or in other fashions, as has been suggested by Barbara and Deborah.    Assuming this occurs, and I hope it does,  I hope you can be involved, as you are a greatly respected member of the IETF community and could add a lot to that discussion.  

Thanks again for taking this seriously!

Mike


-----Original Message-----
From: Ted Lemon <mellon@fugue.com> 
Sent: Friday, December 4, 2020 12:21 PM
To: Ackermann, Michael <MAckermann@bcbsm.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>; BRUNGARD, DEBORAH A <db3546@att.com>om>; Rob Sayre <sayrer@gmail.com>om>; Peter Gutmann <pgut001@cs.auckland.ac.nz>nz>; Watson Ladd <watsonbladd@gmail.com>om>; Eliot Lear <lear=40cisco.com@dmarc.ietf.org>rg>; last-call@ietf.org; tls-chairs@ietf.org; draft-ietf-tls-oldversions-deprecate@ietf.org; STARK, BARBARA H <bs7652@att.com>om>; tls@ietf.org
Subject: Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[External email]


Michael, fundamentally the disconnect here seems to be that the IETF could ever be responsible for helping businesses to figure out how to plan for changes in technology _other_ than by doing work like this. Deprecating old versions of protocols is exactly what the IETF should be doing. This is how the signal burbles up through your vendors to you.

I think it's useful for folks from enterprises to show up and pay attention to this, but it's important to recognize that the reason we are making these changes is not to cause you trouble. It's to try to help you to avoid trouble. If you come to the IETF with the goal in mind to get us to not deprecate protocols that are obsolete and have known attacks that the newer version of the protocol fixes, that's just not the right model. We aren't the adversary here. The IETF is not causing the protocol to be obsolete. The IETF is simply observing that the protocol is in fact obsolete, and it's past time to stop using it. That is, we are observing a fait accompli over which we have no control.

The reason we do this is in the hope that you will do what you need to do to protect your customers from this fait accompli. The only thing that we could do differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version of a protocol, that's an indication of some kind of systemic problem. It's not a problem the IETF can solve. What I heard you saying at the beginning of this problem was that the IETF needed to understand your operational realities. But the implication is that we don't understand your operational realities. That's not what's going on here. What's going on here is that we simply can't do anything about your operational realities.

The fact that we can't do anything about them does not mean that TLS 1.1 shouldn't be deprecated. It just means that you, not the IETF, need to take the next step: now that we have told you TLS 1.1 is so obsolete that nobody should be using it anymore, you need to integrate that into your planning. You need to communicate with your vendors. You need to budget for whatever your plan of action is going to be. If you find yourself in an untenable situation because of this, you need to learn from that and change your planning methodology so that you aren't caught up short next time a protocol needs to be obsoleted.

Don't do business with vendors who do not have a plan for how to deal with this problem. Get it in the purchasing agreements. Get it in the service provider contracts. Begin planning your transition to the new protocol the day it's published, or ideally as soon as you become aware that it's going to be published. Don't wait until we publish a document twelve years later saying that it's now officially obsolete.

This is a very important problem, and I'm sorry if my previous note made it seem like I don't take it seriously. I do. But it's not a problem that the IETF can solve. If the IETF were to decide not to say that the protocol is obsolete, that wouldn't solve it.  You have the problem whether we tell you you have the problem or not.



The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.