Subject: [ietf-dkim] agenda item on upgrading hash algorithms?

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Feb 2006 22:44:39 -0500

I don't like being a guinea pig, but that's what it feels like with the
discussions on how to go about upgrading algorithms. I don't think we
know enough yet to even know how to begin. This is a problem that a
variety of protocols are going to go through, so we are *not* alone (and
*shouldn't* be alone) in trying to figure out how to do it.

Could we invite people in from SAAG to form a design team, investigate
the problem, then come in and tell us how to go about doing it, or at
least to give us some ideas? I know we don't usually do presentations at
WG meetings, but this topic might be worthy of one. So I'm suggesting
that we put "how to go about upgrading the hash algorithm" on the agenda
for the IETF meeting.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Feb 2006 08:40:19 +0100

I disagree with you that we don't know where to start.  I also disagree
with you that we will be guinea pigs any more so than any other new
protocol mechanisms.  I thought I had heard a very reasonable approach
from Mark for dealing with this whole thing, and I wonder if the SAAG
seniors might review That.

Eliot

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Feb 2006 18:03:56 -0500

If Mark's suggestions are considered reasonable by the SAAG seniors,
that's *a good thing*. Perhaps a design team won't be needed then. But I
still think we should have this topic explicitly listed in the agenda.

	Tony Hansen
	[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2006 23:16:01 +0000

Hi Tony,

Consider it added to the agenda.

Stephen.

---

From: Jon Callas <[email-masked]>
Date: Wed, 22 Feb 2006 11:11:52 -0800

> that we put "how to go about upgrading the hash algorithm" on the  

Oh, please no. This has been talked to death over the last year and a  
half.

We know what to do. The *technical* aspects of how you upgrade a hash  
algorithm are well-known, and not that hard. It's not like hash  
algorithms are magical. The problem is basic things like people hard- 
coding lengths into the system.

The *real* problem is that there is no pristine option. Everyone  
believes that the obvious candidate, SHA-256, is flawed, but no one  
knows how. There aren't any other real viable options, other than  
SHA-256. (Ah, but what about Whirlpool, I hear you ask. The only  
problem with Whirlpool is that it is slow. It runs at about half the  
speed of SHA-256, which happens to be about the speed of SHA-512.  
Which means that the only reason to use it over SHA-512 is in a  
situation where the difference in size matters and you need a small  
hash.)

There is nothing that SAAG or anyone else can do for us. We happen to  
be living in a time where we *know* that the cryptographic primitives  
we have handy in our toolkit are not what we like. We live in what  
the Chinese and Scots each call "interesting times."

The only question facing us is whether we jump straight to SHA-256  
now, or allow both. Jumping is cryptographically wiser as it gets us  
off the weak hash. Allowing both is engineeringly wiser as it forces  
us to be agile now. Neither is a bad choice, sadly. If one were a bad  
choice, then it would be easy. As things sit, we have a hard choice,  
and no matter what we do, people will look back with the wisdom of  
hindsight and cluck their tongues sadly about how stupid we were and  
how *clearly* it would have been better to do the other thing.

	Jon

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 14:48:00 -0500

Jon,

Is there any issue in regards to the idea of having a signer/validator
capability logic?

We can have a base defaults (SHA1, SHA-256) or whatever you experts deem
necessary.  But in an advanced implementation, the validator can define its
cryptographic validation strengths which a signer can look up and use. This
will give the signer HIGHER CONFIDENCE that a reception will not fail due to
hashing mismatches.

Example:

santronics.com exposes it supports the algorithms:

    k=sha1, sha256, sha512, whirlpool, other;

If bankofamerica.com had a relationship with one of our users, it can lookup
the santronics.com capability and choose the highest strength.

It will work very nicely for a direct (1 to 1) transaction (which I happen
to believe most high-value transactions will take place with DKIM).

But its not limited to just 1 to 1.  It can also work for a 1 to many
transactions. The signer simply looks up all the targets and get the least
common denominator (and may also exclude those that might be problematic).

This can also be cached too possibly, so it only need to be done once.

I see this as realistic for a high-value domain transaction.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 22 Feb 2006 11:59:27 -0800 (PST)

> the santronics.com capability and choose the highest strength.

What you're advocating here is recipient email policy record, correct?

BTW - Regarding this debate I think you need to say that both SHA1 and 
SHA256 MUST be supported but allow sending systems to choose which one
they want to use. And as I mentioned long ago I also think you need to 
separate PKI algorithm from hash algorithm as was done for text key 
record syntax (you can also just change rsa-sha1 to rsa/sha1 since you
seem to use '/' as separate for multi-part tags anyway...).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 15:32:01 -0500

----- Original Message -----
From: "william(at)elan.net" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> What you're advocating here is recipient email policy record,

yeah, that would be part of it.

I've talked about a TMS or "Transaction Management Service" in the past
where a domain would expose more information about its hosting services and
capabilities prior to connecting to it. Not just MX information. I gave
Scott Kitterman a private preview of my unpublished proposal.

It will not only help resolve this hashing match question but can also help
address other "SSP" related and middle ware "mix bag" questions.

We needed it for SPF, SENDER-ID, so we shouldn't be surprise we need it for
DKIM as well.

I'm not proposing an extensive TMS.  But for DKIM, the same idea can apply.

PS: We had the same issues with older mail/file exchange networks where two
systems needed to established it data transfer capabilities, including
protocols and compression/hashing algorithms to be used.  You knew
everything about the server when looking it up in "DNS".

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 13:03:26 -0800

On Feb 22, 2006, at 11:11 AM, Jon Callas wrote:

> now, or allow both. Jumping is cryptographically wiser as it gets  
> us off the weak hash. Allowing both is engineeringly wiser as it  
> forces us to be agile now. Neither is a bad choice, sadly. If one  
> were a bad choice, then it would be easy. As things sit, we have a  
> hard choice, and no matter what we do, people will look back with  
> the wisdom of hindsight and cluck their tongues sadly about how  
> stupid we were and how *clearly* it would have been better to do  
> the other thing.

There is an equally important question related to this question.   
Adopting an IANA index of the signature/hash algorithms as found with  
RFC2538 rather than expressing this as a textual representation,  
suggests one area not well covered.  This does not require hindsight  
as OpenPGP has already has made an appropriate choice for a binary  
resource record and binary representation of algorithms.  Following  
their example, it is already apparent what should be done.  When  
considering the servers and clients must be modified anyway,  
switching to this resource record type to afford a binary format puts  
DKIM in step with the rest of the industry.

Do not declare there is a way to upgrade, when it relies heavily upon  
defaults that are sure to change.  When these defaults change, the  
information does not fit within the existing TXT resource record.

DNS 512 -12(dns header) -5(question) -9(answer) = 486

Assuming pointer compression, add 3 bytes per label of additional  
overhead.

Now look at the DKIM TXT record:

   8 "v=DKIM1;" 8 bytes,
  66 "g=some-local-part"; 0-66 bytes,
   8 "h=SHA1:SomeNewHash"; 8+N bytes,
   3 "k=SomeNewKeyType;" 3+N bytes,
   0 "n=Notes;"  0-N bytes,
345 "p=base64key;" 345 bytes (2048 bit key)
   9 "s=email:SomeOtherApp;" 9+N bytes,
   0 "t=y; 0-3 bytes,
----
439 --> 47

The "_domainkeys" label needs 14 bytes --> 33.

Assume the domain uses a selector and 4 other labels within their  
domain, (in addition to the "_domainkeys" label) then another 15  
bytes are needed.

33 - 15 = 18 bytes

Discard support for "g="?

Switching to the binary #37 RR saves 100 bytes without requiring  
additional space to define future algorithms.

Out of these 18 bytes, new hash, key, and apps must be defined, in  
addition to forming the 5 remaining labels.  This represents less  
than 3 characters remains for each instance.  Is there a simple means  
to upgrade the DKIM key?  No, not when using a TXT RR.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Wed, 22 Feb 2006 14:04:08 -0800

> Is there any issue in regards to the idea of having a signer/validator

I think I agree with you, Hector.

Presently, the mails are coming in faster than I can read and respond  
to them so some of my earlier writing had time skew, I think.

The language that Dave Crocker proposed is great, from my view point.  
I *think* this satisfies your needs as well. If it does, let's go  
with that and be done with it.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Wed, 22 Feb 2006 14:29:49 -0800

On 22 Feb 2006, at 1:03 PM, Douglas Otis wrote:

> Adopting an IANA index of the signature/hash algorithms as found  
> with RFC2538 rather than expressing this as a textual  
> representation, suggests one area not well covered.  This does not  
> require hindsight as OpenPGP has already has made an appropriate  
> choice for a binary resource record and binary representation of  
> algorithms.  Following their example, it is already apparent what  
> should be done.  When considering the servers and clients must be  
> modified anyway, switching to this resource record type to afford a  
> binary format puts DKIM in step with the rest of the industry.

Yes, but.

The binary formats we have in OpenPGP have their own set of issues.  
It's easy to plop in an new algorithm identifier, but when it comes  
to signatures, we also have to play, "Buddy, can you spare an OID?"  
Furthermore, we end up needing to have things in text, too, because  
people want to have that because the binary objects almost never  
wander around naked; they're almost always armored or in clearsigned  
form. RFC2538 pretty much has the same issues. There are other  
virtues than saving a byte here and there. If you don't believe me,  
look at how OpenPGP handles lengths. There is more complexity in  
saving bytes there than anyone needs.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 15:41:06 -0800

On Feb 22, 2006, at 2:29 PM, Jon Callas wrote:

>> modified anyway, switching to this resource record type to afford  
>> a binary format puts DKIM in step with the rest of the industry.
>
> Yes, but.
>

OID information would not be needed with DKIM public key  
information.  Consider the DKIM public key cert isomorphic to that of  
OpenPGP.

> wander around naked;

Being able to store keys and algorithms in binary form spares more  
than 100 bytes, which likely represents the difference between DKIM  
still working or not after an upgrade in algorithms, even when some  
fields are defined as holding text.  500 bit keys should already be  
considered as not providing a valid signature.  A binary TLV  
structure is simple, extensible, and commonly used.

> There is more complexity in saving bytes there than anyone needs.

Software for dealing with this RR in binary form is already  
available, and binary information is ideal for computers.  It would  
be a terrible mistake to think DNS payloads will increase size before  
needing to utilize larger keys or different algorithms.

-Doug

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 15:42:41 -0800 (PST)

> Oh, please no. This has been talked to death over the last year and a

Indeed it has.

> coding lengths into the system.

Yes, this is certainly one source of trouble.  I think we've been
careful not to make these sorts of size assumptions in our code, but you're
never sure until you get in there and add the support.

> the Chinese and Scots each call "interesting times."

Yes, and complaining about the current state of affairs and how
we got here may be somewhat cathartic but in the end accomplishes nothing.

> how *clearly* it would have been better to do the other thing.

Very nicely put. I completely agree. It should be obvious that I'm in the
"might as well get agility correct now" camp, no doubt because I'm an
implementor first and I've been bitten too many times by bad code and bad
assumptions built into code. But the SHA-256 only position definitely
has merit too.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Feb 2006 00:03:49 +0000

Douglas Otis wrote:
> 
> OID information would not be needed with DKIM public key information.  
> Consider the DKIM public key cert isomorphic to that of OpenPGP.

IMO it is not in scope to develop an alternative to an X.509 PKI nor
anything else remotely equivalent. I believe that that or anything
remotely equivalent would require a recharter. Proposing to define
a new, supposedly simple, certificate format qualifies as remotely
equivalent. DKIM's just-a-key-in-DNS approach is about as complex as
I want to see this getting for a good while yet, if not forever.

So, regardless of whether or not we use TXT or some binary format,
we will not go down the road of developing yet another PKI.

If that's not what you meant, sorry for jumping up and down but you
can put my sensitivity down to the fact that I was involved in the
start of PKIX, now more than a *decade* ago;-)

Stephen.

---

From: Mark Delany <[email-masked]>
Date: Thu, 23 Feb 2006 00:40:22 +0000

> assumptions built into code. But the SHA-256 only position definitely

Me three. As a long-time implementor I suck at getting un-exercised
code right. I'd much prefer agility to be essential to a day one
deployment, as it'll otherwise never work.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 17:11:37 -0800

On Feb 22, 2006, at 4:03 PM, Stephen Farrell wrote:

>> information.  Consider the DKIM public key cert isomorphic to that  
>> of OpenPGP.
>

Using this #37 RR was not a suggestion for developing yet another  
PKI.  This was suggesting the use of a DNS resource record defined by  
RFC2538.

This RR imposes this header:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             type              |             key tag           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   algorithm   |                                               /
  +---------------+

Introduction

Public keys are frequently published in the form of a certificate and  
their authenticity is commonly demonstrated by certificates and   
related certificate revocation lists (CRLs).  A certificate is a   
binding, through a cryptographic digital signature, of a public key,  
a validity interval and/or conditions, and identity, authorization,  
or other information.

This appears to be a rather open definition.  For DKIM, this  
information would be an amalgam of that carried within the email  
message.  While this #37 resource record can hold X.509 certificates,  
nothing appears to prevent this resource records from also holding a  
DKIM key in binary form.  There is an IANA assigned Certificate Type  
which ensures the internal record structure is understood by the  
application.

DKIM already uses a unique label to locate the RR.  The DKIM draft  
indicates an expectation of developing a binary RR for DKIM, which  
should be within the WG charter.  Owing to difficulties created by a  
particular OS vendor for new RR types, utilizing an existing resource  
record likely represents the best opportunity at quickly establishing  
a binary RR, which is vitally needed.

IANA info

type:

     9-252              Available for IANA assignment by IETF  
Standards action
       253   URI        URI private
       254   OID        OID private
       255              Reserved
256-65279              Available for IANA assignment by IETF Consensus
65280-65534            Experimental
     65535              Reserved

DK = 17,483  or 0x44, 0x4b  (only needs IETF Consensus.)

algorithm:

Currently defined in RFC4034.

    Value Algorithm [Mnemonic]
    ----- --------------------
      0   reserved
      1   RSA/MD5 [RSAMD5]
      2   Diffie-Hellman [DH]
      3   DSA/SHA-1 [DSA]
      4   Elliptic Curve [ECC]
      5   RSA/SHA-1 [RSASHA1]
    252   Indirect [INDIRECT]
    253   Private [PRIVATEDNS]
    254   Private [PRIVATEOID]
    255   reserved
    6 - 251  Available for assignment by IETF Standards Action.

key tag:

The key tag algorithm is the sum of the wire format of the DNSKEY  
RDATA broken into 2 octet groups.  First, the RDATA (in wire format)  
is treated as a series of 2 octet groups. These groups are then added  
together, ignoring any carry bits.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 23 Feb 2006 01:30:31 +0000

> This RR imposes this header:

Right. A blob container. I see no functional difference from TXT.

Do you propose extending RFC2538 to support the plethora of tags
currently defined in Selectors or do you want to hide those in the
blob?

If you plan extension, do you have the support of the 2538 authors?

If you plan blobs, are you certain that matches the intent of the 2538
authors or have you not consulted them?

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 19:04:42 -0800

On Feb 22, 2006, at 5:30 PM, Mark Delany wrote:

>> PKI.  This was suggesting the use of a DNS resource record defined  
>> by RFC2538.
>>

The difference would be an assurance the information is not  
considered limited to 7 bit text, and that there is an IANA tag  
ensuring no collisions with other uses of the RR.  In addition, the  
#37 RR header will add significant value to a DKIM Key RR.   
Sourceforge links to applications using this RR was to offer  
illustrative examples of routines and utilities available.  If  
interested, a draft and example code for this DKIM Key RR could be  
provided.

> currently defined in Selectors or do you want to hide those in the  

The RFC2538 draft would not describe the DKIM key structure, as it  
does not describe any other structures for other protocols using this  
RR.  Only general overviews are provided.  There is no structural  
information provided beyond the #37 RR header.  A draft for the DKIM  
key structure, ideally in a binary TLV form, would define the tags  
below the #37 RR header.

> If you plan extension, do you have the support of the 2538 authors?

No changes to this draft appear needed.  IANA could reference the  
assigned Type to the draft defined by the DKIM wg.  The DKIM key and  
signature header amalgam could be considered an identity  
certification.  It should not be surprising to find the algorithm  
parameter already supports the current DKIM key.  Whatever algorithm  
the DKIM wg selects, this will likely cover similar work in this  
area.  There should be no conflicts created.

> If you plan blobs, are you certain that matches the intent of the  
> 2538 authors or have you not consulted them?

This was brought several up months ago.  At the time, concerns raised  
regarding DKIM's uses of this RR were related to the mention of DNS  
wildcard use.  In conjunction with DKIM or OpenPGP, such a wildcard  
record could be exploited as an attack vector to flood DNS caches.   
Some DNS servers do not fair very well in these scenarios.  This was  
not discussed in great detail, as there was greater focus upon other  
minutia.  As there is a vital need to support future upgrades of the  
DKIM Key RR that might not be accommodated by the TXT RR. Use of this  
RR for public keys should not set a precedent where this RR is  
considered nothing more than a blob container.

-Doug