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

From: The IESG <[email-masked]>
Date: Mon, 09 Nov 2020 14:26:04 -0800

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1'
  <draft-ietf-tls-oldversions-deprecate-09.txt> 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
[email-masked] mailing lists by 2020-11-30. Exceptionally, comments may
be sent to [email-masked] 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: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream)
    rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream)
    rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream)
    rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream)
    rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream)
    rfc4732: Internet Denial-of-Service Considerations (Informational - IAB stream)
    rfc4732: Internet Denial-of-Service Considerations (Informational - IAB stream)
    rfc4712: Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed Standard - IETF stream)
    rfc4712: Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed Standard - IETF stream)
    rfc4681: TLS User Mapping Extension (Proposed Standard - IETF stream)
    rfc4680: TLS Handshake Message for Supplemental Data (Proposed Standard - IETF stream)
    rfc4680: TLS Handshake Message for Supplemental Data (Proposed Standard - IETF stream)
    rfc4642: Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
    rfc4642: Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
    rfc4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism (Proposed Standard - IETF stream)
    rfc4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism (Proposed Standard - IETF stream)
    rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream)
    rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream)
    rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental - Independent Submission Editor stream)
    rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental - Independent Submission Editor stream)
    rfc4531: Lightweight Directory Access Protocol (LDAP) Turn Operation (Experimental - IETF stream)
    rfc4513: Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms (Proposed Standard - IETF stream)
    rfc3436: Transport Layer Security over Stream Control Transmission Protocol (Proposed Standard - IETF stream)
    rfc3436: Transport Layer Security over Stream Control Transmission Protocol (Proposed Standard - IETF stream)
    rfc3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3261: SIP: Session Initiation Protocol (Proposed Standard - IETF stream)
    rfc3261: SIP: Session Initiation Protocol (Proposed Standard - IETF stream)
    rfc2246: The TLS Protocol Version 1.0 (Proposed Standard - IETF stream)
    rfc6749: The OAuth 2.0 Authorization Framework (Proposed Standard - IETF stream)
    rfc6739: Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF stream)
    rfc6739: Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF stream)
    rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - IETF stream)
    rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - IETF stream)
    rfc6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF stream)
    rfc6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF stream)
    rfc6042: Transport Layer Security (TLS) Authorization Using KeyNote (Informational - Independent Submission Editor stream)
    rfc5878: Transport Layer Security (TLS) Authorization Extensions (Experimental - IETF stream)
    rfc5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (Informational - IETF stream)
    rfc5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (Informational - IETF stream)
    rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational - IETF stream)
    rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational - IETF stream)
    rfc5364: Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (Proposed Standard - IETF stream)
    rfc5364: Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (Proposed Standard - IETF stream)
    rfc5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF stream)
    rfc5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF stream)
    rfc5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information (Proposed Standard - IETF stream)
    rfc5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information (Proposed Standard - IETF stream)
    rfc5238: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (Proposed Standard - IETF stream)
    rfc5216: The EAP-TLS Authentication Protocol (Proposed Standard - IETF stream)
    rfc5216: The EAP-TLS Authentication Protocol (Proposed Standard - IETF stream)
    rfc5158: 6to4 Reverse DNS Delegation Specification (Informational - IETF stream)
    rfc5091: Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems (Informational - IETF stream)
    rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (Informational - IETF stream)
    rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (Informational - IETF stream)
    rfc5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed Standard - IETF stream)
    rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed Standard - IETF stream)
    rfc4346: The Transport Layer Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF stream)
    rfc2246: The TLS Protocol Version 1.0 (Proposed Standard - IETF stream)
    rfc4346: The Transport Layer Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF stream)
    rfc4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4261: Common Open Policy Service (COPS) Over Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4217: Securing FTP with TLS (Proposed Standard - IETF stream)
    rfc4168: The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc4162: Addition of SEED Cipher Suites to Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc4111: Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) (Informational - IETF stream)
    rfc4097: Middlebox Communications (MIDCOM) Protocol Evaluation (Informational - IETF stream)
    rfc4097: Middlebox Communications (MIDCOM) Protocol Evaluation (Informational - IETF stream)
    rfc3983: Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard - IETF stream)
    rfc3943: Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) (Informational - IETF stream)
    rfc3903: Session Initiation Protocol (SIP) Extension for Event State Publication (Proposed Standard - IETF stream)
    rfc6749: The OAuth 2.0 Authorization Framework (Proposed Standard - IETF stream)
    rfc3887: Message Tracking Query Protocol (Proposed Standard - IETF stream)
    rfc3871: Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
    rfc3871: Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
    rfc3856: A Presence Event Package for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    rfc3767: Securely Available Credentials Protocol (Proposed Standard - IETF stream)
    rfc3749: Transport Layer Security Protocol Compression Methods (Proposed Standard - IETF stream)
    rfc3749: Transport Layer Security Protocol Compression Methods (Proposed Standard - IETF stream)
    rfc3656: The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol (Experimental - Independent Submission Editor stream)
    rfc3568: Known Content Network (CN) Request-Routing Mechanisms (Informational - IETF stream)
    rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (Proposed Standard - IETF stream)
    rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage (Proposed Standard - IETF stream)
    rfc7030: Enrollment over Secure Transport (Proposed Standard - IETF stream)
    rfc7030: Enrollment over Secure Transport (Proposed Standard - IETF stream)
    rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream)
    rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream)
    rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
    rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
    rfc7562: Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates (Informational - Independent Submission Editor stream)
    rfc7562: Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates (Informational - Independent Submission Editor stream)
    rfc7568: Deprecating Secure Sockets Layer Version 3.0 (Proposed Standard - IETF stream)
    rfc7568: Deprecating Secure Sockets Layer Version 3.0 (Proposed Standard - IETF stream)
    rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF stream)
    rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF stream)

---

From: tom petch <[email-masked]>
Date: Tue, 10 Nov 2020 10:21:31 +0000

I am confused about the treatment here of DTLS.

The Abstract seems clear about the proposed action for TLS but then the 
second paragraph has
" This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)"

Mmmm, really?

There is a list of current RFC that Normatively reference the deprecated 
versions of DTLS and TLS; and then a list of obsolete RFC that 
Normatively reference TLS but for DTLS...?  I look, for example, for 
RFC5953 which is
obsolete and which Normatively references DTLS 1.0 but without success; 
nor can I find RFC6353 which is current and which Normatively references 
DTLS 1.0 (and which is part of a STD - not sure what that does to the 
Standard)

And, in several places
/supercede/supersede/

Tom Petch

On 09/11/2020 22:26, The IESG wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2020 11:18:14 +0000

Hiya,

> " This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)"

Sorry, I don't understand the comment. If you're just teeing
up what's below that's fine, but I wasn't sure.

> DTLS 1.0 (and which is part of a STD - not sure what that does to the 

Could be we missed some references for sure. An early
version of those lists was produced from a script I wrote
and those were edited as people commented - I always
figured we'd make that better when getting comments at
IETF LC.

Is the gist of your comment then "add 6353 and 5953 to
the relevant lists" (which'd be fine by me) or that we
need to do something else/more? (In the latter case, I'm
not sure what you're suggesting so clarifying that'd be
good.)

> /supercede/supersede/

One for the RFC editor I guess. But sure, will make 'em
all the same:-)

Thanks,
S.

>>      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)
>>      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)
>>      rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption 
>> for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
>>      rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption 
>> for Transport Layer Security (TLS) (Proposed Standard - IETF stream)
>>      rfc4744: Using the NETCONF Protocol over the Blocks Extensible 
>> Exchange Protocol (BEEP) (Historic - IETF stream)
>>      rfc4744: Using the NETCONF Protocol over the Blocks Extensible 
>> Exchange Protocol (BEEP) (Historic - IETF stream)
>>      rfc4712: Transport Mappings for Real-time Application 
>> Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) 
>> (Proposed Standard - IETF stream)
>>      rfc4712: Transport Mappings for Real-time Application 
>> Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) 
>> (Proposed Standard - IETF stream)
>>      rfc4642: Using Transport Layer Security (TLS) with Network News 
>> Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
>>      rfc4642: Using Transport Layer Security (TLS) with Network News 
>> Transfer Protocol (NNTP) (Proposed Standard - IETF stream)
>>      rfc4616: The PLAIN Simple Authentication and Security Layer 
>> (SASL) Mechanism (Proposed Standard - IETF stream)
>>      rfc4616: The PLAIN Simple Authentication and Security Layer 
>> (SASL) Mechanism (Proposed Standard - IETF stream)
>>      rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol 
>> Version 3.0 (Experimental - Independent Submission Editor stream)
>>      rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol 
>> Version 3.0 (Experimental - Independent Submission Editor stream)
>>      rfc4513: Lightweight Directory Access Protocol (LDAP): 
>> Authentication Methods and Security Mechanisms (Proposed Standard - 
>> IETF stream)
>>      rfc3436: Transport Layer Security over Stream Control 
>> Transmission Protocol (Proposed Standard - IETF stream)
>>      rfc3436: Transport Layer Security over Stream Control 
>> Transmission Protocol (Proposed Standard - IETF stream)
>>      rfc3329: Security Mechanism Agreement for the Session Initiation 
>> Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc3329: Security Mechanism Agreement for the Session Initiation 
>> Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc6739: Synchronizing Service Boundaries and <mapping> Elements 
>> Based on the Location-to-Service Translation (LoST) Protocol 
>> (Experimental - IETF stream)
>>      rfc6739: Synchronizing Service Boundaries and <mapping> Elements 
>> Based on the Location-to-Service Translation (LoST) Protocol 
>> (Experimental - IETF stream)
>>      rfc6367: Addition of the Camellia Cipher Suites to Transport 
>> Layer Security (TLS) (Informational - IETF stream)
>>      rfc6367: Addition of the Camellia Cipher Suites to Transport 
>> Layer Security (TLS) (Informational - IETF stream)
>>      rfc6042: Transport Layer Security (TLS) Authorization Using 
>> KeyNote (Informational - Independent Submission Editor stream)
>>      rfc5422: Dynamic Provisioning Using Flexible Authentication via 
>> Secure Tunneling Extensible Authentication Protocol (EAP-FAST) 
>> (Informational - IETF stream)
>>      rfc5422: Dynamic Provisioning Using Flexible Authentication via 
>> Secure Tunneling Extensible Authentication Protocol (EAP-FAST) 
>> (Informational - IETF stream)
>>      rfc5364: Extensible Markup Language (XML) Format Extension for 
>> Representing Copy Control Attributes in Resource Lists (Proposed 
>> Standard - IETF stream)
>>      rfc5364: Extensible Markup Language (XML) Format Extension for 
>> Representing Copy Control Attributes in Resource Lists (Proposed 
>> Standard - IETF stream)
>>      rfc5281: Extensible Authentication Protocol Tunneled Transport 
>> Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) 
>> (Informational - IETF stream)
>>      rfc5281: Extensible Authentication Protocol Tunneled Transport 
>> Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) 
>> (Informational - IETF stream)
>>      rfc5263: Session Initiation Protocol (SIP) Extension for Partial 
>> Notification of Presence Information (Proposed Standard - IETF stream)
>>      rfc5263: Session Initiation Protocol (SIP) Extension for Partial 
>> Notification of Presence Information (Proposed Standard - IETF stream)
>>      rfc5238: Datagram Transport Layer Security (DTLS) over the 
>> Datagram Congestion Control Protocol (DCCP) (Proposed Standard - IETF 
>> stream)
>>      rfc5091: Identity-Based Cryptography Standard (IBCS) #1: 
>> Supersingular Curve Implementations of the BF and BB1 Cryptosystems 
>> (Informational - IETF stream)
>>      rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS 
>> Authentication (Informational - IETF stream)
>>      rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS 
>> Authentication (Informational - IETF stream)
>>      rfc5049: Applying Signaling Compression (SigComp) to the Session 
>> Initiation Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc4261: Common Open Policy Service (COPS) Over Transport Layer 
>> Security (TLS) (Proposed Standard - IETF stream)
>>      rfc4235: An INVITE-Initiated Dialog Event Package for the Session 
>> Initiation Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc4235: An INVITE-Initiated Dialog Event Package for the Session 
>> Initiation Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc4168: The Stream Control Transmission Protocol (SCTP) as a 
>> Transport for the Session Initiation Protocol (SIP) (Proposed Standard 
>> - IETF stream)
>>      rfc4162: Addition of SEED Cipher Suites to Transport Layer 
>> Security (TLS) (Proposed Standard - IETF stream)
>>      rfc4111: Security Framework for Provider-Provisioned Virtual 
>> Private Networks (PPVPNs) (Informational - IETF stream)
>>      rfc3983: Using the Internet Registry Information Service (IRIS) 
>> over the Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard 
>> - IETF stream)
>>      rfc3943: Transport Layer Security (TLS) Protocol Compression 
>> Using Lempel-Ziv-Stac (LZS) (Informational - IETF stream)
>>      rfc3903: Session Initiation Protocol (SIP) Extension for Event 
>> State Publication (Proposed Standard - IETF stream)
>>      rfc3871: Operational Security Requirements for Large Internet 
>> Service Provider (ISP) IP Network Infrastructure (Informational - IETF 
>> stream)
>>      rfc3871: Operational Security Requirements for Large Internet 
>> Service Provider (ISP) IP Network Infrastructure (Informational - IETF 
>> stream)
>>      rfc3856: A Presence Event Package for the Session Initiation 
>> Protocol (SIP) (Proposed Standard - IETF stream)
>>      rfc3656: The Mailbox Update (MUPDATE) Distributed Mailbox 
>> Database Protocol (Experimental - Independent Submission Editor stream)
>>      rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for 
>> Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
>>      rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for 
>> Preventing Protocol Downgrade Attacks (Proposed Standard - IETF stream)
>>      rfc7562: Transport Layer Security (TLS) Authorization Using 
>> Digital Transmission Content Protection (DTCP) Certificates 
>> (Informational - Independent Submission Editor stream)
>>      rfc7562: Transport Layer Security (TLS) Authorization Using 
>> Digital Transmission Content Protection (DTCP) Certificates 
>> (Informational - Independent Submission Editor stream)
>>      rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for 
>> Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed 
>> Standard - IETF stream)
>>      rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for 
>> Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed 
>> Standard - IETF stream)
>>
>>
>>
>>

---

From: tom petch <[email-masked]>
Date: Tue, 10 Nov 2020 11:30:46 +0000

On 10/11/2020 11:18, Stephen Farrell wrote:
>> The Abstract seems clear about the proposed action for TLS but then
>> the second paragraph has

Try looking at the I-D References and see what you find for RFC6347 and 
see if you want to deprecate it!

>> There is a list of current RFC that Normatively reference the
>> deprecated versions of DTLS and TLS; and then a list of obsolete RFC
>> that Normatively reference TLS but for DTLS...?  I look, for example,
>> for RFC5953 which is
>> obsolete and which Normatively references DTLS 1.0 but without
>> success; nor can I find RFC6353 which is current and which Normatively
>> references DTLS 1.0 (and which is part of a STD - not sure what that
>> does to the Standard)
>

I was not looking for anything missing but, even so, came across these 
two without even looking so I am suspecting that the algorithm you used 
did not cater for DTLS 1.0, perhaps when it is in combination with TLS 
or some such, as it is in these two cases, and that there will be more 
out there that have been missed.  Perhaps a second look at the algorithm 
to work out why these got missed to get a fix on how many more there may be.

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2020 11:33:23 +0000

On 10/11/2020 11:30, tom petch wrote:
> Perhaps a second look at the algorithm 

Sure, that's reasonable. (Mightn't be today.)

Cheers,
S.

---

From: Sean Turner <[email-masked]>
Date: Tue, 10 Nov 2020 11:35:53 -0500

> On Nov 10, 2020, at 05:21, tom petch <[email-masked]> wrote:
> 
> The Abstract seems clear about the proposed action for TLS but then the second paragraph has

Sorry for any confusion introduced as a result of this typo. DTLS 1.0 is RFC4347 not RFC 6347; RFC 6347 is DTLS 1.2.

OLD:

This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)

NEW:

This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC4347)

spt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2020 16:43:05 +0000

On 10/11/2020 16:35, Sean Turner wrote:
> Sorry for any confusion introduced as a result of this typo. DTLS 1.0
> is RFC4347 not RFC 6347; RFC 6347 is DTLS 1.2.
Ah, mea-culpa then (even if someone else suggested
the change I should've spotted that;-). I'll look
back at the script algorithm in any case as Tom
suggested, just in case.

Cheers,
S.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Nov 2020 19:44:23 -0500

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 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 know this because I 
had to update product software to use GIF files instead of PNG, add some 
JS polyfills, and avoid some HTML5 features, in order to be compatible 
with their browsers).   I cite this only as another example that one 
cannot reasonably expect all client and server to be current, or even 
nearly so.

In some of these cases (when the client cannot be upgraded) an 
appropriate remedy may be to install a web proxy to allow the old client 
to communicate with the server.   Of course this can still come with 
risks, including perhaps exposure of the network traffic between the 
client and the web proxy.

In other cases, server operators might do well to consider whether, for 
their specific users, services, and content, TLS >= 1.2  is really an 
appropriate constraint to impose.   For example the ietf.org web server 
is currently supporting older versions of TLS in order to make IETF 
documents as widely available as possible, even on legacy systems.  IMO, 
that practice makes sense given IETF's mission and the fact that all of 
the documents on that server are intended to be publicly available.

(though if other services besides document download are provided on the 
same server, particularly if they use password-over-TLS authentication, 
either requiring a higher version of TLS for those services, or hosting 
those services on a different server that does require >= TLS 1.2, might 
make good sense)

2. Newer clients cannot talk to old servers

Perhaps naively, I assume that most servers reachable via the public 
Internet are upgradeable, and can/should be upgraded to support at least 
TLS 1.2.  Certainly I would recommend against exposing any server to the 
public Internet, for which security upgrades are not routinely 
provided.   So I'm /not/ talking about those servers here.

My concern here is with embedded systems that support HTTPS for 
configuration, monitoring, or control of industrial hardware. The 
security concerns are both very real (monitoring/controlling vital 
manufacturing or infrastructure and/or with potential risk to human 
lives) and often (unfortunately) not given proper regard.   Frankly, 
most operators of such systems probably use (non-TLS) HTTP or other 
cleartext interfaces to configure, monitor, and/or control such devices, 
and rely on the illusion of a completely disconnected network to let 
them sleep at night.   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.)   Again, upgrades may be unavailable, or infeasible, for many of 
these embedded devices.

Client programs in such environments may be a mixture of web browsers 
and/or dedicated special-purpose clients (which may be interactive or 
non-interactive) or proxies (e.g. to adapt a proprietary interface to 
something like OPC-UA).   If the client can just keep using old systems 
with old web browsers, they can keep using those browsers to 
control/configure/monitor those embedded devices, but if the client 
system is replaced with newer hardware and a newer OS and browser, this 
may fail.   For special-purpose clients the situation is slightly 
different - the vendors of those clients will presumably be aware of the 
limitations of the embedded systems they talk to - but deprecating TLS 
1.0 and 1.1 from libraries may make support more difficult.

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.)

For newer non-interactive clients an appropriate action might be to 
permit the client to refuse TLS < 1.2 by default but be explicitly 
configurable to use earlier versions.

