Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank linesfor SIMPLE c14n.

2007-01-25 Thread Douglas Otis
>> >> Bad actors will find signatures surviving as a result of the 'l=n' >> parameter, can then add their malware which might be a very innocent >> looking URI pointing to some provider's AUP. This message can then be >> sent in bulk anywhere. The innocent URI may still cause an exploit to >> occ

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank linesfor SIMPLE c14n.

2007-01-25 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Bad actors will find signatures surviving as a result of the 'l=n' > parameter, can then add their malware which might be a very innocent > looking URI pointing to some provider's AUP. This message can then be > sent in bulk anywhere. The innocen

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank linesfor SIMPLE c14n.

2007-01-25 Thread Douglas Otis
> It is possible for software to detect mailing lists and perhaps use > l= on those messages, but not on others. It is even possible for > software to automatically detect its own signatures that break > because of trailers put on, and then start using l=. It could happen. > It's not a computation

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

2007-01-25 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A quick note to add on to some things others have said. DKIM has features that are useful in some places but not in others. One of those is l=. It seems to me that some people think that DKIM is going to be used uniformly throughout an email syst

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

2007-01-25 Thread Tony Hansen
It's a slippery slope that I think we've already gone down far enough. I think the current exhortations are sufficient. Tony Hansen [EMAIL PROTECTED] Eric Allman wrote: > > --On January 24, 2007 2:08:24 PM -0500 Hector Santos > <[EMAIL PROTECTED]> wrote: > >> At the very least,

Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-base-08.txt

2007-01-25 Thread Scott Kitterman
On Thursday 25 January 2007 17:19, Eric Allman wrote: > --On January 20, 2007 3:59:33 AM +0100 Frank Ellermann > > - 6.3 > > "SHOULD NOT reject" because that "could cause severe > > interoperability problems" is plain nonsense. Accepting > > mail tagged as "suspicious" will cause severe pro

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

2007-01-25 Thread Eric Allman
--On January 24, 2007 2:08:24 PM -0500 Hector Santos <[EMAIL PROTECTED]> wrote: At the very least, Eric should add a statement about omitting the l= tag to avoid any signer concern about partial hashing body limit replay exploits. There are already several warnings in the draft about the

Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-base-08.txt

2007-01-25 Thread Eric Allman
--On January 20, 2007 3:59:33 AM +0100 Frank Ellermann <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: Filename: draft-ietf-dkim-base-08.txt Observations in addition to "example.edu": - [RFC-DK] Is that ready for publication ? I don't get what the I-D tracker pag

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

2007-01-25 Thread Charles Lindsey
On Wed, 24 Jan 2007 18:01:48 -, Douglas Otis <[EMAIL PROTECTED]> wrote: On Jan 24, 2007, at 9:24 AM, Scott Kitterman wrote: IIRC, every time someone brings up l= problems, the response is don't use it. Is there a problem it solves that we need it? If it's inherently risky and shoul