Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Keith Moore <moore@network-heretics.com> Sat, 28 November 2020 03:39 UTC
Return-Path: <moore@network-heretics.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 98DCE3A0DC8; Fri, 27 Nov 2020 19:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level:
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 1fgcFLc1qswL; Fri, 27 Nov 2020 19:39:52 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625593A0DD4; Fri, 27 Nov 2020 19:39:52 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 829A15C017D; Fri, 27 Nov 2020 22:39:51 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 27 Nov 2020 22:39:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=z67HtSCrFpG2Bv9s3V+SgJGH4EQQyImsQQwe2nEZP 0I=; b=cu3PiuA6n+7txDksP8yZIIb8wYFMke944TtWC3XlNkaUolZkq9m+nnH2V 6AXFA0LzduqZgjudo+pD7UfI6ooME0Wu5g3RwuAf0/qCsRAVgozAqO8YsEYuVPO6 Y5lWZdOOKuAQDA2ny5P8Y/OMRpDx6KnVxfmZd1Dx0nsOq5RIh2XiIGrc5FUe7Hnr X0duu023/MMqV75D1DuEGLvV5KFlcSvKcZZcnPEEeD3sQltvhWS2xYA+NEgGRSRg egC3YMHHkkFebuFa0K49myCy1+BYhNaO2lrM5pOZ60r4dohQTgRMvC8v551DLybH oIMoc3SwqB9t3/lwDLjrSHgyKFCKg==
X-ME-Sender: <xms:hsbBX3nYbtM9puSY2yzAiq9WL_TWOzWBJ_BMF9ySevMNjfU2a_Defw> <xme:hsbBX639MGJK5zbD7x0-SPAJodAvTSWr4YxokfRXSWLf_vIEcjheac_hsQnE-OQ_t EP9EoVj6ZH5iA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehhedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:hsbBX9rIoat7yyhYc1VXehZx1UrijIq-BZz8SuInrroDGJitJ94y4g> <xmx:hsbBX_nMMeiJV8WRb5c4CbFFT3Y-gLH_mbsxwbdnGW8oJz2hDjoGGQ> <xmx:hsbBX13AK7vnnpMhpO42FSFf-cFyROMKjLZxQUVcXc9QDbCFVAVoyg> <xmx:h8bBX28eDj8aCgGCFz_sGZ5y1mxzBzjNDsHnv7avKlP-kIcGoha_nA>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D22D3280063; Fri, 27 Nov 2020 22:39:50 -0500 (EST)
To: Eric Rescorla <ekr@rtfm.com>
Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate@ietf.org, tls-chairs <tls-chairs@ietf.org>, tls@ietf.org
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com> <CABcZeBPCccfDuGyZC-y88-dapjWYy57YRWWK3vsFOGM5Bxa+8Q@mail.gmail.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <584c7749-6986-0329-873c-2d1ff8b55251@network-heretics.com>
Date: Fri, 27 Nov 2020 22:39:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBPCccfDuGyZC-y88-dapjWYy57YRWWK3vsFOGM5Bxa+8Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_j_9s66K-xil3Cgd4aHeMhDYzNU>
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: Sat, 28 Nov 2020 03:39:55 -0000
On 11/27/20 9:53 PM, Eric Rescorla wrote: > Keith, > > Thanks for your note. Most of the general points you raise here were > discussed > when the TLS WG decided to move forward with this draft [0], though > perhaps some of that is not reflected in the text. Of course that > doesn't make this points invalid, so I'll try to summarize my > view of the rationale here. > > Your primary objection seems to be this has the effect of creating > interop problems for older implementations that are unable to > upgrade. This is of course true, however I think there are a number of > factors that outweight that. > > First, while certainly is problematic that people who have > un-upgraded endpoints will find they cannot connect to modern endpoints, > we have to ask what is best for the ecosystem as a whole, and IMO what > is best for that ecosystem is to upgrade to modern protocols. If you're going to try to state what's best for the ecosystem as a whole, you need to understand that "the ecosystem" (or at least, the set of hosts and protocols using TLS) is a lot more diverse than things that are connected to the Internet most of the time, well-supported, and easily upgraded. The idea that everybody should be constantly upgraded has not been shown to be workable, and there are reasons to believe that it is not workable. When you give advice that is unworkable because it is based on dubious assumptions, you might not only cause interoperability failures, you might end up degrading security in very important cases. > This > would be true in any case, but is doubly true in the case of COMSEC > protocols: What we want is to be able to guarantee a certain mimimal > level of security if you're using TLS, but having weaker versions in > play makes that hard, and not just for the un-upgraded people because > we need to worry about downgrade attacks. This sort of sounds like a marketing argument. Yes, in some sense we'd like for "TLS" to mean "you're secure, you don't have to think about it" but more realistically TLS 1.0, 1.1, 1.2, and 1.3 each provide different countermeasures against attack (and in some cases, different drawbacks, like TLS 1.3 + ESNI being blocked) and you probably do need to be aware of those differences. > While we have made efforts > to protect against downgrade, the number of separate interacting > versions makes this very difficult to analyze and ensure, and so the > fewer versions in play the easier this is. Asking everyone else to > bear these costs in terms of risk, management, complexity, etc. so > that a few people don't have to upgrade seems like the wrong tradeoff. I don't think it's a matter of "asking everyone else to bear these costs". I think TLS < 1.2 should be disabled in the vast majority of clients, and in many (probably not all) public facing servers, but some users and operators will need to have workarounds to deal with implementations for which near-term upgrades (say, for the next 5-10 years) are infeasible. > > Second, it's not clear to me that we're doing the people who have > un-upgraded endpoints any favors by continuing to allow old versions > of TLS. As a practical matter any piece of software which is so old > that it does not support TLS 1.2 quite likely has a number of security > defects (whether in the TLS stack or elsewhere) that make it quite > hazardous to connect to any network which might have attackers on it, > which, as RFC 3552 reminds us, is any network. Obviously, people have > to set their own risk level, but that doesn't mean that we have to > endorse everything they want to do. Yes, but you might actually increase the vulnerability by insisting that they not use the only TLS versions that are available to them. There's a lot of Bad Ideas floating around about what makes things secure, and a lot of Bad Security Policy that derives from those Bad Ideas. But practically speaking, you can't change those Bad Ideas and Bad Policies overnight without likely making them much worse. People have to actually understand what they're doing first, and that takes time. And there are a lot of things that have to get fixed besides just the TLS versions to make some of these environments more secure. Lots of people having to make security-related decisions simply haven't managed to deal with the complexity of the tradeoffs, so it's really common to hear handwaving arguments of the form "the only threat we need to consider is X, and Y will deal with that threat". And of course that's not anywhere nearly true, and Y is woefully insufficient. None of which is a surprise to you, I'm sure. Personally I often ask myself "what does it take to get devices in the field regularly upgraded?" And it's not a simple answer. First thing that's needed is an ongoing revenue stream to provide those upgrades in the first place, and there's a huge amount of intertia/mindshare to be overcome just for that. Second thing is you have to keep device vendor corporate overlords from repurposing that money, or by sabotaging their products in various ways, say by firing all of their domestic software engineers and outsourcing that work to contractors in another country where the level of security expertise is even lower and there's no institutional memory that keeps track of how things need to work. Then you have to convince customers not only that regular updates are a good idea, just like preventative maintenance (when many of them have very good reasons for not doing anything that could disrupt their operations), but also have to arrange for ways for those upgrades to be convenient and explicitly managed in a way that works consistently (or reasonably so) across all of their vulnerable devices. (and no, they're not going to let those devices talk to anything on the public Internet, and would have quite an uphill battle arranging for VPNs to hardware vendors). And there's still the problem of isolated sites that are disconnected from the Internet. (which of course doesn't make them safe, we know how Stuxnet worked, but it probably does make them safer than any sort of other near-term arrangement that is likely to happen) I've tried to fight these battles many times and always lost. The more pragmatic thing to do is inform operators of the risks and let them figure out how to manage them, not insist that everyone follow the same policy. > > Finally, as is often said, we're not the protocol police, so we can't > make anyone turn off TLS < 1.2. However, we need to make the best > recommendation we can, and that recommendation is that people should > not use versions prior to TLS 1.2. Ok, but the draft says MUST NOT. > If people choose not to comply, > that's of course their right. We were certainly aware at the time > this document was proposed that some people would take longer than > others to comply, but the purpose was to move the ecosystem in the > right direction, which is to say TLS >= 1.2. I believe that a MUST > is more effective than a SHOULD here. > > -Ekr > > P.S. A few specific notes about your technical points here: > > > But some of those embedded devices do support TLS, even if it's old > > TLS (likely with self-signed certs... TLS really wasn't designed to > > work with embedded systems that don't have DNS names.) > > This is not correct. TLS takes no position at all on how servers > are authenticated. It merely assumes that there is some way to > validate the certificate and outsources the details to application > bindings. For instance, you could have an IP address cert. That's technically correct of course, but I think you know what I mean. Without a reliable way of knowing that the server's certificate is signed by a trusted party, the connection is vulnerable to an MITM attack. And the only widely implemented reliable way of doing that is to use well-known and widely trusted CAs. Yes, some implementations run their own CAs and issue their own server certs and install their own root/secondary certs in clients, and they can make the subjects of those certs IP addresses or pretty much anything they want. I've done that myself. But I've never actually seen a single industrial facility do that, or express interest in doing that, no matter how many other security measures they employed. > > > For newer interactive clients I believe the appropriate action when > > talking to a server that doesn't support TLS >= 1.2 is to (a) warn > > the user, and (b) treat the connection as if it were insecure. (so > > no "lock" icon, for example, and the usual warnings about submitting > > information over an insecure channel.) > > I'm not sure what clients you're talking about, but for the clients > I am aware of, this would be somewhere between a broken experience > and an anti-pattern. For example, in Web clients, because the origin > includes the scheme, treating https:// URIs as http:// URIs will have > all sorts of negative side effects, such as making cookies unavailable > etc. For non-Web clients such as email and calendar, having any > kind of overridable warning increases the risk that people will > click through those warnings and expose their sensitive information > such as passwords, which is why many clients are moving away from > this kind of UI. UI design is a tricky art, and I agree that some users might see (or type) https:// in a field and assume that the connection is secure. But I think it's possible for UI designs to be more informative and less likely to be misunderstood, if the designers understand why it's important. I also think that IETF is on thin ice if we think we're in a better position than UI designers to decide what effectively informs users and allows them to make effective choices, across all devices and use cases. Keith
- [TLS] Last Call: <draft-ietf-tls-oldversions-depr… The IESG
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… tom petch
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Sean Turner
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Gary Gapinski
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Eliot Lear
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Lamb
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Martin Duke
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Peter Gutmann
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Viktor Dukhovni
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ben Smyth
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Olle E. Johansson
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Bill Frantz
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Joe Abley
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Gary Gapinski
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Watson Ladd
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… BRUNGARD, DEBORAH A
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… BRUNGARD, DEBORAH A
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Andrew Campling
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Hilliard
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Hilliard
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Christian de Larrinaga
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- [TLS] Results of Last Call: <draft-ietf-tls-oldve… Benjamin Kaduk
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Gary Gapinski
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch