On Tue, Jul 12, 2016 at 1:47 PM David Benjamin <david...@chromium.org> wrote:
> [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.) > I should add: 1.3 CertificateVerify does not have this problem. One signs, e.g.: RSA-PSS-SHA384(padding || context || Hash(HS Context) || Hash(resumption_context)) The HS Context can be maintained as a rolling hash of the PRF hash. The signature scheme internally may use a different pre-hash or no pre-hash at all and the handshake logic doesn't care. 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