Be more explicit on PSS requirements #1098
Conversation
draft-ietf-tls-tls13.md
Outdated
| length of the digest output. This codepoint is new in this document and is also | ||
| defined for use with TLS 1.2. | ||
| length of the digest output. An RSA public key (OID rsaEncryption) MUST be | ||
| supported, an RSASSA-PSS public key (OID id-RSASSA-PSS) MAY be supported. |
There was a problem hiding this comment.
what about distinguishing the RSA-PSS keys with and without parameters:
an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with parameters MAY be supported`.
The reason is that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1 1.5 encryption, and thus they provide a way for the server to know that it must protect that key against attacks which utilize RSA ciphersuites under TLS1.2.
draft-ietf-tls-tls13.md
Outdated
| length of the digest output. This codepoint is new in this document and is also | ||
| defined for use with TLS 1.2. | ||
| length of the digest output. An RSA public key (OID rsaEncryption) MUST be | ||
| supported, an RSASSA-PSS public key (OID id-RSASSA-PSS) MAY be supported. |
There was a problem hiding this comment.
"(OID id-RSASSA-PSS)" should come with a reference to https://tools.ietf.org/html/rfc5756
|
Added reference as suggested by @tomato42, marked id-RSASSA-PSS without params as mandatory as suggested by @nmav. Also changed the proposed text to refer explicitly to the salt length (the begin of the paragraph is already explicit about requiring MGF1). Unchanged:
(*) Since both rsaEncryption and id-RSASSA-PSS are mandatory, an implementation that is worried about PKCS#1 v1.5 encryption can offer and sign with an id-RSASSA-PSS key instead. The client (for SKE/server auth) or server (client auth) has no control over the signature key of the peer, but I think that is acceptable. |
draft-ietf-tls-tls13.md
Outdated
| for TLS handshake messages MUST be supported but other parameters MAY be used. | ||
| length of the digest output. | ||
| When used as signature algorithm in certificates, the length of the salt | ||
| SHOULD be equal to the length of the digest output, but other salt lengths MAY |
There was a problem hiding this comment.
but other salt lengths MAY be used
I find that text a step backwards in terms of interoperability. The previous text of requiring that the salt length MUST be equal to the length of the digest output was specific and left no window of misunderstandings. This on the other hand allows a MAY of other salt lengths. What does this actually mean? Some implementations MAY drop these connections while others not?
There was a problem hiding this comment.
The intention is that use of a standard length is guaranteed, but if a CA somehow issues certs with odd salt lengths, then TLS would not outright forbid it (and leave it up to the PKI to perform policy decisions). See also #1109 (comment)
It was added based on comments from Martin Rex (I am not strongly in favor in keeping this freedom though).
There was a problem hiding this comment.
It is a slippery slope. TLS currently specifies exactly the combo of parameters to use for RSA-PSS signing. The negotiation includes the hash and the salt size. What the new text makes, is make the TLS negotiation include only the hash algorithm, and leaves the application to deal with the salt size requirements, which may come outside TLS. I find the previous text simpler to implement and in alignment with having MUST in RSA-PSS certificates with no parameters.
There was a problem hiding this comment.
how about "but longer salt lengths MAY be used"? AFAIR OpenSSL defaults to maximum allowed size (by public key size) of salt for rsa-pss signatures.
I think it would be silly to reject those certificates only because the salt is too large
There was a problem hiding this comment.
Note that PKCS#1 v2.2 (https://tools.ietf.org/html/rfc8017#page-42) seems to suggest that zero-length salts are also okay:
- Typical salt lengths in octets are hLen (the length of the output
of the hash function Hash) and 0. In both cases, the security of
RSASSA-PSS can be closely related to the hardness of inverting
RSAVP1.
Maybe requiring a single salt length is the best for interop purposes. Btw, I think I'm going to close this in favor of #1109, let's continue the discussion there.
There was a problem hiding this comment.
I have double-checked now - OpenSSL does default to maximum salt length possible for a given key size when making signatures - so requiring a salt length of the same size as the hash length would make all OpenSSL certificates made with default PSS settings invalid.
while 0 length salts are ok in RFC 8017, using different hash for MGF1 and signature hash is also ok, so I don't think that's the sole data point we will want to use
This PR intends to clarify the requirements for PSS support.
The requirements are intentionally minimal to reduce implementation efforts, but recognizes that some other implementations may be more complete. Notes:
From what I have heard, boringssl does not (or will not?) implement any PSS support in the certificates (yet?). Don't know if anything should be changed here to reflect that decision, but I thought it is worth mentioning. It is possible that I'll follow boringssl's example in tris.
If a TLS extension is introduced later, hopefully that improves interop with odd keys and signatures that are optional in this PR (PSS pubkey or custom salt lengths).