Re: [TLS] PR to clarify RSASSA-PSS requirements

[Peter Wu <[e-mail]>]

On Tue, Nov 21, 2017 at 08:37:45PM -0800, Eric Rescorla wrote:
> I don't think that this is the right answer.
> 
> Let's separate out the question of (a) what people need to support and (b)
> what the code points mean. (b) needs to be unambigous, as that's the point
> of the extension and this PR actually makes it explicitly unambigous.
> 
> With that said, there seem to be two points of contention:
> 
> - Whether the code point refers to signatures other than those in
> CertificateVerify
> - Whether the code point refers to SPKIs with OIDs other than rsaEncryption
> 
> For the first point, I recognize that there are those who believe that the
> code point should refer only to CertificateVerify but that's not what it
> meant in TLS 1.2 and I don't think there's consensus to make that change.

Yes, it is my understanding (now) that the code point covers both CV
(and SKE in TLS 1.2) and certificate signatures based on RFC 5246.

> We could certainly introduce a new extension later which refers to just
> chain certificates.
>
> For the second point, I wouldn't be averse to having two code points, one
> for PSS that means "must be rsaEncryption" and one for "PSS with funny
> parameters" (with the hope we only ever needed the first). But that's not
> this PR.

Limiting it to rsaEncryption sounds good to me, it removes some
complication. Since it is not clear to me which parameters MUST be
supported now, rather than defining three codepoints for PSS keys now,
what about deferring it to a future spec (possibly in combination with
the new extension for negotiating supported certificates)?

Alternatively something arbitrary can be done such as requiring the
parameters as used for TLS handshakes to be supported (as the PR
proposes) and allowing alternative configurations to be supported too.

Kind regards,
Peter

> -Ekr
> 
> 
> On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu <[e-mail]> wrote:
> 
> > Hi,
> >
> > At the moment there is still ambiguity in the requirements for PSS with
> > relation to certificates. Proposal to clarify this:
> > https://github.com/tlswg/tls13-spec/pull/1098
> >
> >
> > 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:
> >
> > - "Supporting PSS signatures on certificates is a mandatory requirement
> >   and I think we should be very clear about the parameters we permit."
> >   https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
> > - Martin Rex wishes to remove TLS requirements on signature algorithms
> >   for certificates, hence the "MAY" for other PSS parameters in this PR.
> >   https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
> > - Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
> >   certificates, hence the strong MUST wording in this PR.
> > - It does not say anything about non-end-entity certificates, that's up
> >   to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
> >   rsa-pss; EE key: rsa" from
> >   https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
> > - PSS params in certificates are explicitly not restricted, satisfying
> >   https://www.ietf.org/mail-archive/web/tls/current/msg24457.html
> >
> > >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).
> > --
> > Kind regards,
> > Peter Wu
> > https://lekensteyn.nl