For web browsers, the use of browser plugins might permit the occasional 
use of TLS < 1.2 (since most users won't need it) without the increased 
attack surface for every user.   A web proxy might also work as a 
solution for web browsers and some other http clients.

3.  Fixes to the draft

I believe the draft needs to explicitly discuss some of these cases, and 
suggest workarounds for such cases, rather than simply say "MUST NOT".   
IMO the best result from saying "MUST NOT" is that IETF security 
documents will be more likely to be disregarded since they're making 
poor recommendations for many cases.   That's not good, but worse 
results are also possible, including that the effect of these 
recommendations will be to actually reduce security for many operations, 
at least in the short term.

I realize that "MUST NOT" is attractive because it is simple and clear 
language, and that "SHOULD NOT" (even though it's the right language per 
2119 definitions) may be seen as allowing too much weasel room.   I'm 
not sure how best to address that. "MUST NOT... except..." could also be 
confusing.   Saying "MUST NOT" but also discussing exceptions in the 
document may be seen as conflicting or confusing.   I don't have a 
strong opinion about how to resolve that dilemma, but I do think some 
exceptional cases should be acknowledged somehow.   (or maybe in a 
separate RFC?)

There are probably other cases that I haven't considered.  It's easy to 
make the mistake of assuming that every application that uses TLS is 
like the web (e.g. interactive), but of course that's not the case.    
The Right Thing to do for an SMTP client relaying mail, for example, is 
probably to use the highest TLS version supported by the server, rather 
than disconnect the SMTP session and resend the message as cleartext.    
Even SSL 1.0 seems better than cleartext in that case.   Of course, the 
client could bounce the message, but given that the common expectation 
is that mail will be relayed in cleartext if necessary, bouncing seems 
like the Wrong Thing to do absent an originator-specified requirement 
for hop-by-hop encryption.

Similarly if a user is trying to read his/her mail from an old mobile 
phone, should that user's ability to read mail cease to work because the 
mail server now requires TLS 1.2 or better? Old phones don't necessarily 
have upgrades available.   And while a lot of cellular networks actively 
encourage upgrading of old phones by pessimizing their service (newer 
phones may make better use of radio bandwidth and/or support more 
frequencies), I am not in a position to say what works for the entire 
world. I have heard that old phones are still usable, and in demand, in 
many countries.

4.  Future

This is out of scope for this draft, but I also believe that these kinds 
of compatibility issues may need to be analyzed every time the IETF 
recommends to deprecate something.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2020 18:53:43 -0800

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. 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. 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.

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.

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. 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.

> 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

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.

[0] The minutes are typically sketchy but you can see that people
were concerned about endpoints having trouble upgrading:
https://datatracker.ietf.org/meeting/102/materials/minutes-102-tls-11

On Fri, Nov 27, 2020 at 4:45 PM Keith Moore <[email-masked]>
wrote:

> 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
>    - Some platforms are certified for medical use with specific versions
>    - 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.
>
> 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.
>
> 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.
>
> 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.)
>
> (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 know this because I had to update product
> software to use GIF files instead of PNG, add some JS polyfills, and avoid
> some HTML5 features, in order to be compatible with their browsers).   I
> cite this only as another example that one cannot reasonably expect all
> client and server to be current, or even nearly so.
>
> In some of these cases (when the client cannot be upgraded) an appropriate
> remedy may be to install a web proxy to allow the old client to communicate
> with the server.   Of course this can still come with risks, including
> perhaps exposure of the network traffic between the client and the web
> proxy.
>
> that practice makes sense given IETF's mission and the fact that all of the
> documents on that server are intended to be publicly available.
>
> public Internet, for which security upgrades are not routinely provided.
> So I'm *not* talking about those servers here.
>
> manufacturing or infrastructure and/or with potential risk to human lives)
> and often (unfortunately) not given proper regard.   Frankly, most
> operators of such systems probably use (non-TLS) HTTP or other cleartext
> interfaces to configure, monitor, and/or control such devices, and rely on
> the illusion of a completely disconnected network to let them sleep at
> night.   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.)   Again, upgrades
> may be unavailable, or infeasible, for many of these embedded devices.
>
> control/configure/monitor those embedded devices, but if the client system
> is replaced with newer hardware and a newer OS and browser, this may
> fail.   For special-purpose clients the situation is slightly different -
> the vendors of those clients will presumably be aware of the limitations of
> the embedded systems they talk to - but deprecating TLS 1.0 and 1.1 from
> libraries may make support more difficult.
>
> 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.)
>
> For newer non-interactive clients an appropriate action might be to permit
> the client to refuse TLS < 1.2 by default but be explicitly configurable to
> use earlier versions.
>
> attack surface for every user.   A web proxy might also work as a solution
> for web browsers and some other http clients.
>
>
> 3.  Fixes to the draft
>
> IMO the best result from saying "MUST NOT" is that IETF security documents
> will be more likely to be disregarded since they're making poor
> recommendations for many cases.   That's not good, but worse results are
> also possible, including that the effect of these recommendations will be
> to actually reduce security for many operations, at least in the short term.
>
> 2119 definitions) may be seen as allowing too much weasel room.   I'm not
> sure how best to address that.   "MUST NOT... except..." could also be
> document may be seen as conflicting or confusing.   I don't have a strong
> opinion about how to resolve that dilemma, but I do think some exceptional
> cases should be acknowledged somehow.   (or maybe in a separate RFC?)
>
> make the mistake of assuming that every application that uses TLS is like
> the web (e.g. interactive), but of course that's not the case.    The Right
> Thing to do for an SMTP client relaying mail, for example, is probably to
> use the highest TLS version supported by the server, rather than disconnect
> the SMTP session and resend the message as cleartext.    Even SSL 1.0 seems
> better than cleartext in that case.   Of course, the client could bounce
> the message, but given that the common expectation is that mail will be
> relayed in cleartext if necessary, bouncing seems like the Wrong Thing to
> do absent an originator-specified requirement for hop-by-hop encryption.
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Nov 2020 22:39:49 -0500

On 11/27/20 9:53 PM, Eric Rescorla wrote:

> 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
> 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
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.
> 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.

> not use versions prior to TLS 1.2.

Ok, but the draft says MUST NOT.

> If people choose not to comply,

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.

> such as passwords, which is why many clients are moving away from
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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2020 20:30:55 -0800

Hi Keith,

Thanks for your note. I think it's clear we see things differently,
and I don't think it's that useful to get into an extended back and
forth on those points. Accordingly I've done a fair bit of trimming to
focus on the points where I think you may have misunderstood me
(perhaps due to unclear writing on my part).

> like TLS 1.3 + ESNI being blocked) and you probably do need to be aware

Well, I can't speak to how it sounds to you, but it's not a marketing
argument but rather a security one. This is easiest to understand in
the context of the Web, where you have a reference that contains one
bit: http versus https,and all https content is treated the same, no
matter which version of TLS it uses. In that context, having all the
supported versions meet some minimum set of security properties is
quite helpful. It's true that TLS 1.0, 1.1, 1.2,and 1.3 have different
properties, which is precisely why it's desirable to disable versions
below 1.2 so that the properties are more consistent.

