Re: [TLS] Mail regarding draft-ietf-tls-tls13

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 17 June 2018 03:31 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B4128CF3 for <tls@ietfa.amsl.com>; Sat, 16 Jun 2018 20:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mGnTRNiwCOKb for <tls@ietfa.amsl.com>; Sat, 16 Jun 2018 20:31:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E15128BAC for <tls@ietf.org>; Sat, 16 Jun 2018 20:31:44 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5C6E57A330D; Sun, 17 Jun 2018 03:31:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <BN7PR14MB23560D791932A8CB164C592D917F0@BN7PR14MB2356.namprd14.prod.outlook.com>
Date: Sat, 16 Jun 2018 23:31:42 -0400
Cc: "tls@ietf.org" <tls@ietf.org>
Reply-To: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org>
References: <BN7PR14MB23560D791932A8CB164C592D917F0@BN7PR14MB2356.namprd14.prod.outlook.com>
To: Ben Personick <ben.personick@iongroup.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wzGmmwYd9EtJ7-zo6Kc8mc9Jpv8>
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 17 Jun 2018 03:31:47 -0000


> On Jun 12, 2018, at 4:15 PM, Ben Personick <ben.personick@iongroup.com> wrote:
> 
> We are currently evaluating when to begin offering ECC Certificates based cypto on our websites.
>  
> Despite the advantages to doing this in TLS 1..2, there is a lot of push-back to wait until we “have to support it” once the TLS 1.3 draft is published, and the option to use it becomes available.

I am puzzled why you feel you have to support ECC certificates with
TLS 1.3, and yet not for TLS 1.2?  RSA certificates continue to be
supported in TLS 1.3, and ECDSA certificates are well supported in
TLS 1.2.

Are you referring to deploying ECC certificates in your server
software, or interoperating with ECC servers in your client software?

If the latter, then indeed you should start to support servers that
can only present ECDSA, rather than RSA, certificates.  And do so
with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for
TLS 1.3 to be published.  (We can party when it comes out, but that
should not IMHO hold up implementations of ECDSA support).

-- 
-- 
	Viktor.