[Changing subject since the other thread is about something else.]
On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
> > ### Signature Algorithms
> >
> > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are
> > encoded in two octets, so SignatureScheme values have been allocated to
> > align with TLS 1.2's encoding. Some legacy pairs are left unallocated.
> These
> > algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or
> > negotiated by any implementation. In particular, MD5 {{SLOTH}} and
> SHA-224
> > MUST NOT be used.
> >
> > * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA
> hash/signature pairs.
> > However, the old semantics did not constrain the signing curve.
>
> Also, for interoperability, any legal TLS 1.3 meaning of these algorithms
> must
> be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything
> else
> would be pointless trap.
>
> This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those
> work.
>
> Also, even if meaning of the ECDSA codepoints changed, those would not
> break
> that rule, since new definition is strict subset of old.
Certainly, whether RSA-PSS and EdDSA are defined in 1.2 or not needs to be
decided. Otherwise, a server may see a 1.3 ClientHello with an RSA-PSS
offer, implement RSA-PSS (because the underlying library can do 1.3), but
select 1.2 (because, for whatever reason, the server is still set to 1.2).
If the client believes RSA-PSS does not exist in 1.2 but the server does,
we will have interop failure. There's a few other analogous situations with
things reversed.
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.
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:
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.
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.
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.)
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.
(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.)
David
[*] SSL 3.0 ServerKeyExchange is compatible with 1.3's API, but SSL 3.0
CertificateVerify signs some complex construction rather than simply a hash.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