> attack. And the only widely implemented reliable way of doing that
> is to use well-known and widely trusted CAs.

Yes, and those certificates can contain IP addresses. Not all
public CAs issue them, but some do.

> type) https:// in a field and assume that the connection is secure.

In the Web context this is not primarily a UI issue; web client
security mostly does not rely on the user looking at the URL (and in
fact many clients, especially mobile ones, conceal the URL). Rather,
they automatically enforce partitioning between insecure (http) and
secure (https) contexts, and therefore having a context which is
neither secure nor insecurecreates real challenges. Let me give you
two examples:

* Browsers block active "mixed content": JavaScript from http origins
  loaded into an https origin. In the scenario you posit where we
  treat https from TLS 1.1 as "insecure", then if the target server for
  some reason gets configured as TLS 1.1, then the client would have to
  block it, creating breakage

* Cookies can be set to be secure only. Here again, if you have
  a situation in which some of your servers support TLS 1.2
  and others TLS 1.1, then you can get breakage where cookies
  are not sent.

> informs users and allows them to make effective choices, across all

I'm not suggesting that the IETF design UI.

We're getting pretty far into the weeds here, but I can tell you is
that the general trend in this area -- especially in browsers but also
in some mail and calendar clients -- is to simply present an error and
to make overriding that error difficult if not impossible. This is
informed by a body of research [0] that indicates that users are too
willing to override these warnings even in dangerous settings.

-Ekr

[0] For instance:
 https://www.usenix.org/legacy/events/sec09/tech/full_papers/sunshine.pdf

---

From: Gary Gapinski <[email-masked]>
Date: Fri, 27 Nov 2020 23:39:36 -0500

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?

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

§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.

Regards,

Gary

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Nov 2020 23:43:42 -0500

> below 1.2 so that the properties are more consistent.

Sure, it would be great if users and operators never had to worry about 
old TLS versions.  But in practice, they do, for reasons already 
mentioned.  It's simply not feasible to upgrade or discard everything 
using old versions of TLS in the next few years, and a lot of those 
hosts and devices and programs will continue to need to be used for a 
variety of valid reasons.    Pretending otherwise for the sake of an 
unrealistically simple statement of security policy seems unhelpful.

> public CAs issue them, but some do.

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.

> neither secure nor insecurecreates real challenges. Let me give you

To clarify, my suggestion was that https with TLS < 1.2 be treated as 
insecure, not as neither secure nor insecure or any kind of "in between".

(and yes, I was ware of that kind of partitioning)

> willing to override these warnings even in dangerous settings.

Yes, I'm aware of that too.   You should probably be aware that one 
effect of this that I've seen affect actual products, is to avoid 
supporting TLS in embedded systems.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2020 20:58:13 -0800

Well, I think our respective positions are clear, so I'll just limit myself
to one point.

> insecure, not as neither secure nor insecure or any kind of "in between".

Well, the problem is that it is secure from the perspective of the site
author
but insecure from the perspective of the client. That's not going to end
well
for the reasons I indicated above.

Regardless, this is not likely to happen on the Web: browsers are already
converging on simply disabling older versions, and I doubt are going to
have any interest in the approach you propose.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Nov 2020 00:05:13 -0500

On 11/27/20 11:58 PM, Eric Rescorla wrote:

> Well, the problem is that it is secure from the perspective of the 
> site author
> but insecure from the perspective of the client. That's not going to 
> end well

Well that is an interesting point that I missed earlier.   But I think 
the situation will be the same if any of the obvious workarounds is 
used, like a plugin or proxy.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Sat, 28 Nov 2020 11:45:43 +0100

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 <[email-masked]> wrote:
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Nov 2020 15:13:32 +0000

Hiya,

On 28/11/2020 04:39, Gary Gapinski wrote:
> <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,

> 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
> <https://www.rfc-editor.org/rfc/rfc7322.html> 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.

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Nov 2020 15:22:15 +0000

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...

>     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.

> like the web (e.g. interactive), but of course that's not the case. The 
> Right Thing to do for an SMTP client relaying mail, for example, is

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Nov 2020 15:26:14 +0000

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.

