Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

[David Benjamin <[e-mail]>]

On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote:
> > [Changing subject since the other thread is about something else.]
> >
> > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist
> > in 1.2 because we're not touching the 1.2 registries. But this should be
> > clarified in the spec. I would actually prefer they stay 1.3-only. I
> > personally could live with either, but that's because we've backported
> the
> > 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some
> > minor weirdness). I did intentionally mean for the scheme to be
> > backportable, but I do not think it should be mandated that
> implementations
> > do so.
>
> If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better
> be able to gracefully deal with server picking on the offer, even after
> downnegotiation. Anything else, and you risk interop failures.
>

Right, there is a risk of interop failures if two implementations disagree
on whether the algorithms exist in 1.2. Since getting these algorithms into
1.2 is not that important, I want everyone to standardize on the easier
option (that is, they do *not* exist in 1.2). Otherwise we risk some
implementations backporting (because the spec says to) and some not
(because it is easier not to).


> Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older
> (no problems there: The server won't be able to pick on the offer).
>
> > 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into
> a
> > hash function and a signature algorithm which takes a pre-hashed value. A
> > 1.3 signature scheme is a function that takes a message. This means that,
> > to backport to TLS 1.2, implementations must remove all pre-hash steps
> and:
>
> The current signature algorithm numbers are messed up. I would have
> assigned
> 0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA.
>
> (That way the signature algorithms have proper hash designations, and yes
> 0x00 is hash designation for "unhashed").
>

TLS 1.3 SignatureScheme intentionally does away with the decomposition. It
thinks of a "signature algorithm" at the level of messages, which means
implementations shouldn't care about this.

This also gives us more breathing room to allocate ed25519-style IDs (which
I would like to be the norm, rather than parametrizing everything). We get
most of our 2^16 space rather than just 2^8.


> > 1. For ServerKeyExchange, assemble the client_random || server_random ||
> > ServerKeyExchange payload and then pass it into the signature scheme.
> > Current logic probably hashes and then feeds the hash in.
>
> If one has proper signature primitive, it takes a message and internally
> hashes it the way needed.
>

Yup, that's why TLS 1.3's version looks the way it does. But if one has
such a primitive, one shouldn't care about how the numbers are decomped
(above). :-)


> > 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full
> > handshake transcript, so there's interactions with the PRF. I've seen
> > implementations which require signing hash match the PRF hash, sometimes
> > with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a
> > mess. I've also seen implementations which decouple them, at the cost of
> > maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting
> > forces the second choice.
>
> By the time CertificateRequest is sent, the server knows the final
> protocol, so it can omit algorithms it knows it can't handle. Also,
> the client picks the actual algorithm, so it too can avoid algorithms
> it can't handle. So client auth isn't the interop hazard server auth
> is.
>

When we first added TLS 1.2 to Chrome via NSS, we hit exactly that interop
hazard. Clients don't know a priori which hash functions the server will
accept and may be using some crappy smartcard. The original implementation
only accepted the PRF hash (SHA-256) and we ran into both servers and
client smartcards that could only sign SHA-1. As a result, NSS maintains a
rolling SHA-1 "backup hash" here.

(The failure mode was, of course, everyone's favorite TLS version fallback.)

I am sure that, were we still using NSS when we added AES_256_GCM (SHA-384
PRF), we would have hit more problems with smartcards that can only sign
SHA-256.

But this is all sort of beside the point. The way to avoid this interop
hazard is to maintain the full handshake buffer which is also how you
backport. :-) I'm more worried about implementations which don't do the
backport because it's more work or they don't want to pay the handshake
buffer.


> > Notably, if backporting EdDSA, there is no rolling hash one can maintain
> > for CertificateVerify anyway. EdDSA is inherently message-based, which
> > motivated the 1.3 change. (That and simpler interfaces.)
>
> Well, proper crypto libs only have message-based signature APIs anyway
> (because hash-based ones are trouble).
>
> > There is a middle ground: we backport RSA-PSS (then we should assign it
> in
> > the 1.2 style and allocate corresponding 1.3-style numbers) and not
> EdDSA.
> > I intentionally did not do this. I did not want, many years down the line
> > when EdDSA certificates actually exist, for implementations to discover
> the
> > message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style
> > so any questions about the new scheme would be resolved early.
>
> Well, RFC4492bis is likely have EdDSA, in way that is compatible with
> TLS 1.3...
>

(s/TLS 1.3/TLS 1.2/?)

Yeah, I don't think defining it for 1.2 makes much sense. I expect 1.3 will
get deployed much faster than EdDSA PKIs.


> > (We've implemented the message-based scheme and it seems to be just fine.
> > If you're willing to pay the cost of the backport to all versions, it
> > actually ends up quite tidy.)
>
> Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but
> there either side can decide just not to support it. No such luck
> with clients that implement the algorithm for server certificates in
> any version.
>
>
> -Ilari
>