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

Watson Ladd <> Thu, 13 November 2014 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D48CE1ACE3E for <>; Thu, 13 Nov 2014 11:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x9Jh8WCIPCsY for <>; Thu, 13 Nov 2014 11:41:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D65671ACE21 for <>; Thu, 13 Nov 2014 11:41:58 -0800 (PST)
Received: by with SMTP id 19so754553ykq.4 for <>; Thu, 13 Nov 2014 11:41:58 -0800 (PST)
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 :cc:content-type; bh=BwJtuCzaN4sHjyBkaBDWkGRSVtu1Z4GqT9kFgyJY5F8=; b=IOpoZnRKjRK9h4DC35oG2M8XIDUsTplcXquOCK7BKpbE9t3Zrs6/CpaThqUUMiKiFa CVhL/EiZErYTpgaKdzsB121+zIAS9TSNFWPhAo216QRPeUwMKAXfy5LTuDHjLYeW+H8P 9Xuueqdn5jU0R6orlshccogCWnL8AmPdPz7OkyE9Cs2sslYmvLz9FnNJ2YvDMRibcvf6 DSX3pMw65+PS0bwwSrCfuucOW/DMQZVONzYF8tvhtWLOtuWrvb8DfUgHu/ougg8GYouz 73zCgMpqysBe8qzlr/jw0IMFQe7Kbo1tW48ba9cT4ULza4HcyTiYxD9uqCw+FEhg/cQ8 s08g==
MIME-Version: 1.0
X-Received: by with SMTP id 19mr5457939yhw.4.1415907718077; Thu, 13 Nov 2014 11:41:58 -0800 (PST)
Received: by with HTTP; Thu, 13 Nov 2014 11:41:57 -0800 (PST)
Received: by with HTTP; Thu, 13 Nov 2014 11:41:57 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost> <> <> <20141111173325.GK3412@localhost> <> <20141111203740.GN3412@localhost> <> <> <> <>
Date: Thu, 13 Nov 2014 11:41:57 -0800
Message-ID: <>
From: Watson Ladd <>
To: Rich Salz <>
Content-Type: multipart/alternative; boundary="001a113674469222a00507c2b43e"
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
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: Thu, 13 Nov 2014 19:42:04 -0000

On Nov 13, 2014 10:18 AM, "Salz, Rich" <> wrote:
> I think the major concern is that this is a pretty radical change from
the current deployment model of SSL/TLS.  For what it's worth, I think it's
cool and clever and has a number of real nice properties. But we are
already getting 'picked on' for adding too many new things, and I am
concerned that adding this, fairly late in the game, will delay the
deployment of TLS 1.3 as people will take a step back and consider if they
really need to use this revolutionary new protocol, rather than the
evolutionary changes they were expecting.
> I used my personal opinion here, but I feel pretty comfortable saying I'm
not the only one who feels this way. It's a case of "too much, too late."
> Does that make sense?
> Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts,
including a  non-CA trust model?

Wrap up what exactly? The TLS 1.3 draft as it stands has had very little
security analysis applied. Important questions remain to be resolved. It's
already a major change from TLS 1.2 and increasingly so as more gets

OPTLS is not something to be added as an option on top of whatever else we
want. It's a protocol that solves the problems TLS 1.3 was intended to
solve, and to do so with a design that takes advantage of our knowledge of
security analysis.

Whatever deployment issues exist will exist for TLS 1.3: reuse of TCP
connections reduces the impact of latency.

TLS 2 could do a lot more for security: use formal languages to make
parsing easy, make implementation simplicity a priority.  I doubt the IETF
ever could achieve this: we had IRC and now have XMPP, to name the most
egregious example.

While you can use a different deployment model you don't have to: certs can
be put on all frontend machines exactly as now.

As for non-CA trust model, I'm not sure we have a good one that includes
all uses of TLS: I'd like to know what you propose,  but I'm not sure this
list is the place.

Watson Ladd
>         /r$
> _______________________________________________
> TLS mailing list