I'm starting a separate thread for the considered intro text discussion.
This response attempts to provide DKIM in-scope justification why two
additional outputs should be part of a more DKIM Complete Output
summary.
Murray S. Kucherawy wrote:
That's probably true, but that is also
Murray S. Kucherawy wrote:
-Original Message-
But what it did most of for me (yesterday) was highlight the confusion
with AUID with the lack of an official DKIM label for an Originating
Domain Identity. I guess I was moving forward the past year with
integrating DKIM into our mail
John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes the
recipient's
Murray S. Kucherawy wrote:
How will you state it?
How about:
1. Introduction
[...]
1.1. DKIM Architecture Documents
Readers are advised to be familiar with the material in [RFC4686]
and [RFC5585] and [RFC5863], which respectively provide the background
for the development of
Dave CROCKER wrote:
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for
the specification to suggest dealing with it.
At least, please show working group rough consensus support for doing
what you
On 01/May/11 06:18, John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially or completely changes
I don't think we actually understand all the ways that l= allows you to
shoot yourself in the foot, so I would prefer not to give the impression
that if people avoid a few cases we describe, they're safe.
-1, I agree we don't know all the ways DKIM can be fooled. Neither we
actually saw
Dave CROCKER wrote:
On 4/30/2011 9:10 PM, Hector Santos wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This identity
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE IMPLEMENTATION NOTE: Using body length
limits
Alessandro Vesely wrote:
On 01/May/11 06:18, John R. Levine wrote:
What's your counter-proposal to Alessandro's proposal to modify 9.1.1?
Oh, that. Replace all of sec 9.1 with:
As noted in Section 4.4.5, use of the l= tag enables a variety of
attacks in which added content can partially
Michael Thomas wrote:
Dave CROCKER wrote:
On 4/30/2011 9:10 PM, Hector Santos wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From:
Hector Santos wrote:
Murray S. Kucherawy wrote:
Hector stated:
I think this message by Barry in March 2009 summarizing a conference
call between Pasi, Stephen and Barry nicely captures the upper/lower
layers, ADSP, i= and outputs conflicts that continue today:
On 4/30/11 10:37 PM, Murray S. Kucherawy wrote:
-Original Message- From: Hector Santos
[mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM
To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re:
[ietf-dkim] Output summary - proposing ODID Originating Domain
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Sunday, May 01, 2011 4:51 PM
To: Michael Thomas
Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary - proposing ODID
Is this new text for section 9.1 Misuse of Body Length Limits (l= Tag)?
Murray S. Kucherawy wrote:
INFORMATIVE IMPLEMENTATION NOTE: Using body length
limits enables an attack in which an attacker modifies a
message to include content that solely benefits the
attacker. It is
-Original Message-
From: Hector Santos [mailto:hsan...@isdg.net]
Sent: Sunday, May 01, 2011 5:33 PM
To: Murray S. Kucherawy
Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain
Identity
Here is the correct
Hello all,
As you know WGLC for our two open drafts closed yesterday.
The MLM draft hasn't changed in this round, so the -08 version can be
considered the output of the WGLC for that draft.
I'm in the process of posting an -09 for RFC4871bis, which I believe is the
WGLC output for that draft.
Murray S. Kucherawy wrote:
-Original Message-
Its just really odd that the we need to hide the facts in RFC4871bis
but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment
Guideline)?
I've lost track of how many times and how many different ways
it's been explained
Murray S. Kucherawy wrote:
-Original Message-
Here is the correct message link:
Status and direction
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html
That message (a) was sent six months before ADSP was published,
and (b) was written at a time when ADSP still
The new section 1.1 DKIM Architecture Documents advises reading
RFC5585 (DKIM Service Architecture) and RFC5863 (Deployment
Guideline). The new 3.9 Output Requirement does not provide the
essential piece (RFC5322.From) explicitly described by the advised
DKIM related RFC documents.
A simple
On 5/1/2011 6:36 PM, Murray S. Kucherawy wrote:
I've lost track of how many times and how many different ways it's been
explained that nothing is being hidden. I'm going to give up now.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Dave CROCKER wrote:
On 5/1/2011 6:36 PM, Murray S. Kucherawy wrote:
I've lost track of how many times and how many different ways it's been
explained that nothing is being hidden.
+1
Good. So there should not be a problem *not* hiding an explicit
identity definition required to
22 matches
Mail list logo
