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 complet
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 o
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
> recip
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 d
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
> wha
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 c
>> 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
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. Thi
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:
>
> INFORMATIVE IMPLEMENTATION NOTE: Using body length
> limit
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 c
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
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:
>>>
>>> http:
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 Do
> -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 O
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.
> -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
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 exp
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 whe
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 ch
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