[TLS] Simplifying signature algorithm negotiation
Hi folks,
This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
1.2, signature algorithms are spread across the handshake. We have
SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
independent registries. NamedGroup is sent in one list, also used for
(EC)DH, while the other two are sent as a pair of (HashAlgorithm,
SignatureAlgorithm) tuples but live in separate registries.
This is a lot of moving parts. Signature negotiation in TLS 1.2 tends to be
messy to implement. Client certificate keys may be in smartcards via
OS-specific APIs, so a lot of time is spent transiting new preference
shapes across API boundaries in order to discover smartcard bugs. Sometimes
I think people deploy client certs because they hate me and want to cause
me pain… :-)
Anyway, the new CFRG curves also bind signature curve and hash together.
The current draft represents this as eddsa_ed25519 and eddsa_ed448
NamedGroups and eddsa SignatureAlgorithm. But this doesn’t capture that
EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA + FF3072.)
I propose we fold the negotiable parameters under one name. Think of how
we’ve all settled on AEADs being a good named primitive with a common type
signature[1]. Specifically:
1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now on,
NamedGroup is only used for (EC)DH.
2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as
they are. Introduce a new SignatureAlgorithm u16 type and negotiate that
instead. (Or maybe a different name to not collide.) u8 is a little tight
to allocate eddsa_ed25519 and eddsa_ed448 separately, but u16 is plenty.
3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2 by
(ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples. 0x0401
becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently with
HashAlgorithm from TLS 1.2. Note this does not introduce new
premultiplications on the wire. Just in the spec and registry.
4. Deprecate ecdsa_sha256, etc., in favor of new
ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
introduces new premultiplications, it’s only 9 values with the pruned TLS
1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
rsapss_{sha256,sha384,sha512}. These come with the signature algorithm and
curve pre-specified. (See [2] at the bottom for full list of allocations.)
Thoughts?
David
[1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
a subset of X.509's RSA-PSS. We'll just not bother with RSA-PSS with
hashAlgorithm SHA-256, maskGenAlgorithm
MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField 14.
And RSA key generation still has size parameter. Hopefully future things
can look more like Ed25519.
[2]
0x-0x06ff - Reserved range for TLS 1.2 compatibility values. Note this
is wire-compatible with TLS 1.2.
- 0x0101 - rsa_pkcs1_md5
- 0x0201 - rsa_pkcs1_sha1
- 0x0301 - rsa_pkcs1_sha224
- 0x0401 - rsa_pkcs1_sha256
- 0x0501 - rsa_pkcs1_sha334
- 0x0601 - rsa_pkcs1_sha512
- 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
- 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility but
ignored in TLS 1.3.
0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3] to
avoid colliding with existing signature algorithms, but I don’t think
that’s necessary[3].
- rsapss_sha256
- rsapss_sha384
- rsapss_sha512
- ecdsa_p256_sha256
- ecdsa_p256_sha384
- ecdsa_p256_sha512
- ecdsa_p384_sha256
- ecdsa_p384_sha384
- ecdsa_p384_sha512
- ecdsa_p521_sha256
- ecdsa_p521_sha384
- ecdsa_p521_sha512
- eddsa_ed25519
- eddsa_ed448
0xfe00-0x - reserved for private use, compatible with existing
HashAlgorithm reservation.
[3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
RSA}, they should ignore it since hash 7 doesn't exist.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
David Benjamin wrote:
> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
> introduces new premultiplications, it’s only 9 values with the pruned TLS
> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>
Have you considered the possibility of using this mapping?:
TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.
Then:
1. You don't have to define any new values.
2. The extension size would be smaller.
3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
(I don't have any particular affinity for that profile other than it seems
to have made choices that have historically been shown to be above average,
and it might be a good idea to avoid interop failure with other
implementations that might have a special affinity for it.)
5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> rsapss_{sha256,sha384,sha512}.
>
This seems like a good idea to me.
> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
> a subset of X.509's RSA-PSS.
>
I believe this is already largely taken care of in TLS 1.3 by fixing all
the parameters to be a function of the digest algorithm used for the
message.
- ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
>
The subset of your proposed values I listed above do not seem helpful. For
example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
truncated to 256 bits.
> 0xfe00-0x - reserved for private use, compatible with existing
> HashAlgorithm reservation.
>
> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
> RSA}, they should ignore it since hash 7 doesn't exist.
>
I think we should expect more pure ECC (no RSA) deployments soon. In that
case, it would be better if new ECC-based values used the value "ECDSA" (3)
instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
as support for RSA.
[1] https://tools.ietf.org/html/rfc6460
Cheers,
Brian
--
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys
We discussed this topic briefly at IETF94 and in more detail at the Marnew workshop. There seemed to be at least enough interest for a list so... Cheers, S. PS: I'd say best to wait 'till next Wednesday or so to start list discussion so that folks have time to join the list. Forwarded Message Subject: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys Date: Fri, 15 Jan 2016 16:54:44 -0800 From: IETF Secretariat Reply-To: i...@ietf.org To: IETF Announcement List CC: @ericsson.com, stephen.farr...@cs.tcd.iedaniel.migault, l...@ietf.org A new IETF non-working group email list has been created. List address: l...@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=lurk To subscribe: https://www.ietf.org/mailman/listinfo/lurk Purpose: Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based the proof of ownership of a private key. Currently most trust models assume the private key is associated and owned by the peer. In addition, the remote peer is both responsible of the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of service on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application, - like a web browser - expects to authenticate a content provider while authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content. There may be a BoF at IETF95 to discuss this topic. For additional information, please contact the list administrators. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. [...] > I propose we fold the negotiable parameters under one name. [...] > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > instead. I previously proposed this here: https://www.ietf.org/mail-archive/web/tls/current/msg18035.html ekr was against it, though it hasn't been discussed that throughly. https://www.ietf.org/mail-archive/web/tls/current/msg18036.html Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduces new premultiplications, it’s only 9 values with the pruned TLS
>> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>>
>
> Have you considered the possibility of using this mapping?:
>
> TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
> TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
> TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.
>
> Then:
> 1. You don't have to define any new values.
> 2. The extension size would be smaller.
>
Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
lose them. I just wrote out all 9 without thinking about it much. Apart
from "please don't cause me interop pain", I don't have strong opinions
about how aggressively we prune the list.
My main worry is, for better or worse (I realize this is a point of
contention), some servers apply sigalgs to both CertificateVerify and
certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a
nuisance.
Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
it would prevent them from adopting TLS 1.3 without switching certificates.
Alternatively, if people decide that sigalgs and certificates officially
have nothing to do with each other in TLS 1.3, then things are fine but we
wouldn't have a way to negotiate such algorithms. I was hoping to avoid
that issue for this proposal, but there is some interaction.
(Whether such certificates exist on the web is probably answerable via CT
logs, but I haven't checked.)
If changing the existing meaning is a nuisance, another option is to
continue to allocate new values but only define ecdsa_p256_sha256,
ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
is) for TLS 1.3 and later.
> 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
> (I don't have any particular affinity for that profile other than it seems
> to have made choices that have historically been shown to be above average,
> and it might be a good idea to avoid interop failure with other
> implementations that might have a special affinity for it.)
>
What interop faliures are you worried about here?
> - ecdsa_p256_sha384
>> - ecdsa_p256_sha512
>> - ecdsa_p384_sha256
>>
> - ecdsa_p384_sha512
>> - ecdsa_p521_sha256
>> - ecdsa_p521_sha384
>>
>
> The subset of your proposed values I listed above do not seem helpful. For
> example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
> truncated to 256 bits.
>
Good point. That makes some of the combinations unlikely.
> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
>> RSA}, they should ignore it since hash 7 doesn't exist.
>>
>
> I think we should expect more pure ECC (no RSA) deployments soon. In that
> case, it would be better if new ECC-based values used the value "ECDSA" (3)
> instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
> as support for RSA.
>
Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with
'ECDSA'. The same footnote applies. :-)
I don't think it makes sense to strategically assign the second byte for
new numbers. Either we believe TLS 1.2 implementations are unlikely to
react to 0x0703 and not worry about it, or we believe they will and we
reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
u16 hack is too silly and don't do it at all.)
David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote: > On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > > 1.2, signature algorithms are spread across the handshake. > [...] > > I propose we fold the negotiable parameters under one name. > [...] > > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > > instead. > > I previously proposed this here: > https://www.ietf.org/mail-archive/web/tls/current/msg18035.html > > ekr was against it, though it hasn't been discussed that throughly. > https://www.ietf.org/mail-archive/web/tls/current/msg18036.html Ah, thanks! I must have missed this discussion. Or perhaps I saw it and forgot. ekr, are you still against this sort of thing? I think the new CFRG signature algorithms tying decisions together is a good argument for why we'd want this. If we believe this trend is to continue (and I hope it does. Ed25519 is a nice and simple interface), trying to decompose it all seems poor. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin wrote: > On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett > wrote: > >> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS >> > 1.2, signature algorithms are spread across the handshake. >> [...] >> > I propose we fold the negotiable parameters under one name. >> [...] >> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm >> as >> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that >> > instead. >> >> I previously proposed this here: >> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >> >> ekr was against it, though it hasn't been discussed that throughly. >> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html > > > Ah, thanks! I must have missed this discussion. Or perhaps I saw it and > forgot. > > ekr, are you still against this sort of thing? I think the new CFRG > signature algorithms tying decisions together is a good argument for why > we'd want this. If we believe this trend is to continue (and I hope it > does. Ed25519 is a nice and simple interface), trying to decompose it all > seems poor. > I'm not sure. I agree that the CFRG thing seems to be a new development. I'll try to confirm my previous opinion or develop a new one over the weekend :) Ekr > David > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Fri, Jan 15, 2016 at 8:10 PM David Benjamin wrote: > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset > is) for TLS 1.3 and later. > (Hrm. Nevermind, actually. If we go with only those three, I don't think this option does anything useful. If we go with a superset, we might want it separate? Would have to think about that to convince myself. Anyway, whether/how to subset is the more important question. Overlap's mostly an optimization.) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
David Benjamin wrote: > (Whether such certificates exist on the web is probably answerable via CT > logs, but I haven't checked.) > Me neither, and I think that's the key thing that would need to be checked to see if my suggestion is viable. 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. >> (I don't have any particular affinity for that profile other than it seems >> to have made choices that have historically been shown to be above average, >> and it might be a good idea to avoid interop failure with other >> implementations that might have a special affinity for it.) >> > > What interop faliures are you worried about here? > The way I proposed things to work for TLS 1.3 is what the Suite B profile does for TLS 1.2. A Suite B client cannot describe the Suite B profile policy with the signature_algorithms extension as-is, so in theory if a Suite B profile client even exists, it would work better if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't know if any such "Suite B client" actually exists, though. > I don't think it makes sense to strategically assign the second byte for > new numbers. Either we believe TLS 1.2 implementations are unlikely to > react to 0x0703 and not worry about it, or we believe they will and we > reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to > u16 hack is too silly and don't do it at all.) > I would bet there will be some logic like "Is sha-256 mentioned at all in the signature_algorithms extension" and/or "is ecdsa mentioned at all in the signature_algorithms" extension that is used by some servers to decide whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think it would be worth the effort at least when the effort is minimal. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Sat, Jan 16, 2016 at 01:10:06AM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
>
> Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
> lose them. I just wrote out all 9 without thinking about it much. Apart
> from "please don't cause me interop pain", I don't have strong opinions
> about how aggressively we prune the list.
Also, only the matching-size 3 of those 9 combinations tend to be
properly (as in, computing correct results most of the time)
implemented. Other 6 can easily be busted, especially the 3 where
hash is larger than curve, as that hits the hash truncation
special case.
> My main worry is, for better or worse (I realize this is a point of
> contention), some servers apply sigalgs to both CertificateVerify and
> certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
> definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a
> nuisance.
I would think that any case where meanings are different (except for
case where use in TLS 1.3 is restricted) is a nuisance.
Avoiding these differences with restriction of server signatures to
RSA-PSS would imply that if client signals TLS 1.3 with only the only
RSA algorithms being the v1.5 ones, then server can't sign using RSA
if selecting TLS 1.3.
And it would also imply that if TLS 1.2 server gets TLS 1.3 client
hello with the new RSA-PSS algorithms, it can sign using RSA-PSS,
even after having downnegotiated TLS 1.2.
> Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
> it would prevent them from adopting TLS 1.3 without switching certificates.
> Alternatively, if people decide that sigalgs and certificates officially
> have nothing to do with each other in TLS 1.3, then things are fine but we
> wouldn't have a way to negotiate such algorithms. I was hoping to avoid
> that issue for this proposal, but there is some interaction.
The ECDSA nasty case can only occur for certificate-to-certificate
linkages, since EE SPKI does not contain hash algorithm, and server is
always able to choose matching one.
Then TLS 1.3 AFAIK does not deprecate Brainpool, so Brainpool ECDSA can
also be seen...
Then RSA might be nastier: do normal RSA certificates work with RSA-
PSS? If not, then the TLS 1.3 servers can't use them.
> If changing the existing meaning is a nuisance, another option is to
> continue to allocate new values but only define ecdsa_p256_sha256,
> ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
> is) for TLS 1.3 and later.
If one does not want to change too much, then one would have to sup-
port those for TLS 1.2 as well (not breaking signature verification
if such algorithm is first advertised and then selected with connection
downnegotiated to TLS 1.2).
> > 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
> > (I don't have any particular affinity for that profile other than it seems
> > to have made choices that have historically been shown to be above average,
> > and it might be a good idea to avoid interop failure with other
> > implementations that might have a special affinity for it.)
> >
>
> What interop faliures are you worried about here?
Things like: Trying to use ECDSA-P256-SHA384 and then one end not imp-
lementing it correctly (e.g. missing truncation).
Apparently ECDSA-P256-SHA384 failure rate is much higher than
ECDSA-P256-SHA256 and ECDSA-P384-SHA384.
> I don't think it makes sense to strategically assign the second byte for
> new numbers. Either we believe TLS 1.2 implementations are unlikely to
> react to 0x0703 and not worry about it, or we believe they will and we
> reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
> u16 hack is too silly and don't do it at all.)
I think it is fairly unlikely that TLS 1.2 endpoints react to things
like 0x0703 or 0x0404. Since even known signature algorithms are un-
usable with unknown hashes, ServerKeyExchange is temporally localized
and CertificateRequest comes too late to be useful for filtering.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
