On 16/Oct/10 21:24, John R. Levine wrote:
Which header fields are essential to protect?
How much of the message body is essential to protect?
Your questions are noted. Other than the MUST to sign the From:
header, the DKIM spec offers the technical latitide to create a
totally worthless
On Fri, 15 Oct 2010 15:48:05 +0100, Ian Eiloart i...@sussex.ac.uk wrote:
Here's a more interesting attack:
Compose an email apparently from eBay, and send it to yourself. Get a
valid
DKIM signature, then add a From: header containing an eBay address, and
use
the replay to send that
On Fri, 15 Oct 2010 17:50:33 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
Sent: Friday, October 15, 2010 7:30 AM
To: DKIM
Subject: Re: [ietf-dkim]
On Fri, 15 Oct 2010 17:47:24 +0100, Jim Fenton fen...@cisco.com wrote:
On 10/15/10 6:06 AM, Charles Lindsey wrote:
I don't quite see what an attacker can usefully do by modifying messages
in transit. If they message was already signed (say by ebay), then the
attacker must somehow get ebay
On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos hsan...@isdg.net wrote:
This probably means that it should clarified what that 5.4 sentence
means and also the next section 5.5
5.5. Recommended Signature Content
..
The following header fields SHOULD be included in the signature,
On Fri, 15 Oct 2010 17:45:22 +0100, Michael Thomas m...@mtcc.com wrote:
On 10/15/2010 06:51 AM, Charles Lindsey wrote:
And yet the current protocol will allow an evil mail _apparently_ from
Ebay to appear, with no means for the recipient to detect the
difference.
They're not apparently
On Fri, 15 Oct 2010 18:04:22 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
This to me says you still believe DKIM's ultimate payload is something
other than a validated identifier, in this case a domain name. We're
thus not on the same page.
If instead we do agree that that's
Charles, I was showing what already is written and suggesting that it
might need clarification.
Charles Lindsey wrote:
On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos hsan...@isdg.net wrote:
This probably means that it should clarified what that 5.4 sentence
means and also the next
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
--On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to be semantically identical to
On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote:
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
--On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote:
On 10/15/2010 11:40 AM, Mark Delany wrote:
Well, if you want to introduce semantic changes why not
SM wrote:
Hi Hector,
At 09:28 16-10-10, Hector Santos wrote:
From an IETF procedural angle. :)
I'll comment on how I read what the WG Chairs said in general terms. If
you believe that the process followed is not fair, you could discuss the
matter with the WG Chairs. I'll quote a
Well, if you want to introduce semantic changes why not just change
the meaning of h=from:to: to be semantically identical to
h=from:from:to:to:
...
I assumed that the proposal applied only to headers rfc5322 says cannot be
duplicated.
That is a constraint that was not stated.
It is now.
Mark Delany:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I see are the
ones that paypal sent. No more, no less.
But the user does not see a bunch of
Wietse Venema wrote:
Mark Delany:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I see are the
ones that paypal sent. No more, no less.
But the user
result of software layers that render those bits. DKIM has no
control over that rendering process.
Really? Do you mean doesn't or shouldn't or can't?
Apropos layering violations: are we saying that having a UA inject
message 'A' via a DKIM layer into the mail stream, and then having
some
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John Levine
Sent: Friday, October 15, 2010 7:14 PM
To: ietf-dkim@mipassoc.org
Cc: dcroc...@bbiw.net
Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Friday, October 15, 2010 11:19 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] DKIM and patents
On Sat, Oct 16, 2010 at 02:54:13PM +1200, Franck
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Saturday, October 16, 2010 8:37 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-04.txt
I have two
Mark Delany:
But the user does not see a bunch of bits. The user sees the combined
result of software layers that render those bits. DKIM has no
control over that rendering process.
Really? Do you mean doesn't or shouldn't or can't?
Does DKIM control text-to-voice conversion, or
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of MH Michael Hammer (5304)
Sent: Saturday, October 16, 2010 10:43 AM
To: Wietse Venema; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Saturday, October 16, 2010 11:56 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims
The current DKIM
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Sunday, October 17, 2010 6:23 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Data integrity claims
By DKIM process, I would include anything
On 10/18/2010 11:01 AM, Wietse Venema wrote:
Does DKIM control text-to-voice conversion,
...
Obviously these two are among the more lossy transformations. But
even text-to-screen conversion,
...
Folks,
This is all slightly surreal.
There is a premise that is motivating the proponents of
-Original Message-
From: MH Michael Hammer (5304) [mailto:mham...@ag.com]
Sent: Monday, October 18, 2010 11:44 AM
To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: RE: [ietf-dkim] Data integrity claims
There's nothing between an MTA and an MUA that prevents this attack in
On Monday, October 18, 2010 02:19:06 pm Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman
Sent: Saturday, October 16, 2010 11:56 AM
To: ietf-dkim@mipassoc.org
Subject: Re:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Monday, October 18, 2010 11:50 AM
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] How MUAs render mail
Folks making assertions about what MUAs
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy
Sent: Monday, October 18, 2010 2:51 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Data integrity claims
-Original Message-
From:
-Original Message-
From: MH Michael Hammer (5304) [mailto:mham...@ag.com]
Sent: Monday, October 18, 2010 12:11 PM
To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: RE: [ietf-dkim] Data integrity claims
See above. This leads me to believe that you might be amenable to
I'm trying to find a way for us to build a consensus on how to move
forward.
While I have tended towards favoring a normative approach, you are
swaying me with this amazing Security Considerations addendum.
Mike
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
On 10/18/10 6:49 AM, Wietse Venema wrote:
Mark Delany:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I see are the
ones that paypal sent. No more, no
MH Michael Hammer (5304) wrote:
This is no more presumptuous than expecting that MUAs will adapt to
consume the output of DKIM as it stands now. The question is the value
equation. I'm not in a position to answer that question. Perhaps we
should try to get some of the MUA folks to join the
Murray S. Kucherawy wrote:
Current implementations, especially the two library ones that
are referenced most often in here, haven't the functionality to
cause header fields to be removed, prefixed, reordered, modified,
etc. This change would require them to be overhauled to extend
their
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, October 18, 2010 4:24 AM
To: DKIM
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after signing
Irrelevant for
FWIW, the telnet mail interface typo fix should be:
telnet bbs.winserver.com
--
HLS
Hector Santos wrote:
I'm a MUA author of BOTH types and people forget that there are TWO
kinds here. We have:
Console based Mail Reader/Writers Online Interface (Dialup/Telnet)
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, October 18, 2010 4:24 AM
To: DKIM
Subject: Re: [ietf-dkim] layer violations, was detecting header mutations
after
On 10/18/10 12:18 PM, Murray S. Kucherawy wrote:
This is no more presumptuous than expecting that MUAs will adapt
to consume the output of DKIM as it stands now.
In another message I indicated that I don't presume either, but
assert that there's no middle ground; they will or they
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Douglas Otis
Sent: Monday, October 18, 2010 3:33 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Data integrity claims
Should the charter of a security related
I think most people understand this:
- DKIM SHOULD be checking its input,
- With increase awareness, the backend MTA receivers SHOULD
checking for these Special RFC5322 multiple header issues.
Whether SHOULD should be changed to MUST is not a concern to me,
either way, there is
What is the value proposition that DKIM offers that incentivizes people
to adopt it?
I'll take a crack at that: DKIM offers the MUA enough data to know what
parts of a message to be rendered can be considered valid inasmuch as
someone (the signer) took responsibility for it.
I have to
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Monday, October 18, 2010 5:25 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
Also, although I certainly do not purport to be a whiz at UI
John R. Levine wrote:
So, uh, can we agree that Jim's SHOULD language to tell people to do
this is a good idea?
Yes. +1. I think I was the first to agree with Jim's input and didn't
see much follow up except you and maybe another person.
Maybe Barry can provide a repeat of the exact change
difference between a green bar SSL page and one with no SSL. I don't want
to mess with the MUA at all, but rather use DKIM to help decide what
messages to show her and which messages to consign to the junk folder.
Why do we think such a sorting module can't/won't have the
intelligence to do
On Oct 18, 2010, at 5:50 PM, John Levine wrote:
difference between a green bar SSL page and one with no SSL. I don't want
to mess with the MUA at all, but rather use DKIM to help decide what
messages to show her and which messages to consign to the junk folder.
Why do we think such a
On 10/18/10 4:15 PM, Murray S. Kucherawy wrote:
On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote:
Should the charter of a security related protocol need to
anticipate minor modifications to a verification process, that
appears essential for ensuring a DKIM signature is not
There's a strong correlation between badly structured emails (SMTP,
MIME, HTML) and email that the recipient doesn't want to see.
You're right, but I think that's largely orthogonal to DKIM. If a
message has a good signature from a credible signer, I expect I'd want
to show it to the user even
FYI:
Maybe there are lurkers here from Network Solutions reading my recent
posts, but the issue with their web-based DNS Records Manager
inability to allow domain customer to make TXT records without a
sub-domain has been resolved.
It was done by allowing a special sub-domain input:
@
46 matches
Mail list logo
