Re: [TLS] OPTLS: Signature-less TLS 1.3

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sun, 09 November 2014 07:01 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ED51A19FB for <tls@ietfa.amsl.com>; Sat, 8 Nov 2014 23:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 sA9dty9TCqyN for <tls@ietfa.amsl.com>; Sat, 8 Nov 2014 23:01:06 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 403831A19EB for <tls@ietf.org>; Sat, 8 Nov 2014 23:01:06 -0800 (PST)
Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id B3706F991 for <tls@ietf.org>; Sun, 9 Nov 2014 02:01:03 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 6017120087; Sat, 8 Nov 2014 10:20:42 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: tls@ietf.org
In-Reply-To: <CALCETrXsYooPPhyPPAYzq6rQvqsFpwE6oQQ1+yTVf0pDoKrZeQ@mail.gmail.com>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <545C3175.5070204@amacapital.net> <CACsn0cmGvDTZyd3krrBmKgjijFBJh_gUZPoX-UEsE=1b2d0Ajg@mail.gmail.com> <CALCETrXsYooPPhyPPAYzq6rQvqsFpwE6oQQ1+yTVf0pDoKrZeQ@mail.gmail.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Sat, 08 Nov 2014 10:20:38 -0500
Message-ID: <87tx29g1mh.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WHvsAgF6HrH5bQ1X21964Q2Alq0
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 09 Nov 2014 07:01:09 -0000

On Fri 2014-11-07 01:21:26 -0500, Andy Lutomirski wrote:

> If I buy a cert for *.my.domain, I want to be able to provision
> foo.my.domain with some secret that lets it act as foo.my.domain but
> not bar.my.domain.  Since the PKIX people seem to be completely unable
> to address this, pinning DH shares to a domain would solve the problem
> without involving any PKIX changes.

If we could provide this, it could be a very interesting operational win
in the context of expensive/cumbersome CAs and medium-sized
organizations with many services (internal and external).

It would effectively allow a wildcard cert for a given domain to act as
a domain-constained sub-CA, without getting into the X.509 weeds about
domain constraints.  The secret key material corresponding to the
wildcard cert could be kept offline, and used to issue medium-term DH
shares that are distributed to each service.

Unfortunately, i don't see a way to deploy this effectively without
putting the secret key material associated with the wildcard cert online
for each service that needs to support legacy clients, which would make
the security advantage moot.

    --dkg