>> The IESG has received a request from the Transport Layer Security
>> WG (tls) to consider the following document: - 'Deprecating TLSv1.0
>> and TLSv1.1' <draft-ietf-tls-oldversions-deprecate-09.txt> 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 [email-masked] mailing lists by 2020-11-30.
>> Exceptionally, comments may be sent to [email-masked] instead. In
>> either case, please retain the beginning of the Subject line to
>> allow automated sorting.
>> 
>> Abstract
>> 
>> 
>> 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 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
>> 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) 
>> rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed
>> Standard - IETF stream) rfc4791: Calendaring Extensions to WebDAV
>> (CalDAV) (Proposed Standard - IETF stream) rfc4785: Pre-Shared Key
>> (PSK) Ciphersuites with NULL Encryption for Transport Layer
>> Security (TLS) (Proposed Standard - IETF stream) rfc4785:
>> Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
>> Transport Layer Security (TLS) (Proposed Standard - IETF stream) 
>> Exchange Protocol (BEEP) (Historic - IETF stream) rfc4744: Using
>> the NETCONF Protocol over the Blocks Extensible Exchange Protocol
>> (BEEP) (Historic - IETF stream) rfc4743: Using NETCONF over the
>> Simple Object Access Protocol (SOAP) (Historic - IETF stream) 
>> rfc4743: Using NETCONF over the Simple Object Access Protocol
>> (SOAP) (Historic - IETF stream) rfc4732: Internet Denial-of-Service
>> Considerations (Informational - IAB stream) rfc4732: Internet
>> Denial-of-Service Considerations (Informational - IAB stream) 
>> (Proposed Standard - IETF stream) rfc4712: Transport Mappings for
>> Real-time Application Quality-of-Service Monitoring (RAQMON)
>> Protocol Data Unit (PDU) (Proposed Standard - IETF stream) rfc4681:
>> TLS User Mapping Extension (Proposed Standard - IETF stream) 
>> rfc4680: TLS Handshake Message for Supplemental Data (Proposed
>> Standard - IETF stream) rfc4680: TLS Handshake Message for
>> Supplemental Data (Proposed Standard - IETF stream) rfc4642: Using
>> Transport Layer Security (TLS) with Network News Transfer Protocol
>> (NNTP) (Proposed Standard - IETF stream) rfc4642: Using Transport
>> Layer Security (TLS) with Network News Transfer Protocol (NNTP)
>> (Proposed Standard - IETF stream) rfc4616: The PLAIN Simple
>> Authentication and Security Layer (SASL) Mechanism (Proposed
>> Standard - IETF stream) rfc4616: The PLAIN Simple Authentication
>> and Security Layer (SASL) Mechanism (Proposed Standard - IETF
>> stream) rfc4582: The Binary Floor Control Protocol (BFCP) (Proposed
>> Standard - IETF stream) rfc4582: The Binary Floor Control Protocol
>> (BFCP) (Proposed Standard - IETF stream) rfc4540: NEC's Simple
>> Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental
>> - Independent Submission Editor stream) rfc4540: NEC's Simple
>> Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental
>> - Independent Submission Editor stream) rfc4531: Lightweight
>> Directory Access Protocol (LDAP) Turn Operation (Experimental -
>> IETF stream) rfc4513: Lightweight Directory Access Protocol (LDAP):
>> IETF stream) rfc3436: Transport Layer Security over Stream Control
>> Transmission Protocol (Proposed Standard - IETF stream) rfc3436:
>> Transport Layer Security over Stream Control Transmission Protocol
>> (Proposed Standard - IETF stream) rfc3329: Security Mechanism
>> Agreement for the Session Initiation Protocol (SIP) (Proposed
>> Standard - IETF stream) rfc3329: Security Mechanism Agreement for
>> the Session Initiation Protocol (SIP) (Proposed Standard - IETF
>> stream) rfc3261: SIP: Session Initiation Protocol (Proposed
>> Standard - IETF stream) rfc3261: SIP: Session Initiation Protocol
>> (Proposed Standard - IETF stream) rfc2246: The TLS Protocol Version
>> 1.0 (Proposed Standard - IETF stream) rfc6749: The OAuth 2.0
>> Authorization Framework (Proposed Standard - IETF stream) rfc6739:
>> Synchronizing Service Boundaries and <mapping> Elements Based on
>> the Location-to-Service Translation (LoST) Protocol (Experimental -
>> IETF stream) rfc6739: Synchronizing Service Boundaries and
>> <mapping> Elements Based on the Location-to-Service Translation
>> (LoST) Protocol (Experimental - IETF stream) rfc6367: Addition of
>> the Camellia Cipher Suites to Transport Layer Security (TLS)
>> (Informational - IETF stream) rfc6367: Addition of the Camellia
>> Cipher Suites to Transport Layer Security (TLS) (Informational -
>> IETF stream) rfc6176: Prohibiting Secure Sockets Layer (SSL)
>> Version 2.0 (Proposed Standard - IETF stream) rfc6176: Prohibiting
>> Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - IETF
>> stream) rfc6042: Transport Layer Security (TLS) Authorization Using
>> rfc5878: Transport Layer Security (TLS) Authorization Extensions
>> (Experimental - IETF stream) rfc5469: DES and IDEA Cipher Suites
>> for Transport Layer Security (TLS) (Informational - IETF stream) 
>> rfc5469: DES and IDEA Cipher Suites for Transport Layer Security
>> (TLS) (Informational - IETF stream) rfc5422: Dynamic Provisioning
>> Using Flexible Authentication via Secure Tunneling Extensible
>> Authentication Protocol (EAP-FAST) (Informational - IETF stream) 
>> (Informational - IETF stream) rfc5364: Extensible Markup Language
>> (XML) Format Extension for Representing Copy Control Attributes in
>> Resource Lists (Proposed Standard - IETF stream) rfc5364:
>> Extensible Markup Language (XML) Format Extension for Representing
>> Copy Control Attributes in Resource Lists (Proposed Standard - IETF
>> stream) rfc5281: Extensible Authentication Protocol Tunneled
>> Transport Layer Security Authenticated Protocol Version 0
>> (EAP-TTLSv0) (Informational - IETF stream) rfc5281: Extensible
>> Authentication Protocol Tunneled Transport Layer Security
>> Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational - IETF
>> stream) rfc5263: Session Initiation Protocol (SIP) Extension for
>> Partial Notification of Presence Information (Proposed Standard -
>> IETF stream) rfc5263: Session Initiation Protocol (SIP) Extension
>> for Partial Notification of Presence Information (Proposed Standard
>> - IETF stream) rfc5238: Datagram Transport Layer Security (DTLS)
>> over the Datagram Congestion Control Protocol (DCCP) (Proposed
>> Standard - IETF stream) rfc5216: The EAP-TLS Authentication
>> Protocol (Proposed Standard - IETF stream) rfc5216: The EAP-TLS
>> Authentication Protocol (Proposed Standard - IETF stream) rfc5158:
>> 6to4 Reverse DNS Delegation Specification (Informational - IETF
>> stream) rfc5091: Identity-Based Cryptography Standard (IBCS) #1:
>> (Informational - IETF stream) rfc5054: Using the Secure Remote
>> Password (SRP) Protocol for TLS Authentication (Informational -
>> IETF stream) rfc5054: Using the Secure Remote Password (SRP)
>> Protocol for TLS Authentication (Informational - IETF stream) 
>> rfc3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (Proposed
>> Standard - IETF stream) rfc3501: INTERNET MESSAGE ACCESS PROTOCOL -
>> VERSION 4rev1 (Proposed Standard - IETF stream) rfc4346: The
>> Transport Layer Security (TLS) Protocol Version 1.1 (Proposed
>> Standard - IETF stream) rfc2246: The TLS Protocol Version 1.0
>> (Proposed Standard - IETF stream) rfc4346: The Transport Layer
>> Security (TLS) Protocol Version 1.1 (Proposed Standard - IETF
>> stream) rfc4279: Pre-Shared Key Ciphersuites for Transport Layer
>> Security (TLS) (Proposed Standard - IETF stream) rfc4261: Common
>> Open Policy Service (COPS) Over Transport Layer Security (TLS)
>> (Proposed Standard - IETF stream) rfc4235: An INVITE-Initiated
>> Dialog Event Package for the Session Initiation Protocol (SIP)
>> (Proposed Standard - IETF stream) rfc4235: An INVITE-Initiated
>> Dialog Event Package for the Session Initiation Protocol (SIP)
>> (Proposed Standard - IETF stream) rfc4217: Securing FTP with TLS
>> (Proposed Standard - IETF stream) rfc4168: The Stream Control
>> Transmission Protocol (SCTP) as a Transport for the Session
>> rfc4162: Addition of SEED Cipher Suites to Transport Layer Security
>> (TLS) (Proposed Standard - IETF stream) rfc4111: Security Framework
>> for Provider-Provisioned Virtual Private Networks (PPVPNs)
>> (Informational - IETF stream) rfc4097: Middlebox Communications
>> (MIDCOM) Protocol Evaluation (Informational - IETF stream) rfc4097:
>> Middlebox Communications (MIDCOM) Protocol Evaluation
>> (Informational - IETF stream) rfc3983: Using the Internet Registry
>> Information Service (IRIS) over the Blocks Extensible Exchange
>> Protocol (BEEP) (Proposed Standard - IETF stream) rfc3943:
>> Transport Layer Security (TLS) Protocol Compression Using
>> Lempel-Ziv-Stac (LZS) (Informational - IETF stream) rfc3903:
>> Session Initiation Protocol (SIP) Extension for Event State
>> Publication (Proposed Standard - IETF stream) rfc6749: The OAuth
>> 2.0 Authorization Framework (Proposed Standard - IETF stream) 
>> rfc3887: Message Tracking Query Protocol (Proposed Standard - IETF
>> stream) rfc3871: Operational Security Requirements for Large
>> Internet Service Provider (ISP) IP Network Infrastructure
>> (Informational - IETF stream) rfc3871: Operational Security
>> Requirements for Large Internet Service Provider (ISP) IP Network
>> Infrastructure (Informational - IETF stream) rfc3856: A Presence
>> Event Package for the Session Initiation Protocol (SIP) (Proposed
>> Standard - IETF stream) rfc3767: Securely Available Credentials
>> Protocol (Proposed Standard - IETF stream) rfc3749: Transport Layer
>> Security Protocol Compression Methods (Proposed Standard - IETF
>> stream) rfc3749: Transport Layer Security Protocol Compression
>> Methods (Proposed Standard - IETF stream) rfc3656: The Mailbox
>> Update (MUPDATE) Distributed Mailbox Database Protocol
>> (Experimental - Independent Submission Editor stream) rfc3568:
>> Known Content Network (CN) Request-Routing Mechanisms
>> (Informational - IETF stream) rfc6750: The OAuth 2.0 Authorization
>> Framework: Bearer Token Usage (Proposed Standard - IETF stream) 
>> rfc6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
>> (Proposed Standard - IETF stream) rfc7030: Enrollment over Secure
>> Transport (Proposed Standard - IETF stream) rfc7030: Enrollment
>> over Secure Transport (Proposed Standard - IETF stream) rfc7465:
>> Prohibiting RC4 Cipher Suites (Proposed Standard - IETF stream) 
>> rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - IETF
>> stream) rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV)
>> for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF
>> stream) rfc7507: TLS Fallback Signaling Cipher Suite Value (SCSV)
>> for Preventing Protocol Downgrade Attacks (Proposed Standard - IETF
>> stream) rfc7562: Transport Layer Security (TLS) Authorization Using
>> (Informational - Independent Submission Editor stream) rfc7562:
>> Transport Layer Security (TLS) Authorization Using Digital
>> Transmission Content Protection (DTCP) Certificates (Informational
>> - Independent Submission Editor stream) rfc7568: Deprecating Secure
>> Sockets Layer Version 3.0 (Proposed Standard - IETF stream) 
>> rfc7568: Deprecating Secure Sockets Layer Version 3.0 (Proposed
>> Standard - IETF stream) rfc8422: Elliptic Curve Cryptography (ECC)
>> Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and
>> Earlier (Proposed Standard - IETF stream) rfc8422: Elliptic Curve
>> Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
>> Versions 1.2 and Earlier (Proposed Standard - IETF stream)
>> 
>> 
>> 
>> 
>> _______________________________________________ IETF-Announce
>> mailing list [email-masked] 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nick Lamb <[email-masked]>
Date: Sat, 28 Nov 2020 20:29:51 +0000

