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 w
--On 15 October 2010 11:53:51 -0400 Dave CROCKER 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
>> h=from:from:to:to:
>
>
> This would mean that it is /ne
On Fri, 15 Oct 2010 15:48:05 +0100, Ian Eiloart 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 message to thi
On Fri, 15 Oct 2010 17:50:33 +0100, Murray S. Kucherawy
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] detect
On Fri, 15 Oct 2010 17:47:24 +0100, Jim Fenton 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 to sign a
On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos 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, if
>
On Fri, 15 Oct 2010 17:45:22 +0100, Michael Thomas 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 from t
On Fri, 15 Oct 2010 18:04:22 +0100, Murray S. Kucherawy
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 its sole intend
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 wrote:
>
>> This probably means that it should clarified what that 5.4 sentence
>> means and also the next section 5.5
>>
>>
On 10/18/2010 3:31 AM, Ian Eiloart wrote:
> --On 15 October 2010 11:53:51 -0400 Dave CROCKER 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
>>> h=from:from:
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 CROCKER wrote:
> >> On 10/15/2010 11:40 AM, Mark Delany wrote:
> >>> Well, if you want to introduce semantic changes why not just c
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 quot
> 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
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
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
> 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 ran
> -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 re
> -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, F
> -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
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 Mark Delany
> Sent: Friday, October 15, 2010 11:39 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Data integrity claims
>
> So anything that circumvents "what you
> -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 si
> -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 curr
> -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 anythi
> -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:26 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Data integrity claims
>
> > -Original Message-
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 atta
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
> > Subjec
> -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 MUA
> -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-
> -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 [mailto:ietf-
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
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
> t
> -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
>
> > Irrelev
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 mutation
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 t
> -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 relat
Merely detecting that an incoming message is malformed (e.g. two From:
fields, whether or not either was signed) and refusing to verify it is
insufficient, because that has the net effect of setting a bit that the
MUA likely won't even check, ...
This is getting awfully overcomplicated. One of
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
>> 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 ha
> -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
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 chang
>> 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
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
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
>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:
"@ (n
John Levine wrote:
>> OTOH, we already have a SHOULD that tells MUA writers
>> to splatter the d= field somewhere in the GUI where the user
>> can't ignore it
>
> Ugh, you're right. Now that I look at it, I'd like to completely
> delete Appendix D, since it says some things that are just wrong,
51 matches
Mail list logo
