Re: [TLS] RSA-PSS in TLS 1.3

2016-03-04 Thread Martin Rex 
Fedor Brunner wrote:
> 
> Please see the paper "Another Look at ``Provable Security''" from Neal
> Koblitz and Alfred Menezes.
> 
> https://eprint.iacr.org/2004/152
> 
> Section 7: Conclusion
> 
> "There is no need for the PSS or Katz-Wang versions of RSA;
> one might as well use just the basic ?hash and exponentiate? signature
> scheme (with a full-domain hash function)."


Thanks a million for adding some clue to this discussion!

-Martin

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

Re: [TLS] Accepting that other SNI name types will never work.

2016-03-04 Thread Richard Moore 
On 3 March 2016 at 23:16, Martin Thomson  wrote
​:​

>
> I assume that the last
> error indicates that you didn't get an alert, which I find is
> alarmingly common in TLS.
>
>
​Yes, that's right.

Cheers

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

Re: [TLS] RSA-PSS in TLS 1.3

2016-03-04 Thread Martin Rex 
Hanno Böck wrote:
> m...@sap.com (Martin Rex) wrote:
>>
>> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
>> signatures is that one can clearly distinguish "wrong public key"
>> from "signature does not fit plaintext" errors, and loosing this
>> capability makes certain kinds of programming goofs (plus a few
>> admin configuration goofs) much harder to distinguish from
>> data corruption during transfer.
> 
> Actually I see this as a disadvantage. Separating different error
> states has been the source of a whole number of vulnerabilities. The
> original Bleichenbacher attack (and all its variants including drown)
> is based on separating different errors, the Vaudenay attack is.

I'm sorry, but this is clueless.
Signature verification is a PUBLIC KEY operation.
You're not creating an oracle with a public key operation.

The examples you cite are about secret key and private key operations
which create oracles.  That isn't even in the same universe.

-Martin

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

Re: [TLS] RSA-PSS in TLS 1.3

2016-03-04 Thread Hanno Böck 
On Fri, 4 Mar 2016 14:45:13 +0100 (CET)
m...@sap.com (Martin Rex) wrote:

> What should have adopted for TLSv1.2 already, however, is the less
> forgiving PKCS#1 v1.5 signature check, that re-creates the encoding
> and then compares the recreated inner encoding with the RSA-decrypted
> encoding only.  Get rid of the de-padding and get rid of the ASN.1
> decoding of the contents.

The Problem with this is that you're relying on the implementor to get
it right. Sure, you're giving them a receip how they could implement
the check to be correct, but you have no way of checking whether they
actually follow that receip.
Given all past experiences I'd bet you can write whatever you want in
your new standards document, no implementor will replace their
(seemingly working, but insecure) PKCS #1 1.5 implementation as long
as it works, just because you say they have to do it in a
different way than they did in the past.

> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
> signatures is that one can clearly distinguish "wrong public key"
> from "signature does not fit plaintext" errors, and loosing this
> capability makes certain kinds of programming goofs (plus a few
> admin configuration goofs) much harder to distinguish from
> data corruption during transfer.

Actually I see this as a disadvantage. Separating different error
states has been the source of a whole number of vulnerabilities. The
original Bleichenbacher attack (and all its variants including drown)
is based on separating different errors, the Vaudenay attack is.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpYHTQr5FQIB.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

2016-03-04 Thread Martin Rex 
Hanno Böck wrote:
> Joseph Salowey  wrote:
>> 
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
>> Please respond on the list on whether you think this is a reasonable
>> way forward or not.
> 
> I recently already saw the message here asking for PKCS #1 1.5
> compatibilty and was quite angry about it, but as there wasn't much
> discussion I thought this issue would go away. It seems it did not.
> 
> RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago.

RSA-PSS signatures are crap, and they're pretty close to useless.

What should have adopted for TLSv1.2 already, however, is the less
forgiving PKCS#1 v1.5 signature check, that re-creates the encoding
and then compares the recreated inner encoding with the RSA-decrypted
encoding only.  Get rid of the de-padding and get rid of the ASN.1
decoding of the contents.  This is also the recommended fashion
for PKCS#1 v1.5 signature verification in rfc3447.


The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
signatures is that one can clearly distinguish "wrong public key"
from "signature does not fit plaintext" errors, and loosing this
capability makes certain kinds of programming goofs (plus a few
admin configuration goofs) much harder to distinguish from
data corruption during transfer.  XMLdsig and XML canonicalization
is another source of endless fun, where being able to distinguish
these causes for signature verification failure facilitates
troubleshooting.


Signature verification itself is a public key operation, so RSA-PSS
is a wholly different beast than RSA-OAEP.


-Martin

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

Re: [TLS] Accepting that other SNI name types will never work.

2016-03-04 Thread Fossati, Thomas (Nokia - GB) 
On 04/03/2016 07:58, "EXT Yuhong Bao"  wrote:
>
>> From: thomas.foss...@nokia.com
>> To: a...@imperialviolet.org; tls@ietf.org
>> Date: Fri, 4 Mar 2016 07:10:06 +
>> Subject: Re: [TLS] Accepting that other SNI name types will never work.
>>
>> Trying again...
>>
>>> Hi Adam,
>>
>>
>> In CoRE we might need to allocate a new SNI NameType for non-DNS host
>> names [1].
>>
>> Removing SNI extensibility would make it unfeasible.
>>
>> Cheers, t
>>
>> [1]
>> 
>>https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#secti
>>on
>> -3.3
>Is limiting the list to only one SNI name entry feasible?

Yes, I think so.

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

Re: [TLS] Accepting that other SNI name types will never work.

2016-03-04 Thread Martin Thomson 
On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB)
 wrote:
> In CoRE we might need to allocate a new SNI NameType for non-DNS host
> names [1].
>
> Removing SNI extensibility would make it unfeasible.

Not at all.  Define a new extension.  We have evidence that that works.

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