[TLS] TLS 1.3 and vendor strings?

Jeffrey Walton <noloader@gmail.com> Fri, 22 May 2015 02:46 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1DE601A8F51 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 19:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TGkWZA7TGg9n for <tls@ietfa.amsl.com>; Thu, 21 May 2015 19:46:34 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86731A8F43 for <tls@ietf.org>; Thu, 21 May 2015 19:46:33 -0700 (PDT)
Received: by iesa3 with SMTP id a3so22414133ies.2 for <tls@ietf.org>; Thu, 21 May 2015 19:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=upZkqkW19nu+kW/81qbEw9fXBPaym4UUqxweZievn0s=; b=exZC3QybpjWdnWp+wAKB+Do3d36+lQKGWHHmUwdXMYGRdslxjrV/x3MBVlj3kMfwfz vomQE8ErQdFSehllRnJjvknwiyXpi3US99ZcktihFg5y6dDYZbQW3nAR4t8t1y97j+85 5FWYhce53+uxagrbWbWPi+q7N5N9oP+P1vLhltbUXEtT3pGWAan65rxaV7fxxlZB2nL7 leDRSSwUptob+0IpARLGqXGi/q3TEXjdCrwFPVexo5tx68t85/6DAx6Fl5z7FgE/Jpwb 1Nv24uxZhSrgF/W2zg5bZcbqWcZP549YzHqqbFdlHn4X4Vy2pWzWSmeSFYxXu2ctqefQ 16rw==
MIME-Version: 1.0
X-Received: by with SMTP id g124mr7828041ioe.11.1432262793275; Thu, 21 May 2015 19:46:33 -0700 (PDT)
Received: by with HTTP; Thu, 21 May 2015 19:46:33 -0700 (PDT)
Date: Thu, 21 May 2015 22:46:33 -0400
Message-ID: <CAH8yC8ma-+3XjG9w2Q6Dz41-T_w8L_gpzAybRH5h=H5YVHJudA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vi_p-hMjK8gsKEGyOGijx9uKjdE>
Subject: [TLS] TLS 1.3 and vendor strings?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
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: Fri, 22 May 2015 02:46:35 -0000

Are there any plans to support free form vendor strings?

The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport
for OS X 10.8 and iOS 7.

In this case, OpenSSL had to jump through a number of hoops to
identify the potentially affected clients via fingerprinting.
Fingerprinting was not precise, and it potentially captured unaffected
clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is, an
OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as
buggy even though it was patched.

Or is there another way to handle the occasional implementation bug like this?

(And to be clear: patching is not always an option. Apple is not like
Microsoft or Linux. Rather, they left a number of hosts unpatched for
the ECDHE-ECDSA bug; and did the same with CVE-2015-1130 (Goto Fail);
and did the same with CVE-2015-1130 (Hidden Backdoor)).