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
