Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Eliot Lear]

Hi there IESG

I support the intent of this document, and I think the approach to update the 
various documents listed is the right one.

Because of the breadth of documents updated, I wonder if at least some 
implementation guidance is warranted, in order to assist developers and even 
perhaps administrators.  Perhaps in some cases these are compile-time or even 
run time options.  I’d suggest guidance for common libraries, such as Microsoft 
.NET, OpenSSL, GNUTLS, and WolfSSL. Better to give that guidance to get people 
to TLS 1.3 rather than 1.2, of course.  Even informational references would be 
fine, as assuredly some of this guidance exists.

Thanks,

Eliot




> On 9 Nov 2020, at 23:26, The IESG  wrote:
> 
> 
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1'
>   as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document, if approved, formally deprecates Transport Layer
>   Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
>   Accordingly, those documents (will be moved|have been moved) to
>   Historic status.  These versions lack support for current and
>   recommended cryptographic algorithms and mechanisms, and various
>   government and industry profiles of applications using TLS now
>   mandate avoiding these old TLS versions.  TLSv1.2 has been the
>   recommended version for IETF protocols since 2008, providing
>   sufficient time to transition away from older versions.  Removing
>   support for older versions from implementations reduces the attack
>   surface, reduces opportunity for misconfiguration, and streamlines
>   library and product maintenance.
> 
>   This document also deprecates Datagram TLS (DTLS) version 1.0
>   (RFC6347), but not DTLS version 1.2, and there is no DTLS version
>   1.1.
> 
>   This document updates many RFCs that normatively refer to TLSv1.0 or
>   TLSv1.1 as described herein.  This document also updates the best
>   practices for TLS usage in RFC 7525 and hence is part of BCP195.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent 
> Submission Editor stream)
>rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent 
> Submission Editor stream)
>rfc5023: The Atom Publishing Protocol (Proposed Standard - IETF stream)
>rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile 
> for High-Volume Environments (Proposed Standard - IETF stream)
>rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile 
> for High-Volume Environments (Proposed Standard - IETF stream)
>rfc5018: Connection Establishment in the Binary Floor Control Protocol 
> (BFCP) (Proposed Standard - IETF stream)
>rfc4992: XML Pipelining with Chunks for the Internet Registry Information 
> Service (Proposed Standard - IETF stream)
>rfc4992: XML Pipelining with Chunks for the Internet Registry Information 
> Service (Proposed Standard - IETF stream)
>rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) 
> (Proposed Standard - IETF stream)
>rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - 
> IETF stream)
>rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - 
> IETF stream)
>rfc4964: The P-Answer-State Header Extension to the Session Initiation 
> Protocol for the Open Mobile Alliance Push to Talk over Cellular 
> (Informational - IETF stream)
>rfc4964: The P-Answer-State Header Extension to the Session Initiation 
> Protocol for the Open Mobile Alliance Push to Talk over Cellular 
> (Informational - IETF stream)
>rfc4851: The Flexible Authentication via Secure Tunneling Extensible 
> Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
>rfc4851: The Flexible Authentication via Secure Tunneling Extensible 
> Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
>rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange 
> over the Internet (Informational - IETF stream)
>rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange 
> over the Internet (Informational - IETF stream)
>rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - 
> IETF stream)
>rfc4791: Calen

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hiya,

On 28/11/2020 04:39, Gary Gapinski wrote:

Looking at https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09
 §2:

   * §2 ¶5 has «TLS 1.3, specified in TLSv1.3 [RFC8446]…».
   * §2 ¶4 has «TLSv1.2, specified in RFC5246 [RFC5246]…»
   * §2 ¶3 has «TLS 1.1, specified in [RFC4346]…»

Were these variant ( specified in plaintext+[link], specified in link+[link],
specified in [link] ) citation forms deliberate?


Nope. We'll make 'em more consistent.


TLS 1.2 was given a "v" for version; the others not.


Ack,


§2 ¶1 cites RFC 7457 twice with hyperlinks.

