[TLS] "Spec Compliance" and the older TLS protocols

Bradford Wetmore <bradford.wetmore@oracle.com> Fri, 03 March 2017 23:32 UTC

Return-Path: <bradford.wetmore@oracle.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67235129453 for <tls@ietfa.amsl.com>; Fri, 3 Mar 2017 15:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fByqfPb09HG8 for <tls@ietfa.amsl.com>; Fri, 3 Mar 2017 15:32:22 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5641C12941D for <tls@ietf.org>; Fri, 3 Mar 2017 15:32:22 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v23NWLa3003416 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tls@ietf.org>; Fri, 3 Mar 2017 23:32:21 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v23NWKFW006141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tls@ietf.org>; Fri, 3 Mar 2017 23:32:21 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v23NWKLj024246 for <tls@ietf.org>; Fri, 3 Mar 2017 23:32:20 GMT
Received: from [10.132.189.81] (/10.132.189.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Mar 2017 15:32:20 -0800
To: tls@ietf.org
From: Bradford Wetmore <bradford.wetmore@oracle.com>
Message-ID: <85c7a8fe-6963-ebbf-f600-49e88477ac26@oracle.com>
Date: Fri, 3 Mar 2017 15:32:19 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZQYzJjJho76bkI39o_6jqpOlKAs>
Subject: [TLS] "Spec Compliance" and the older TLS protocols
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 23:32:24 -0000

An interpretation question for our older RFCs, in particular TLSv1 
[RFC2246] and TLSv1.1 [RFC4346] in the context of recent developments 
[SWEET32].

In particular, likely for minimal interoperability reasons, specific 
3DES-based ciphersuites must be implemented in TLS:

TLS 1.0

    In the absence of an application profile standard specifying
    otherwise, a TLS compliant application MUST implement the cipher
    suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

TLS 1.1

    In the absence of an application profile standard specifying
    otherwise, a TLS compliant application MUST implement the cipher
    suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Ignoring the data limits approach, the degree of vendor/implementation 
response to these ciphersuites varies:

1.  default enabled/available ciphersuites remain the same,

2.  reduce the ciphersuite priority, but the ciphersuites are still 
enabled/available by default,

3.  "disable" the ciphersuites by default, but allow for reenabling 
through API or system configuration,

4.  remove the ciphersuites from the binary (e.g. via conditional 
compilation/packaging),

5.  completely remove all trace from the library's source.

So, strictly speaking from a RFC point of view (not practical or 
security POV, those are different questions), what do these "MUST 
implement" statements mean in order for an implementation to still be 
considered "spec-compliant" in the post-SWEET32 era.  1-2 above?  1-3? 
[RFC2119] isn't clear on whether 3 would be ok.

Would 4-5 be considered technically non-compliant implementations?

Thanks,

Brad

[SWEET32] https://sweet32.info/
[RFC2119] https://www.ietf.org/rfc/rfc2119.txt
[RFC2246] https://www.rfc-editor.org/rfc/rfc2246.txt
[RFC4346] https://www.rfc-editor.org/rfc/rfc4346.txt