Subject: RSA/SHA256

From: Jelte Jansen <[email-masked]>
Date: Wed, 24 Oct 2007 23:30:35 +0200

I'm sorry, it's been a month already (how time flies when you're having
fun), so I'm really gearing up to start typing again, and I'd like to
try to state the issues and give you a heads-up on the direction I'm
about to take.

IMHO, there are four separate issues here:

1) Should this document be written?

It seems clear to me that the answer to this is yes, so I won't talk
about it further.

2) Should this document specify other hash algorithms as well?

My personal opinion is that while I'm at it, I might as well add others
in the SHA2 range, and perhaps even others, although for clarity, it
might be better to stick to SHA.

3) If so, how will we handle the different algorithm/hash types?

Currently, we have a bunch of different algorithms, a bunch of different
hash types, and NSEC3. I know that last one has been under discussion
again lately and I don't want this thread to go into that, so let's for
the sake of argument assume that it's there and we need to address the
way it uses the algorithm type field.

Another fast assumption is that every cryptographic algorithm is usable,
and wanted, with every hash type available. But I'll come back to that
below.

That gives us <nr of algos> * <number of hash types> * 2 as the total
number of possibilities that we need to cram into the 8-bit algorithm field.

Now there have been a few proposals how to handle this:

  a. Don't. Just give every combination its own number and be done with it.
  b. Drop the hash type from the algorithm field for future combinations
and move it to the RDATA part of the signature.
  c. Split up the algorithm field and reserve a place for algorithm and
for hash type

Let's start with c. I don't think this is a good idea. While I like the
fact that it would possibly ease the burden on writing documents because
we can ignore the hash type when specifying algorithms, and the other
way around, it doesn't actually save space, it only consumes more. You'd
still need a unique octet for every combination but you lose any
possible flexibility if my fast assumption wouldn't hold. And i think it
won't.

Let's move on (or back, as you will) to b. I'm not sure whether I can
imagine the possible security implications this has. One thing that's
already mentioned is downgrade attacks. We might be able to circumvent
this by demanding that if you implement any hash algorithm, you have to
implement all. However, I'm not sure whether this can be done. It can be
for the current set of algorithms, but what about one that's invented
next week, solves everybody's problems, and is applicable to all known
cryptographic algorithms? And we'd need yet another IANA list of
supported hash types. For each algorithm. The developer in me also
screams that this is an incredible abstraction violation, and as I'll
probably be one of the first to actually have to implement this, I'm not
to pleased about taking this approach.

So, unless someone can convince me otherwise real soon now, that'll
leave me option a. I really do think that splitting algorithm and hash
types is a good idea, but it should have been in DNSSEC already, and
possible backwards-compatible patching might do more harm than good. In
this sense, getting more combinations in one I-D will be a good thing,
because we only have to reserve a set of numbers once.

My, it's becoming quite a rant by now, but I still have one more issue:

4) What should the actual status be of the new combinations?

I'm currently leaning towards mandatory-to-implement. If only because,
given the rate of implementation and adoption, if people aren't told to
use it, they won't. I realize that it would be just another RFC that
people can choose to implement or not, so I might settle for
very-very-very-recommended, but still, Royal Bank of Suburbia will
probably not use SHA256 when there's even one client that might only be
able to handle SHA1. And if they put up both, we get back to the hairy
business of downgrade attacks, and the end-all of all protocol
discussions, local policy. Which I think is a bit off here, since we're
talking about different points of 'local' here, but that's probably
beside the point. By the way, if someone can provide me with an English
translation of the Dutch term 'dooddoener', I'd be very grateful.

Jelte 'I wish I had something witty to put here' Jansen

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 25 Oct 2007 12:00:11 +0200

> It seems clear to me that the answer to this is yes, so I won't talk

I welcome this work. I think that support of the SHA2 set it important for 
DNSSEC.

> might be better to stick to SHA.

I agree. I would like to see the entire SHA2 set supported.

> because we only have to reserve a set of numbers once.

I agree with (a). We're not close to running out of typespace. If running 
out of typespace would be an issue, we can always come up with an 
extendible scheme.

> translation of the Dutch term 'dooddoener', I'd be very grateful.

It is hard to retrospectively mandate to implement something. It would be 
a paper tiger. What I do like to mandate is support for the new keytypes 
implies support for NSEC3, provided that NSEC3 is proposed standard by 
that time. That would avoid allocating an alias for every keytype.

> Jelte 'I wish I had something witty to put here' Jansen

As for "dooddoener", the closest that comes to mind is "aphorism", though 
"deadpan" would be appropriate if the "dooddoener" would be funny.

Regards,

Roy

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Oct 2007 12:41:52 -0700 (PDT)

I'm basically in agreement with what you're proposing, with one question.

> might be better to stick to SHA.

I'd like to repeat the question I asked before, which is what are the 
benefits of adding more algorithms besides full SHA256, and what are the 
costs? In particular I'm concerned about the costs of adding a lot of 
different possible combinations both in terms of implementation complexity 
on the server side and policy complexity on the client side.

Doug

-- 

 	If you're never wrong, you're not trying hard enough

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 26 Oct 2007 02:52:28 +0200

Michael StJohns wrote:
> Each Signature strength has an appropriate Hash strength to go with it.
> E.g. with RSA, 2048 bits of signature is matched roughly by SHA224.
> Ideally, we should have an SHA<n>withRSA algorithm identifier for each
> group of signature strengths we might expect to see. If/when we start
> doing Elliptic Curve we'll need SHA<n>withECDSA identifiers for the
> complete range of strengths.

