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

Martin Thomson <martin.thomson@gmail.com> Sun, 05 March 2017 10:55 UTC

Return-Path: <martin.thomson@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 14389129451 for <tls@ietfa.amsl.com>; Sun, 5 Mar 2017 02:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 bNeSN_te3FDd for <tls@ietfa.amsl.com>; Sun, 5 Mar 2017 02:55:27 -0800 (PST)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 722D5129440 for <tls@ietf.org>; Sun, 5 Mar 2017 02:55:27 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id v125so55573268qkh.2 for <tls@ietf.org>; Sun, 05 Mar 2017 02:55:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kL5L/yFWMjmGGKZvMtqO5HyKfCKx54jzDV4x+8Mt75Q=; b=doLfsOy4DRxYVHSPgRQDM60VTp9bzoPgdIHp41QfR7JhgKX2FOPibrUpVr7a4OSlRc 7EnI6Fsi/YnOBkN0GdX8XnqKh8CO1ZSrLw0K4eY1PNA68eBsgloLoEkGgSnmDT9hnoo2 aGPw9OGqaypK+Pv54QaC11uJwYmnKH4b4zGp0qBN6wxLQFLzDn3ApVdSHm1sJxKV1WkN siUfUzkQUlN6zvXSfIAq9R9Qml3ZpHDms/oQW4hnOanV2YydzIZl70xS1JMLU9Z9xu1q PrmRlV4lvDpRFvoBR0t/Lvd4oOHLxXweyp4TcfwR+txienAngrxYfy/VcOehiC0Iwcz4 ZaQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kL5L/yFWMjmGGKZvMtqO5HyKfCKx54jzDV4x+8Mt75Q=; b=aBxYrjHvOZSFTsnb9k/ZBi2SE2ZLeq87Oz7Ojw3V05oIucH9KvP3YNMNKJfxm3SKkR 7wghF/EZmRQ5col/Tk9eGQ1HQ/9E3rv7/120NEs4UFGx6s8n2dbcRAJaSmKeXGlbQSli HxuG94pLQMiPG1mP0zQdsJMf7m0MhKsTqbb+UJHbUAazpC9k+zq9vYe05aNsBekZ9ojw jghVkLtEFpBOXDkbpGhjTqdBoI7TH0DMrHDA04xlYHaHWb12Jn+uo8xjrwraFLS9p2zz pdlGVbFIjbGVn8mI/Kl2irvWxhPMJkDC71eRYS7XLoOj0FVYnWRbVlCAvUYS/NE8CMs2 b44g==
X-Gm-Message-State: AMke39kOuhZeMyWsz0ytoxa/gJZJJmW7An+r6cimR/K6Dz3q3Pvi9prG8szZbVd0MIRJOs59j4sIiXFvi4rUtw==
X-Received: by 10.237.51.5 with SMTP id u5mr12136028qtd.247.1488711326544; Sun, 05 Mar 2017 02:55:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 5 Mar 2017 02:55:26 -0800 (PST)
In-Reply-To: <85c7a8fe-6963-ebbf-f600-49e88477ac26@oracle.com>
References: <85c7a8fe-6963-ebbf-f600-49e88477ac26@oracle.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Sun, 5 Mar 2017 21:55:26 +1100
Message-ID: <CABkgnnVTcx8DpUH_FHmPRJWJKdA_6XAaQ1TQOeQCrh3XB_EugQ@mail.gmail.com>
To: Bradford Wetmore <bradford.wetmore@oracle.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nB-heWsm0gH4-IeMoTnDXgFMu6E>
Cc: "tls@ietf.org" <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 10:55:29 -0000

If you want to lawyer up on this, I think that the official
interpretation is that those RFCs were obsoleted by RFC 5246 and so if
you support 5246, you can do what it says and not what the older specs
say.  I don't think that anyone will fault you if you decide to burn
all traces of DES from your stack.  It's your stack, and there's
enough AES to go around.

On 4 March 2017 at 10: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