Re: [ietf-dkim] signing and verifying invalid messages
On Oct 5, 2010, at 4:45 PM, Michael Thomas wrote: On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
Michael Thomas wrote: On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. In my engineering opinion, it was a security hole that fell through the cracks during the development of the RFC 4886 Threat Analysis. If it was presented back then, we would be dealing with the semantics as I propose to deal with it simply because we can't ignore it or blame RFC 822/2822/5322 implementation or MUAs. This is a DKIM issue and it needs to get addressed. Any system today that displays: signed by: but displays a spoofed 2nd From can produce a major confidence problem for DKIM. I have a problem understanding the blow back to the security issue. 4871bis is active. Something needs to be added to 4871bist so that implementations and operators are made aware of it, now and into the future. I highly recommend that the key editors embrace this and deal with it or risk negative DKIM public relations if this gets into the media or into the mind set of any hackers and potential DKIM exploiters. You need to deal with it. Not ignore it or pass the buck to other layers of email. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] http://tools.ietf.org/html/rfc4686 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
