Paul Hoffman wrote:
Greetings again. This follows up on the desire to allow multiple
signatures in the same message.
As a point of order, multiple signatures in the same message work just
fine today. It should be noted that this is a proposal for enhancing
multiple signatures.
This must
be do
This must
be done in a way to prevent bid-down attacks during transitions,
I believe that Mark also has a proposal on the table for how to deal
with bid-down attackes.
And actually, as I recall the discussion in Dallas it seems that even
Russ and EKR were not worried about this issue. The i
Barry Leiba wrote:
This must
be done in a way to prevent bid-down attacks during transitions,
I believe that Mark also has a proposal on the table for how to deal
with bid-down attackes.
And actually, as I recall the discussion in Dallas it seems that even
Russ and EKR were not worried ab
Someone else had suggested adding some sort of signature sequence
field, which, if we did that, could robustly identify the order, and
could make is clear which are missing. Something like this:
DKIM-Signature: seq=3,1,1; ...
DKIM-Signature: seq=2,2,2; ...
DKIM-Signature: seq=2,1,2; ...
Barry Leiba wrote:
Well, the issue is that if, say with the above example, signer #3 signs
the other three signature headers, and then the next hop re-orders them,
the verifier can still figure out which records signed which others.
So what?
There are many "interesting" things that we might
The only interesting think dkim does is ensure that the message the
receiver see's actually was sent by the purported publisher of that
internet bitstream. Who has seen it before offers nothing of interest.
thanks
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-639
Well, the issue is that if, say with the above example, signer #3
signs the other three signature headers, and then the next hop
re-orders them, the verifier can still figure out which records signed
which others.
So what?
So the signature can survive the reordering; it's essentially a helpe
Barry Leiba wrote:
Well, the issue is that if, say with the above example, signer #3
signs the other three signature headers, and then the next hop
re-orders them, the verifier can still figure out which records
signed which others.
So what?
So the signature can survive the reordering; i
On Mar 31, 2006, at 10:31 AM, Dave Crocker wrote:
Barry Leiba wrote:
Well, the issue is that if, say with the above example, signer #3
signs the other three signature headers, and then the next hop re-
orders them, the verifier can still figure out which records
signed which others.
So
On Mar 31, 2006, at 11:15 AM, Douglas Otis wrote:
This approach would be far simpler, as in most cases it would be a
static bit of information, such as "w=S" (primary) or
"w=s" (secondary) or "w=d" (mda).
Small mistake. If Upper case is used to denote primary, then for
consistency, the
Paul Hoffman wrote:
> Interesting issues; see below.
>
> At 4:54 PM -0800 3/30/06, Jim Fenton wrote:
>> > The hash is computed using the hash algorithm
>> > that is used in the signing algorithm (taken from the "a=" tag),
>>> using "simple" header canonicalization on the DKIM-Signat
Mark Delany wrote:
> I agree that 'simple' is the easiest - in the original DomainKeys
> drafts there was a sample perl implementation that took 4 or 5 lines
> of code. Unfortunately because sendmail milter has a bug (that SMI
> have promised to fix) some of those who are bound by milter
> implemen
Barry Leiba <[EMAIL PROTECTED]> writes:
>>> This must
>>> be done in a way to prevent bid-down attacks during transitions,
>> I believe that Mark also has a proposal on the table for how to deal
>> with bid-down attackes.
>
> And actually, as I recall the discussion in Dallas it seems that even
>
> My question was much more basic: what useful thing would a receiver do
> differently if it knew the order in which signatures were applied? I
> really can't think of anything.
I can't think of anything either. I don't think we should add this
additional complexity.
--
Arvel
_
> The goal is to ensure when there are two signatures added to the
> message, an attacker does not toss out the stronger signature in order
> to exploit the weaker signature added within a transition period.
I think that we should leave this to the verifier. If the verifier is
uncomfortable acc
> Mark Delany wrote:
> > I agree that 'simple' is the easiest - in the original DomainKeys
> > drafts there was a sample perl implementation that took 4 or 5 lines
> > of code. Unfortunately because sendmail milter has a bug (that SMI
> > have promised to fix) some of those who are bound by milter
[EMAIL PROTECTED] wrote:
Mark Delany wrote:
I agree that 'simple' is the easiest - in the original DomainKeys
drafts there was a sample perl implementation that took 4 or 5 lines
of code. Unfortunately because sendmail milter has a bug (that SMI
have promised to fix) some of those who are
On Fri, Mar 31, 2006 at 02:25:49PM -0800, [EMAIL PROTECTED] allegedly wrote:
> And let's please not forget that even if this got fixed tomorrow the amount of
> time it takes to significantly deploy new MTA versions is very long - far
> longer than we can afford to wait.
I'm confused. We expect wi
Mark Delany wrote:
On Fri, Mar 31, 2006 at 02:25:49PM -0800, [EMAIL PROTECTED] allegedly wrote:
And let's please not forget that even if this got fixed tomorrow the amount of
time it takes to significantly deploy new MTA versions is very long - far
longer than we can afford to wait.
On Mar 31, 2006, at 2:18 PM, Arvel Hathcock wrote:
The goal is to ensure when there are two signatures added to the
message, an attacker does not toss out the stronger signature in
order to exploit the weaker signature added within a transition
period.
I think that we should leave this t
20 matches
Mail list logo
