Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Mon, 4 Jul 2016 17:59:06 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5503852-9B73-41DD-A54C-5B5ADA643397@gmail.com>
References: <4A93EB96-11C3-4F08-B1DC-6ED21E11BFC0@gmail.com>
 <20160704140625.GD4287@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VZ0kMUoOocsgZX8o9-I5TT4sIlk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] PR #23 for RFC4492bis
Precedence: list


> On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusvaara@welho.com> =
wrote:
>=20
> On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote:
>> Hi
>>=20
>> Based on an email exchange with Nikos Mavrogiannopoulos, I=E2=80=99ve =
submitted a PR.
>>=20
>> https://github.com/tlswg/rfc4492bis/pull/23
>>=20
>> If there are no objections, I will accept it and submit version -08 =
this Friday.
>=20
> While scanning through, I noticed that the Ed25519 and Ed448 "curves"
> are still there. I think negotiating those should be done the same way
> as in TLS 1.3 (those would then appear as hash=3D7 signature=3D3/4 =
IIRC).

IMO this makes it very complex. TLS 1.3 replaces the old =
signature_algorithms extension that had pairs of signature =
algorithm/hash algorithm with one that has 16-bit values.

It changes things for ECDSA as well. We=E2=80=99re not going to change =
ECDSA in TLS 1.2. So if we wanted to adopt that we would still interpret =
0x04,0x03 as ECDSA (with whatever curve) along with SHA-256, while =
0x07,0x03 would be Ed25519, not ECDSA with some unknown hash function =
0x07.

Seems strange to me, but I=E2=80=99ll make whatever changes the group =
wants.

Yoav