The document references in square brackets link directly to the documents;
elsewhere in the document, many square-bracketed document references are
intra-document links to §10, though RFC references seem mostly to be direct
(i.e., not intra-document). Perhaps all square-bracketed links should be
intra-document links to §10? RFC 7322
 seems adopt the same seemingly
arbitrary (some links are direct; some intra-document) hyperlinking without any
related etiquette guidance.


Those links are tool-generated and not part of the document
source. I'll double check but I think the change required
there is a tooling change and nothing to do with this draft.

Thanks,
S.




Regards,

Gary


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hi Keith,

In general I agree with Ekr's position on this (not a
surprise as a co-author I guess:-) so I won't repeat
arguments. I do have one question below though that
wasn't yet touched upon...

On 28/11/2020 00:44, Keith Moore wrote:
While I agree that TLSv1.0 and TLSv1.1 should be avoided as much as 
possible, I believe this document fails to consider that there are old 
systems that are still in use that cannot be upgraded.   Strict 
implementation of the MUST NOT rules in this document can even prevent 
those systems from being upgraded at all, even when upgrades are 
available.   Strict implementation of the MUST NOT rules in this 
document can also make old embedded systems with built-in servers 
effectively unusable or require the operators of such systems to disable 
TLS entirely.


In general, it should not be assumed that old systems can be upgraded, 
or that old systems are feasibly replaced with newer systems.   There 
are several reasons for that.


  * One is that operating system vendors sometimes stop supporting old
    hardware, and client or server software vendors stop supporting old
    operating systems.
  * Some platforms are certified for medical use with specific versions
    of operating systems for which OS or software upgrades would require
    recertification, and the manufacturers of such systems do not always
    recertify their platforms with the latest operating systems.
  * Some embedded systems either do not have provision for firmware
    upgrades and/or are operated on disconnected networks so that
    upgrades are cumbersome (and may violate company security policies);
    those products sometimes do not have the option of firmware updates
    because there is no revenue stream to support them and they wouldn't
    be used anyway.  And yet, it's common for embedded systems to be
    configured, queried, or monitored using HTTP[S].
  * I have also worked on products for manufacturing environments for
    which upgrades were forbidden; any firmware upgrade would have
    required shutting down the assembly line for days and retesting the
    whole thing.
  * Finally, sometimes software or firmware "upgrades" take away
    functionality present in earlier versions, so that the "upgrade" may
    make that computer useless for its intended purpose.


In earlier iterations of the draft we included some survey
results for TLS version usage in web, mail and OSes. I think
your argument to special-case embedded systems or systems
without s/w update would be a lot stronger if you or someone
else had data to offer about the prevalence of these systems
and the TLS versions they support. I realise that sometimes
people can't name product versions (but then sometimes one
can!) or be very precise about deployments but people have
figured out ways to measure these things in other contexts.
(Note: I said "stronger" above - I'm not dismissing your
point due to the current lack of concrete data.)

Cheers,
S.



In general, there are two kinds of problems caused by disabling of TLS 
1.0/1.1 in implementations:


1. Old clients cannot talk to newer servers

Again, sometimes clients run on old machines that cannot be upgraded or 
replaced.   When servers refuse to support old TLS versions, an old 
client may refuse to work at all.   It is not always feasible to 
download the same file from a different machine or different client 
program.


I have seen this happen when trying to upgrade some software on an old 
MacBook Pro.   The software I was trying to download could only be 
downloaded from Apple using Safari on a Mac. Apple's server would not 
use a version of TLS compatible with the old version of Safari I had, 
and there were no upgrades to that version of Safari.  I tried 
downloading the software from another (non-Apple) computer; the server 
would not let me do so.   I didn't have a more current Mac to use, 
didn't wish to buy one, and the pandemic made using someone else's Mac 
infeasible.


The best idea I came up with was to set up a web proxy that supported 
more recent versions of TLS, and configure Safari to communicate via 
that web proxy.   But I never found time to do that.


I'm not saying the RFC should be fixed for me, but rather, that I've 
personally experienced a situation that many other people undoubtedly 
have experienced and will experience after publication of this RFC. 
(Some servers are already following these recommendations.)


