Re: [TLS] null auth ciphers for TLS 1.3?

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 August 2018 18:33 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 40B01130E4F for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 11:33:56 -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 S1jtQMKa9uv8 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 11:33:54 -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 75699130E25 for <tls@ietf.org>; Tue, 21 Aug 2018 11:33:54 -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 ADE17295085 for <tls@ietf.org>; Tue, 21 Aug 2018 14:33:53 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBO8tBN4a4SZirxbwNdRyep705dNgGZiuKydg=xu1JT_uQ@mail.gmail.com>
Date: Tue, 21 Aug 2018 14:33:53 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <3321850E-D95E-457C-A574-2A1A3F7AC06C@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> <EC6705A4-A6CB-45B4-B006-FC0AE42FA6DD@dukhovni.org> <CABcZeBO8tBN4a4SZirxbwNdRyep705dNgGZiuKydg=xu1JT_uQ@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/Sh5Gl8o_CkRENg3XaVC8D34LoP8>
Subject: Re: [TLS] null auth ciphers for TLS 1.3?
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:33:56 -0000


> On Aug 21, 2018, at 2:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>> As for TLS 1.3, it is indeed missing both null encryption and null
>> authentication ciphers.
> 
> If by "null authentication" you mean "without certificates", then TLS 1.3 does
> support these via RFC 7250. See:
> 
> https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.5

My comment was about ADH/AECDH cipher-suites, in which the server
does not sign the key exchange, because it has no keys and the
client has no intention/means to authenticate such a signature.

You are of course right that TLS 1.3 supports raw public keys,
which make it possible to do away with X.509 support.  I would
not call these null authentication, since DANE or key pinning
(much less scalably) make it possible to authenticate raw public
keys.

I've not yet seen raw public key support in any mainstream
TLS libraries, though admittedly my focus is primarily on
OpenSSL.  Do any of NSS, GnuTLS, BoringSSL, LibreSSL, ...
support raw public keys?

In the case of OpenSSL, adding such support is difficult, because
the assumption that the peer returns X.509 certificates and not
some more general data type is baked into the API.  We'd need to
invent some sort of special X.509 object that holds only a public
key, but behaves in some sensible way when used with functions
that expect X.509 certificates.

-- 
	Viktor.