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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 10 November 2014 22:23 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 D8E501A8934 for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 14:23:44 -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 Ui0AGEX5azur for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 14:23:42 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CC7381A8968 for <tls@ietf.org>; Mon, 10 Nov 2014 14:23:41 -0800 (PST)
Received: from fifthhorseman.net (unknown [199.68.254.218]) by che.mayfirst.org (Postfix) with ESMTPSA id 731EDF986; Mon, 10 Nov 2014 17:23:37 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A9AF51FF74; Mon, 10 Nov 2014 12:23:36 -1000 (HST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Martin Thomson <martin.thomson@gmail.com>
In-Reply-To: <CABkgnnWqppL-1VJORYfrwuKn8n=NO-rZX6LDTiq+-qxddsp1mg@mail.gmail.com>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <CABcZeBNQBC1XXFR5sGo=V8WmxmL5thaBpeHSasy3SordbqNRTQ@mail.gmail.com> <CADi0yUMM6C=NpvFsc67J6Dc6uEO3OZ490tFWhAYmD362mC+D4A@mail.gmail.com> <CABcZeBNKpTMg+xhMK5TnO_W99MotoPw+_m9yrTqTUSwqyPpUPA@mail.gmail.com> <CACsn0cnkRZ5ZzX0bHfVFsvsrNoJxU2Txs0O2YW386fsg9GF1vQ@mail.gmail.com> <CABcZeBMQc5Mb_FK3davMxi0oBgzawqCMaYp1DqGYgg3nEHYHHw@mail.gmail.com> <CADi0yUOZ8LqsJbTTZmYL6XgrTjWvTMqvFMd7euzv+xQPU9vPJg@mail.gmail.com> <CABcZeBM+CcG8Tr_+XZ6nkw4xJP8DGFXguvRvLGhTUXYdhEOUqA@mail.gmail.com> <87r3xdfzi1.fsf@alice.fifthhorseman.net> <CABkgnnWqppL-1VJORYfrwuKn8n=NO-rZX6LDTiq+-qxddsp1mg@mail.gmail.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Mon, 10 Nov 2014 12:23:33 -1000
Message-ID: <87r3xawv8a.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/8v4AFSVv161sR3s4J3zLHMc6fZc
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 10 Nov 2014 22:23:45 -0000

On Sun 2014-11-09 09:25:27 -1000, Martin Thomson wrote:
> On 8 November 2014 08:06, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> To achieve this separation of purpose, though, we'd need to be able to
>> distinguish between certificates capable of anchoring the end entity in
>> a TLS 1.2 session and certificates capable of certifying a long-term
>> g^s.  Making these distinguishable would probably require a new X.509v3
>> extension, or extendedKeyUsage.
>
> There may still be operational advantages: you could issue the 1.2
> cert with a shorter lifetime and the 1.3 cert with a longer one.

I'm not sure i understand this suggestion (it may be moot since it
sounds like we're not considering this approach for 1.3 anyway after
yesterday's interim discussion about the risks of introducing delegation
in this fashion).

> Mucking with X.509 would probably make this harder than its worth, I think.

i agree that X.509 is a disaster here, but i think making up a new
delegation protocol won't necessarily be a non-disaster -- we could
instead just rehash some of the sharp bits of the X.509 mess
(revocation, duration, transparency, identity, etc) in a different
format if we're not clear about what we're doing :/

           --dkg