Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Fri, Dec 1, 2017 at 12:34 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/12/2017 17:06, Ryan Sleevi wrote:
>
>> On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Depending on the prevalence of non-public CAs (not listed in public
>>> indexes) based on openssl (this would be a smallish company thing more
>>> than a big enterprise thing), it might be useful to have *two* fixed
>>> salt lengths for each combination of hash algorithm and RSA key length:
>>>
>>> 1. The salt length=hash length case previously suggested.
>>>
>>> 2. The salt length=largest permitted by RSA key length and hash length
>>> (OpenSSL default).
>>>
>>> Each of these could still be defined in a memcmp-able way.
>>>
>>>
>> Yes. You could add flexibility if there was both data to support it and
>> justification for the added complexity (passed on to all consumers).
>>
>> I think there is a tremendously high bar to suggest such things are good,
>> and I don't think it's much useful to discuss what's possible without
>> having a position in favor (and data to support) or against (and data to
>> support).
>>
>>
> I am saying someone with the resources should check if there is such
> data.
>

I'm not disagreeing with you that's a potential step.

I'm saying that unless you're stepping up with that data, then describing
how and saying someone should do it - without data to support its necessity
or lack thereof - isn't as useful.

That is, you've described a possible hypothetical scenario. You've
described how it could be measured. We could rathole into the discussions
about the challenges in such measurement (and the time to gather such
data), but such a discussion would not be useful without some initial sense
of how realistic that hypothetical is. We know, from the facts of the
matter, that the realistic nature of that hypothetical is low, and
furthermore, given the facts, the relative impact of said hypothetical is
low. So I don't think it's necessary useful to discuss what we could do to
support an unmeasured hypothetical whose prevalence can be empirically
deduced to be low apriori.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Fri, Dec 1, 2017 at 11:20 AM, Hubert Kario  wrote:

> On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote:
> > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario  wrote:
> > > and fine for NSS too, if that changes don't have to be implemented in
> next
> > > month or two, but have to be implemented before NSS with final TLS 1.3
> > > version
> > > ships
> >
> > Is there a reason not to disable RSA-PSS support in NSS for certificate
> > signatures until that time?
>
> yes, disabling it without disabling RSA-PSS support in TLS (and thus TLS
> 1.3
> in its entirety) is non-trivial and not possible with current code base
>
> > The argument in favor is that this would be a known-buggy implementation
> > (as already demonstrated by the parameter decoder)
> > The argument against is that, in addition to rejecting definitely-bad
> > certs, it would reject definitely-good certs, and thus would limit the
> > ability to test TLS1.3's experimental implementation.
>
> I don't think NSS does reject good certs, can you provide example of such a
> certificate?


We both said the same thing :) That is, the reason to not disable / the
argument against disabling is it'd disable TLS1.3 - unless someone enabled
(RSA-PSS & TLS1.3)

That said, considering that TLS 1.3 is not "stable" in NSS (after all, it's
still a draft), I'm not sure how unreasonable it would be to say that
RSA-PSS should only be enabled if the caller enabled TLS1.3, but given
Firefox enabling TLS1.3, the value itself may be minimal-to-negative, since
it'd always enable RSA-PSS anyways.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Jakob Bohm via dev-security-policy]

On 01/12/2017 17:06, Ryan Sleevi wrote:

On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Depending on the prevalence of non-public CAs (not listed in public
indexes) based on openssl (this would be a smallish company thing more
than a big enterprise thing), it might be useful to have *two* fixed
salt lengths for each combination of hash algorithm and RSA key length:

1. The salt length=hash length case previously suggested.

2. The salt length=largest permitted by RSA key length and hash length
(OpenSSL default).

Each of these could still be defined in a memcmp-able way.



Yes. You could add flexibility if there was both data to support it and
justification for the added complexity (passed on to all consumers).

I think there is a tremendously high bar to suggest such things are good,
and I don't think it's much useful to discuss what's possible without
having a position in favor (and data to support) or against (and data to
support).



I am saying someone with the resources should check if there is such
data.

If the data shows that OpenSSL-style salt lengths are common in closed 
networks, the complexity would consist of:


1. Having two (rather than one) valid value per hash algorithm.

2. The second valid value (OpenSSL default) needs to be computed from
  the RSA key length (it's not a fixed value, though test vectors can
  be given for common RSA key lengths).  In practice there would be
  one value (except 2 bytes) for salt lengths < 65536 bits, one for salt
  lengths >= 65536 bits (with 3 varying bytes), so a full DER encoder is
  not even needed, though most X.509 libraries will already contain a
  suitable DER encoder.  Salt lengths < 256 bits are already banned by
  other parts of policy, salt lengths >= 16Mbit are unrealistic.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote:
> On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario  wrote:
> > and fine for NSS too, if that changes don't have to be implemented in next
> > month or two, but have to be implemented before NSS with final TLS 1.3
> > version
> > ships
> 
> Is there a reason not to disable RSA-PSS support in NSS for certificate
> signatures until that time?

yes, disabling it without disabling RSA-PSS support in TLS (and thus TLS 1.3 
in its entirety) is non-trivial and not possible with current code base
 
> The argument in favor is that this would be a known-buggy implementation
> (as already demonstrated by the parameter decoder)
> The argument against is that, in addition to rejecting definitely-bad
> certs, it would reject definitely-good certs, and thus would limit the
> ability to test TLS1.3's experimental implementation.

I don't think NSS does reject good certs, can you provide example of such a 
certificate?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Friday, 1 December 2017 16:33:10 CET Jakob Bohm via dev-security-policy 
wrote:
> On 01/12/2017 16:23, Hubert Kario wrote:
> > On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote:
> >> On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario  wrote:
>  It does feel like again the argument is The CA/EE should say 'I won't
>  do
> >>> 
> >>> X'
> >>> 
>  so that a client won't accept a signature if the CA does X, except it
>  doesn't change the security properties at all if the CA/EE does
>  actually
> >>> 
> >>> do
> >>> 
>  X, and the only places it does affect the security properties are
>  either
>  already addressed (e.g. digitalSignature EKU) or themselves not
>  protected
>  by the proposed mechanism.
> >>> 
> >>> a). I think you're talking about Key Usage, not Extended Key Usage
> >>> b). digitalSignature is a Key Usage, not Extended Key Usage bit
> >>> c). Extended Key Usage has only one flag for use in TLS - serverAuth -
> >>> which
> >>> doesn't say anything about applicability of the key for SKE signature
> >>> but
> >>> not
> >>> RSA key exchange
> >>> d). show me the clients that actually honour the Key Usage flags for TLS
> >>> in a
> >>> way that prevents use of certificate with rsaEncryption SPKI for RSA key
> >>> exchange
> >>> 
> >>> so, yes, I'm afraid that you "must be missing something"
> >> 
> >> So while we started off in disagreement, it sounds like we have cycled
> >> back
> >> to the view that RSA-PSS-params, if present, should be memcmp() able
> >> (between SPKI and Signature and between Signature and Policy)
> >> So the only thing that we're debating here is whether or not expressing
> >> RSA-PSS in the SPKI (at all) is a good thing.
> >> 
> >> The view in favor of this is:
> >> - Because CAs have made a complete mess of the existing rsaEncryption +
> >> KU
> >> , clients don't check KU for rsaEncryption (Notably, they do check KU for
> >> ECDSA because that's necessary to distinguish from ECDH)
> >> - If a certificate is encoded with rsaEncryption, it's possible for a
> >> server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS
> >> 1.3
> >> RSA-PSS ciphersuites
> >> - If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that
> >> the
> >> implementation may be buggy and subject to Bleichenbacher
> >> - And expressing (via the SPKI OID) is an 'effective' way to prevent that
> >> downgrade, which itself is only a risk if you're using a buggy
> >> implementation.
> >> 
> >> Is that accurate?
> > 
> > yes
> > 
> >> To offset that risk, the goal is to use the SPKI algorithm as the signal
> >> to
> >> 'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5).
> >> This, despite the fact that SPKI parsing does not correctly work on any
> >> platform
> > 
> > rejecting what you do not understand (iOS, Android) is completely valid
> > and
> > expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys
> > imported from PKCS#12 file...
> > 
> >>- Windows and NSS both apply DER-like BER parsers and do not strictly
> >> 
> >> reject (Postel's principle, despite Postel-was-wrong)
> > 
> > NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them
> > (probably even 1.1.0), are you certain that Windows doesn't reject
> > certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional
> > code to know that the public key for OID rsaEncryption and rsassaPss is
> > formatted in one and the same way... If you don't don't have that code,
> > it looks like completely different key type (think EdDSA or ECDSA for
> > RSA-only
> > implementation)
> > 
> >>- macOS and iOS reject unrecognized SPKIs as weak keys
> >>- Android supports PSS-signatures but a provider for decoding said
> >>public
> >> 
> >> keys is not provided by default
> >> 
> >> Are there any other arguments in favor of the PSS-SPKI not captured here?
> > 
> > there is a remote chance that RSA-PSS with non-zero salts is strictly more
> > secure (unforgeable) than PKCS#1 v1.5, but for the sake of argument let's
> > say that what you said is the primary and only argument for RSA-PSS OID
> > in SPKI
> > 
> > so no, there aren't other arguments
> > 
> >> I think that we agree on the substance of the PSS implementation - Must
> >> Be
> >> Memcmp-able - makes many of the client complexity concerns. The
> >> deployment
> >> complexity concerns are unavoidable - few clients support RSA-PSS in part
> >> because of the disaster than is RFC 4055 - but that's a deployment
> >> concern,
> >> not an implementation concern.
> >> 
> >> As it relates to what changes this means for NSS:
> >> - Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts
> >> 
> >>- That means NSS should NOT support arbitrary salt lengths, as doing
> >>so
> >> 
> >> adds flexibility at the cost of maintainability and security
> 
> Depending on the prevalence of non-public CAs (not listed in public
> indexes) 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario  wrote:
>
> >   - Windows and NSS both apply DER-like BER parsers and do not strictly
> > reject (Postel's principle, despite Postel-was-wrong)
>
> NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them
> (probably even 1.1.0), are you certain that Windows doesn't reject
> certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional
> code to
> know that the public key for OID rsaEncryption and rsassaPss is formatted
> in
> one and the same way... If you don't don't have that code, it looks like
> completely different key type (think EdDSA or ECDSA for RSA-only
> implementation)
>

Apologies for again not being very precise here (and now you can see why I
also like precision in policy)

Both Windows and (as of now) NSS accept RSS-PSS SPKIs, but they apply
rather liberal decoders that do not enforce the DER encoding rules - for
example, it's valid to supply an explicitly encoded SHA-1 hash, rather than
omit it, despite DER rules stating you don't encode the default value.

That's why I say they do not strictly reject - they demonstrate the very
problem I'm suggesting we avoid (by memcmp()ing), which is that validation
is hard and not consistently implemented.


> and fine for NSS too, if that changes don't have to be implemented in next
> month or two, but have to be implemented before NSS with final TLS 1.3
> version
> ships


Is there a reason not to disable RSA-PSS support in NSS for certificate
signatures until that time?

The argument in favor is that this would be a known-buggy implementation
(as already demonstrated by the parameter decoder)
The argument against is that, in addition to rejecting definitely-bad
certs, it would reject definitely-good certs, and thus would limit the
ability to test TLS1.3's experimental implementation.

Is that correct?

If that is, I'm not sure why a policy of disable-by-default and allow code
wanting to experiment with TLS1.3 (knowing it's experimental) from enabling
the experimental (but incomplete) PSS support.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Depending on the prevalence of non-public CAs (not listed in public
> indexes) based on openssl (this would be a smallish company thing more
> than a big enterprise thing), it might be useful to have *two* fixed
> salt lengths for each combination of hash algorithm and RSA key length:
>
> 1. The salt length=hash length case previously suggested.
>
> 2. The salt length=largest permitted by RSA key length and hash length
> (OpenSSL default).
>
> Each of these could still be defined in a memcmp-able way.
>

Yes. You could add flexibility if there was both data to support it and
justification for the added complexity (passed on to all consumers).

I think there is a tremendously high bar to suggest such things are good,
and I don't think it's much useful to discuss what's possible without
having a position in favor (and data to support) or against (and data to
support).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Jakob Bohm via dev-security-policy]

On 01/12/2017 16:23, Hubert Kario wrote:

On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote:

On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario  wrote:

It does feel like again the argument is The CA/EE should say 'I won't do


X'


so that a client won't accept a signature if the CA does X, except it
doesn't change the security properties at all if the CA/EE does actually


do


X, and the only places it does affect the security properties are either
already addressed (e.g. digitalSignature EKU) or themselves not
protected
by the proposed mechanism.


a). I think you're talking about Key Usage, not Extended Key Usage
b). digitalSignature is a Key Usage, not Extended Key Usage bit
c). Extended Key Usage has only one flag for use in TLS - serverAuth -
which
doesn't say anything about applicability of the key for SKE signature but
not
RSA key exchange
d). show me the clients that actually honour the Key Usage flags for TLS
in a
way that prevents use of certificate with rsaEncryption SPKI for RSA key
exchange

