Re: [TLS] Simplifying signature algorithm negotiation

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 19 January 2016 19:28 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285931B34C7 for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 11:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 ykp4A4H47XxQ for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 11:28:20 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BB9041B34C3 for <tls@ietf.org>; Tue, 19 Jan 2016 11:28:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 40BE85E3; Tue, 19 Jan 2016 21:28:19 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id VD3K_YlJpyrx; Tue, 19 Jan 2016 21:28:19 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 02A0E230D; Tue, 19 Jan 2016 21:28:19 +0200 (EET)
Date: Tue, 19 Jan 2016 21:28:15 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: David Benjamin <davidben@chromium.org>
Message-ID: <20160119192815.GA5795@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> <CAF8qwaBisJRAhbP1Hq1p4SnXNa=4uTaa8Cf-hOmmpTTk4FcRMw@mail.gmail.com> <1717909.HACNtZYKZV@pintsize.usersys.redhat.com> <CAF8qwaCZXdhor8s8=cq-OrYBYzF-_H7MwudmG4BJ+i0uR4nVTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAF8qwaCZXdhor8s8=cq-OrYBYzF-_H7MwudmG4BJ+i0uR4nVTw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Dan2DhEHqGgcA7MbOzoVX47UgEo>
Cc: tls@ietf.org
Subject: Re: [TLS] Simplifying signature algorithm negotiation
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Jan 2016 19:28:23 -0000

On Tue, Jan 19, 2016 at 06:55:49PM +0000, David Benjamin wrote:
> On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <hkario@redhat.com>; wrote:
> 
> >
> > Problem I am pointing out is that NamedGroup specifies not only what
> > curves can be used for signing but also what curves can get signed.
> >
> > Or are you saying that the NamedGroup would stay, and would now specify
> > only the supported parameters for the key exchange, not how they are
> > authenticated (as it is now)?
> >
> 
> Yes.

Also, IIRC some have expressed that sometimes softare can sanely do
ECDHE over some curve but not signature verification. Or it can sanely
do signature verification but not ECDSA.
 
> > On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now
> on, NamedGroup is only used for (EC)DH.
> 
> > On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> > Why would it need to specify what [DH group's] DH share gets signed?
> > NamedGroup still exists for the key exchange (see step 1). I'm only
> > proposing pulling signature curves out of NamedGroup.
> 
> 
> Or to put it other way: what extensions and with what values should I
> > sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either
> > P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA?
> 
> 
> supported_groups {p256, p384}
> supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> rsa_pkcs1_sha512}
> (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.)

Of course, one wants at least semi-sane behaviour when downnegotiating...

> [1] I have not been following the CFRG curve work very closely. Adam tells
> me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion,
> let's assume that's how it ends up.

Actually, it isn't raw SHAKE256 but some weird prefixed variant...
Fortunately only matters for TLS 1.2 client signatures, due to every-
thing else being highly temporally localized.

I do have should-be-final reference implementation and test vectors
(and another implementation that is just slow and has the test
vectors pass). Currently waiting on co-editor.


-Ilari