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

Ben Personick <> Mon, 18 June 2018 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07457130DE7 for <>; Mon, 18 Jun 2018 06:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6V5J9j8OlP5l for <>; Mon, 18 Jun 2018 06:10:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB38A126DBF for <>; Mon, 18 Jun 2018 06:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pJhJr+I8cpewTdBqu4VJrxt7R8QTUXz37HEziAZEWnA=; b=fdlrUmiqckFCySSsEL0zzHwuzP80/EEkYRr2XvdVXNT9nCYBYe6drcwOe887S10B1H/yGi/yMniCAmVjTvx0G5slLRG9ajeANZ8BG+GM6hvF9GZg8CmuGWDgQuyN7SVUCS3EGtjTI+0AKeZDHX4v+wmSblPHRRnhUYfXOZvBKPU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Mon, 18 Jun 2018 13:10:55 +0000
Received: from ([fe80::ac24:4123:784d:29f7]) by ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 13:10:55 +0000
From: Ben Personick <>
To: TLS WG <>
Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13
Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTY=
Date: Mon, 18 Jun 2018 13:10:55 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN7PR14MB2418; 7:mNGb8Idd2ZOaFrwmUky5tMW5dyx3pWUOXritR1mC8pZClNBVqVpEF8cL8LOjJGFX8FqgcDGqIgL5boP8X2rpSkov1d77k7mjqiNaswz4ZUlnhdfp3nwGIy5uqXY9xg/gI1QiqSz57xdjHv4HdcGi6ZQ6GrBtk6df5KCYnyx3vOxWj6KH048ZgJIggUJ/khwl6YkU946+VBmfao4VwixpTAUO/vQusKG19d/yWFZBPGdvfp1c4h/nBWD1w+gJB3RL
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9cf04d2e-f1dd-4528-4b99-08d5d51ced09
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2418;
x-ms-traffictypediagnostic: BN7PR14MB2418:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2418; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2418;
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(39380400002)(376002)(366004)(189003)(199004)(486006)(5660300001)(31696002)(6246003)(81166006)(81156014)(2616005)(11346002)(446003)(99286004)(8936002)(54896002)(76176011)(86362001)(7736002)(6512007)(3280700002)(44832011)(186003)(5250100002)(476003)(53936002)(8676002)(3660700001)(6486002)(14454004)(26005)(6916009)(2906002)(229853002)(66066001)(68736007)(36756003)(316002)(6436002)(2900100001)(478600001)(31686004)(25786009)(106356001)(97736004)(3846002)(6116002)(6506007)(105586002)(102836004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2418;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: o3axErGecm93R96aGArx4RFkn+WTnltlCkYSTnT1IOrb9Qd2FYPJNQQ/dscgvuVAEblVbGtLv2m7hDQyyb65/hZcN9ir8li0jJJsW9y2FyE521HABIZstACWLDkYXDOp8/+XlnMlvhxTj0WM/6maUsMidF+r1lc65uSyHAhmHLyw5NX6razatUj9LCDVHpvC
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_cc5fe1d8b0654f308b7657714aea1949iongroupcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf04d2e-f1dd-4528-4b99-08d5d51ced09
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 13:10:55.3371 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2418
Archived-At: <>
X-Mailman-Approved-At: Mon, 18 Jun 2018 06:29:44 -0700
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jun 2018 13:11:00 -0000

Hello Viktor,

  Thanks for your thoughtful reply.

  I haven't read the draft itself, only the articals which point to it.

  There is a common thread circulating, that all support for RSA Certificates/Ciphers are dropped in TLS 1.3.

  As I wrote in the last email, I am aware we can implemenet ECC certs and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consistent fear of breaking what already works by moving onto offering both an ECC and RSA certificate and corrosponding ciphers.

  If TLS 1.3 does support RSA certs, that removes the drive to begin offering ecdhe_ecdsa alongside ecdhe_rsa, which essentially moves it back to the "Do not need to implement pile", which will not tick forward into the "must implement" pile until it is absolutely required.

I was sincerely hoping to be able to use the expected "end of ths RSA Cert" to move us there in preparation of supporting TLS 1.3 and for once be ahead of the curve instead of implemementing what seems to be superiod encryption methods much later.


From: Viktor Dukhovni <>
Sent: Saturday, June 16, 2018 11:31 PM
To: Ben Personick
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

> On Jun 12, 2018, at 4:15 PM, Ben Personick <> 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).