so, yes, I'm afraid that you "must be missing something"


So while we started off in disagreement, it sounds like we have cycled back
to the view that RSA-PSS-params, if present, should be memcmp() able
(between SPKI and Signature and between Signature and Policy)
So the only thing that we're debating here is whether or not expressing
RSA-PSS in the SPKI (at all) is a good thing.

The view in favor of this is:
- Because CAs have made a complete mess of the existing rsaEncryption + KU
, clients don't check KU for rsaEncryption (Notably, they do check KU for
ECDSA because that's necessary to distinguish from ECDH)
- If a certificate is encoded with rsaEncryption, it's possible for a
server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS 1.3
RSA-PSS ciphersuites
- If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that the
implementation may be buggy and subject to Bleichenbacher
- And expressing (via the SPKI OID) is an 'effective' way to prevent that
downgrade, which itself is only a risk if you're using a buggy
implementation.

Is that accurate?


yes


To offset that risk, the goal is to use the SPKI algorithm as the signal to
'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5).
This, despite the fact that SPKI parsing does not correctly work on any
platform


rejecting what you do not understand (iOS, Android) is completely valid and
expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys
imported from PKCS#12 file...


   - Windows and NSS both apply DER-like BER parsers and do not strictly
reject (Postel's principle, despite Postel-was-wrong)


NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them
(probably even 1.1.0), are you certain that Windows doesn't reject
certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional code to
know that the public key for OID rsaEncryption and rsassaPss is formatted in
one and the same way... If you don't don't have that code, it looks like
completely different key type (think EdDSA or ECDSA for RSA-only
implementation)


   - macOS and iOS reject unrecognized SPKIs as weak keys
   - Android supports PSS-signatures but a provider for decoding said public
keys is not provided by default

Are there any other arguments in favor of the PSS-SPKI not captured here?


there is a remote chance that RSA-PSS with non-zero salts is strictly more
secure (unforgeable) than PKCS#1 v1.5, but for the sake of argument let's say
that what you said is the primary and only argument for RSA-PSS OID in SPKI

so no, there aren't other arguments
  

I think that we agree on the substance of the PSS implementation - Must Be
Memcmp-able - makes many of the client complexity concerns. The deployment
complexity concerns are unavoidable - few clients support RSA-PSS in part
because of the disaster than is RFC 4055 - but that's a deployment concern,
not an implementation concern.

As it relates to what changes this means for NSS:
- Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts
   - That means NSS should NOT support arbitrary salt lengths, as doing so
adds flexibility at the cost of maintainability and security


Depending on the prevalence of non-public CAs (not listed in public
indexes) based on openssl (this would be a smallish company thing more
than a big enterprise thing), it might be useful to have *two* fixed
salt lengths for each combination of hash algorithm and RSA key length:

1. The salt length=hash length case previously suggested.

2. The salt length=largest permitted by RSA key length and hash length
(OpenSSL default).

Each of these could still be defined in a memcmp-able way.


   - This resolves the DER-like BER decoding
- Strictly enforcing the KU for RSA-PSS (which it improperly enforces KUs
on keys today already, but hopefully RSA-PSS has not been ruined)

Is that correct?


yes, fine by me

and fine for NSS too, if that changes 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote:
> On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario  wrote:
> > > It does feel like again the argument is The CA/EE should say 'I won't do
> > 
> > X'
> > 
> > > so that a client won't accept a signature if the CA does X, except it
> > > doesn't change the security properties at all if the CA/EE does actually
> > 
> > do
> > 
> > > X, and the only places it does affect the security properties are either
> > > already addressed (e.g. digitalSignature EKU) or themselves not
> > > protected
> > > by the proposed mechanism.
> > 
> > a). I think you're talking about Key Usage, not Extended Key Usage
> > b). digitalSignature is a Key Usage, not Extended Key Usage bit
> > c). Extended Key Usage has only one flag for use in TLS - serverAuth -
> > which
> > doesn't say anything about applicability of the key for SKE signature but
> > not
> > RSA key exchange
> > d). show me the clients that actually honour the Key Usage flags for TLS
> > in a
> > way that prevents use of certificate with rsaEncryption SPKI for RSA key
> > exchange
> > 
> > so, yes, I'm afraid that you "must be missing something"
> 
> So while we started off in disagreement, it sounds like we have cycled back
> to the view that RSA-PSS-params, if present, should be memcmp() able
> (between SPKI and Signature and between Signature and Policy)
> So the only thing that we're debating here is whether or not expressing
> RSA-PSS in the SPKI (at all) is a good thing.
> 
> The view in favor of this is:
> - Because CAs have made a complete mess of the existing rsaEncryption + KU
> , clients don't check KU for rsaEncryption (Notably, they do check KU for
> ECDSA because that's necessary to distinguish from ECDH)
> - If a certificate is encoded with rsaEncryption, it's possible for a
> server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS 1.3
> RSA-PSS ciphersuites
> - If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that the
> implementation may be buggy and subject to Bleichenbacher
> - And expressing (via the SPKI OID) is an 'effective' way to prevent that
> downgrade, which itself is only a risk if you're using a buggy
> implementation.
> 
> Is that accurate?

yes

> To offset that risk, the goal is to use the SPKI algorithm as the signal to
> 'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5).
> This, despite the fact that SPKI parsing does not correctly work on any
> platform

rejecting what you do not understand (iOS, Android) is completely valid and 
expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys 
imported from PKCS#12 file...

>   - Windows and NSS both apply DER-like BER parsers and do not strictly
> reject (Postel's principle, despite Postel-was-wrong)

NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them 
(probably even 1.1.0), are you certain that Windows doesn't reject 
certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional code to 
know that the public key for OID rsaEncryption and rsassaPss is formatted in 
one and the same way... If you don't don't have that code, it looks like 
completely different key type (think EdDSA or ECDSA for RSA-only 
implementation)

>   - macOS and iOS reject unrecognized SPKIs as weak keys
>   - Android supports PSS-signatures but a provider for decoding said public
> keys is not provided by default
> 
> Are there any other arguments in favor of the PSS-SPKI not captured here?

there is a remote chance that RSA-PSS with non-zero salts is strictly more 
secure (unforgeable) than PKCS#1 v1.5, but for the sake of argument let's say 
that what you said is the primary and only argument for RSA-PSS OID in SPKI

so no, there aren't other arguments
 
> I think that we agree on the substance of the PSS implementation - Must Be
> Memcmp-able - makes many of the client complexity concerns. The deployment
> complexity concerns are unavoidable - few clients support RSA-PSS in part
> because of the disaster than is RFC 4055 - but that's a deployment concern,
> not an implementation concern.
> 
> As it relates to what changes this means for NSS:
> - Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts
>   - That means NSS should NOT support arbitrary salt lengths, as doing so
> adds flexibility at the cost of maintainability and security
>   - This resolves the DER-like BER decoding
> - Strictly enforcing the KU for RSA-PSS (which it improperly enforces KUs
> on keys today already, but hopefully RSA-PSS has not been ruined)
> 
> Is that correct?

yes, fine by me

and fine for NSS too, if that changes don't have to be implemented in next 
month or two, but have to be implemented before NSS with final TLS 1.3 version 
ships
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario  wrote:

> > It does feel like again the argument is The CA/EE should say 'I won't do
> X'
> > so that a client won't accept a signature if the CA does X, except it
> > doesn't change the security properties at all if the CA/EE does actually
> do
> > X, and the only places it does affect the security properties are either
> > already addressed (e.g. digitalSignature EKU) or themselves not protected
> > by the proposed mechanism.
>
> a). I think you're talking about Key Usage, not Extended Key Usage
> b). digitalSignature is a Key Usage, not Extended Key Usage bit
> c). Extended Key Usage has only one flag for use in TLS - serverAuth -
> which
> doesn't say anything about applicability of the key for SKE signature but
> not
> RSA key exchange
> d). show me the clients that actually honour the Key Usage flags for TLS
> in a
> way that prevents use of certificate with rsaEncryption SPKI for RSA key
> exchange
>
> so, yes, I'm afraid that you "must be missing something"
>

