At 14:23 28-02-2007, Stephen Farrell wrote:
issue #1365 calls for eliminating requirement
6.3.2 which says:
" [PROVISIONAL] The Protocol MUST be able to publish a Practice
which is indicative that domain doesn't send mail."
If you want to eliminate that requirement say: +1
If you wan
> [mailto:[EMAIL PROTECTED] On Behalf Of Arvel Hathcock
> I have had some sympathy for this in the past but now I have
> to ask: Are we creating "Sender *SIGNING* Practices" or
> "Sender Practices In General"? Besides, there are already at
> least two other ways with more traction to achieve t
On Feb 28, 2007, at 5:30 PM, Arvel Hathcock wrote:
> What mechanism is there for 'never send mail today'?
Sender ID and NULL MX (draft-delany-nullmx-00.txt)
Ignoring the DDoS problem inherent with Sender-ID, Sender-ID
identifies the IP address used by an SMTP client used in conjunction
w
On Feb 28, 2007, at 4:41 PM, Arvel Hathcock wrote:
This protection depends upon a means for the signer to assert
which algorithm is deprecated, and what shiny new algorithm is
being offered.
That doesn't follow at all. The *receiver* will decide what
algorithms are and are not sufficien
Well I have no intention of ever letting Sender ID in the door and
nullMX is just another dns entry to maintain. I already have DKIM and
SSP I should be able to use either as a method to warn people that I
don't originate mail, I either sign or forward.
thanks
Bill Oxley
Messaging Engineer
Cox Com
> What mechanism is there for 'never send mail today'?
Sender ID and NULL MX (draft-delany-nullmx-00.txt)
Arvel
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Hallam-Baker, Phillip wrote:
We all agree on the transition strategy here.
The question is purely what the policy is capable of expressing. If the
transition strategy means that you are always going to sign twice once with a
key selector of each type then that is what the policy must be capabl
+1 - ditch this fluff.
I have had some sympathy for this in the past but now I have to ask: Are
we creating "Sender *SIGNING* Practices" or "Sender Practices In
General"? Besides, there are already at least two other ways with more
traction to achieve this particular goal.
Arvel
Stephen Fa
> Subject: Re: [ietf-dkim] 1365 yes/no
>
>
> On Feb 28, 2007, at 2:23 PM, Stephen Farrell wrote:
>
> >
> > issue #1365 calls for eliminating requirement
> > 6.3.2 which says:
> >
> > " [PROVISIONAL] The Protocol MUST be able to publish a Practice
> > which is indicative that domain do
On Wed, 28 Feb 2007 22:23:53 + Stephen Farrell
<[EMAIL PROTECTED]> wrote:
>
>issue #1365 calls for eliminating requirement
>6.3.2 which says:
>
>" [PROVISIONAL] The Protocol MUST be able to publish a Practice
> which is indicative that domain doesn't send mail."
>
I want to eliminat
We all agree on the transition strategy here.
The question is purely what the policy is capable of expressing. If the
transition strategy means that you are always going to sign twice once with a
key selector of each type then that is what the policy must be capable of
expressing.
> -Ori
> This protection depends upon a means for the signer to assert which
> algorithm is deprecated, and what shiny new algorithm is being
> offered.
That doesn't follow at all. The *receiver* will decide what algorithms
are and are not sufficient and when to act on that decision. And
besides, th
We are not proposing infrastructure to deal with a catastrophic failure. Dave
has again missed the point.
The purpose here is to allow an orderly transition to a new algorithm over the
space of five years or more.
Without it no transition is practical and the only option would be to wait for
t
Mike, this is what I was trying to say in a previous post. You are
exactly right. We have already faced this situation and it has proven
itself in the field to work just fine.
Arvel
Michael Thomas wrote:
I'm still not seeing what the problem is with things as they stand now.
We've already b
> The problem is that UNLESS you have the ability to tell people that
> your signing practices are transitional the policy language will be
> insufficiently expressive to provide any value.
Seems to me signers will just sign with both algorithms for a period of
time. Regardless of what is expre
-1 == KEEP REQUIREMENT
Stephen Farrell wrote:
issue #1365 calls for eliminating requirement
6.3.2 which says:
" [PROVISIONAL] The Protocol MUST be able to publish a Practice
which is indicative that domain doesn't send mail."
If you want to eliminate that requirement say: +1
If you
-1 keep, I'm with Doug on this
Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas Otis
Sent: Wednesday, February 28, 2007 6:02 PM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: [ietf-dkim]
issue #1365 calls for eliminating requirement
6.3.2 which says:
" [PROVISIONAL] The Protocol MUST be able to publish a Practice
which is indicative that domain doesn't send mail."
If you want to eliminate that requirement say: +1
If you want to keep that requirement say: -1
Remember:
On Feb 28, 2007, at 2:23 PM, Stephen Farrell wrote:
issue #1365 calls for eliminating requirement
6.3.2 which says:
" [PROVISIONAL] The Protocol MUST be able to publish a Practice
which is indicative that domain doesn't send mail."
If you want to eliminate that requirement say: +1
On Wednesday 28 February 2007 10:47, Michael Thomas wrote:
> Does this requirement have support? I've seen no discussion on it that
> I can recall which means that it probably doesn't.
>
>
> Mike
>
> 8. [PROVISIONAL] The protocol MUST have the ability to provide
> practices and
All,
Ok, we're starting to repeat ourselves (as usual;-)
on 1386 and 1365.
Can I ask that we stop discussing now, and move to
dealing with text for in/exclusion in ssp-reqs-03. (Mike
needs this v. soon if he's to make the cutoff.)
Phill - you're the main proponent on 1386 so can you
write a co
I'm not seeing Dave saying that at all. So far as I can tell, he and
everyone else believes in gradual transitions such as the one you
cite.
I think he *is* saying that we have no experience with a nightmare
scenario where some basic algorithm such as RSA is cracked --- not
theoretically or
We have avoided catastrophic failures in the past by designing our systems in
such a way that gradual transition is possible.
For example in 2010 the Server Gated Crypto roots will expire and it will no
longer be possible for a user of a Windows 98 machine with the 40-bit export
encryption stac
At 10:48 AM -0800 2/28/07, Dave Crocker wrote:
It's probably worth noting that a catastrophe with a deployed
algorithm, so that a rapid transition is required, has no precedent
in the large-scale, open Internet, and probably would take
considerably more effort and mechanism than anything we are
Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
The related attack would be as follows: A signer might
deploy a brand-new signature algorithm (I'll call it N) that
very few verifiers can yet handle. The attacker sees this,
and starts forging messages
On Feb 28, 2007, at 10:00 AM, Eric Allman wrote:
--On February 26, 2007 4:23:47 PM -0800 Douglas Otis <[EMAIL PROTECTED]
abuse.org> wrote:
There are more aspects related to DKIM than just signature, hash,
and canonicalization algorithms. At this point, it would be
difficult to predict
Eric Allman wrote:
[By the way, there was also some confusion about whether transitions are
O(years) or O(days). Changing selector records is O(days), whether or
not those selectors change algorithms, but changing algorithms requires
software updates and hence is O(years).]
Important disti
--On February 26, 2007 4:23:47 PM -0800 Douglas Otis
<[EMAIL PROTECTED]> wrote:
On Feb 26, 2007, at 2:31 PM, Eric Allman wrote:
Folks, I've been trying to understand the issues here, and I just
can't seem to wrap my head around it, which means that either (a)
there isn't actually an issue,
Folks,
I have been ruminating on the different kinds of confusion that some/many of
us keep having with discussion about SSP proposals. I keep trying to figure
out what details should be included in a proposal, to make it possible for
everyone to understand it adequately and evaluate it on th
> [mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
> The related attack would be as follows: A signer might
> deploy a brand-new signature algorithm (I'll call it N) that
> very few verifiers can yet handle. The attacker sees this,
> and starts forging messages with invalid signatures
> re
> From: Hector Santos [mailto:[EMAIL PROTECTED]
> Hallam-Baker, Phillip wrote:
>
> > The discussion here is about a REQUIREMENT. How the requirement is
> > achieved is not the issue at this point.
> >
> > Of course since everyone seems to skip straight to the
> implementation,
>
> That is
(For some reason Charles didn't copy the group on his reply to my
message, so I've included the entire thing even though I only have
one comment.
--On February 27, 2007 1:16:05 PM + Charles Lindsey
<[EMAIL PROTECTED]> wrote:
On Mon, 26 Feb 2007 22:31:15 -, Eric Allman
<[EMAIL PROTE
On Wed, 28 Feb 2007 07:51:17 + Graham Murray <[EMAIL PROTECTED]>
wrote:
>Jon Callas <[EMAIL PROTECTED]> writes:
>
>> You can say that you never send mail from a domain with SPF.
>
>SPF operates on the RFC2181 envelope, so with SPF you can state that a
>domain will never legitimately appear in
> [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell
> But even if SPF doesn't provide the exact thing that 1365
> requests, we still have to address whether or not this
> feature is in-scope for DKIM (which is different from wanting
> it done somewhere).
I think that as with 'I am a phis
Graham Murray wrote:
>> SPF operates on the RFC2181 envelope,
> That should, of course, be RFC2821. I do not know
> what I must have been thinking when I wrote that :)
For some time SPF drafts had a normative reference
to RFC 2181 chapter 6 (Zone Cuts). Until Paul Vixie
convinved us that it re
Does this requirement have support? I've seen no discussion on it that
I can recall which means that it probably doesn't.
Mike
8. [PROVISIONAL] The protocol MUST have the ability to provide
practices and expectations keyed off of the local part of the
[RFC2822].From
John doesn't seem to have sent this to the list (maybe because a sent
separate copies to him and to the list).
On Tue, 27 Feb 2007 07:30:03 -, John L <[EMAIL PROTECTED]> wrote:
So you consult the SSP for the signing domain to see whether the
combination of dkim-2, rsa, sha-foo, complicat
On Wed, 28 Feb 2007 00:17:54 -, Jim Fenton <[EMAIL PROTECTED]> wrote:
Paul Hoffman wrote:
You keep saying this without justifying it. Others have shown it to be
wrong. Please stop repeating it or support your statement.
Absent this mechanism, a message which has at least one valid signat
Hallam-Baker, Phillip wrote:
The discussion here is about a REQUIREMENT. How the requirement is
achieved is not the issue at this point.
Of course since everyone seems to skip straight to the implementation,
That is what happens in a mixed discipline environment. :-) Plus there
is 100s if n
On Tue, 27 Feb 2007 13:06:05 -, Stephen Farrell
<[EMAIL PROTECTED]> wrote:
Charles Lindsey wrote:
[big snip describing use of Magic s/w]
And then you have sufficient
information to decide whether it had failed because your Magic software
was inadequate, or because it was a bogus signature
Graham Murray wrote:
Jon Callas <[EMAIL PROTECTED]> writes:
You can say that you never send mail from a domain with SPF.
SPF operates on the RFC2181 envelope, so with SPF you can state that a
domain will never legitimately appear in the SMTP MAIL FROM: (or
EHLO). It offers no mechanism to say
Jim Fenton wrote:
The related attack would be as follows: A signer might deploy a
brand-new signature algorithm (I'll call it N) that very few verifiers
can yet handle. The attacker sees this, and starts forging messages
with invalid signatures referencing the N selector, in hopes that some
Graham Murray <[EMAIL PROTECTED]> writes:
> SPF operates on the RFC2181 envelope,
That should, of course, be RFC2821. I do not know what I must have
been thinking when I wrote that :)
___
NOTE WELL: This list operates according to
http://mipassoc.org/d
Graham Murray wrote:
Jon Callas <[EMAIL PROTECTED]> writes:
You can say that you never send mail from a domain with SPF.
SPF operates on the RFC2181 envelope, so with SPF you can state that a
domain will never legitimately appear in the SMTP MAIL FROM: (or
EHLO). It offers no mechanism to s
44 matches
Mail list logo
