Re: [TLS] Enforcing Protocol Invariants

Viktor Dukhovni <> Fri, 09 November 2018 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64A9012F1AB for <>; Thu, 8 Nov 2018 17:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XpOL-SbQ-SJH for <>; Thu, 8 Nov 2018 17:08:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16742130DD0 for <>; Thu, 8 Nov 2018 17:08:05 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 12EF6301CA9 for <>; Thu, 8 Nov 2018 20:08:04 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 08 Nov 2018 20:08:03 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<>" <>
Message-Id: <>
References: <> <>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Nov 2018 01:08:11 -0000

> On Nov 8, 2018, at 4:34 AM, Salz, Rich <> wrote:
> What makes you say that?  Please be specific about what you think should be taken out.

One example area where the complexity is noticeably high:

 * Certificate selection metadata specificity seems to far exceed
   plausible diversity of choice on the peer end.  Are there
   really clients or servers out there with so many different
   certificates to choose from that we need:

	a.  CA name hints from client to server?
	b.  OID filters in the certificate request from server to client?
	c.  signature_algorithms_cert (TLS -> X.509 layer violation, I
            just ignore this one)?

    In TLS 1.2 the signature_algorithms extension needs to be combined
    with the certificate types list, and neither 5246 or 4492 provides
    a means for the client to decide which curves the server supports
    in the client certificate (addressed in TLS 1.3).

TLS 1.2 has fixed-(EC)DH ciphersuites that should probably never have
been defined, and for some unknown reason added MD5 as a valid signature
algorithm hash, even though MD5 had already reached its use-by date...

For simplicity, I am a fan of Mike Hamburg's STROBE (a protocol design
framework, not a finished protocol):

of course one still needs to plug in some sort of PKI to get
a complete system, but it robustly unifies many things that in
TLS need to be built with one's bare hands.  I do hope that
STROBE is getting used somewhere, and not just languishing as
a paper design.