[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
--On Friday, May 31, 2024 14:06 + lloyd.wood=40yahoo.co...@dmarc.ietf.org wrote: > Am I the only one who remembers massive public corporate > commitments to ATM and B-ISDN in the 1990s? > > But then the CCiTT and ITU-T were already heavily invested. The > IETF has never had the same sway. Lloyd, I do. I also remember massive public commitments to OSI as a principle and various elements (standards and Recommendations) of it a decade (or more) earlier.But there were at least two (additional) differences from the present situation and considerations about it. (1) By the time those commitments (and press releases) were made, there were general claims that the there were finished specifications. Whether those making them thought they were true was another matter: I remember conversations with a few people who were involved with the public announcements but who privately expressed doubts as to whether the specs were really ready and workable. Having versions of some of those specs that were widely hyped and endorsed only to be replaced by partially incompatible versions a few years later when the early versions turned out to be impractical. But, in each of those cases, there were specs. They might have turned out later to be incomplete or unworkable, but there were specs. I think part of the concern here -- which I am not nearly as concerned about as some others have been-- is that a significant public commitment was required before the work had actually started. In any event, I believe that either of the two alternate phrasings Murray suggested yesterday eliminate whatever problem might exist. best, john > On Monday, May 20, 2024, 12:23, Dave Crocker > wrote: > > On 5/10/2024 2:33 PM, Dave Crocker wrote: > > On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote: > > * Prior to accepting any Standards Track document for development, > there must be a commitment to implement the resulting proposed > standard from at least two independent parties, as recorded on a > related IETF mailing list. > > Just realized this concern did not get attention: > > Simply put this is a thoroughly unreasonable burden. > > Companies don't work that way. > > > Companies do not make public, future commitments for implementing > standards. And when there are attempts to get them to, they > waffle and evade. > Also, I believe, the IETF has wisely never tried to impose this > burden. > Again, if the goal is to limit this working group to only take on > specifications that are already in use, then just say that. > It's simpler, clearer, more direct and, frankly, more pragmatic. > > Because that is the practical effect of what's in the charter. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker@mastodon.social > > ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
Am I the only one who remembers massive public corporate commitments to ATM and B-ISDN in the 1990s? But then the CCiTT and ITU-T were already heavily invested. The IETF has never had the same sway. Lloyd woodlloyd.w...@yahoo.co.uk I think 4G/5G/6G required a lot of public commitment too. On Monday, May 20, 2024, 12:23, Dave Crocker wrote: On 5/10/2024 2:33 PM, Dave Crocker wrote: On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote: * Prior to accepting any Standards Track document for development, there must be a commitment to implement the resulting proposed standard from at least two independent parties, as recorded on a related IETF mailing list. Just realized this concern did not get attention: Simply put this is a thoroughly unreasonable burden. Companies don't work that way. Companies do not make public, future commitments for implementing standards. And when there are attempts to get them to, they waffle and evade. Also, I believe, the IETF has wisely never tried to impose this burden. Again, if the goal is to limit this working group to only take on specifications that are already in use, then just say that. It's simpler, clearer, more direct and, frankly, more pragmatic. Because that is the practical effect of what's in the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Manipulation of signed messages
On Thu 30/May/2024 19:19:16 +0200 Murray S. Kucherawy wrote: On Thu, May 30, 2024 at 9:13 AM Alessandro Vesely wrote: z= saves all fields, which would be too much in most cases. Moreover, doing so suggests treating all fields as a whole, rather than dealing with each one's peculiarity. > That's not what the RFC says. Most implementations put there all signed fields. OpenDKIM also "skip" fields. Undoing transformations is not a diagnostic operation. For example, Mailman 3 is qp-encoding the Subject: X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BIetf-dkim=5D_Re=3A_Manipulation_of_signed_messages?= That way I cannot verify Gmail's signatures any more. Diagnostics is only needed to get the culprit, so as to better the heuristics... Of course, if an Original- field is tampered with the original signature won't verify after replacing it, just like if you altered z=. But then, reverting without cooperation is not the same as doing it with active opposition. Why would someone alter Original- fields? A mediator wanting to disrupt the possibility to reverse had better removing the signature directly. > Space munging applied to all fields, for example, is enough to break this scheme. "z=", by contrast, is immune to such mutations, because it's encoded. Right. However, Mailman re-folds header fields it writes from memory, so if canonicalization is not relaxed the verification fails anyway. z= doesn't include itself. Best Ale -- ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