On Fri, 27 Nov 2020 23:43:42 -0500
Keith Moore <[email-masked]> 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.

---

From: Martin Duke <[email-masked]>
Date: Sun, 29 Nov 2020 19:02:05 -0800

I support this draft. RFCs do not always equal the real world, but less
secure versions of TLS should be deprecated with the strongest possible
terms.

On Mon, Nov 9, 2020 at 2:27 PM The IESG <[email-masked]> wrote:

>     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)
>     rfc4964: The P-Answer-State Header Extension to the Session Initiation
> Protocol for the Open Mobile Alliance Push to Talk over Cellular
>     rfc4964: The P-Answer-State Header Extension to the Session Initiation
> Protocol for the Open Mobile Alliance Push to Talk over Cellular
>     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)
>     rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
>     rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
> Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed
> Standard - IETF stream)
> Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed
> Standard - IETF stream)
>     rfc4616: The PLAIN Simple Authentication and Security Layer (SASL)
> Mechanism (Proposed Standard - IETF stream)
>     rfc4616: The PLAIN Simple Authentication and Security Layer (SASL)
> Mechanism (Proposed Standard - IETF stream)
>     rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version
> 3.0 (Experimental - Independent Submission Editor stream)
>     rfc4540: NEC's Simple Middlebox Configuration (SIMCO) Protocol Version
> 3.0 (Experimental - Independent Submission Editor stream)
>     rfc4513: Lightweight Directory Access Protocol (LDAP): Authentication
> Methods and Security Mechanisms (Proposed Standard - IETF stream)
>     rfc3436: Transport Layer Security over Stream Control Transmission
> Protocol (Proposed Standard - IETF stream)
>     rfc3436: Transport Layer Security over Stream Control Transmission
> Protocol (Proposed Standard - IETF stream)
>     rfc6739: Synchronizing Service Boundaries and <mapping> Elements Based
> on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF
> stream)
>     rfc6739: Synchronizing Service Boundaries and <mapping> Elements Based
> on the Location-to-Service Translation (LoST) Protocol (Experimental - IETF
> stream)
>     rfc6367: Addition of the Camellia Cipher Suites to Transport Layer
> Security (TLS) (Informational - IETF stream)
>     rfc6367: Addition of the Camellia Cipher Suites to Transport Layer
> Security (TLS) (Informational - IETF stream)
>     rfc6042: Transport Layer Security (TLS) Authorization Using KeyNote
>     rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure
> Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational -
> IETF stream)
>     rfc5422: Dynamic Provisioning Using Flexible Authentication via Secure
> Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational -
> IETF stream)
> Representing Copy Control Attributes in Resource Lists (Proposed Standard -
> IETF stream)
> Representing Copy Control Attributes in Resource Lists (Proposed Standard -
> IETF stream)
>     rfc5281: Extensible Authentication Protocol Tunneled Transport Layer
> Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational -
> IETF stream)
>     rfc5281: Extensible Authentication Protocol Tunneled Transport Layer
> Security Authenticated Protocol Version 0 (EAP-TTLSv0) (Informational -
> IETF stream)
>     rfc5238: Datagram Transport Layer Security (DTLS) over the Datagram
> Congestion Control Protocol (DCCP) (Proposed Standard - IETF stream)
>     rfc5091: Identity-Based Cryptography Standard (IBCS) #1: Supersingular
> Curve Implementations of the BF and BB1 Cryptosystems (Informational - IETF
> stream)
> Transport for the Session Initiation Protocol (SIP) (Proposed Standard -
> IETF stream)
> (TLS) (Proposed Standard - IETF stream)
>     rfc4111: Security Framework for Provider-Provisioned Virtual Private
> Networks (PPVPNs) (Informational - IETF stream)
>     rfc3983: Using the Internet Registry Information Service (IRIS) over
> the Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard - IETF
> stream)
>     rfc3943: Transport Layer Security (TLS) Protocol Compression Using
> Lempel-Ziv-Stac (LZS) (Informational - IETF stream)
>     rfc3903: Session Initiation Protocol (SIP) Extension for Event State
> Publication (Proposed Standard - IETF stream)
>     rfc3871: Operational Security Requirements for Large Internet Service
> Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
>     rfc3871: Operational Security Requirements for Large Internet Service
> Provider (ISP) IP Network Infrastructure (Informational - IETF stream)
>     rfc3656: The Mailbox Update (MUPDATE) Distributed Mailbox Database
> Protocol (Experimental - Independent Submission Editor stream)
>     rfc7562: Transport Layer Security (TLS) Authorization Using Digital
> Transmission Content Protection (DTCP) Certificates (Informational -
> Independent Submission Editor stream)
>     rfc7562: Transport Layer Security (TLS) Authorization Using Digital
> Transmission Content Protection (DTCP) Certificates (Informational -
> Independent Submission Editor stream)
>     rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
> Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF
> stream)
>     rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
> Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - IETF
> stream)
>
>
>
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Dec 2020 00:21:30 +0000

