Hi Jim,
Here are some comments on the threats draft which looks to me
like a very good start.
The main one is the stuff about the structure, most of the others
are much less of a deal, and that was already raised so there's
not too much new here.
If you've time to take some of these into accou
I'm interested in hearing people's thoughts on how they think DKIM could be extended (likely in a post 1.0 release I know) to support reputation and accreditation systems.
From past conversations, it seems the abililty to limit third party signing to a particular list of third parties would be im
Stephen and I have put together a proposed agenda, and talked it over
with Jim and Eric, who we've asked brief presentations of. Here's what
we propose. When you look at it, keep in mind that the goal of this
BOF is to decide whether or not to form a Working Group, and if the
answer to that is "Y
Douglas Otis wrote:
When the From/Sender headers do not represent the actual
sender, such messages may be forfeit had the domain contained within the
From/Sender published close-ended authorizations. SSP policies reduce
delivery integrity for other senders! : (
I don't agree. I believe the
Stephen,
2. There should be a complete analysis, including threats caused by/to the DKIM
protocol. There is in fact some text along these lines (see the nits below),
but we should include as much as we can here.
I have been a strong supporter of doing the threat analysis and doing it
before c
Ah - bit of confusion there - I'm asking that the fuller analysis
be done for Feb, not before starting work.
S.
Dave Crocker wrote:
Stephen,
2. There should be a complete analysis, including threats caused by/to
the DKIM
protocol. There is in fact some text along these lines (see the nits
b
On Wed, Oct 19, 2005 at 10:21:54AM -0400, Barry Leiba allegedly wrote:
> I argue that "sensitive transactions" are not what DKIM is about. If
> one wants to protect sensitive transactions, one should use S/MIME or
> OpenPGP.
I'm not sure what term to use - "sensitive" seems insufficient - but
cl
Oh drat!
I just posted a half-written response and did not mean to. Please just
ignore it. I want to talk with Stephen offline before burdening the
list with more of this exchange.
A thousand apollogies.
d/
Dave Crocker wrote:
Is it ok with folks to be required to replace essentially
On Oct 19, 2005, at 7:21 AM, Barry Leiba wrote:
Douglas Otis wrote:
When the From/Sender headers do not represent the actual sender,
such messages may be forfeit had the domain contained within the
From/Sender published close-ended authorizations. SSP policies
reduce delivery integrity
I do have one practical suggestion for the list.
Unless it is intentional to promote DKIM mailing list broken signature
problem solving, how about removing the unnecessary footer and any other
body alteration in the IETF-DKIM distribution?
I would think this forum might become a good test bed and
Either that or add DKIM support and resign the broken DKIM signed messages
on the list.
Once there is a DKIM standard, having the list sign messages is a swell
idea. Until then, we'll leave the list alone.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for
Dum
Stephen and I have put together a proposed agenda,
and talked it over with Jim and Eric, who we've asked
brief presentations of.
I think the agenda is workable and I'm very pleased that the focus will be
on WG formation and charter rather than arguing endlessly over DKIM
mechanics.
I'm hopef
What world calamity is created by removing the footer?
This list would be a great source for developers to do exploration and
testing as we did early on until footers were added thereby breaking the
integrity of the DKIM mail. The test bed and resource of various DKIM
signing domain was now remove
But what about the addition of [ietf-dkim] to the subject lines if it
isn't already there? That will break signatures as well (since just
about everyone signs Subject) but not adding [ietf-dkim] will likely
break mail filtering for some folks.
-Jim
Hector Santos wrote:
What world calamity
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
> But what about the addition of [ietf-dkim] to the subject lines if it
> isn't already there? That will break signatures as well (since just
> about everyone signs Subject) but not adding
I'm catching up, so pardon me if I didn't see a response to Dave's
question on
this too:
Stephen Farrell wrote:
t this that there'll be (though there'll always be some:-)
But, I think the charter text is fine btw.
Is it ok with folks to be required to replace essentially all of the
current
On October 19, 2005 at 15:13, "Hector Santos" wrote:
> 1) The signer can use the z= tags to save the header signing data.
Unfortunately, the verification algorithm, as it is currently designed,
does nothing with z=. I think z= needs to be reconsidered, as
I have noted awhile back (probably on ie
On October 18, 2005 at 18:53, "Arvel Hathcock" wrote:
> > This behavior raises a security problem since such
> > senders will go with policies that lean towards
> > delivery versus potential security threats.
>
> If I'm understanding you rightly you are arguing against the o=~ or
> "relaxed" pol
On October 19, 2005 at 10:29, Douglas Otis wrote:
> This opportunistic approach can be improved by specifying the role of
> the signer, such as:
>
> - Originating
> - Resending
> - Verifying
Is "Resending" only for entities that "re-submit" a message into
the transit system? Would pass-
Earl Hood wrote:
As I have argued before, allowing 3rd-party signatures open you up
to general spoofing by malicious domains (as DKIM SSP is currently
defined).
There's a difference between allowing their existence and relying on them
in the same fashion as a first party signature. I think
On Wed, 19 Oct 2005, Michael Thomas wrote:
The only way to have the length specifier not be a security
vulnerability is to require all verifiers to strip all content that
exceeds the length.
Which is to say that today (eg, pre-DKIM), any inbound MTA ought to strip
all content.
Correct?
I'm
william(at)elan.net wrote:
On Wed, 19 Oct 2005, Michael Thomas wrote:
The only way to have the length specifier not be a security
vulnerability is to require all verifiers to strip all content that
exceeds the length.
Which is to say that today (eg, pre-DKIM), any inbound MTA ought to
strip
On Wed, 19 Oct 2005, Earl Hood wrote:
On October 19, 2005 at 10:29, Douglas Otis wrote:
This opportunistic approach can be improved by specifying the role of
the signer, such as:
- Originating
- Resending
- Verifying
Is "Resending" only for entities that "re-submit" a message into
th
On Wed, 19 Oct 2005, Michael Thomas wrote:
william(at)elan.net wrote:
On Wed, 19 Oct 2005, Michael Thomas wrote:
The only way to have the length specifier not be a security
vulnerability is to require all verifiers to strip all content that
exceeds the length.
Which is to say that today (
On October 19, 2005 at 14:43, Michael Thomas wrote:
> Er, um, oh bother. The point being that currrently mail is not signed
> yet we somehow limp on without stripping "extra" content.
But DKIM adds a new dynamic and semantics.
As has been argued (successfully) on these lists is that an attacker
On October 19, 2005 at 14:18, Michael Thomas wrote:
> >As I have argued before, allowing 3rd-party signatures open you up
> >to general spoofing by malicious domains (as DKIM SSP is currently
> >defined).
>
> There's a difference between allowing their existence and relying on them
> in the same
On Oct 19, 2005, at 2:22 PM, Earl Hood wrote:
On October 19, 2005 at 10:29, Douglas Otis wrote:
This opportunistic approach can be improved by specifying the role of
the signer, such as:
- Originating
- Resending (remailing)
- Verifying
Is "Resending" only for entities that "re-sub
Hector Santos wrote:
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
But what about the addition of [ietf-dkim] to the subject lines if it
isn't already there? That will break signatures as well (since just
about everyone signs S
- Original Message -
From: "Earl Hood" <[EMAIL PROTECTED]>
To:
> On October 19, 2005 at 15:13, "Hector Santos" wrote:
>
> > 1) The signer can use the z= tags to save the header signing data.
>
> Unfortunately, the verification algorithm, as it is currently designed,
> does nothing with z
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> 2) I suggest all removing mail alteration to help the project.
>>
> I agree that it would be a great idea to have a mailing list that
> re-signs messages in order to get some experience
Stephen Farrell wrote:
Hi Jim,
Here are some comments on the threats draft which looks to me
like a very good start.
The main one is the stuff about the structure, most of the others
are much less of a deal, and that was already raised so there's
not too much new here.
If you've time to take
31 matches
Mail list logo
