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

Yoav Nir <ynir.ietf@gmail.com> Sun, 05 March 2017 12:04 UTC

Return-Path: <ynir.ietf@gmail.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 07EA112947A for <tls@ietfa.amsl.com>; Sun, 5 Mar 2017 04:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJssdmD10q5t for <tls@ietfa.amsl.com>; Sun, 5 Mar 2017 04:04:16 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872D0128B38 for <tls@ietf.org>; Sun, 5 Mar 2017 04:04:16 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id u108so99465233wrb.3 for <tls@ietf.org>; Sun, 05 Mar 2017 04:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CPXZ2JbMF9HGZ5tykmf/6cAUVEFrT9IErusxdheahXE=; b=s294d5qpm4uoQNJ99w6kUfQrzxg5pgQYphSGGv8b/7O/nIAJO0F1V0UX1rUxZ/D+Es 6WChrWBlWvifjz5025SYLgXQCntZgtvvUeHKx/0YrlGb0jiJn7VrbVYeoHgWKE8YTPD5 6paEC+raaUhHxADFEufKTLl7NB+x3/URCykkvmoBu8Mn5RogICke/s0k9Fq+dq4Jh9RL xvPzU3zBXtVDtqkhrZPMcdKcibV/gZkD4+UMEHUBEdRqwsFNFmqusPtrQ9lsQA/LKyfS F6lGS8aM0EzbnSJnqcQPLDGNdvLL791Hn6Gl38nHD5wkyLkFTjVlC5y3GBlHhs2pSBPQ 9oYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CPXZ2JbMF9HGZ5tykmf/6cAUVEFrT9IErusxdheahXE=; b=X8hIn7b/qsmKJyzGWQRhq3q7nwy417t+ZQSV+DTBx8PDsV+q8JBgtKfAkJbvCGK1D7 OQcYq0BZ43R0oBmeEu0ypQSB36w7SQENkexhfwNVg0fqMXzgQM4HZMVGdD67uOY75auX ACdklWDTflhdz69nsVUq/C7SQypn7gfEqPM5WkPEywTF15gFqGpc3im+ZOSbscI/tjC2 TuexzWeaOFpulU3G7+nCe+d68f+o+HL9GoxTG3d7ZYdeG2kMlSwCCfpmH9QXdw++rj9y qF9zfUsNru0JJtRsmr0lYk7nbNeBqP7YPOpZXRqZw6W5twTgHCbMgQ3vVS/rbx2DpNyh Du2w==
X-Gm-Message-State: AMke39lMsAJrsonW4n3v5nOJIUzv9AfQyMg+Ld9trUezJHu9QA7xUk3lcPgZd313HAEYqA==
X-Received: by 10.223.135.1 with SMTP id a1mr1562627wra.174.1488715454705; Sun, 05 Mar 2017 04:04:14 -0800 (PST)
Received: from [172.24.250.100] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 63sm10626935wmg.22.2017.03.05.04.04.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 04:04:13 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <073D1922-03EA-4D7E-AD3E-78A85F42EF90@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5BA52019-208D-4E0D-9A79-3A6C69116F70"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sun, 5 Mar 2017 14:04:09 +0200
In-Reply-To: <85c7a8fe-6963-ebbf-f600-49e88477ac26@oracle.com>
To: Bradford Wetmore <bradford.wetmore@oracle.com>
References: <85c7a8fe-6963-ebbf-f600-49e88477ac26@oracle.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bnDmERFh2nrEROIL13fD20p8_ck>
Cc: tls@ietf.org
Subject: Re: [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: Sun, 05 Mar 2017 12:04:18 -0000

Hi, Brad

What Martin said. Additionally, I work for a vendor that has to really “lawyer up” sometimes.

So if RFC 2246 says “MUST implement X” and your code doesn’t implement X, just don’t claim compliance with RFC 2246. You can still have TLS 1.0 code for BC.

In general, people looking for statements about compliance will be fine with only claiming compliance with the latest and greatest as long as the latest and greatest is also implemented in their “other side”.  So TLS 1.2 is likely good enough.

As for what “MUST implement” means, there have been very long-winded discussions about this over the years. The general agreement seems to be “must implement but not necessarily enabled”. So if your implementation has TLS_RSA_WITH_3DES_EDE_CBC_SHA and it’s disabled by default and there’s some way to enable it, you can still claim RFC 4346 compliance.

Yoav

> On 4 Mar 2017, at 1:32, Bradford Wetmore <bradford.wetmore@oracle.com> wrote:
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls