Subject: [ietf-dkim] z= question with X headers

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Apr 2006 19:29:00 -0500

Should we add some text like “signers MAY exclude X type headers when calculating the z= tag?”  I was polishing our implementation today and integrating it and turned on the z= tag wherein my test messages promptly grew really large due to thousands of X headers (from SpamAssassin and other sources too).
 
Arvel

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Apr 2006 17:42:50 -0700

Arvel Hathcock wrote:

Should we add some text
like “signers MAY exclude X
type headers when calculating the z= tag?”  I was polishing our
implementation today and integrating it and turned on the z= tag
wherein my test
messages promptly grew really large due to thousands of X headers (from
SpamAssassin and other sources too).

The z= tag allows you to put as many
or as few headers in it as you want. I typically

only put subject, from, to and maybe a few others that I regularly see
getting toasted.

Was this actually unclear? If so it might make sense to be more
explicit.

Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Apr 2006 20:56:29 -0500

> The z= tag allows you to put as many or as few headers in it as you
 > want. I typically only put subject, from, to and maybe a few others
 > that I regularly see getting toasted.  Was this actually unclear? If
 > so it might make sense to be more explicit.

Mike, it could just be me being dense.  FWIW though this text was 
understood by two of us here as meaning copy all the headers:

"A vertical-bar-separated list of header field names and copies of 
header field values that identify the header fields present when the 
message was signed."

Perhaps:

"A vertical-bar-separated list of select header field names and copies 
of header field values that identify the header fields present when the 
message was signed.  It is not required to include all header field 
names and values."

-- 
Arvel

---

From: Tony Hansen <[email-masked]>
Date: Thu, 27 Apr 2006 22:40:38 -0400

I also read it the same way Arvel did. Also, if it isn't interpreted
that way, you get ambiguities when multiple instances of a particular
header are listed and only some of the values are presented in z=. In
particular, the z= field is also supposed to help you work around header
reordering; you need all values to be there in order to do that.

	Tony Hansen
	[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Apr 2006 05:23:10 -0700 (PDT)

You can not avoid such ambiguities unless you can specifically reference 
the copied data as part of signed header field listing. That is why I went
with copying to make new header field and referencing that in my design.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Apr 2006 06:24:33 -0700

Tony Hansen wrote:

>I also read it the same way Arvel did.
>
Huh. Ok, then Arvel's clarification seems reasonable.

> Also, if it isn't interpreted

Well that's the first I've heard of that possible use of z= :) I don't 
think you need
all of the headers in z= to be able to handle repeated headers, just a 
rule like with
h=  that tells you how to interpret h=received:received. In fact, I'm 
pretty sure that
we could lift the text there about that directly.

       Mike

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Apr 2006 12:34:00 -0700

> Perhaps:
>
> "A vertical-bar-separated list of select header field names and
> copies of header field values that identify the header fields
> present when the message was signed.  It is not required to include
> all header field names and values."

I've added essentially this wording.  Sorry for the confusion; it was 
definitely ambiguous.

eric

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Apr 2006 15:54:59 -0400

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 28, 2006 3:34 PM
Subject: Re: [ietf-dkim] z= question with X headers

> I've added essentially this wording.  Sorry for the confusion; it was

Thanks.  This was one of the issues I had brought in the issues list.

I think what is may be important is what to do when a header is different
from a possible copy in the z= list.

I.e., for a mailing server that may alter the subject line to add the
[mailinglist_name] subject tag.

Example:  This might be the correction.

    // Hash Headers

    hash = empty;
    for each hdr in (dkim_h_list) do

      s  = mail_headers[hdr];
      sz = dkim_z_list[hdr];  // see is copy is available

      if (s != sz) {
         WHAT? INVALID?  Should they be the same?
         What can cause this? Mailing list?
      }

      if (s == "") s = sz;  // correction

      if (s != "")
         hash += hash_string(s)
      else
         WHAT? INVALID?

    end for

Make sense?

---
Hector

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Apr 2006 13:16:01 -0700 (PDT)

On Fri, 28 Apr 2006, Eric Allman wrote:

> The z= tag is only supposed to be used for "diagnostic purposes", not for 
> computing the hash.  Changing that would have major implications that we 
> would have to examine very carefully.

So if mail list changed Subject header field (and for purposes of this
question did not add other fields or changed content data) and there was
a signature in message before that contained original Subject in the 'z'
tag AND now message got to verifying agent - that agent is supposed
to say the signature is invalid rather then use data from 'z' tag to 
attempt to verify the signature?

---
William Leibzon
Elan Networks
[email-masked]

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Apr 2006 13:22:22 -0700

>> The z= tag is only supposed to be used for "diagnostic purposes",
>> not for  computing the hash.  Changing that would have major
>> implications that we  would have to examine very carefully.
>
> So if mail list changed Subject header field (and for purposes of
> this question did not add other fields or changed content data) and
> there was a signature in message before that contained original
> Subject in the 'z' tag AND now message got to verifying agent -
> that agent is supposed to say the signature is invalid rather then
> use data from 'z' tag to attempt to verify the signature?

Yes.  The mailing list should have re-signed the message.

eric

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 28 Apr 2006 13:25:58 -0700 (PDT)

> Yes.  The mailing list should have re-signed the message.

Hm. I've a certain suspicion that there would be a number of
implementations that will purposely not comply with your draft...

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Apr 2006 13:38:08 -0700

william(at)elan.net wrote:

>> The z= tag is only supposed to be used for "diagnostic purposes", not 
>> for computing the hash.  Changing that would have major implications 
>> that we would have to examine very carefully.
>
>

Yes, but let me explain. As far as the spec is concerned, there is a 
single way
to verify a signature, and that does not involve anything with z=. We 
need this
to be true lest we infinitely devolve into arguments about what 
heuristics are
good, evil, etc. The current spec is algorithmic, and that's a Good Thing.

That said, dkim-base does not specify any output other than the internal 
state
of the verifier after the operation is complete, and this can be used 
for whatever
purpose the verifier thinks is useful. Nor does -dkim-base say that you 
must not
try to figure out what went wrong; this is the receiver's perogative, 
and we aren't
the net.police. If you were to try to do that and make a different 
decision in your
receiver based upon that, that's your perogative, but it's completely 
outside the
scope of the -dkim-base document. In other words, your on your own.

       Mike

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Apr 2006 16:55:39 -0400

The pseudo code ignores the case where multiple existences of a header
field name may exist in either/both of the h= and z= values.

	Tony

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Apr 2006 16:56:39 -0400

The revised wording ignores the case where multiple existences of a
header field name may exist in either/both of the h= and z= values. It's
still ambiguous.

	Tony Hansen
	[email-masked]

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Apr 2006 13:06:52 -0700

>       if (s == "") s = sz;  // correction

This makes me nervous (assuming I'm understanding the pseudo-code). 
It seems to say that if a header doesn't exist you use the header 
from the z= tag.  But since MUAs aren't going to see that, I think 
it's problematic.  Also, it doesn't address the "mailing list adds a 
prefix" problem.

eric

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Apr 2006 17:11:16 -0400

I agree. I highlighted the ambiguity for the issues list.

But I wanted to point out even without multiple signatures, what to do when
a header is missing or changed.

I believe what came out of the little discussions was that in the end, it
(z=) is totally useless information for verifiers. It is purely for signer
diagnostics.

I can see an implementator going the extra mile trying to find out "why" a
hashing failure.  It might do a header comparison if it is listed in z=.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Apr 2006 12:17:00 -0700

At 1:06 PM -0700 4/28/06, Eric Allman wrote:
>not for computing the hash.

Fully agree.

>Changing that would have major implications that we would have to 
>examine very carefully.

Fully agree, but that doesn't lead to the conclusion that the 
verifier *cannot* use heuristics (one of which might be the value of 
x=) to try to get the signature to validate.

So, let's have that examination now.

At 1:22 PM -0700 4/28/06, Eric Allman wrote:

>Yes.

Fully disagree. The verifier can use whatever means it has, including 
using heuristics, to see if the message is actually sent by the 
purported sender. One such heuristic is to dissect the value of x= 
and see if any parts are different than the current message; if so, 
try validating with those parts. Another such heuristic is to notice 
that the subject starts with "[foo]", and that is often a sign that 
the subject might have been changed after the signature was applied, 
and to try to validate the signature without that string in the 
signature.

The security implications of the verifier taking this route is that a 
sender who wanted to spoof a signature could try to put in stuff that 
the verifier would try which would be successful. However, doing so 
involves creating a pre-image of the hash, which is considered 
impossible here and in all IETF work. There is no collision attack 
here. So, there is no attack vector in allowing the recipient to keep 
trying heuristics until it either finds a changed message that works 
or gives up.

It is up to the verifier to decide how much effort after the first 
attempt it wants to do. The cost to the verifier is a doing multiple 
hashes, not doing multiple signature validations.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Apr 2006 12:34:02 -0700

> purported sender. 

Again, we need to distinguish between the mechanics of verifying a 
signature, versus the policies that might be used to process a message. 
Hence, a receiver plays two different roles.  In one role, they are 
validating a digital signature. In the second they are attempting to 
decide what to do with a message they have received.

A specification for doing signature validation should not use 
heuristics. It needs to have simple, mechanical, universal  procedures 
that produce a binary valid/invalid result and produce those same 
results anywhere the validation is attempted.

A specification for processing a message well might suggest use of 
heuristics and well might produce very different results, depending upon 
where the processing is performed.

Anything that confuses these two, very different types of activity makes 
it more likely that the entire DKIM effort has fuzzy meaning, and 
therefore fuzzy benefit, and therefore is questionable to adopt.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Apr 2006 17:15:29 -0700

At 12:34 PM -0700 4/29/06, Dave Crocker wrote:
>heuristics. It needs to have simple, mechanical, universal 
>procedures that produce a binary valid/invalid result and produce 
>those same results anywhere the validation is attempted.

Fully agree, but that's not what was being discussed. The 
specification should not prevent the verifier from trying other 
things to get a signature to verify unless there is a significant 
security issue in doing so. We don't have to encourage (or even 
mention) making multiple attempts with expected changes on a message, 
but we should not prohibit it either.

>heuristics and well might produce very different results, depending 
>upon where the processing is performed.

Too many softeners in that.

>Anything that confuses these two, very different types of activity 
>makes it more likely that the entire DKIM effort has fuzzy meaning, 
>and therefore fuzzy benefit, and therefore is questionable to adopt.

A verifier that chooses to try heuristic message modifications in 
order to get a positive result for verification does not change the 
meaning of DKIM at all, unless those modifications can come from an 
plausible attack. As I stated in my previous message, given that this 
attack would require a preimage attack, it is not plausible.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Apr 2006 21:08:21 -0700

> specification should not prevent the verifier from trying other things 
> to get a signature to verify unless there is a significant security 
> issue in doing so. We don't have to encourage (or even mention) making 
> multiple attempts with expected changes on a message, but we should 
> not prohibit it either.

A specification cannot "prevent" a verifier from trying any crazy (or 
sane) thing they want. 

However, it CAN distinguish between text that is specifying how to 
perform straight verification, versus text explains all sorts of 
secondary hacks.  The former is precise, reliable and clear.  The latter 
is whatever folks feel like making it. Mixing the two confuses both.

> Too many softeners in that.

OK.

How about:  It is silly (and dangerous) to specify a verification 
technique that gives different results depending upon who is doing the 
verification.

> attack would require a preimage attack, it is not plausible.

A protocol that is successful on Internet scale -- large numbers of 
independent implementations and large numbers of independent 
administrations that interoperate -- is nearly always simple, 
mechanical, and predictable.  

The use of heuristics in any of the core specifications runs contrary to 
this experience.  It introduces ambiguities, ie, uncertainties. For some 
reason, people deciding to spend the time and money to implement 
critical infrastructure services are a tad reticent to pursue standards 
that make guesses.

Feel free to proffer examples to the contrary.

d/

-- 

Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Sun, 30 Apr 2006 08:49:03 -0400

Paul Hoffman wrote:
>> for computing the hash.
> Fully agree, but that doesn't lead to the conclusion that the verifier
> *cannot* use heuristics (one of which might be the value of x=) to try
> to get the signature to validate.
> 

I know that Michael Thomas was doing some work along these lines, to see
how resilient you could be to changes incurred through a mailing list.

> purported sender. One such heuristic is to dissect the value of x= and
> see if any parts are different than the current message; if so, try
> validating with those parts. Another such heuristic is to notice that
> the subject starts with "[foo]", and that is often a sign that the
> subject might have been changed after the signature was applied, and to
> try to validate the signature without that string in the signature.
> 
> impossible here and in all IETF work. There is no collision attack here.
> So, there is no attack vector in allowing the recipient to keep trying
> heuristics until it either finds a changed message that works or gives up.
> 

Ummm, we don't currently run a hash of the headers, just the body. We
currently do the signature validation based on the actual headers, the
body hash, and the dkim-signature. So doing such a verification *would*
require multiple signature validations.

It's been suggested that we adopt another tack, and use a hash of the
headers as well as a hash of the body. So the actual signature
validation would be on two hashes along with the rest of the
dkim-signature header field.

This particular suggestion hasn't received any traction as yet.

	Tony Hansen
	[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Apr 2006 08:26:17 -0700

At 9:08 PM -0700 4/29/06, Dave Crocker wrote:
>A specification cannot "prevent" a verifier from trying any crazy 
>(or sane) thing they want.
>secondary hacks.  The former is precise, reliable and clear.  The 
>latter is whatever folks feel like making it. Mixing the two 
>confuses both.

Fully agree. I am proposing staying silent on heuristics in the core 
protocol, not banning them. Does that work for you?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Apr 2006 08:40:18 -0700

At 8:49 AM -0400 4/30/06, Tony Hansen wrote:
>Ummm, we don't currently run a hash of the headers, just the body.

Umm, yes we do. See section 3.7:
    In hash step 2, the signer or verifier MUST pass the following to the
    hash algorithm in the indicated order.

Digital signature algorithms almost always encrypt a hash of the 
data, not the data itself, because the encryption and decryption 
steps are so expensive.

>We

A verifier using heuristics (not specified in the spec) would do the following:

1) Look at the hash in the signature.

2) Marshall the hash as specified in dkim-base.

3) Perform the hash function. See if the result is the same as the 
one from step 1.
3a) If yes, go to step 5.
3b) If no, go to step 4.

4) Modify the verifier's internal view of the message in some 
heuristic way and marshall the hash. Go to step 3.

5) Check that the signature over the hash in the message verifies.

Again, steps 3a and 4 should not be in the base spec, but they should 
also not be prohibited by the base spec.

>This particular suggestion hasn't received any traction as yet.

Nor should it. The header format in base-01 is fine for the 
cryptography involved.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Apr 2006 08:49:41 -0700

>> latter is whatever folks feel like making it. Mixing the two confuses 
>> both.

silence would be, ummm, golden.

an added benefit would be that we could all stop talking about them in 
this standards process...

d/

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 30 Apr 2006 12:09:50 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, April 30, 2006 11:26 AM
Subject: Re: [ietf-dkim] Re: What the verifier can do

> protocol, not banning them. Does that work for you?

Define heuristics.

Keep in mind that saying such things:

    "... considered Invalid"

is an heuristic.

    "Treat as If unsigned"

is an heuristic, and by its very virtue it is helping to define "rules" for
local policy that quite frankly won't make send when the goal is to general
control, dare I say, "mail pollution."

The problem I have is that what you are proposing isn't a protocol.  In my
view, what is being confused is "real mechanical" deterministic protocol
concepts such as:

     - Syntax failures,
     - Incorrect usage,
     - Unauthorized usage,
     - Not honoring protocol attributes, (i.e, expiration x=)
     - Interoperability failures,

etc, etc, etc.

When the base is written so vague for the sake of purity and simplicity, it
promote chaos and confusion and inconsistencies down the road.

What is patently different now is that we want domains to inherit a new
responsibility by signing messages.  To what end when we have a spectrum of
different verifier behaviors?  Is there no risk here for the domain?  Why
would it want to put its reputation on the line here?

You need a baseline here where all verifiers are expected to honor and
support.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 30 Apr 2006 12:19:31 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, April 30, 2006 11:49 AM
Subject: Re: [ietf-dkim] Re: What the verifier can do

> this standards process...

Well, that isn't realistic.

There are too many inconsistencies and problems with the base specs and most
of the resolution will be based on what one thinks how the world should
work - heuristically.

If the specs was indeed more "mechanical" - spokes and wheels, leg bone
connected to the hip bone, etc, that really have nothing to do with your
opinion, then you might have a chance and less pressure to use "heuristics"
to resolve its many inconsistencies.

DKIM is a, dare I say, an unprotected protocol, and signature authorization
and usage will play a vital role for verifiers to help protect the "new
responsibility" you have placed on domains.

Lack there of, simply adds to more mail pollution and the victims will be
verifiers and the domains who won't have confidence in expecting a
consistent set of "heuristics" in the network.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 30 Apr 2006 10:24:09 -0700 (PDT)

On Sun, 30 Apr 2006, Paul Hoffman wrote:

> Digital signature algorithms almost always encrypt a hash of the data, not 
> the data itself, because the encryption and decryption steps are so 
> expensive.
>
>> We

If I understand technology correctly the DKIM indeed does not contain
full hash and only RSA1 signed version of that. Yes, that is unusual
as most signature protocols such as SMIME do contain the hash (and so
does META as it was designed to be more like header-based SMIME in the 
form and extendeability). So I obviously believe it is wrong that you 
chose such minimalistic approach - what you see  here (such as
inability to verify only hash) is just one of those consequences.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Apr 2006 10:58:27 -0700

Paul Hoffman <[email-masked]> writes:

> Digital signature algorithms almost always encrypt a hash of the data,
> not the data itself, because the encryption and decryption steps are
> so expensive.

I know it's pedantic, but it's important: digital signature algorithms
*sign* the hash. They do not, in general, encrypt it. It's true that
signature and encryption are similar in RSA, but they're not the same
in (e.g., DSA). Also, while the performance reason is important,
it's not the only reason. Because signature algorithms can only
process small chunks of data, a digest lets you sign large blocks
without having to worry about gluing together the signatures somehow.

> 3) Perform the hash function. See if the result is the same as the one
> from step 1.

This procedure only works if either:

(1) You place a copy of the message digest in the DKIM headers.
    Based on my reading of draft-allman-*, this is not the case
    in DKIM. It's not the case in S/MIME either, AFAIK.
(2) You have a signature algorithm with message recovery
    (meaning that you can extract the hash from the signature).
    Again, this is only true of RSA.

Otherwise you need to do a full signature verification for each
trial manipulation.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Apr 2006 11:19:58 -0700

>without having to worry about gluing together the signatures somehow.

Pendantry accepted. But, in this case, the only signature algorithm 
we have defined is RSA.

>Otherwise you need to do a full signature verification for each

Correct. #2 applies here because we have only defined RSA.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Apr 2006 11:22:07 -0700

Paul Hoffman <[email-masked]> writes:

> Pendantry accepted. But, in this case, the only signature algorithm we
> have defined is RSA.

Yes, but it's a bad idea to design systems assuming that's going
to be the only algorithm you ever use. 

>>Otherwise you need to do a full signa ture verification for each
>>trial manipulation.
>

Sure, but what happens when you want to use ECDSA because you're
worried about key size constraints? Digital signature algorithms
really should be treated as black boxes, rather than modelled as
RSA.

-Ekr

---

From: Tony Hansen <[email-masked]>
Date: Sun, 30 Apr 2006 14:41:46 -0400

Paul Hoffman wrote:
> not the data itself, because the encryption and decryption steps are so
> expensive.
> 
>> We

Paul, which hash where? There is no hash in the dkim signature for the
headers, only a hash for the body and the resulting signature.

Now, *if* there were a header hash in the signature, each of your other
steps 2-4 would be accurate. But there isn't, which is why the algorithm is:

   1)	calculate the body hash
   2)	verify the hash of the body
	2a) if desired, apply heuristics to body and repeat from 1
   3)	verify the signature using RSA
	3a) if desired, apply heuristics to headers and repeat from 3

If you're going to apply heuristics to the headers, you can't get away
from recalculating the RSA signature after each application of the
heuristics.

	Tony Hansen
	[email-masked]

> 4) Modify the verifier's internal view of the message in some heuristic
> way and marshall the hash. Go to step 3.
> 
> Nor should it. The header format in base-01 is fine for the cryptography
> involved.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Apr 2006 12:16:44 -0700

>how resilient you could be to changes incurred through a mailing list.

Yep, and in fact I only compute exactly one message hash that I do the
RSA verify with, not multiple. Which isn't to say that other heuristics 
might
require more than one.

I have to say that I'm a little confused by this thread. Nobody's suggesting
that we change the spec to include any of this are they?

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 30 Apr 2006 12:19:51 -0700 (PDT)

>    Again, this is only true of RSA.

Doesn't that require public key to be able to get hash out of RSA 
signature (and in fact requires doing RSA crypto which "expensive")? 
And isn't this system working only because you're basicly using reverse
of original RSA for purposes of digital signatures?

Although I suspect for programmer optimization its not quite as bad as
I originally thought. If you have original data in "z" and you know 
something has been changed, you can in parallel do calculation of hashes 
(based on original values and if you really want of the header data
in the messge) while at the same time in paraller running decryption. 
Then in the end the values are all verified which is simple and quick 
operation. But the slowest point here is probably getting public key
from dns; it would have been possible to  optimize this 3 way-parallel 
if public key was in the signture (i.e. then do RSA crypto, do hash and 
get public key or fingerprint all at same time and then 2 comparisons of 
the results).

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Apr 2006 12:22:41 -0700

>from recalculating the RSA signature after each application of the
I think you're both saying the same thing. The RSA verify operation yields
a hash that you compare against the hash of the headers (and body from bh).
I think that's what Paul is referring to.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Apr 2006 12:29:15 -0700

> signature (and in fact requires doing RSA crypto which "expensive")?

Yes, you need the public key to do message recovery with RSA.
And yes, it's expensive to do the RSA crypto, but you would
only need to do it once--to extract the hash and then you
can use the hash from there on in.

> of original RSA for purposes of digital signatures?

I'm not sure I'd call it "reverse of original RSA". Yes, this
only works because RSA allows message recovery. That's why I
think it's a bad design choice.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Apr 2006 13:41:40 -0700

>to be the only algorithm you ever use.

We are explicitly *not* designing this system to use heuristics that 
would cause multiple rounds. My assertion is that if an 
implementation wants to do it, it can. Along with that assertion is 
the fact that, with all the algorithms defined in the document and 
the assumption that we are unlikely to change them except in a 
cryptographic emergency, the expensive operations (asymmetric signing 
and verifying) only need to happen once.

>worried about key size constraints?

Then you decide if your actions that go beyond the spec are worth it 
for you in terms of effort.

At 12:22 PM -0700 4/30/06, Michael Thomas wrote:
>...snip...
>I think you're both saying the same thing.

We are not, I believe.

>The RSA verify operation yields

It is. At that point, you know what hash was signed. You then compare 
the hashes you get with your heuristics (if you are using them...) 
against that one hash.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Apr 2006 13:50:48 -0700

Paul Hoffman <[email-masked]> writes:

> would cause multiple rounds. My assertion is that if an implementation
> wants to do it, it can. Along with that assertion is the fact that,
> with all the algorithms defined in the document and the assumption
> that we are unlikely to change them except in a cryptographic
> emergency, the expensive operations (asymmetric signing and verifying)
> only need to happen once.
>

Better to design a system that doesn't require people to make
that kind of tradeoff. In this case, that could be easily
done by including a copy of the unsigned digest along with
the signature.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Apr 2006 18:14:33 -0700

>done by including a copy of the unsigned digest along with
If we ever move to a new signing algorithm that doesn't encrypt like RSA
does, it seems like that might be a worthwhile thing to do. As it stands 
now,
we don't have the need so it would probably not do much more than add
confusion.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Apr 2006 18:17:20 -0700

Michael Thomas <[email-masked]> writes:
> does, it seems like that might be a worthwhile thing to do. As it
> stands now,

That's fine, but if we believe that in order to have an operational
system you're going to need to be able to do signature message 
recovery in some way, I think that needs to be explicitly stated
somewhere, not just left silent.

-Ekr