> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Barry Leiba
> Sent: Thursday, May 05, 2011 1:55 PM
> To: John R. Levine
> Cc: ietf-dkim@mipassoc.org; Alessandro Vesely
> Subject: Re: [ietf-dkim] 23 again (sorry John) was Ou
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Barry Leiba
> Sent: Thursday, May 05, 2011 1:55 PM
> To: John R. Levine
> Cc: ietf-dkim@mipassoc.org; Alessandro Vesely
> Subject: Re: [ietf-dkim] 23 again (sorry John) was Ou
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Hector Santos
> Sent: Thursday, May 05, 2011 9:41 PM
> To: dcroc...@bbiw.net
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Priz
Dave CROCKER wrote:
>>> I don't think this is correct. The signer creates and signs the i= value,
>>> so it's not "garbage",
>
>> By "garbage", I mean "not guaranteed to have any useful meaning".
>
>> So, I believe, it's essentially meaningless as far as the protocol can
>> stipulate. A
On 5/5/2011 8:12 PM, Murray S. Kucherawy wrote:
>> From: Michael Thomas [mailto:m...@mtcc.com] Sent: Thursday, May 05, 2011
>> 1:35 PM
>>
>> On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
>>> Technical: The AUID is an unvetted value. The local-part and the
>>> subdomain could be garbage. It
>I don't think this is correct. The signer creates and signs the i= value,
>so it's not "garbage", and it can't be "false" either.
Perhaps the word "stable" would be more applicable. The d= value is
tied to the DNS, is relatively stable, and the verifier can check that
there's a key record in the
> -Original Message-
> From: Michael Thomas [mailto:m...@mtcc.com]
> Sent: Thursday, May 05, 2011 1:35 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
>
> On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
>
Barry Leiba wrote:
>> I think the definition of i= should include information about the
>> public key t=s tag. �This t=s information that will deviate the "i="
>> definition is not found until 3.6.1 and 3.10. �The same can apply to
>> section 2.6 Agent or User Identifier (AUID) which makes no menti
Barry Leiba wrote:
>>> That's not what RFC5617 says.
>> � �Meaning: �No valid Author Domain Signature was found on the message
>> � � � � � � �and the published ADSP was "unknown".
>>
>> Can't that be read as meaning a non-Author Domain Signature was not
>> expected?
>
> No, not at all. I can't t
> I agree, as a participant. Nevertheless, we have consensus to leave
> it in because of the stats Murray gave us on the usage (on the signing
> side).
I agree we need to leave it in, but as I said, I would rather not offer
advice about how to code around its limitations, not least because
what
> Repeating or rephrasing specification text invites divergent interpretations.
Indeed, and I agree that not repeating is best. On the other hand,
we're already repeating the part about "or a subdomain of", which is
why I support adding a notation about "except when t=s".
> Note the constrain
On 5/5/11 1:34 PM, Michael Thomas wrote:
> On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
>> Technical: The AUID is an unvetted value. The local-part and the subdomain
>> could be garbage. It's inappropriate for a security protocol to return a
>> possibly false value in the context of sayin
On 5/5/11 1:24 PM, Barry Leiba wrote:
> Dave says...
>> In terms of working group process, one line of criticism demands
>> re-opening
>> (and, apparently, reversing) the work of the Update (RFC 5672). I
>> haven't seen
>> any working group consensus to do this nor any industry feedback
>> indi
On 5/5/2011 1:37 PM, Barry Leiba wrote:
>> Possible small change in 3.5 i= definition, 2nd paragraph change:
>>
>>The syntax is a standard email address where the Local-part MAY be
>>omitted. The domain part of the address MUST be the same as, or a
>>subdomain of, the val
>>> If this is the sort of advice we are going to give then we should just
>>> deprecate "l=".
>>
>> +1: it was an error in the PS and the DS fixes it.
>>
>> Alternatively we can allow it, warn, and expect implementers to code
>> heuristics that can discern attacks from regular footers.
>
> Speakin
>> That's not what RFC5617 says.
>
> Meaning: No valid Author Domain Signature was found on the message
> and the published ADSP was "unknown".
>
> Can't that be read as meaning a non-Author Domain Signature was not
> expected.
No, not at all. I can't think of any interpretation
> I think the definition of i= should include information about the
> public key t=s tag. This t=s information that will deviate the "i="
> definition is not found until 3.6.1 and 3.10. The same can apply to
> section 2.6 Agent or User Identifier (AUID) which makes no mention of
> t=s or any refe
On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
> Technical: The AUID is an unvetted value. The local-part and the subdomain
> could be garbage. It's inappropriate for a security protocol to return a
> possibly false value in the context of saying something was cryptographically
> validated
Dave says...
> In terms of working group process, one line of criticism demands re-opening
> (and, apparently, reversing) the work of the Update (RFC 5672). I haven't
> seen
> any working group consensus to do this nor any industry feedback indicating
> this
> is necessary. Consequently, attemp
>> + Verifiers SHOULD ignore those signatures that produce a PERMFAIL
>> + result (see Section 7.1), acting as though they were not present in
>> + the message. ...
>
> s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/
>
> (and probably in other places too). Veriffiers are explicit
Mike Thomas says...
> 4871 had it right on this account. Everything since then has
> screwed the pooch. Put it back.
Mike, I have a lot of catching up to do, having been travelling for a
bit. Some of that catching up involves dealing with complaints
(plural) about what you say on this list. Whil
Rolf E. Sonneveld wrote:
> On 5/5/11 1:52 AM, Hector Santos wrote:
>>
>> 3.x Originating Domain Identity (ODID)
>>
>> The ODID is the domain part of the From: address. This identity
>> MAY be considered as an output communicated to an advanced
>> Identity Assessor module.
>>
>>
Rolf E. Sonneveld wrote:
>>
>> 3.x Originating Domain Identity (ODID)
>>
>> The ODID is the domain part of the From: address. This identity
>> MAY be considered as an output communicated to an advanced
>> Identity Assessor module.
>>
>> INFORMATIVE IMPLEMENTATION NOTE:
>>
>
Murray, your technical *subjective* reasoning is not convincing.
First, as for procedural issues, I have come to understand for bis
work, how Hansen, Klensin and SM describes it. You do not seem to
reflect the same advice and quite often in contradiction.
In regards to AUID, the only technical *n
Rolf E. Sonneveld wrote:
>>
>> 3.x Originating Domain Identity (ODID)
>>
>> The ODID is the domain part of the From: address. This identity
>> MAY be considered as an output communicated to an advanced
>> Identity Assessor module.
>>
>> INFORMATIVE IMPLEMENTATION NOTE:
>>
>
Murray, your technical *subjective* reasoning is not convincing.
First, as for procedural issues, I have come to understand for bis
work, how Hansen, Klensin and SM describes it. You do not seem to
reflect the same advice and quite often in contradiction.
In regards to AUID, the only technical
> Alternatively we can allow it, warn, and expect implementers to code
> heuristics that can discern attacks from regular footers.
Speaking as an implementer, I ignore l=, because the hassle of working
around it and trying to guess how hostile any added content might be is
vastly greater than an
On 04.05.2011 21:13, MH Michael Hammer (5304) wrote:
>> boun...@mipassoc.org] On Behalf Of Dave CROCKER
>> On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote:
>>> So the issue is that someone might read it as "leave l= out
>>> of what you feed to the hash" versus "hash it, but ignore what it's
>>> te
On 05/05/2011 03:35 AM, Rolf E. Sonneveld wrote:
> Excuse me for my poor English, I shouldn't have used the word 'certify'
> here. I'm not talking about validity of content. Were I used the word
> 'certify' I mean:
>
> if a DKIM signature verifies successfully, the consumer can be sure that
> the b
On 5/4/11 10:01 AM, Dave CROCKER wrote:
> Folks,
> \
> In terms of working group process, one line of criticism demands re-opening
> (and, apparently, reversing) the work of the Update (RFC 5672). I haven't
> seen
> any working group consensus to do this nor any industry feedback indicating
> th
On 5/5/11 1:36 AM, Michael Thomas wrote:
> On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote:
>>
>> Well, I think you both are right in reading what my concern/objection
>> against 4871bis is. And maybe you're also right in that RFC4871
>> wasn't that much different of RFC4871bis.
>>
>> I think in
On 5/5/11 1:07 AM, Murray S. Kucherawy wrote:
>> I think in the early days of DKIM most people assumed DKIM would become a
>> protocol where:
>> * the body hash and header hash, using various header fields, certifies the
>> DKIM signature and
>> * the DKIM signature certifies the body and header
On 5/5/11 1:52 AM, Hector Santos wrote:
>>> Murray wrote:
>>> You want AUID and RFC5322.From added to the Output Requirements
>>> section explicitly.
> BTW, while RFC5322.From will satisfy requirements, I am proposing a
> new ODID identity (RFC5322.From.domain) since that is whats already
> extract
33 matches
Mail list logo
