On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <hka...@redhat.com> wrote:
> > > If it does not specify the DH share signed, it doesn't really change
>
> > anything...
> >
> > 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.
> >
> > (Is the DH share even signed directly? It looks like TLS 1.3 signs via
> > CertificateVerify's handshake context in both directions. Either way,
> > it's just a byte-string message. We could also backport this sort of
> > thing to TLS 1.2 and the signature algorithm still doesn't care about
> > the DH share. That gets encoded into a byte string somehow.)
> >
> > I'm trying to make the decompositions and premultiplications align
> > with how the protocol is structured. TLS 1.2 decomposed algorithm,
> > signing curve, and hash which isn't universal (Ed25519, Ed448, even
> > RSA-PSS's params in full generality aren't the same shape, the
> > definition of "digitally-signed" takes only a byte-string message as
> > input), so they should be premultiplied. Whereas signature algorithm
> > and DH group are cleanly separated in the protocol and needn't be
> > premultiplied.
>
> 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.
> 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.)
For your example, nothing on the wire changes at all. Before, you'd end up
sending:
supported_groups {p256, p384}
supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512, rsa}}
And rsa_pkcs1_sha256 should be allocated to align with {sha256, rsa}, etc.
The interesting case is Ed25519 and Ed448. You'd currently have to send:
supported_groups {..., eddsa_ed25519, eddsa_ed448}
supported_signature_algorithms {..., {sha512, eddsa}, {shake256[1], eddsa}}
However, this does not capture that {shake256, eddsa} + eddsa_ed25519 isn't
legal. Instead I want:
supported_groups {..., irrelevant to ed25519 and friends}
supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448}
David
[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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
