Re: [TLS] Why there should not be a TLS 2.0

Watson Ladd <> Sun, 08 June 2014 19:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D68D91A037B for <>; Sun, 8 Jun 2014 12:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k_O7Jzf06Al0 for <>; Sun, 8 Jun 2014 12:46:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF00D1A037F for <>; Sun, 8 Jun 2014 12:46:54 -0700 (PDT)
Received: by with SMTP id b6so543443yha.40 for <>; Sun, 08 Jun 2014 12:46:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Gq84zm/3Jr3oKhrhm0kxuibkxCWaD4JSIWnlmcpFv4A=; b=BJjlKUagq0rVDzS3zgMKzx6gPr/kpCujRSOUXXqlCyGVBD8gB++o1qqDh9CHTEacsg 5LzEz2zpIiMUUlxqXrX9QwStsEsW9OEBRO0/ZLzvkDxoaIm1TQJZVIZCoeGCoeJl7/YH bVHGZiHbcavYOlQtzZIHUrg9RJ5I/kfUw9F8Pf/r7+nnKZ2zJyH2N0qHHIKGGEu+gsjW FzznOHptcAJjZ2WSqcaY2Y8HShevMfB0K1fbWOP3MniPrfvayU4J7rLRr8Eof0rqQsyD vyHwVPu9RvOEG0YIoaYsKLFs7jUkCzA9mUh5Eg1Juuyd5U6t63BymyjxKciV10LJvLYO 3bFA==
MIME-Version: 1.0
X-Received: by with SMTP id 65mr3126184yhd.107.1402256814023; Sun, 08 Jun 2014 12:46:54 -0700 (PDT)
Received: by with HTTP; Sun, 8 Jun 2014 12:46:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 8 Jun 2014 12:46:53 -0700
Message-ID: <>
From: Watson Ladd <>
To: "" <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Why there should not be a TLS 2.0
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Jun 2014 19:46:57 -0000

On Sun, Jun 8, 2014 at 8:49 AM, Viktor Dukhovni
<> wrote:
> On Sun, Jun 08, 2014 at 02:27:58PM +0200, Kurt Roeckx wrote:
>> I would imagine that the client would like to do a "please give me
>> a tunnel to that hostname", and then get back some descriptor that
>> it can use to talk to it.  Please note that I say hostname,
>> because I think that you can have several names each which it's
>> own certificate on the same IP address.
> Yes, but stronger yet, one needs (ala GSSAPI + Kerberos, which for
> all its limitations gets some things right) to be able to ask for
> service@hostname, not just hostname.  The underlying Kerberos
> stack works with service/instance@REALM, which also makes sense.

See also Ethos, where the network protocol authenticates services and
users to each other. The kicker is services no longer need to
authenticate users.
> We could define new DANE record formats for scalable public-key
> cross realm authentication with Kerberos or a Kerberos-like system,
> and DNSSEC for a suitably secure hostname->realm mapping.

Or one could use a certificate format that supported this natively.
The fact that TLS is (mostly) tied to X509 is a real shame when it
comes to extending.

Yes, you could define extensions for certificate type and use them: at
some point SPKI may have been used this way. But as Viktor points out
GSSAPI dominates this space (unfortunately: anonymous users are hard
to rope in here).

Watson Ladd

> --
>         Viktor.
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin