On Tue, Jan 19, 2016 at 06:55:49PM +0000, David Benjamin wrote:
> On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <hka...@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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
