Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 August 2018 18:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D2E75130E62 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 11:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 JfZHW47cZqB7 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 11:11:48 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E191130E37 for <tls@ietf.org>; Tue, 21 Aug 2018 11:11:48 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id AD59A4F6D for <tls@ietf.org>; Tue, 21 Aug 2018 14:11:46 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAPt1N1mm9FzGknCUTOVZH_S=AsjutXS8qM7Ksa8xWwsSKKAgAg@mail.gmail.com>
Date: Tue, 21 Aug 2018 14:11:46 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <EC6705A4-A6CB-45B4-B006-FC0AE42FA6DD@dukhovni.org>
References: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com> <64d23891-2f32-9bb8-1ec8-f4fad13cdfb9@cs.tcd.ie> <982363FD-A839-4175-BA53-7CA242F9ADA6@ll.mit.edu> <2D7F2926-6376-4B2C-BDE9-7A6F1C0FA748@gmail.com> <5B7C1571020000AC0015C330@gwia2.rz.hs-offenburg.de> <E6C9F0E527F94F4692731382340B337804AEFA24@DENBGAT9EH2MSX.ww902.siemens.net> <A51CF46A-8C5F-4013-A4CE-EB90A9EE94CA@akamai.com> <E6C9F0E527F94F4692731382340B337804AEFB10@DENBGAT9EH2MSX.ww902.siemens.net> <D5FF0E0E-F9C3-4843-AB77-19F45E3C00D5@akamai.com> <8A2746A8-6B41-45C3-9D77-6AF3536C6E2D@siemens.com> <DM5PR2201MB1433B9D7F9AA3B7B688CD33C99310@DM5PR2201MB1433.namprd22.prod.outlook.com> <CAPt1N1mm9FzGknCUTOVZH_S=AsjutXS8qM7Ksa8xWwsSKKAgAg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vbBhPjs-Bs7_nF6vIoHE0NxMZGs>
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 21 Aug 2018 18:11:50 -0000


> On Aug 21, 2018, at 1:29 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
>   You're going to have to change what you do anyway—rather than arguing with us why not bypass us entirely?

TLS is not just a WWW protocol.  Other transport security use-cases
should not have to justify their existence.

It is, of course, appropriate to make sure that proposed TLS code-points
that cater to specialized needs are well thought out and include
suitable security considerations.

It is also reasonable to check that the requirements are not already
met without the proposed code-points.

I am concerned that we are going beyond that to questioning the
legitimacy of the use-cases.  IPsec is rarely a practical alternative
to TLS.

That said, TLS-LTS (a TLS 1.2 profile) may well be a good long-term
choice where TLS 1.3 is not sufficiently compatible.

As for TLS 1.3, it is indeed missing both null encryption and null
authentication ciphers.  I've not seen any evidence that their
presence in TLS 1.2 has led to either widespread support or
non-negligible accidental misuse.

TLS in SMTP is (still) largely unauthenticated opportunistic TLS,
and in almost all cases certificate verification errors get ignored
by sending MTAs.  When doing opportunistic unauthenticated TLS,
Postfix goes a step further and prefers ADH/AECDH cipher-suites (with
TLS <= 1.2), since any presented certificates will be ignored.
The null auth ciphers are automatically disabled when authentication
is required.

Similarly, Postfix provides either NO null encryption cipher-suites,
or ONLY null encryption cipher-suites.  One is unlikely to stumble
into a null-only configuration by accident and not notice.

With appropriate documentation, sensible default settings, and
configuration interfaces that make good choices easy and bad
choices more difficult, one can safely provide support for
non-mainstream use-cases.

This is not to say that null encryption ciphers for TLS 1.3 are
unconditionally good, their specification would need to provide
sound security considerations and be fit for purpose.  But I do
think that we should not reject the proposal out of hand.

-- 
-- 
	Viktor.