So while we started off in disagreement, it sounds like we have cycled back
to the view that RSA-PSS-params, if present, should be memcmp() able
(between SPKI and Signature and between Signature and Policy)

So the only thing that we're debating here is whether or not expressing
RSA-PSS in the SPKI (at all) is a good thing.

The view in favor of this is:
- Because CAs have made a complete mess of the existing rsaEncryption + KU
, clients don't check KU for rsaEncryption (Notably, they do check KU for
ECDSA because that's necessary to distinguish from ECDH)
- If a certificate is encoded with rsaEncryption, it's possible for a
server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS 1.3
RSA-PSS ciphersuites
- If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that the
implementation may be buggy and subject to Bleichenbacher
- And expressing (via the SPKI OID) is an 'effective' way to prevent that
downgrade, which itself is only a risk if you're using a buggy
implementation.

Is that accurate?

To offset that risk, the goal is to use the SPKI algorithm as the signal to
'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5).
This, despite the fact that SPKI parsing does not correctly work on any
platform
  - Windows and NSS both apply DER-like BER parsers and do not strictly
reject (Postel's principle, despite Postel-was-wrong)
  - macOS and iOS reject unrecognized SPKIs as weak keys
  - Android supports PSS-signatures but a provider for decoding said public
keys is not provided by default

Are there any other arguments in favor of the PSS-SPKI not captured here?

I think that we agree on the substance of the PSS implementation - Must Be
Memcmp-able - makes many of the client complexity concerns. The deployment
complexity concerns are unavoidable - few clients support RSA-PSS in part
because of the disaster than is RFC 4055 - but that's a deployment concern,
not an implementation concern.

As it relates to what changes this means for NSS:
- Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts
  - That means NSS should NOT support arbitrary salt lengths, as doing so
adds flexibility at the cost of maintainability and security
  - This resolves the DER-like BER decoding
- Strictly enforcing the KU for RSA-PSS (which it improperly enforces KUs
on keys today already, but hopefully RSA-PSS has not been ruined)

Is that correct?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Thursday, 30 November 2017 21:49:42 CET Ryan Sleevi wrote:
> On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario  wrote:
> > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario 
> > 
> > wrote:
> > > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > > > vulnerable to attacks like the Bleichenbacher, if it is not usable
> > > > with
> > > > PKCS#1
> > > > v1.5 it's not vulnerable in practice to such attacks
> > > 
> > > A certificate does not produce signatures - a key does.
> > > A certificate carries signatures, but only relevant to verifiers.
> > 
> > and verifiers are who enforces if the signatures are sane
> > and for verifiers only the certificate is visible, not private key
> > and certificate for the user of the key is essentially a blob, not
> > something
> > he or she can edit, so it is a commitment (even for CA, as that self
> > signed
> > one is no longer in control of it)
> > 
> > > Your reference to Bleichenbacher again makes it unclear if you're
> > > expressing a concern about the protection of the private key or the
> > 
> > quality
> > 
> > > of the signatures, or whether you're conflating with ciphersuite
> > > negotiation and encryption.
> > 
> > key with rsaEncryption SPKI can be used for both signatures and
> > encryption,
> > key with RSA-PSS SPKI can't be used for encryption if at least one party
> > is
> > standards compliant
> > 
> > and the only way the other party can tell if the key is a rsa or a rsa-pss
> > key
> > is by looking at the certificate
> > 
> > so if the _private_ key is rsa or rsa-pss type is of purely philosophical
> > concern
> 
> Then I think this is an incredibly convoluted concern.
> 
> If I'm understanding correctly - and I hope you can correct me if I'm not -
> the view is that it is valuable to limit a public key via an unnecessary
> complex encoding scheme so that it does not get used for encryption (in
> what protocol? Obviously not X.509 - so presumably certificates) so that it
> is robust against CCA like Bleichenbacher?
> 
> It feels like I just spewed out words writing that out, because it does not
> seem like it fits a consistent or coherent threat model, and so surely I
> must be missing something.

I discussed it with Bob Relyea, Daiki Ueno, Nikos Mavrogiannopoulos and they 
see it as a valid concern and acceptable solution.

My feeling of the discussion on the TLS WG mailing about the same topic was 
the same - that prohibiting use of key for RSA key exchange has value.
(continued below)
 
> It does feel like again the argument is The CA/EE should say 'I won't do X'
> so that a client won't accept a signature if the CA does X, except it
> doesn't change the security properties at all if the CA/EE does actually do
> X, and the only places it does affect the security properties are either
> already addressed (e.g. digitalSignature EKU) or themselves not protected
> by the proposed mechanism.

a). I think you're talking about Key Usage, not Extended Key Usage
b). digitalSignature is a Key Usage, not Extended Key Usage bit
c). Extended Key Usage has only one flag for use in TLS - serverAuth - which 
doesn't say anything about applicability of the key for SKE signature but not 
RSA key exchange
d). show me the clients that actually honour the Key Usage flags for TLS in a 
way that prevents use of certificate with rsaEncryption SPKI for RSA key 
exchange

so, yes, I'm afraid that you "must be missing something"

> > that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI?
> 
> Both!
> 
> I think the 'correct' solution from a policy perspective, given these
> constraints, is:
> - rsaEncryption as SPKI is perfectly fine (and, indeed, the only one that
> interoperates)
>   - I would even go as far as to say rsaEncryption as SPKI should be
> *required*, as anything else is merely an expression of intent that only
> matters if the private key control has been lost or confused

that's your opinion, not the community consensus

>   - The policy itself should express that while the certificate may not
> express the intent, any other use of the associated private key is a
> fundamental trust violation, regardless of whether or not clients will
> accept it (again, because it means you've lost control of the key / cannot
> keep it constrained as you intended to)

I have no problem with phrasing it primarily in terms of policy and allowing 
for that policy to be duplicated in CA's certificate SPKI

>   - If allowed, it should be fully absent or byte-for-byte identical to the
> signature

again, no problem 

> - rsaPSS as the signature
>   - It should have byte-for-byte encodings of the blessed forms for PSS +
> SHA-256/384/512

no problem

>  - This means no salt size variability as an unnecessary complexity
> that imposes decoding costs upon the client

no problem

>   - It should be byte-for-byte matched with the SPKI if 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario  wrote:

> On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario 
> wrote:
> > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > > vulnerable to attacks like the Bleichenbacher, if it is not usable with
> > > PKCS#1
> > > v1.5 it's not vulnerable in practice to such attacks
> >
> > A certificate does not produce signatures - a key does.
> > A certificate carries signatures, but only relevant to verifiers.
>
> and verifiers are who enforces if the signatures are sane
> and for verifiers only the certificate is visible, not private key
> and certificate for the user of the key is essentially a blob, not
> something
> he or she can edit, so it is a commitment (even for CA, as that self signed
> one is no longer in control of it)
>
> > Your reference to Bleichenbacher again makes it unclear if you're
> > expressing a concern about the protection of the private key or the
> quality
> > of the signatures, or whether you're conflating with ciphersuite
> > negotiation and encryption.
>
> key with rsaEncryption SPKI can be used for both signatures and encryption,
> key with RSA-PSS SPKI can't be used for encryption if at least one party is
> standards compliant
>
> and the only way the other party can tell if the key is a rsa or a rsa-pss
> key
> is by looking at the certificate
>
> so if the _private_ key is rsa or rsa-pss type is of purely philosophical
> concern
>

Then I think this is an incredibly convoluted concern.

If I'm understanding correctly - and I hope you can correct me if I'm not -
the view is that it is valuable to limit a public key via an unnecessary
complex encoding scheme so that it does not get used for encryption (in
what protocol? Obviously not X.509 - so presumably certificates) so that it
is robust against CCA like Bleichenbacher?

It feels like I just spewed out words writing that out, because it does not
seem like it fits a consistent or coherent threat model, and so surely I
must be missing something.

It does feel like again the argument is The CA/EE should say 'I won't do X'
so that a client won't accept a signature if the CA does X, except it
doesn't change the security properties at all if the CA/EE does actually do
X, and the only places it does affect the security properties are either
already addressed (e.g. digitalSignature EKU) or themselves not protected
by the proposed mechanism.

This doesn't make sense. It's not good policy.


>
> > No, such CAs do exist, and we haven't revoked such trust. Your statement
> is
> > empirically false.
> >
> > That's why I'm trying to be explicit in the policy here - that the policy
> > is about the keys, not the certificates.
>
> but the private keys are invisible and they should be invisible to anyone
> but
> the owner! the only way to check if they are used according to their
> intention
> is to look at the corresponding certificate!
>

I thought I already demonstrated that this was false, because the statement
of capability is n capabilities to 1 key, and who makes those statements is
not the private key.

And that intention can be expressed through means other than the inanity of
RFC 4055 to begin with, or that intention is an unnecessary option imposed
on clients to satisfy the whims of the signature producer, and we should
favor clients over producers.


> it's fully an implementation's detail whether implementation stores the
> rsa-
> pss params with the private key or derives them from associated
> certificate -
> it doesn't matter
>

And this is where I disagree - the fact that deriving them from the
associated certificate imposes a significant cost upon clients is something
to be concerned about and worthy of prohibition. There's no need to
outsource the implementation cost upon the ecosystem for what can and
ostensibly should be the CA's ability to control.


> > > I don't think that it's the act of making the signature that weakens
> the
> > > key
> >
> > Great, then we don't need to restrict keys.
>
> that's cherry picking and taking sentences out of context...
>

I don't think it is.

There has been a constant conflation between a desire to:
1) Ensure that a sufficient level of security is afforded all clients
against known risks
2) Allow producers flexibility to implement their arbitrary security
policies

I disagree that 2 should be a consideration, unless it comes without client
cost. In the case of RFC 4055, it comes with substantial client cost (as
already demonstrated by the missteps made by NSS, past and present), and so
such flexibility is unreasonably complex. We've also seemingly reached
agreement that, with respect to 1, it's either a matter of client policy
(to accept or reject a given 'weak' signature) or that it's a matter of
cross-algorithm attacks (which we've agreed doesn't undermine security)

So 1 doesn't apply, 2 is too costly, and clients 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario  wrote:
> > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > vulnerable to attacks like the Bleichenbacher, if it is not usable with
> > PKCS#1
> > v1.5 it's not vulnerable in practice to such attacks
> 
> A certificate does not produce signatures - a key does.
> A certificate carries signatures, but only relevant to verifiers.

and verifiers are who enforces if the signatures are sane
and for verifiers only the certificate is visible, not private key
and certificate for the user of the key is essentially a blob, not something 
he or she can edit, so it is a commitment (even for CA, as that self signed 
one is no longer in control of it)

> Your reference to Bleichenbacher again makes it unclear if you're
> expressing a concern about the protection of the private key or the quality
> of the signatures, or whether you're conflating with ciphersuite
> negotiation and encryption.

key with rsaEncryption SPKI can be used for both signatures and encryption, 
key with RSA-PSS SPKI can't be used for encryption if at least one party is 
standards compliant

and the only way the other party can tell if the key is a rsa or a rsa-pss key 
is by looking at the certificate

so if the _private_ key is rsa or rsa-pss type is of purely philosophical 
concern

> > > It does not do prevent such a signature from being created - that's what
> > 
> > I
> > 
> > > mean.
> > 
> > now you're being silly
> > 
> > the Mozilla policy doesn't prohibit the CA from making a service that will
> > perform RSA private key operation on arbitrary strings either but we would
> > still revoke trust from CA that would do such a thing, because just the
> > fact
> > that such a service _could_ have been used maliciously (to sign arbitrary
> > certificates) is enough to distrust it!
> 
> No, such CAs do exist, and we haven't revoked such trust. Your statement is
> empirically false.
> 
> That's why I'm trying to be explicit in the policy here - that the policy
> is about the keys, not the certificates.

but the private keys are invisible and they should be invisible to anyone but 
the owner! the only way to check if they are used according to their intention 
is to look at the corresponding certificate!

it's fully an implementation's detail whether implementation stores the rsa-
pss params with the private key or derives them from associated certificate - 
it doesn't matter

> > I don't think that it's the act of making the signature that weakens the
> > key
> 
> Great, then we don't need to restrict keys.

that's cherry picking and taking sentences out of context...

> > > I understand - but I'm saying that what we're discussing fundamentally
> > > relates to the key.
> > > 
> > > If a CA was technically constrained to .com, said they would never issue
> > > for something not .com, but then issued for .org, it's absolutely
> > > grounds
> > > for concern.
> > > If it doesn't matter whether a CA issues for .com or .org, and they
> > 
> > simply
> > 
> > > choose to only issue for .com, then it doesn't make sense to require
> > > clients to support the CA's expression of intent if doing so introduces
> > > security risk to clients (and it does) and complexity risk.
> > 
> > so where's the bug that removes support for that in Firefox? Will we get
> > it in
> > before the next ESR? /s
> 
> You've again misunderstood the argument. But I'm not sure that there's much
> value in continuing - I've attempted to get you to either outline the value
> proposition or to outline the risks.

the only risk you're bringing up again and again is a nebulous "but it's hard 
to do, so we may make mistakes"

guess what: that's the case for all of crypto, all of network protocols, 
that's why we repeat the mantra of "don't implement crypto yourself", it's 
silly to bring it up in the first place

> We've danced around on semantic games,

And how am I supposed to answer to that without invoking an ad hominem?

> but we've identified that there is no risk in comingling these hash
> algorithms,

no, there is risk, we just can't quantify it

> that the only risk in being strict relates to a single software
> product with an unknown (but understandably miniscule, by virtue of no bugs
> being filed) number of extant certificates, while we have a profound
> opportunity to do the Right Thing based on lessons repeatedly learned.

that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI?

> > you're arguing that machine readable CA policy is a _bad thing_ ?
> 
> 
> Yes, when the method of expressing that policy is unnecessary complex,
> burdensome, and error prone for both clients and servers.

I already said I'm ok with the hardcoded encoding of the RSA-PSS params, with 
salt sizes assigned to hash sizes, and I started by saying that I'm ok with 
forbidding RSA-PSS params in EE certificate SPKI, that's not 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario  wrote:

> if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> vulnerable to attacks like the Bleichenbacher, if it is not usable with
> PKCS#1
> v1.5 it's not vulnerable in practice to such attacks
>

A certificate does not produce signatures - a key does.
A certificate carries signatures, but only relevant to verifiers.

Your reference to Bleichenbacher again makes it unclear if you're
expressing a concern about the protection of the private key or the quality
of the signatures, or whether you're conflating with ciphersuite
negotiation and encryption.


> > It does not do prevent such a signature from being created - that's what
> I
> > mean.
>
> now you're being silly
>
> the Mozilla policy doesn't prohibit the CA from making a service that will
> perform RSA private key operation on arbitrary strings either but we would
> still revoke trust from CA that would do such a thing, because just the
> fact
> that such a service _could_ have been used maliciously (to sign arbitrary
> certificates) is enough to distrust it!
>

No, such CAs do exist, and we haven't revoked such trust. Your statement is
empirically false.

That's why I'm trying to be explicit in the policy here - that the policy
is about the keys, not the certificates.


> I don't think that it's the act of making the signature that weakens the
> key
>

Great, then we don't need to restrict keys.


> If I generate a certificate has RSA-PSS SPKI I won't be able to use it for
> PKCS#1 v1.5 signatures - no widely deployed server will use it like that
> and
> no widely deployed client will accept such use. So a chance that a key
> will be
> abused like that and will remain abused like that is negligible.
>
> and that's the whole point - defence in depth - to make it another hurdle
> to
> jump through if you want to do something stupid
>

That's an argument often made for unnecessary complexity - or more aptly,
the benefits of such defense in depth needs to be weighed against how that
cost is distributed. In the case of RSA-PSS, because of the inanity of RFC
4055, that cost is distributed unevenly - it places the burden of such
complexity upon the clients, which have repeatedly lead to exploits (and
again, NSS has itself been vulnerable to this several times, or deftly
avoided it due to Brian Smith's keen rejection of unnecessary complexity).

It is a joint we don't need, and whose oiling will be needless toil.

It also adds complexity to the CA ecosystem, for CAs who are unfortunately
incapable of complying with the RFCs unless their hands are held and they
are carefully guided down the happy path. To the extent those CAs should
not be trusted is easy to say, but as shown time and time again, it's hard
to express "You must be this competent to ride" in an objective policy, and
even harder to address the situation where the CA is trusted and then let's
all the competent staff go.


>
> > I understand - but I'm saying that what we're discussing fundamentally
> > relates to the key.
> >
> > If a CA was technically constrained to .com, said they would never issue
> > for something not .com, but then issued for .org, it's absolutely grounds
> > for concern.
> > If it doesn't matter whether a CA issues for .com or .org, and they
> simply
> > choose to only issue for .com, then it doesn't make sense to require
> > clients to support the CA's expression of intent if doing so introduces
> > security risk to clients (and it does) and complexity risk.
>
> so where's the bug that removes support for that in Firefox? Will we get
> it in
> before the next ESR? /s
>

You've again misunderstood the argument. But I'm not sure that there's much
value in continuing - I've attempted to get you to either outline the value
proposition or to outline the risks. We've danced around on semantic games,
but we've identified that there is no risk in comingling these hash
algorithms, that the only risk in being strict relates to a single software
product with an unknown (but understandably miniscule, by virtue of no bugs
being filed) number of extant certificates, while we have a profound
opportunity to do the Right Thing based on lessons repeatedly learned.

you're arguing that machine readable CA policy is a _bad thing_ ?
>

Yes, when the method of expressing that policy is unnecessary complex,
burdensome, and error prone for both clients and servers.

RFC 4055 is a bad RFC. It is a host of unnecessary joints and unnecessary
complexity that does not, in practice, add any modicum of 'future
compatibility' as it tried to do, does not in practice reduce any risks (as
it tried to do), and does not provide any tangible value over a sane
expression of that via policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Wednesday, 29 November 2017 21:59:39 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario  wrote:
> > > So are you stating you do not believe cross-algorithm attacks are
> > 
> > relevant?
> > 
> > No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1
> > v1.5
> > are likely.
> > 
> > I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be
> > leveraged against both PKCS#1 v1.5 and RSA-PSS
> 
> I'm really not sure how to parse your response. I'm not sure if your "No"
> is your answer - as in you don't believe they're relevant - or "No" as you
> disagreeing with my framing of the question and that "Yes", you do believe
> they're relevant, despite them not being likely.
> 
> I'm further not sure how to parse your remark about "users of PKCS#1 v1.5"
> - as to whether you mean the signers or the verifiers.

if the certificate is usable with PKCS#1 v1.5 signatures, it makes it 
vulnerable to attacks like the Bleichenbacher, if it is not usable with PKCS#1 
v1.5 it's not vulnerable in practice to such attacks
 
> > > Sure. But why does that intention - which cannot be technically enforced
> > 
> > RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be
> > technically
> > enforced"?
> 
> It does not do prevent such a signature from being created - that's what I
> mean.

now you're being silly

the Mozilla policy doesn't prohibit the CA from making a service that will 
perform RSA private key operation on arbitrary strings either but we would 
still revoke trust from CA that would do such a thing, because just the fact 
that such a service _could_ have been used maliciously (to sign arbitrary 
certificates) is enough to distrust it!