There might also be the operational issue of rrset and packet sizes,
although I haven't put much thought into this yet.

> The reason you do this now is so you can change the strength of the
> signature without having to go back and completely replace the installed
> base. The implementations across the SHA2 suite are fairly common for
> each hash - 224 differs from 256 only by the input table values and the
> fact the result is truncated. Ditto 384/512 so there's really no reason
> not to require all 4 as mandatory.

Heh, you had me up to the last word there.

Another reason to do it once is to get it over with in terms of
standardization; do we want to repeat this discussion for every hash
algorithm that is not completely new? Why go through this process again
when some organizations decide that SHA-256 isn't good enough for them
and they require 512, when this could have been handled now? It's mostly
the same argument, but from a protocol perspective.

But you mentioned mandatory, which does raise questions. There is no
handshake to discuss which combinations are known to both parties here,
so I would assume that people would gravitate to combinations that are
known and deployed. I've talked about this to some people in the hallway
today and they are doing a good job of convincing me that this is not a
problem, but I'm not exactly there yet. If this actually is a problem,
that brings me to your last point;

> I suggested in a previous note that we split the registries for Key
> types and signature algorithm types - I reiterate that suggestion as I
> don't expect the current scheme to work for many more values. (e.g.
> which of the RSA algorithms numbers do you use in a DNSKEY record when
> you have 5 different RSA signature types?)

Doesn't it actually make this worse if you split them? We'd either have
to make it mandatory to support every combination that is possible,
which I think can't be done, since it still seems hard to predict the
future, or we'd have to require every combination that is allowed to
have its own specification somewhere in a published document. I don't
really see the difference in the location of the actual bits within the
algorithm field in that case.

Okay, it'll probably be easier to refer to previously registered numbers
in a new document than asking for new ones, but is it worth sacrificing
possible space for combinations that may never be used at all?

Jelte

---

From: Michael StJohns <[email-masked]>
Date: Thu, 25 Oct 2007 19:23:38 -0400

Each Signature strength has an appropriate Hash strength to go with it. E.g. with RSA, 2048 bits of signature is matched roughly by SHA224.   Ideally, we should have an SHA<n>withRSA algorithm identifier for each group of signature strengths we might expect to see.  If/when we start doing Elliptic Curve we'll need SHA<n>withECDSA identifiers for the complete range of strengths.

The reason you do this now is so you can change the strength of the signature without having to go back and completely replace the installed base.  The implementations across the SHA2 suite are fairly common for each hash - 224 differs from 256 only by the input table values and the fact the result is truncated.  Ditto 384/512 so there's really no reason not to require all 4 as mandatory.

I suggested in a previous note that we split the registries for Key types and signature algorithm types - I reiterate that suggestion as I don't expect the current scheme to work for many more values.  (e.g. which of the RSA algorithms numbers do you use in a DNSKEY record when you have 5 different RSA signature types?)

At 15:41 10/25/2007, Doug Barton wrote:
>I'd like to repeat the question I asked before, which is what are the benefits of adding more algorithms besides full SHA256, and what are the costs? In particular I'm concerned about the costs of adding a lot of different possible combinations both in terms of implementation complexity on the server side and policy complexity on the client side.
>
>Doug
>
>-- 
>

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Oct 2007 13:01:04 -0700 (PDT)

You guys seem to think that you're making an argument FOR including 
additional hashes, but in my mind you're actually making a case not to do 
it.

> although I haven't put much thought into this yet.

I think that the difference between SHA1 and SHA256 will be measurable (I 
thought this factor was obvious, but I suppose it's worth putting on the 
record). I don't think that the marginal difference between SHA(N) and 
SHA(N+M) will be important enough to justify the complexity that you're 
proposing to add.

>> not to require all 4 as mandatory.

Yes, there is a reason. It adds significant complexity on both sides of 
the transaction, for no benefit that I can see.

> the same argument, but from a protocol perspective.

I don't see how adding a lot of hashes now makes adding a new one later 
any easier. (Other than perhaps the fact that implementors will get lots 
of practice writing code for new hashes.)

Seriously guys, if there is an overwhelmingly good reason to add all the 
intermediate hashes, please elaborate because I don't see it. "Because we 
can" is NOT a good reason.

> that brings me to your last point;

I suggested 3 years ago in those same hallways that we SWITCH to SHA256 
INSTEAD of SHA1 which would have given us a lot more time to figure out a 
solution to the problem you're seeing (and FWIW I agree that it's a 
problem) but I was told then that it was too late in the game to make that 
kind of change, and we were too far away from SHA1 being compromised to 
make it worthwhile. Now it's 3 years later, people are (justifiably) 
concerned that SHA1 isn't going to last as long as we need it to, and 
instead of talking about one mandatory hash that everyone can implement 
and finally get this thing off the ground we're spending more time talking 
about rollover and/or quintupling the complexity of the system.

Paul's "redesigning the plane in flight" shirts are proving to be 
pathetically prophetic, and how many YEARS ago was that?

You have to resist the temptation to keep tinkering with this thing. If 
you don't think SHA256 is strong enough to last through the early 
implementation cycle while we figure out solutions to problems like 
algorithm rollover, then pick ONE that will be (SHA512?, more?) and then 
let's move on.

Ok, rant over. I think I've said pretty clearly what my position is, so 
I'll let others voice theirs.

Doug

--