I have also worked with systems operated by a major petroleum producer 
(who will remain unamed) who had (unsurprisingly) very elaborate 
security measures.   Their internal networks were inaccessible from 
outside systems except via multiple layers of remote desktop.  So any 
client software to be used had to be software already vetted and 
installed on their internal machines.   But presumably because of the 
difficulty of vetting new software, the only browser available was MSIE 
5 [don't remember which version of Windows].   (I

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hi Eliot,

On 28/11/2020 10:45, Eliot Lear wrote:

Hi there IESG

I support the intent of this document, and I think the approach to
update the various documents listed is the right one.


Cool.


Because of the breadth of documents updated, I wonder if at least
some implementation guidance is warranted, in order to assist
developers and even perhaps administrators.  Perhaps in some cases
these are compile-time or even run time options.  I’d suggest
guidance for common libraries, such as Microsoft .NET, OpenSSL,
GNUTLS, and WolfSSL. Better to give that guidance to get people to
TLS 1.3 rather than 1.2, of course.  Even informational references
would be fine, as assuredly some of this guidance exists.


Text welcomed of course, but I think it's mostly a case of
doing the s/w update for the library and then either waiting
'till the library developer defaults to TLSv1.2 or better, or
else various config file or API options that don't differ
that much from library to library. I can check it out before
we're done (again, text welcome if someone else wants to do
that), but not sure it'll be that useful in the end TBH.
(I'll get back when I get to doing that.)

Cheers,
S.



Thanks,

Eliot





On 9 Nov 2020, at 23:26, The IESG  wrote:


The IESG has received a request from the Transport Layer Security
WG (tls) to consider the following document: - 'Deprecating TLSv1.0
and TLSv1.1'  as Best
Current Practice

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the last-c...@ietf.org mailing lists by 2020-11-30.
Exceptionally, comments may be sent to i...@ietf.org instead. In
either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract


This document, if approved, formally deprecates Transport Layer 
Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). 
Accordingly, those documents (will be moved|have been moved) to 
Historic status.  These versions lack support for current and 
recommended cryptographic algorithms and mechanisms, and various 
government and industry profiles of applications using TLS now 
mandate avoiding these old TLS versions.  TLSv1.2 has been the 
recommended version for IETF protocols since 2008, providing 
sufficient time to transition away from older versions.  Removing 
support for older versions from implementations reduces the attack 
surface, reduces opportunity for misconfiguration, and streamlines 
library and product maintenance.


This document also deprecates Datagram TLS (DTLS) version 1.0 
(RFC6347), but not DTLS version 1.2, and there is no DTLS version 
1.1.


This document updates many RFCs that normatively refer to TLSv1.0
or TLSv1.1 as described herein.  This document also updates the
best practices for TLS usage in RFC 7525 and hence is part of
BCP195.




The file can be obtained via 
https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/







No IPR declarations have been submitted directly on this I-D.



The document contains these normative downward references. See RFC
3967 for additional information: rfc5024: ODETTE File Transfer
Protocol 2.0 (Informational - Independent Submission Editor
stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational -
Independent Submission Editor stream) rfc5023: The Atom Publishing
Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight
Online Certificate Status Protocol (OCSP) Profile for High-Volume
Environments (Proposed Standard - IETF stream) rfc5019: The
Lightweight Online Certificate Status Protocol (OCSP) Profile for
High-Volume Environments (Proposed Standard - IETF stream) rfc5018:
Connection Establishment in the Binary Floor Control Protocol
(BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining
with Chunks for the Internet Registry Information Service (Proposed
Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the
Internet Registry Information Service (Proposed Standard - IETF
stream) rfc4976: Relay Extensions for the Message Sessions Relay
Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The
Message Session Relay Protocol (MSRP) (Proposed Standard - IETF
stream) rfc4975: The Message Session Relay Protocol (MSRP)
(Proposed Standard - IETF stream) rfc4964: The P-Answer-State
Header Extension to the Session Initiation Protocol for the Open
Mobile Alliance Push to Talk over Cellular (Informational - IETF
stream) rfc4964: The P-Answer-State Header Extension to the Session
Initiation Protocol for the Open Mobile Alliance Push to Talk over
Cellular (Informational - IETF stream) rfc4851: The Flexible
Authentication via Secure Tunneling Extensible Authentication
Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4851:
The Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST) (Informational - IETF
stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business
Data Interchange over

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Nick Lamb]

On Fri, 27 Nov 2020 23:43:42 -0500
Keith Moore  wrote:

> I'm aware of that.  But what really is the point of a cert
> (especially one issued by a public CA) that has an RFC1918 address as
> its subject? Not that it matters that much because the vast majority
> of sites using embedded systems aren't going to bother with them.
> Most of those systems probably don't support cert installation by
> customers anyway.

You won't get such a certificate from a public CA (presumably meaning
a CA issuing in the Web PKI). They're subject to the CA/B Baseline
Requirements which explicitly forbid this (in 7.1.4.2.1):

  CAs SHALL NOT issue certificates with a subjectAltName extension or
  subject:commonName field containing a Reserved IP Address or Internal
  Name.