Nick Lamb <[email-masked]> writes:

>You won't get such a certificate from a public CA (presumably meaning a CA
>issuing in the Web PKI).

Well, you're less likely to now thanks to CT.  Before that public CAs issued
huge numbers of them, including EV certs.

>They're subject to the CA/B Baseline Requirements which explicitly forbid
>this (in 7.1.4.2.1):

In practice the BR is more what you'd call "guidelines" than actual rules...

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Dec 2020 00:29:59 +0000

Stephen Farrell <[email-masked]> writes:

>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.

That's more or less impossible since they're invisible to the public Internet.
Or at least they're supposed to be, large numbers of them are publicly visible
when they shouldn't be, but in any case at best you're going to get a lot of
anecdotal evidence rather than anything comprehensive.

However I think your comment points out the overall problem:

  usage in web, mail and OSes

This means there's no consideration at all of use in embedded/SCADA/whatever.
So I think the text should include wording to the effect that it applies to
public Internet use but not to embedded/SCADA/etc for which very different
considerations apply.  For example the issue in the previous message with
regard to the CA/B BR is mutually exclusive with embedded use, systems like
that will pretty much never see a cert from a CA/B CA.  Conversely, they'll
have certs for RFC 1918 addresses and EUIs and whatnot which shouldn't (but
probably have been) issued by public CAs.

Peter.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Nov 2020 19:40:34 -0500

On 11/30/20 7:29 PM, Peter Gutmann wrote:

> considerations apply.

I've been thinking something like this also.  But IMO there are still 
valid cases for negotiating older versions of TLS on the public 
Internet, such as the mail relaying case mentioned earlier.    So far I 
haven't thought of a reason where either (a) bouncing an email message; 
(b) resending it in cleartext; or (c) discarding it, is better than 
relaying with TLS 1.0 or 1.1. (Though maybe there aren't enough MTAs 
that do opportunistic TLS using version <= 1.1 to matter.)

More generally, the right remedial behavior for an application with e2e 
connectivity and an interactive UI that can't do better than TLS 1.1, 
isn't necessarily the right behavior for all applications.

So maybe two restrictions on scope?  (1) public Internet; (2) e2e and 
interactive application?

But it's important to understand that protocols and protocol 
implementations that are used on the public Internet are also used on 
isolated and mostly-isolated networks.

Given that this is BCP and not standards-track, maybe it should just be 
made clear that an implementation that does support 1.0 or 1.1 isn't 
necessarily violating the standard, it's just discouraged as a practice.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Dec 2020 00:48:29 +0000

Hiya,

> This means there's no consideration at all of use in embedded/SCADA/whatever.

I wouldn't agree with "no consideration" but guess we might
agree about a lack of data. In particular, mail servers
within enterprises were an explicit consideration but one
where the consensus I think ended up pretty clear to be to
deprecate despite at that time ongoing non-trivial usage of
old versions.

That said, if someone had words to suggest that might garner
consensus, that would be good. I earlier said I'd try craft
such, and will, but maybe better to start that with text from
someone who works with these deliberately update-averse
devices. (My guess as of now, is that would need to try
describe cases where our "MUST NOT" is really an rfc6919
"MUST NOT (but we know you will)" rather than an attempt to
characterise all the situations where the "MUST NOT" is
clearly correct.)

Cheers,
S.

PS: I think the earlier discussion referred to above answers
Keith's point about mail servers, if one looks back over it.
(That's from memory though, me not actually having gone back
and looked over it again... yet;-)

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 30 Nov 2020 23:11:44 -0500

> that do opportunistic TLS using version <= 1.1 to matter.)

For lack of any known substantive downgrade attacks against STARTTLS in
SMTP relay from TLS 1.2 to TLS 1.0, I've no immediate plans to disable
default support for TLS 1.0 in Postfix.  For opportunistic TLS the
effect of that would be to send in cleartext rather TLS 1.0, which seems
unnecessary at present.

SMTP servers that support DANE have been steadily moving away from TLS
1.0, but these are presumably operated by folks who pay extra attention
to security, and are not representative of the long tail of folks who
leave "well enough" alone.  My most negotiated TLS version stats for
SMTP servers supporting DANE are:

   TLS 1.3: 9064
   TLS 1.2: 7239
   TLS 1.1:    0
   TLS 1.0:   27

Two years ago, they were:

    TLS 1.3:  204
    TLS 1.2: 3561
    TLS 1.1:    2
    TLS 1.0:   35

The trend is definitely towards TLS 1.3, and away from TLS 1.0, but
the long tail takes time to fade away.

So at some point it might make sense to disable TLS 1.0 support by
default, and some users are choosing to do it early by overriding the
defaults, but I am not convinced the pros outweight the cons today.

-- 
    Viktor.

---

From: Ben Smyth <[email-masked]>
Date: Tue, 1 Dec 2020 06:52:12 +0100

I haven't followed all the nuances of this discussion, but it seems to boil
down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private
enterprise running legacy kit, which makes decision makers anxious, since
they don't want responsibility for something they "MUST NOT" do: A solution
might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby
allowing sectors to define their standards/principles/expectations.