Subject: [dnsext] RSA algorithm padding in RFC 5702, RSASSA-PSS

From: Hanno Böck <[email-masked]>
Date: Wed, 20 Oct 2010 17:07:00 +0200

Hi,

I'm currently working on a study project about RSASSA-PSS. This is a padding 
variant with security proofs and standardized within PKCS #1 2.1.

I saw that dnssec currently seems to use the old PKCS #1 1.5 padding methods 
(RFC 5702, Section 3). I wonder if there was any discussion about that 
decision (there is some hint in section 8.1). RFC 5702 was published in 2009, 
so it's a pretty new standard.

Are there any plans to support algorithms with EMSA-PSS-padding within dnssec 
in the future?

regards,

-- 
Hanno Böck		Blog:		http://www.hboeck.de/
GPG: 3DBD3B20		Jabber/Mail:	[email-masked]

http://schokokeks.org - professional webhosting

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Oct 2010 09:50:42 +1100

In message <[email-masked]>, Hanno =?utf-8?q?B=C3=B6ck?= wr
ites:
> Hi,
> 
> I'm currently working on a study project about RSASSA-PSS. This is a paddin=
> g=20
> I saw that dnssec currently seems to use the old PKCS #1 1.5 padding method=
> s=20
> (RFC 5702, Section 3). I wonder if there was any discussion about that=20
> decision (there is some hint in section 8.1). RFC 5702 was published in 200=
> 9,=20
> Are there any plans to support algorithms with EMSA-PSS-padding within dnss=
> ec=20
> in the future?
> 
> regards,
> 
> =2D-=20
> Hanno B=C3=B6ck		Blog:		http://www.hboeck.de/

This is a decision for any new algorithm to make.

I can't see any point in issuing new code points just to change the
padding for existing algorithms.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 20 Oct 2010 20:14:56 -0400

> Are there any plans to support algorithms with EMSA-PSS-padding within dnssec

There are no such plans at this point in time.
RFC5702 is likely to be the last change to any RSA algorithm for DNSSEC,
as ECC based algorithms are likely to become the recommended algorithms 
in the not so distant future.

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Oct 2010 08:11:50 -0400

>in the not so distant future.

If there's going to be a change in the recommended algorithms any 
time soon, the operator community will need better key management and 
signature maintenance tools.  I'm not pointing to any implementations 
in particular, but there's a growing awareness that changing 
algorithms isn't easy with what we have.

It's not the specification but the tools.  So maybe this isn't 
something that the DNSEXT solves - but if the DNSEXT group dictates 
operational parameters they have to do so realizing that tools are 
needed if the operator community is able to keep up.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Oct 2010 17:43:27 -0400 (EDT)

> Are there any plans to support algorithms with EMSA-PSS-padding within dnssec

I brought this up a year or two ago, when RSASHA256 was getting
specified.  Specifically, I argued the IETF itself had already
recommended moving from PKCS 1.1.5 to RSASSA-PSS in 2003:
http://tools.ietf.org/html/rfc3447#section-8.2

At the time the concensus seemed to be that RSASSA-PSS was less
standarised and less available in crypto libraries, and the gains on
theoretical security would be lost in practical implementation issues
(interop issues, implementation mistakes, etc)

I can't find the thread but I think it was on the dnssec-deployment or dnsext list.

Paul