As I understand it the purpose of the IETF is to develop and promote
Internet standards, to the extent that people enjoy using some of these
standards to do things that aren't part of the Network they are welcome
but it doesn't make sense for the IETF to focus on these uses.

As an IETF draft the die-die-die work addresses the Internet, and it
seems to me that ekr's assessment is entirely correct in that context.

Nick.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Issues
--
* tlswg/draft-ietf-tls-esni (+1/-0/💬2)
 1 issues created:
 - Potential SNI leak via cross-ECH resumption (by kjacobs-moz)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/369 


 2 issues received 2 new comments:
 - #369 Potential SNI leak via cross-ECH resumption (1 by davidben)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/369 
 - #354 "Don't stick out" considerations for ECH (1 by kjacobs-moz)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/354 




Pull requests
-
* tlswg/draft-ietf-tls-esni (+3/-4/💬1)
 3 pull requests submitted:
 - Fix ClientHelloOuterAAD.outer_hello length (by cjpatton)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/368 
 - Specify the backend server's behavior when "ech_is_inner" is not empty (by cjpatton)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/367 
 - Editorial pass and advance ECHConfig.version to ECH-09 (by cjpatton)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/366 


 1 pull requests received 1 new comments:
 - #368 Fix ClientHelloOuterAAD.outer_hello length (1 by davidben)
   https://github.com/tlswg/draft-ietf-tls-esni/pull/368 


 4 pull requests merged:
 - Fix ClientHelloOuterAAD.outer_hello length
   https://github.com/tlswg/draft-ietf-tls-esni/pull/368 
 - Quick editorial pass.
   https://github.com/tlswg/draft-ietf-tls-esni/pull/365 
 - Specify the backend server's behavior when "ech_is_inner" is not empty
   https://github.com/tlswg/draft-ietf-tls-esni/pull/367 
 - Editorial pass and advance ECHConfig.version to ECH-09
   https://github.com/tlswg/draft-ietf-tls-esni/pull/366 


* tlswg/dtls-conn-id (+1/-0/💬12)
 1 pull requests submitted:
 - Update to new (hopefully) injective MAC structure as discussed in the 
meeting and on-list (by ekr)
   https://github.com/tlswg/dtls-conn-id/pull/77 


 1 pull requests received 12 new comments:
 - #77 Update to new (hopefully) injective MAC structure as discussed in the 
meeting and on-list (12 by boaks, ekr, kaduk, thomas-fossati)
   https://github.com/tlswg/dtls-conn-id/pull/77 


* tlswg/tls-subcerts (+1/-0/💬0)
 1 pull requests submitted:
 - It should verify for client and server auth (by claucece)
   https://github.com/tlswg/tls-subcerts/pull/82 


* tlswg/tls-exported-authenticator (+1/-0/💬0)
 1 pull requests submitted:
 - Grammar fixes (by claucece)
   https://github.com/tlswg/tls-exported-authenticator/pull/67 



Repositories tracked by this digest:
---
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/external-psk-design-team
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls