Re: [TLS] PSS and TLS 1.3

[Ilari Liusvaara]

On Mon, Feb 06, 2017 at 11:57:30AM -0500, Nikos Mavrogiannopoulos wrote:
> 
> 
> Isn't the whole purpose of moving to formally proved schemes, the fact that 
> there
> is a proof of security? This support by TLS 1.3 invalidates this proof, thus
> making any reason to have RSASSA-PSS moot, (unless of course we have a proof
> that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure).

As to why I said I consider it unlikely: You need to match up a lot of hash
output bits (easily over 1,000) with at most 512 bits of input in order to
effect a cross-protocol attack.

Matching up 1,000 hash output bits would be hard enough. That one has
only 512 bits of input makes it with overwhelming probability impossible.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Nikos Mavrogiannopoulos]

- Original Message -
> On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > The issue is that we cannot tell for sure. Any proof of security
> > assumes that the keys are restricted to a single scheme. So I think we
> > got into a trap where we intended to increase security, while in fact
> > reduced the protocol's security, by ending-up adding RSA-PSS in a way
> > that can share keys with PKCS#1 1.5. I think that we should treat RSA-
> > PSS as the mean to increase security rather than the end-goal.
> 
> Looking at the signature constructions, I would say it is _extremely_
> unlinkely that cross-protocol attacks are possible.

Isn't the whole purpose of moving to formally proved schemes, the fact that 
there
is a proof of security? This support by TLS 1.3 invalidates this proof, thus
making any reason to have RSASSA-PSS moot, (unless of course we have a proof
that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure).

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Ilari Liusvaara]

On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote:
> 
> The issue is that we cannot tell for sure. Any proof of security 
> assumes that the keys are restricted to a single scheme. So I think we
> got into a trap where we intended to increase security, while in fact
> reduced the protocol's security, by ending-up adding RSA-PSS in a way
> that can share keys with PKCS#1 1.5. I think that we should treat RSA-
> PSS as the mean to increase security rather than the end-goal.

Looking at the signature constructions, I would say it is _extremely_
unlinkely that cross-protocol attacks are possible.

And this is with extremely loose criteria and extremely loose attacker
resource budget.
 
> Even if the approach of separating keys would mean that RSA-PSS will
> not be deployed immediately, it will allow implementors to provide
> well-behaved clients that will refuse to mix marked as RSA-PSS keys
> with the legacy ones. On the current protocol description it is
> impossible for an implementor to do that. The reason is that if one
> does that, his software will not be functional, will fail to connect to
> several web servers, and thus will have to compromise (functionality
> always wins over security).
> 
> 
> > [2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
> > with RSA[3] and even then most ACME software can't handle those)..
> 
> TLS 1.3 requiring a different key type, will provide an incentive for
> them to update.

More like roadblock to upgrade to TLS 1.3.

Getting CA support for RSA-PSS keys would be SLOW to say the least.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Yoav Nir]

> On 6 Feb 2017, at 4:36, Martin Thomson  wrote:
> 
> On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos  wrote:
>> TLS 1.3 requiring a different key type, will provide an incentive for
>> them to update.
> 
> 
> I don't think that's how this works.  More likely, that would become a
> reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are
> used.

Right. The only reason anyone is currently using RSA rather than ECDSA is for 
compatibility with older clients. If those clients are so old that they don’t 
support ECDSA keys, they’re not likely to support RSA-PSS.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Peter Gutmann]

Nikos Mavrogiannopoulos  writes:

>TLS 1.3 requiring a different key type, will provide an incentive for them to
>update.

No, it'll be an incentive for them to ignore the requirement, or work around
it.  The S/MIME WG looked at this years ago when they considered tying AES use
to RSA-PSS/OAEP, the plan being to use the adoption of AES to try and force
adoption of RSA-not-PKCS1.5.  It was canned pretty quickly: No implementation
support, no CA support, no HSM/smart card support, and you'd have to somehow
figure out how to set up keys so they couldn't be used with PKCS # 1.5 any
more in an environment where everything did PKCS #1.5.

(I realise this was a long time ago, so now it'll be more like little
implementation support, no CA support, little to no HSM/smart card support,
and the same thing about the environment.  And, as long as you do PKCS #1.5 as
encode-then-compare as per the spec, no particular motivation to move to PSS).

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Martin Thomson]

On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos  wrote:
> TLS 1.3 requiring a different key type, will provide an incentive for
> them to update.


I don't think that's how this works.  More likely, that would become a
reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are
used.

Yes, I know that it's relatively easy to configure a PSS certificate
separately.  I wrote the code that did that in NSS, but it's going to
remain the case that most servers have one cert.  If you have one
cert, then it's going to be the one that works with all the clients.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Nikos Mavrogiannopoulos]

On Mon, 2017-01-23 at 12:52 +0200, Ilari Liusvaara wrote:
> On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote:
> > 
> > > Additionally PSS signatures (see RFC4055) can be used with RSA
> > > keys
> > > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID).
> > > Does
> > > the RSASSA-PSS mean that both types must be accepted?
> > 
> > That's a quite interesting finding. Although that protocol behavior
> > seems to ease transition to RSASSA-PSS, it also paves the field for
> > new
> > cross protocol attacks. A server which can sign with either of
> > RSASSA-
> > PSS and RSA-PKCS1 and the same key is certainly less secure than a
> > server which can sign with either of them. The only way to enforce
> > that
> > a key is restricted is by requiring the id-RSASSA-PSS OID for
> > RSASSA-
> > PSS.
> 
> Unfortunately, dedicated RSA-PSS keys are pretty much undeployable,
> and
> requirement to use those would be de facto the same as removing RSA
> server signatures entierely from TLS 1.3[1].
> 
> I don't know any CA that would certify RSA-PSS keys. And adding new
> key
> types is a slow process. Heck, Certifying ECDSA keys are poorly
> supported among CAs[2].
> 
> And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that
> there
> exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any
> messages, unless keysizes are too small, hashes are too large or
> salts are too large.

The issue is that we cannot tell for sure. Any proof of security 
assumes that the keys are restricted to a single scheme. So I think we
got into a trap where we intended to increase security, while in fact
reduced the protocol's security, by ending-up adding RSA-PSS in a way
that can share keys with PKCS#1 1.5. I think that we should treat RSA-
PSS as the mean to increase security rather than the end-goal.

Even if the approach of separating keys would mean that RSA-PSS will
not be deployed immediately, it will allow implementors to provide
well-behaved clients that will refuse to mix marked as RSA-PSS keys
with the legacy ones. On the current protocol description it is
impossible for an implementor to do that. The reason is that if one
does that, his software will not be functional, will fail to connect to
several web servers, and thus will have to compromise (functionality
always wins over security).


> [2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
> with RSA[3] and even then most ACME software can't handle those)..

TLS 1.3 requiring a different key type, will provide an incentive for
them to update.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Ilari Liusvaara]

On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote:
> 
> > Additionally PSS signatures (see RFC4055) can be used with RSA keys
> > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does
> > the RSASSA-PSS mean that both types must be accepted?
> 
> That's a quite interesting finding. Although that protocol behavior
> seems to ease transition to RSASSA-PSS, it also paves the field for new
> cross protocol attacks. A server which can sign with either of RSASSA-
> PSS and RSA-PKCS1 and the same key is certainly less secure than a
> server which can sign with either of them. The only way to enforce that
> a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-
> PSS.

Unfortunately, dedicated RSA-PSS keys are pretty much undeployable, and
requirement to use those would be de facto the same as removing RSA
server signatures entierely from TLS 1.3[1].

I don't know any CA that would certify RSA-PSS keys. And adding new key
types is a slow process. Heck, Certifying ECDSA keys are poorly
supported among CAs[2].

And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that there
exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any
messages, unless keysizes are too small, hashes are too large or salts
are too large.

E.g. with 2048-bit keys, and SHA-512 with 512-bit salts, there are
126 octets to match, but only 64 octets to control, making it very
unlikely that suitable control value can be found. With longer keys,
each octet in key adds an octet to match but leaves octets to control
unchanged.


[1] Not that this wouldn't have security benefits, thanks to insecure
stuff SSL and earlier TLS versions pull off...

[2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
with RSA[3] and even then most ACME software can't handle those)..

[3] TLS 1.2 and 1.3 allows mixing and matching RSA and ECDSA in
chain.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Nikos Mavrogiannopoulos]

On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote:

> Additionally PSS signatures (see RFC4055) can be used with RSA keys
> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does
> the RSASSA-PSS mean that both types must be accepted?

That's a quite interesting finding. Although that protocol behavior
seems to ease transition to RSASSA-PSS, it also paves the field for new
cross protocol attacks. A server which can sign with either of RSASSA-
PSS and RSA-PKCS1 and the same key is certainly less secure than a
server which can sign with either of them. The only way to enforce that
a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-
PSS.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Adam Langley]

On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith  wrote:
> RSA PSS with a zero-length salt is a deterministic,
> subliminal-channel-free signature scheme. It is one of the few
> signature schemes that structurally prevent an HSM from directly
> leaking (parts of) the private key in an undetectable way.

Brian's disowned recommendation in the TLS 1.3 draft matches what I
suggest for PSS signatures:

* Salt length is the length of the hash function.
* MGF1 hash function is the same as the message hash function.
* The trailer field has the default value.

(I like Brian's idea, but I hate options, so I'm torn here.)

Certificates that don't match that format are at risk of not working
in Google products because we hate excessive options. (We'll see,
practically speaking, much we have to bend on that point, as always)


Cheers

AGL

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

[Ilari Liusvaara]

On Fri, Jan 20, 2017 at 05:43:21PM +, Dr Stephen Henson wrote:
> Draft 18 says:
> 
>RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
>   PSS [RFC3447] with MGF1.  The digest used in the mask generation
>   function and the digest being signed are both the corresponding
>   hash algorithm as defined in [SHS].  When used in signed TLS
>   handshake messages, the length of the salt MUST be equal to the
>   length of the digest output.  This codepoint is defined for use
>   with TLS 1.2 as well as TLS 1.3.
> 
> What are the requirements for certificates when these RSSSA-PSS is used?

AFAIK, no special requirements.
 
> The text above indicates the salt length for TLS messages. There are no
> restrictions placed on certificate signature salt lengths. Does this mean that
> any valid salt length (from 0 to the maximum permitted) must be supported?

Well, the code I have written enforces the salt length restriction also on
any possible RSA-PSS certificates in chain.

This comes from not even having RSA-PSS validation code that could deal
with arbitrary salt length.
 
> Additionally PSS signatures (see RFC4055) can be used with RSA keys
> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does the
> RSASSA-PSS mean that both types must be accepted?
 
I don't think you will see the latter outside some test sites for a
while...

But hmm, I think I should implement RSA-PSS only keys in some of my
stuff...


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls