Re: [TLS] Deployment ... Re: This working group has failed

Andy Lutomirski <> Tue, 19 November 2013 02:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7256E1AEAE4 for <>; Mon, 18 Nov 2013 18:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GWzJjkSr1FMB for <>; Mon, 18 Nov 2013 18:49:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F07881AEADF for <>; Mon, 18 Nov 2013 18:48:59 -0800 (PST)
Received: by with SMTP id kp14so6080951pab.9 for <>; Mon, 18 Nov 2013 18:48:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zvPTjRODGcJ1dOlS8CWdMSgKv5qzcFNojy/tZ9Thrj0=; b=O4/wB3fGYrHKe5ycmtGn7kxdNm4PosA2qEg42xukhAmmMCLuJ8cJfJ+RQvv9s0S86c 9f6oOkYkFyKVXVCwCKcyudeg/EyHff9EW47KqF453HGCGHrDHeFhxblK7VlHZFcHpxNP AxM7ZMH7JJVMYAD0ORUuh9X9aqzO+Rnri8JNjanT0+WUZLFzBtdMeVfnhWw94iNNrXRP 2rF2m/l02mahehqnUmrBf3Gtyw1oYUlM18nXvheqdrM97xuv6dN8GgHNjoF7GApji+7M Ix7LsMt6gTGFIay+7thhI6759s6mE/0HkogsvP+8FxM9ex9pGtwSoquDztBCm5PNefnD MrRw==
X-Gm-Message-State: ALoCoQnAgUg2LHOIyW4VTnSf4ljU2h3NLNOndJVv06sT/lN9Dmteu7bDCTVcIs8ra8wqJGSCi7Eu
X-Received: by with SMTP id uk8mr16588742pbc.93.1384829334061; Mon, 18 Nov 2013 18:48:54 -0800 (PST)
Received: from ( []) by with ESMTPSA id ha10sm26700673pbd.17.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 18:48:53 -0800 (PST)
Message-ID: <>
Date: Mon, 18 Nov 2013 18:48:52 -0800
From: Andy Lutomirski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Salz, Rich" <>, Watson Ladd <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Tue, 19 Nov 2013 02:49:02 -0000

On 11/18/2013 07:02 AM, Salz, Rich wrote:
>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
> Do you really believe this or are you trying to just be provocative?

Watson's right.  OpenSSL is the norm and the OpenSSL API is
fundamentally wrong.  Let's see:

1. Defaults are insane.  (A crypto library should select a reasonable
set of cipher suites, for example.)  To make OpenSSL work decently, you
have to program a large array of poorly documented settings.  Want GCM?
 You have to ask for it.  (To make matters worse, OpenSSL's cipher suite
names don't match the RFC.)

2. New features need silly code in order to work.  Want DHE?  You need
to write code to feed OpenSSL a DH group.  Want ECDHE?  You need to call
a few poorly documented functions.  Want to support ECDHE with more than
one group (since the client can send a list)?  Oh wait, OpenSSL forgot
about that use case.  So, if and when curve25519 gets added to TLS, all
users of OpenSSL will need to start using a new API to support
curve25519 without losing P-256 support.

3. There are no useful diagnostics.  Want decent reports of why a
connection was rejected?  Good luck.  (I think I figured it out as long
as the client speaks SSL3 or higher, but I'm at a loss as to getting a
meaningful diagnostic for SSLv2.)

4. Want to do anything intelligent about certificate validation?  Good
luck understanding that API.

The world needs a good, permissively licensed,
hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
there is, and it has its set of issues, too.