> If it doesn't prevent such a signature, and the act of signing weakens the
> key itself, then such a constraint is pointless.
> If it simply indicates to a client "Don't accept this signature", but the
> act of signing weakens the key still, then such a constraint is pointless.
> If it does not weaken the key, then indicating to the client such a
> constraint is pointless, because any client that encounters such a
> signature has proof that the CA has failed to abide by the policy of their
> key - and if so, everything used with that key should be rightfully called
> into question, and no 'damage mitigation' has been achieved.

I don't think that it's the act of making the signature that weakens the key

If I generate a certificate has RSA-PSS SPKI I won't be able to use it for 
PKCS#1 v1.5 signatures - no widely deployed server will use it like that and 
no widely deployed client will accept such use. So a chance that a key will be 
abused like that and will remain abused like that is negligible.

and that's the whole point - defence in depth - to make it another hurdle to 
jump through if you want to do something stupid

> > > and is itself related to the usage of the key, not the trust in the
> > > signatures - need to be expressed in the certificate?
> > 
> > If the certificates has SPKI with RSA-PSS id, that means exactly that -
> > never
> > trust PKCS#1 v1.5 signatures made with this key.
> 
> Yes. And expressing that is pointless (see above).
>
> > > I disagree. I don't believe there's value in the expression of that from
> > > the CA within the certificate, for the reasons I previously mentioned -
> > > that intention can be subverted if the CA is willing to use SHA-1 or
> > > SHA-256 when they declared they will not, or if the CA is not willing,
> > 
> > then
> > 
> > > it's introducing unnecessary complexity into the client ecosystem for
> > > limited benefits.
> > 
> > If the RSA-PSS parameters in SPKI say SHA-256, SHA-1 signature made with
> > such
> > certificates never was and never will be valid. So creating SHA-1
> > signatures
> > is useless from point of view of legitimate CA.
> > 
> > It's like having technically constrained CA limited to .com domain and
> > issuing
> > certificate for .org domain - no valid PKIX implementation will trust
> > them.
> 
> I understand - but I'm saying that what we're discussing fundamentally
> relates to the key.
> 
> If a CA was technically constrained to .com, said they would never issue
> for something not .com, but then issued for .org, it's absolutely grounds
> for concern.
> If it doesn't matter whether a CA issues for .com or .org, and they simply
> choose to only issue for .com, then it doesn't make sense to require
> clients to support the CA's expression of intent if doing so introduces
> security risk to clients (and it does) and complexity risk.

so where's the bug that removes support for that in Firefox? Will we get it in 
before the next ESR? /s

> > > The extent of which this provides value is to allow a CA who, bearing a
> > > certificate whose public key is constrained to SHA-384, and upon being
> > > presented a SHA-256 certificate signed by the associated private key, to
> > > claim "That's not misissuance, because I said 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario  wrote:

> > The extent of the argument for flexibility, so far, has been OpenSSL's
> > behaviour to produce RSA-PSS signatures with a maximal salt length. These
> > same clients are also incapable of parsing RSA-PSS SPKIs (that only came
> > recently, AFAICT).
>
> yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures,
> and my understanding is that we want the same kind of limitations for
> signatures and for SPKI - if only to limit the confusion
>

Correct, the behaviour of OpenSSL is to unfortunately take maximal
advantage of the unnecessary complexity of RFC 4055.

I do not feel that it is in the best interest of users or security to
interoperate with that decision.


> > This probability of encountering such signatures within
> > the Web PKI itself is substantially lower, due to the many requirements
> > around protection of keys and the ease (or more aptly, difficulty) in
> > integrating such libraries with such systems - but even still, can be
> > configured by the client (nominally, the value of -1 indicates saltLen ==
> > len(hash), while -2 indicates the maximal encoding)
>
> Web PKI, now - yes
> But the problem is that Microsoft CAs (for Active Directory) default to
> RSA-
> PSS signatures, which means that Firefox cannot be deployed on such
> internal
> networks.
> This does not help Firefox market share.
>

Let's be precise: My proposal does not change the status quo. It does not
improve the situation as deployed, I readily admit, but it does not make
the entire ecosystem worse because of it.

Further, let's not conflate Microsoft CA generated certificates - which is
what you're noting as the internal networks - with OpenSSL generated
certificates - which have no such data as to the extent of the problem.

Today's status quo: If you have deployed RSA-PSS certificates on your
network, browsers such as Chrome or Firefox, and systems such as macOS or
Android, do not accept such certificates. You need to replace such
certificates.
Tomorrow's status quo: If you have deployed RSA-PSS certificates on your
network, and they do not reflect a sensible security configuration,
browsers such as Chrome or Firefox, and systems such as macOS or Android,
do not accept such certificates. You'd need to replace such certificates -
but you would be able to do so with 'sensible' RSA-PSS configuration.


> and I'm not saying that it is not possible to create signatures with
> correct
> salt lengths with old OpenSSL - but it is not the default, so any kind of
> certificates that were created previously will likely use the default.
> That in
> turn means that it would require reprovisioning all certificates like that,
> not a task that is easy at scale, welcome or with any benefit from the PoV
> of
> users.
>

Again, I think this is an extremely poor argument for introducing global
complexity into the ecosystem, and known-dangerous anti-patterns into
libraries such as NSS.

That is, when I weigh the risk of a limited set of Enterprise users (which
we know is limited, given the above constraints and the lack of prevalence
of OpenSSL in the CA space), I do not feel that it is reasonable or
responsible to suggest that we must accept undue complexity because they
crapped the proverbial bed first by shipping a non-sensical configuration.


> > So are you stating you do not believe cross-algorithm attacks are
> relevant?
>
> No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1
> v1.5
> are likely.
>
> I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be
> leveraged against both PKCS#1 v1.5 and RSA-PSS
>

I'm really not sure how to parse your response. I'm not sure if your "No"
is your answer - as in you don't believe they're relevant - or "No" as you
disagreeing with my framing of the question and that "Yes", you do believe
they're relevant, despite them not being likely.

I'm further not sure how to parse your remark about "users of PKCS#1 v1.5"
- as to whether you mean the signers or the verifiers.


> > Sure. But why does that intention - which cannot be technically enforced
>
> RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be
> technically
> enforced"?
>

It does not do prevent such a signature from being created - that's what I
mean.

If it doesn't prevent such a signature, and the act of signing weakens the
key itself, then such a constraint is pointless.
If it simply indicates to a client "Don't accept this signature", but the
act of signing weakens the key still, then such a constraint is pointless.
If it does not weaken the key, then indicating to the client such a
constraint is pointless, because any client that encounters such a
signature has proof that the CA has failed to abide by the policy of their
key - and if so, everything used with that key should be rightfully called
into question, and no 'damage mitigation' has been achieved.


> > and is itself related to the 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
> 
> dev-security-policy@lists.mozilla.org> wrote:
> > Because I do not consider making the salt length rigid (one value allowed
> > for
> > every hash) to be of any value. If it is not rigid, it would be silly to
> > provide a correct encoding for every single possible valid encoding.
> 
> I do not consider making the salt length flexible to be of any value.
> Further, I point to the past issues with respect to flexibility - and to
> the many CVEs across a wide spectrum of clients, including NSS, with
> respect to decoding signature parameters, that such flexibility will be
> actively detrimental both to the implementation within Mozilla products and
> to the implementation within the broader Web PKI community.
>
> The extent of the argument for flexibility, so far, has been OpenSSL's
> behaviour to produce RSA-PSS signatures with a maximal salt length. These
> same clients are also incapable of parsing RSA-PSS SPKIs (that only came
> recently, AFAICT).

yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures, 
and my understanding is that we want the same kind of limitations for 
signatures and for SPKI - if only to limit the confusion

> This probability of encountering such signatures within
> the Web PKI itself is substantially lower, due to the many requirements
> around protection of keys and the ease (or more aptly, difficulty) in
> integrating such libraries with such systems - but even still, can be
> configured by the client (nominally, the value of -1 indicates saltLen ==
> len(hash), while -2 indicates the maximal encoding)

Web PKI, now - yes
But the problem is that Microsoft CAs (for Active Directory) default to RSA-
PSS signatures, which means that Firefox cannot be deployed on such internal 
networks.
This does not help Firefox market share.

and I'm not saying that it is not possible to create signatures with correct 
salt lengths with old OpenSSL - but it is not the default, so any kind of 
certificates that were created previously will likely use the default. That in 
turn means that it would require reprovisioning all certificates like that, 
not a task that is easy at scale, welcome or with any benefit from the PoV of 
users.
 
> > > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5
> > > and
> > > RSA-PSS signatures with the same key?
> > 
> > depends on the circumstances
> > 
> > 
> > I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5.
> > 
> > So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase
> > the
> > security of the system, but it doesn't decrease it either.
> 
> So are you stating you do not believe cross-algorithm attacks are relevant?

No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1 v1.5 
are likely.

I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be 
leveraged against both PKCS#1 v1.5 and RSA-PSS

> If it is, then it either theorhetically or practically weakens the security
> of the system.
> If it's not, then there's no need to afford the flexibility.
> 
> > if one does use rsa-pss only (or has such intention), then use of pkcs#1
> > v1.5
> > with such key would lower the security of the system.
> 
> Sure. But why does that intention - which cannot be technically enforced

RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be technically 
enforced"?

> and is itself related to the usage of the key, not the trust in the
> signatures - need to be expressed in the certificate?

If the certificates has SPKI with RSA-PSS id, that means exactly that - never 
trust PKCS#1 v1.5 signatures made with this key.

> I propose it doesn't
> - which is where the need to express that intention introduces significant,
> and unnecessary, complexity.

I really don't think we're on the same page here...
 
> > > 2) Do you believe it represents a security risk to mix hash algorithms
> > > within RSA-PSS signatures with the same key?
> > 
> > like I said before, the problem is not that the key can be used with
> > sha-384
> > and sha-512 at the same time - that I don't see as a risk, at least not
> > now
> 
> Again, cross-algorithm attacks.
> 
> > Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I
> > don't
> > think this should be allowed.
> 
> But that's not a risk to the key - that's a risk being proposed in which
> the client accepts SHA-1.
> 
> > Now, one may expect that SHA-256 will go the way of SHA-1, then having
> > ability
> > say "I won't use SHA-256", even when it is allowed by both policy and code
> > is
> > a value-add.
> 
> I disagree. I don't believe there's value in the expression of that from
> the CA within the certificate, for the reasons I previously mentioned -
> that intention can be subverted if the CA is willing to use SHA-1 or
> SHA-256 when they declared they will not, or if the 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> > The fact that this new NSS implementation does not properly validate the
> > well-formedness of these signatures is somewhat in conflict with your
> > statement:
> > ""it turned out to be a problem because a). it was the 90's, b).
> everybody
> > did
> > it like that, c). everybody assumed (not test) that security software was
> > written, well, securely..."""
> >
> > So are we to conclude that this is still a problem because everybody
> > assumes, but does not test, that NSS is written, well, securely?
>
> I definitely do not assume that, I just do not consider the issues we
> suspect
> to be there and issues we know about (and plan to fix in near future) to be
> blockers for shipping it, because RSA-PSS is in its infancy on the public
> 'net.
>
> I do think that they need to be resolved before TLS 1.3 is in its final
> state
> though.
>

My hope is that we'd prioritize bugs that affect security (SHA-1 in MGF1)
and stability (RSA-PSS laxness), especially if they're identified prior
to/within days of shipping.


>
> > This is similarly an example of a policy 'requiring' X, but this is not
> > required through code or, with your proposed policy, required through
> > policy.
>
> requirement that the certificates be DER encoded is part of X.509 standard,
> it's implicit
>

And yet it's so frequently been messed up that an entire section of
mozilla::pkix workarounds to address this.

The goal of policy is to learn from the mistakes of the past, to better
inform the future.

the policy doesn't state that the byte is 8 bits long or that 'a' is encoded
> using big endian octet of decimal value 97 either...
>

You're correct - but if CAs were frequently messing this up, or
requirements within similar sections, then I would just as ardently
advocate we include such in the policy.


> Because I do not consider making the salt length rigid (one value allowed
> for
> every hash) to be of any value. If it is not rigid, it would be silly to
> provide a correct encoding for every single possible valid encoding.
>

I do not consider making the salt length flexible to be of any value.
Further, I point to the past issues with respect to flexibility - and to
the many CVEs across a wide spectrum of clients, including NSS, with
respect to decoding signature parameters, that such flexibility will be
actively detrimental both to the implementation within Mozilla products and
to the implementation within the broader Web PKI community.

The extent of the argument for flexibility, so far, has been OpenSSL's
behaviour to produce RSA-PSS signatures with a maximal salt length. These
same clients are also incapable of parsing RSA-PSS SPKIs (that only came
recently, AFAICT). This probability of encountering such signatures within
the Web PKI itself is substantially lower, due to the many requirements
around protection of keys and the ease (or more aptly, difficulty) in
integrating such libraries with such systems - but even still, can be
configured by the client (nominally, the value of -1 indicates saltLen ==
len(hash), while -2 indicates the maximal encoding)


> > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and
> > RSA-PSS signatures with the same key?
>
> depends on the circumstances


> I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5.
>
> So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase
> the
> security of the system, but it doesn't decrease it either.
>

So are you stating you do not believe cross-algorithm attacks are relevant?
If it is, then it either theorhetically or practically weakens the security
of the system.
If it's not, then there's no need to afford the flexibility.


> if one does use rsa-pss only (or has such intention), then use of pkcs#1
> v1.5
> with such key would lower the security of the system.
>

Sure. But why does that intention - which cannot be technically enforced
and is itself related to the usage of the key, not the trust in the
signatures - need to be expressed in the certificate? I propose it doesn't
- which is where the need to express that intention introduces significant,
and unnecessary, complexity.


> > 2) Do you believe it represents a security risk to mix hash algorithms
> > within RSA-PSS signatures with the same key?
>
> like I said before, the problem is not that the key can be used with
> sha-384
> and sha-512 at the same time - that I don't see as a risk, at least not now
>

Again, cross-algorithm attacks.


> Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I
> don't
> think this should be allowed.
>

But that's not a risk to the key - that's a risk being proposed in which
the client accepts SHA-1.


> Now, one may expect that SHA-256 will go the way of SHA-1, then having
> ability
> say "I won't use SHA-256", even when it is allowed by both policy and code
> is
> a value-add.

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario  wrote:

> On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote:
> > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario  wrote:
> > > > So no, we should not assume well-meaning actors, and we should be
> > >
> > > explicit
> > >
> > > > about what the "intention" of the RFCs is, and whether they actually
> > > > achieve that.
> > >
> > > but we should achieve that by saying "do this", not "don't do this",
> > > enumerating badness doesn't work - ask firewall people if you don't
> > > believe
> > > me.
> > >
> > > Or did we add to policy that keys revoked because they may haven been
> > > compromised (heartbleed) can't be reused? Ever? Even by a different CA?
> >
> > You've completely misframed my proposal. I'm enumerating a specific
> > whitelist of what is permitted. Every other option, unless otherwise
> > permitted, is restricted. I'm even going to the level of proposing a
> > byte-for-byte comparison function such that there's not even a prosaic
> > whitelist - it's such that the policy is black and white and transcends
> > language barriers by expressing directly in the technology.
> >
> > You're enumerating a blacklist - saying that all of the flexibility of
> 4055
> > is permitted (except for these specific combinations), but propose to
> > enforce neither of those through code or policy.
>
> where did I do that?
>
> it's the second time you're putting words in my mouth, I really do not
> appreciate that.


Hubert, while it's certainly not my intent to misrepresent your position, I
think it's worth remarking that in your reply immediately prior, you
highlighted that "but we should achieve that by saying 'Do this', not
"don't do this", enumerating badness doesn't work". This was similarly
putting words in my mouth - but, as I highlighted, it was a
misunderstanding, and tried to clarify.

To your question, the following statements were made earlier in the thread:
"" - issuing certificates may include RSA-PSS parameters in the Public Key
Info
Algorithm Identifier, it's recommended that the hash selected matches the
security of the key
 - signature hash and the hash used for mask generation must be the same
both
in public key parameters in certificate and in signature parameters
 - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64
bytes for SHA-512""

And yet, in a follow-up, you replied

""that would require hardcoding salt lengths, given their meaning in
subjectPublicKeyInfo, I wouldn't be too happy about it

looking at OpenSSL behaviour, it would likely render all past signatures
invalid and making signatures with already released software unnecessarily
complex (OpenSSL defaults to as large salt as possible)"

I hope you can see how these two are in conflict - on the one hand, you
suggest the policy should require X, but then suggest the implementation
should not enforce X, because it would invalidate OpenSSL signatures.

Similarly, with respect to the differences in our approaches, the framing
you put forward is:
""for X.509 only DER is allowed, if the tags or values are not encoded with
minimal number of bytes necessary, or with indeterminate length, it's not
DER
it's BER and that's strictly forbidden""

However, despite it being forbidden, the code contributed to NSS (and
mentioned in your original post -
https://bugzilla.mozilla.org/show_bug.cgi?id=1400844) does not actually
enforce this.

The fact that this new NSS implementation does not properly validate the
well-formedness of these signatures is somewhat in conflict with your
statement:
""it turned out to be a problem because a). it was the 90's, b). everybody
did
it like that, c). everybody assumed (not test) that security software was
written, well, securely..."""

So are we to conclude that this is still a problem because everybody
assumes, but does not test, that NSS is written, well, securely?

This is similarly an example of a policy 'requiring' X, but this is not
required through code or, with your proposed policy, required through
policy.

When I offered suggestions of how to avoid this, you seemingly rejected
them (when taking the message as a whole), with your suggestion being:
""or provide examples of specific encodings with explanations what can
change
and to what degree...""

Which is to afford the flexibility of 4055 by encoding a variety of
parameters - yet still in seeming direct conflict with the policy proposal
you yourself made.


These examples of internal inconsistencies are instead why I tried to focus
on first principles, and would like to revisit them. Framed differently:

1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and
RSA-PSS signatures with the same key?
2) Do you believe it represents a security risk to mix hash algorithms
within RSA-PSS signatures with the same key?

These questions are, perhaps, the crux of our disagreement. They should be
answered 'yes/no'. If they're yes, we 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote:
> On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario  wrote:
> > > So no, we should not assume well-meaning actors, and we should be
> > 
> > explicit
> > 
> > > about what the "intention" of the RFCs is, and whether they actually
> > > achieve that.
> > 
> > but we should achieve that by saying "do this", not "don't do this",
> > enumerating badness doesn't work - ask firewall people if you don't
> > believe
> > me.
> > 
> > Or did we add to policy that keys revoked because they may haven been
> > compromised (heartbleed) can't be reused? Ever? Even by a different CA?
> 
> You've completely misframed my proposal. I'm enumerating a specific
> whitelist of what is permitted. Every other option, unless otherwise
> permitted, is restricted. I'm even going to the level of proposing a
> byte-for-byte comparison function such that there's not even a prosaic
> whitelist - it's such that the policy is black and white and transcends
> language barriers by expressing directly in the technology.
> 
> You're enumerating a blacklist - saying that all of the flexibility of 4055
> is permitted (except for these specific combinations), but propose to
> enforce neither of those through code or policy. 

where did I do that?

it's the second time you're putting words in my mouth, I really do not 
appreciate that.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario  wrote:
>
> > First, I absolutely disagree with your assumption - we need to assume
> > hostility, and design our code and policies to be robust against that. I
> > should hope that was uncontroversial, but it doesn't seem to be.
>
> my point was that there are some actions of the other party we interact
> with
> that must be taken on faith, like that the server_random is actually
> random,
> or the server private part of the key share stays secret, or a myriad other
> things that we cannot verify legitimacy or correctness of. Without assuming
> that good faith it's impossible to communicate. Same for generated keys
> provided to CAs.
>

With respect to CA behaviours, I still disagree.

I agree we must rely on server random to be random. Similarly, we 'rely' on
CA's random serials to be random - but we also make it clear that it's a
policy expectation.

In this same regard, if the intent is to limit a given key from being used
with multiple RSA-PSS hash algorithms, or from being used with RSA-PSS and
RSA-PKCS#1v1.5, then we should explicitly state that in policy. Implying
that (via the certificate limits) without requiring that is, as time has
repeatedly shown, a recipe for disaster, because it's completely
non-obvious as to why this might be (and, again, not supported by the
literature)

Alternatively, if it's not necessary to limit such usage, then we should
not be requiring parameters in the SPKI, because it's not necessary.
Further, for simplicitly and interoperability - and to prevent the
misguided belief it is necessary - then we should explicitly forbid
parameters.

There's no need to support both cases - we should MUST or MUST NOT, but
should not SHOULD.


> > Second, the only reason this is an issue was your suggestion (derived
> from
> > 4055, to be fair) about restricting the params<->signature interaction.
> The
> > flexibility afforded by 4055 in expressing the parameters, and then
> > subsequently constraining the validation rules, is not actually met by
> the
> > threat model.
>
> There was a threat model in RFC 4055?
>
> Is it so hard to imagine that a CA may want to ensure that the signatures
> it
> makes will never use weak hash? And even if it makes them, they won't be
> validated by a conforming implementation?
>

If the CA wishes to ensure that, then it doesn't need the certificate to
ensure that - as the certificate doesn't control how they use the key.
If the CA happens to do so anyways, the certificate doesn't prevent them
from being validated by a conforming implementation, because another
certificate may have been issued with the same subject name with a
different set of parameters.

That is, under an adversarial model, it makes no sense to hinge it on the
certificate's encoding of the parameters. If you're trying to prevent CA
misuse of the private key, then be explicit about the policy being that the
CA should not misuse said private key, and any use of the private key is a
violation. If any signatures are thus created, the fact that the CA has
generated such a signature is the issue, not whether or not clients accept
it - because if the CA can't protect their private key adequately (from
insider misconfiguration or external attack), then all bets are off.

This is about having a rational threat model for the required policy. What
you propose is not rational under either external CA adversarial threats or
internal misconfiguration.


>
> > That is, if it's dangerous to mix the hash algorithms in PSS signatures
> > (and I'm not aware of literature suggesting this is necessary, versus
> being
> > speculative concern), then we should explicitly prohibit it via policy.
> > Requiring the parameters in the certificates does not, in any way,
> mitigate
> > this risk - and its presumptive inclusion in 4055 was to constrain how
> > signature-creating-software behaved, rather than how
> > signature-accepting-clients should behave.
> >
> > Alternatively, if mixing the hash algorithms is not fundamentally unsafe
> in
> > the case of RSA-PSS, then it's unnecessary and overly complicating things
> > to include the params in the SPKI of the CA's certificate. The fact that
> > 'rsaEncryption' needs to be accepted as valid for the issuance of RSA-PSS
> > signatures already implies it's acceptable, and so the whole SHOULD
> > construct is imposing on the ecosystem an unsupported policy.
>
> it would be nice if the world was black and white, it would make any kind
> of
> nuanced work so much easier...
>
> Those are all shades of grey, for some uses allowing possibility of cross-
> protocol attacks is not important, for other, not so much.
>

We're talking about the Web PKI. It really is black or white here - there's
no need to introduce flexibility that can be misused (intentionally or not)
by CAs and add complexity to clients.

Either it's safe to do - and we should both explicitly allow it and prevent
unnecessary complexity that 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Monday, 27 November 2017 20:31:53 CET Ryan Sleevi wrote:
> On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario  wrote:
> > > On the realm of CA policy, we're discussing two matters:
> > > 1) What should the certificates a CA issue be encoded as
> > > 2) How should the CA protect and use its private key.
> > > 
> > > While it may not be immediately obvious, both your proposal and 4055
> > > attempt to treat #2 by #1, but they're actually separate issues. This
> > > mistake is being made by treating PSS-params on CA certificates as an
> > > important signal for reducing cross-protocol attacks, but it doesn't.
> > 
> > This
> > 
> > > is because the same public/private key pair can be associated with
> > 
> > multiple
> > 
> > > certificates, with multiple params encodings (and potentially the same
> > > subject), and clients that enforced the silly 4055 restrictions would
> > > happily accept these.
> > 
> > the CA can also use sexy primes as the private key, making the private key
> > easy to derive from the modulus... We can't list every possible way you
> > can
> > overturn the intention of the RFCs.
> > 
> > we need to assume well-meaning actors, at least to a certain degree
> 
> First, I absolutely disagree with your assumption - we need to assume
> hostility, and design our code and policies to be robust against that. I
> should hope that was uncontroversial, but it doesn't seem to be.

my point was that there are some actions of the other party we interact with 
that must be taken on faith, like that the server_random is actually random, 
or the server private part of the key share stays secret, or a myriad other 
things that we cannot verify legitimacy or correctness of. Without assuming 
that good faith it's impossible to communicate. Same for generated keys 
provided to CAs.

> Second, the only reason this is an issue was your suggestion (derived from
> 4055, to be fair) about restricting the params<->signature interaction. The
> flexibility afforded by 4055 in expressing the parameters, and then
> subsequently constraining the validation rules, is not actually met by the
> threat model.

There was a threat model in RFC 4055?

Is it so hard to imagine that a CA may want to ensure that the signatures it 
makes will never use weak hash? And even if it makes them, they won't be 
validated by a conforming implementation?

> That is, if it's dangerous to mix the hash algorithms in PSS signatures
> (and I'm not aware of literature suggesting this is necessary, versus being
> speculative concern), then we should explicitly prohibit it via policy.
> Requiring the parameters in the certificates does not, in any way, mitigate
> this risk - and its presumptive inclusion in 4055 was to constrain how
> signature-creating-software behaved, rather than how
> signature-accepting-clients should behave.
> 
> Alternatively, if mixing the hash algorithms is not fundamentally unsafe in
> the case of RSA-PSS, then it's unnecessary and overly complicating things
> to include the params in the SPKI of the CA's certificate. The fact that
> 'rsaEncryption' needs to be accepted as valid for the issuance of RSA-PSS
> signatures already implies it's acceptable, and so the whole SHOULD
> construct is imposing on the ecosystem an unsupported policy.

it would be nice if the world was black and white, it would make any kind of 
nuanced work so much easier...

Those are all shades of grey, for some uses allowing possibility of cross-
protocol attacks is not important, for other, not so much.
 
> So no, we should not assume well-meaning actors, and we should be explicit
> about what the "intention" of the RFCs is, and whether they actually
> achieve that.

but we should achieve that by saying "do this", not "don't do this", 
enumerating badness doesn't work - ask firewall people if you don't believe 
me.

Or did we add to policy that keys revoked because they may haven been 
compromised (heartbleed) can't be reused? Ever? Even by a different CA?
 
> > > So I think it's useful to instead work from a clean set of principles,
> > 
> > and
> > 
> > > try to express them:
> > > 
> > > 1) The assumption, although the literature doesn't suggest it's
> > 
> > necessary,
> > 
> > > and it's not presently enforced in the existing WebPKI, is that the hash
> > > algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single
> > > hash algorithm for the private key.
> > > 
> > >   a) One way to achieve this is via policy - to state that all
> > >   signatures
> > > 
> > > produced by a CA with a given private key must use the same set of
> > > parameters
> > > 
> > >   b) Another way is to try and achieve this via encoding (as 4055
> > > 
> > > attempts), but as I noted, this is entirely toothless (and somewhat
> > > incorrectly presumes X.500's DIT as the mechanism of enforcing policy a)
> > 
> > just because the mechanism can be abused, doesn't make it useless for
> > people
> > that want to use it correctly. It 

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario  wrote:
>
> > On the realm of CA policy, we're discussing two matters:
> > 1) What should the certificates a CA issue be encoded as
> > 2) How should the CA protect and use its private key.
> >
> > While it may not be immediately obvious, both your proposal and 4055
> > attempt to treat #2 by #1, but they're actually separate issues. This
> > mistake is being made by treating PSS-params on CA certificates as an
> > important signal for reducing cross-protocol attacks, but it doesn't.
> This
> > is because the same public/private key pair can be associated with
> multiple
> > certificates, with multiple params encodings (and potentially the same
> > subject), and clients that enforced the silly 4055 restrictions would
> > happily accept these.
>
> the CA can also use sexy primes as the private key, making the private key
> easy to derive from the modulus... We can't list every possible way you can
> overturn the intention of the RFCs.
>
> we need to assume well-meaning actors, at least to a certain degree
>

First, I absolutely disagree with your assumption - we need to assume
hostility, and design our code and policies to be robust against that. I
should hope that was uncontroversial, but it doesn't seem to be.

Second, the only reason this is an issue was your suggestion (derived from
4055, to be fair) about restricting the params<->signature interaction. The
flexibility afforded by 4055 in expressing the parameters, and then
subsequently constraining the validation rules, is not actually met by the
threat model.

That is, if it's dangerous to mix the hash algorithms in PSS signatures
(and I'm not aware of literature suggesting this is necessary, versus being
speculative concern), then we should explicitly prohibit it via policy.
Requiring the parameters in the certificates does not, in any way, mitigate
this risk - and its presumptive inclusion in 4055 was to constrain how
signature-creating-software behaved, rather than how
signature-accepting-clients should behave.

Alternatively, if mixing the hash algorithms is not fundamentally unsafe in
the case of RSA-PSS, then it's unnecessary and overly complicating things
to include the params in the SPKI of the CA's certificate. The fact that
'rsaEncryption' needs to be accepted as valid for the issuance of RSA-PSS
signatures already implies it's acceptable, and so the whole SHOULD
construct is imposing on the ecosystem an unsupported policy.

So no, we should not assume well-meaning actors, and we should be explicit
about what the "intention" of the RFCs is, and whether they actually
achieve that.


> > So I think it's useful to instead work from a clean set of principles,
> and
> > try to express them:
> >
> > 1) The assumption, although the literature doesn't suggest it's
> necessary,
> > and it's not presently enforced in the existing WebPKI, is that the hash
> > algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single
> > hash algorithm for the private key.
> >   a) One way to achieve this is via policy - to state that all signatures
> > produced by a CA with a given private key must use the same set of
> > parameters
> >   b) Another way is to try and achieve this via encoding (as 4055
> > attempts), but as I noted, this is entirely toothless (and somewhat
> > incorrectly presumes X.500's DIT as the mechanism of enforcing policy a)
>
> just because the mechanism can be abused, doesn't make it useless for
> people
> that want to use it correctly. It still will protect people that use it
> correctly.
>

B is absolutely useless as a security mechanism against threats, and is
instead a way of signature-producing software to bake in an API contract in
to an RFC. We shouldn't encourage that, nor should the ecosystem have to
bear that complexity.

If it's not a security mechanism, then it's unnecessary.


> > 2) We want to ensure there is a bounded, unambiguous set of accepted
> > encodings for what a CA directly controls
> >   a) The "signature" fields of TBSCertificate (Certs) and TBSCertList
> > (CRL). OCSP does not duplicate the signature algorithm in the
> ResponseData
> > of a BasicOCSPResponse, so it's not necessary
>
> that's already a MUST requirement, isn't it?
>

It's not what NSS has implemented, but shipping, as captured on the bug.

And this matters, because permissive bugs in client implementation
absolutely leads to widespread ossification of server bugs, and why I
specifically requested that the NSS developers unship RSA-PSS support until
they can correctly and properly implement it.

We already saw this with RSA-PKCS#1v1.5 - it shouldn't be repeated again.


>
> >   b) The "subjectPublicKeyInfo" of a TBSCertificate
>
> that's the biggest issue
>
> > 3) We want to make sure to set expectations around what is supported in
> the
> > signatureAlgorithm fields of a Certificate (certs), CertificateList
> (CRLs),
> > and BasicOCSPResponse (OCSP).
> >   - Notably, these 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Monday, 27 November 2017 17:28:02 CET Ryan Sleevi wrote:
> On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy <
> 
> dev-security-policy@lists.mozilla.org> wrote:
> > In response to comment made by Gervase Markham[1], pointing out that
> > Mozilla
> > doesn't have an official RSA-PSS usage policy.
> > 
> > This is the thread to discuss it and make a proposal that could be later
> > included in Mozilla Root Store Policy[2]
> > 
> > I'm proposing the following additions to the Policy (leaving out exactly
> > which
> > sections this needs to be added, as that's better left for the end of
> > 
> > discussion):
> >  - RSA keys can be used to make RSASSA-PKCS#1 v1.5 or RSASSA-PSS
> > 
> > signatures on
> > issued certificates
> > 
> >  - certificates containing RSA parameters can be limited to perform
> > 
> > RSASSA-PSS
> > signatures only by specifying the X.509 Subject Public Key Info algorithm
> > identifier to RSA-PSS algorithm
> > 
> >  - end-entity certificates must not include RSA-PSS parameters in the
> > 
> > Public
> > Key Info Algorithm Identifier - that is, they must not be limited to
> > creating
> > signatures with only one specific hash algorithm
> > 
> >  - issuing certificates may include RSA-PSS parameters in the Public Key
> > 
> > Info
> > Algorithm Identifier, it's recommended that the hash selected matches the
> > security of the key
> > 
> >  - signature hash and the hash used for mask generation must be the same
> > 
> > both
> > in public key parameters in certificate and in signature parameters
> > 
> >  - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and
> > 
> > 64
> > bytes for SHA-512
> > 
> >  - SHA-1 and SHA-224 are not acceptable for use with RSA-PSS algorithm
> >  
> >  1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844#c15
> >  2 - https://www.mozilla.org/en-US/about/governance/policies/
> > 
> > security-group/
> > certs/policy/
> 
> Hubert,
> 
> Thanks for raising this issue in m.d.s.p.
> 
> I think it's helpful to break the discussion into two (or more) parts.
> 
> One part worth discussing is the CA policy - that is, what are CAs expected
> to do or not do, and what constitutes "misissuance". Another part worth
> discussing is client behaviour - what will NSS (and Mozilla) clients
> support and not support, despite it not being misissuance, so that there's
> a clear understanding about what's supported.

but the latter must be a superset of the former. And it also describes the 
part that NSS will explicitly support (and thus must test)

> The reason I make these distinction is that the relevant RFCs - 4055 and
> 5766 - are bad RFCs. While well-intentioned, they were written at the
> height of the obsession to 'parameterize all the things' to ensure 'future
> compatibility' - but the consequence of this is that they introduced a
> tremendous amount of complexity, while also mistaking risk mitigation for
> policy advice. Because these RFCs confuse and conflate these two issues,
> while also introducing significant area for mistakes, we need to be very
> careful and very precise.
> 
> On the realm of CA policy, we're discussing two matters:
> 1) What should the certificates a CA issue be encoded as
> 2) How should the CA protect and use its private key.
> 
> While it may not be immediately obvious, both your proposal and 4055
> attempt to treat #2 by #1, but they're actually separate issues. This
> mistake is being made by treating PSS-params on CA certificates as an
> important signal for reducing cross-protocol attacks, but it doesn't. This
> is because the same public/private key pair can be associated with multiple
> certificates, with multiple params encodings (and potentially the same
> subject), and clients that enforced the silly 4055 restrictions would
> happily accept these.

the CA can also use sexy primes as the private key, making the private key 
easy to derive from the modulus... We can't list every possible way you can 
overturn the intention of the RFCs.

we need to assume well-meaning actors, at least to a certain degree
 
> So I think it's useful to instead work from a clean set of principles, and
> try to express them:
> 
> 1) The assumption, although the literature doesn't suggest it's necessary,
> and it's not presently enforced in the existing WebPKI, is that the hash
> algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single
> hash algorithm for the private key.
>   a) One way to achieve this is via policy - to state that all signatures
> produced by a CA with a given private key must use the same set of
> parameters
>   b) Another way is to try and achieve this via encoding (as 4055
> attempts), but as I noted, this is entirely toothless (and somewhat
> incorrectly presumes X.500's DIT as the mechanism of enforcing policy a)

just because the mechanism can be abused, doesn't make it useless for people 
that want to use it correctly. It still will protect people that use it 
correctly.

Re: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In response to comment made by Gervase Markham[1], pointing out that
> Mozilla
> doesn't have an official RSA-PSS usage policy.
>
> This is the thread to discuss it and make a proposal that could be later
> included in Mozilla Root Store Policy[2]
>
> I'm proposing the following additions to the Policy (leaving out exactly
> which
> sections this needs to be added, as that's better left for the end of
> discussion):
>
>  - RSA keys can be used to make RSASSA-PKCS#1 v1.5 or RSASSA-PSS
> signatures on
> issued certificates
>  - certificates containing RSA parameters can be limited to perform
> RSASSA-PSS
> signatures only by specifying the X.509 Subject Public Key Info algorithm
> identifier to RSA-PSS algorithm
>  - end-entity certificates must not include RSA-PSS parameters in the
> Public
> Key Info Algorithm Identifier - that is, they must not be limited to
> creating
> signatures with only one specific hash algorithm
>  - issuing certificates may include RSA-PSS parameters in the Public Key
> Info
> Algorithm Identifier, it's recommended that the hash selected matches the
> security of the key
>  - signature hash and the hash used for mask generation must be the same
> both
> in public key parameters in certificate and in signature parameters
>  - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and
> 64
> bytes for SHA-512
>  - SHA-1 and SHA-224 are not acceptable for use with RSA-PSS algorithm
>
>  1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844#c15
>  2 - https://www.mozilla.org/en-US/about/governance/policies/
> security-group/
> certs/policy/


Hubert,

Thanks for raising this issue in m.d.s.p.

I think it's helpful to break the discussion into two (or more) parts.

One part worth discussing is the CA policy - that is, what are CAs expected
to do or not do, and what constitutes "misissuance". Another part worth
discussing is client behaviour - what will NSS (and Mozilla) clients
support and not support, despite it not being misissuance, so that there's
a clear understanding about what's supported.

The reason I make these distinction is that the relevant RFCs - 4055 and
5766 - are bad RFCs. While well-intentioned, they were written at the
height of the obsession to 'parameterize all the things' to ensure 'future
compatibility' - but the consequence of this is that they introduced a
tremendous amount of complexity, while also mistaking risk mitigation for
policy advice. Because these RFCs confuse and conflate these two issues,
while also introducing significant area for mistakes, we need to be very
careful and very precise.

On the realm of CA policy, we're discussing two matters:
1) What should the certificates a CA issue be encoded as
2) How should the CA protect and use its private key.

While it may not be immediately obvious, both your proposal and 4055
attempt to treat #2 by #1, but they're actually separate issues. This
mistake is being made by treating PSS-params on CA certificates as an
important signal for reducing cross-protocol attacks, but it doesn't. This
is because the same public/private key pair can be associated with multiple
certificates, with multiple params encodings (and potentially the same
subject), and clients that enforced the silly 4055 restrictions would
happily accept these.

So I think it's useful to instead work from a clean set of principles, and
try to express them:

1) The assumption, although the literature doesn't suggest it's necessary,
and it's not presently enforced in the existing WebPKI, is that the hash
algorithm for both PKCS#1 v1.5 and RSA-PSS should be limited to a single
hash algorithm for the private key.
  a) One way to achieve this is via policy - to state that all signatures
produced by a CA with a given private key must use the same set of
parameters
  b) Another way is to try and achieve this via encoding (as 4055
attempts), but as I noted, this is entirely toothless (and somewhat
incorrectly presumes X.500's DIT as the mechanism of enforcing policy a)

2) We want to ensure there is a bounded, unambiguous set of accepted
encodings for what a CA directly controls
  a) The "signature" fields of TBSCertificate (Certs) and TBSCertList
(CRL). OCSP does not duplicate the signature algorithm in the ResponseData
of a BasicOCSPResponse, so it's not necessary
  b) The "subjectPublicKeyInfo" of a TBSCertificate

3) We want to make sure to set expectations around what is supported in the
signatureAlgorithm fields of a Certificate (certs), CertificateList (CRLs),
and BasicOCSPResponse (OCSP).
  - Notably, these fields are mutable by attackers as they're part of the
'unsigned' portion of the certificate, so we must be careful here about the
flexibility

4) We want to define what the behaviour will be for NSS (and Mozilla)
clients if/when these constraints are violated
  - Notably, is the presence of something awry a