apparea - Thursday, 19 May 2011

apparea

apparea@jabber.ietf.org

Thursday, 19 May 2011< ^ >

stpeter has set the subject to: IETF Applications Area

Room Configuration

GMT+0
[06:46:44] Tobias joins the room
[10:15:38] Tobias leaves the room: Computer went to sleep
[10:39:36] Tobias joins the room
[10:57:14] Tobias leaves the room: Computer went to sleep
[11:00:02] Tobias joins the room
[11:00:41] Tobias leaves the room: Disconnected: Server is shutting down: Received SIGINT
[11:01:01] Tobias joins the room
[11:14:51] cm-msk leaves the room
[11:23:26] Tobias leaves the room: Computer went to sleep
[11:27:21] Tobias joins the room
[11:34:53] Tobias leaves the room: Computer went to sleep
[11:48:47] Tobias joins the room
[12:39:10] Tobias leaves the room: Computer went to sleep
[12:39:10] resnick leaves the room
[14:07:14] Tobias joins the room
[15:30:33] resnick joins the room
[17:01:41] msk joins the room
[17:01:41] Tobias leaves the room
[17:39:32] msk leaves the room
[17:45:05] msk joins the room
[18:10:50] <msk> rest3
[18:10:53] <msk> oops
[19:49:26] Tobias joins the room
[19:49:26] msk leaves the room
[21:02:21] Tobias_ joins the room
[21:09:14] msk joins the room
[21:20:28] <msk> hmm
[21:21:05] <resnick> Yes?
[21:21:19] <msk> still with the strange client behaviours, but at least now i can get in here
[21:21:26] <msk> anyway, hello
[21:21:36] <resnick> howdy
[21:21:53] <msk> have some newbies barking at me about why DKIM insists on a 7bit downgrade of 8bit content prior to signing
[21:22:08] <msk> er, actually, why it says SHOULD instead of MUST
[21:22:37] <resnick> The newbies want what?
[21:30:04] <msk> an MTA receives 8bit content. it signs, then downgrades (invalidating the signature). the DKIM RFC specifically allows this by saying SHOULD downgrade instead of MUST. they say that normative language is thus wrong.
[21:30:19] <msk> (SHOULD downgrade prior to signing)
[21:30:56] <msk> i maintain that the downgrade is unnecessary if the path is known to be 8bit, for example. plus a MUST sets the bar to entry extremely high for current MTAs
[21:32:04] <resnick> Correct. SHOULD (if one reads 2119) means "MUST unless you really know what you're doing". If you know the path is 8-bit clean (and the spec writers know that such possibilities exist), then it's OK to not downgrade.
[21:33:56] <resnick> SHOULD is appropriate if you know there are circumstances in which the MUST can reasonably be ignored.
[21:34:06] <msk> i agree
[21:34:22] <resnick> (Remember, these are *interoperability* statements, not *conformance* statements.)
[21:34:29] <msk> and if they're really keen on this being universal, they can design and come up with a canonicalization that takes into account the downgrade
[21:34:44] <resnick> Now wait a minute:
[21:34:49] <resnick> It *is* universal.
[21:34:59] <msk> i mean having DKIM cope with a downstream downgrade
[21:35:10] <msk> i.e. it's agnostic to what happens in the path, at least with respect to downgrades
[21:35:23] <resnick> Any bozo who sends 8-bit into an environment which he doesn't *know* to be 8-bit clean end-to-end is violating the spec.
[21:35:38] <resnick> That's violating the SHOULD.
[21:36:06] <msk> i know, i'm trying to get these points across to non-IETF types that don't have the background and don't understand the downgrade issues
[21:36:25] <resnick> My guess is they don't understand the meaning of the 2119 terms. :-)
[21:36:30] <msk> that too
[21:36:43] <msk> i think they're stuck with an MTA implementation that signs, then downgrades
[21:36:46] <msk> and they're trying to blame the RFC
[21:37:18] <resnick> You can tell them that the MTA is already in violation of the RFC. No new language needed.
[21:37:29] <msk> heh
[21:37:33] <msk> "also, shut up"
[21:37:33] <resnick> It's true.
[21:37:48] <resnick> Well, that too. But we like *welcoming* newbies. :-)
[21:37:51] <msk> yeah
[21:38:02] <msk> i really like the energy, but they have no interest in the years of background that led to that SHOULD.
[21:38:37] <resnick> I read the messages on the list. AFAICT, every single response to you missed the point.
[21:38:51] <resnick> Happy to respond myself.
[21:39:31] <msk> this hasn't been on the list yet
[21:39:43] <msk> happened in an IRC room
[21:39:55] <msk> oh woops, you're right
[21:40:08] <msk> i meant the original question came from someone not on the list
[21:40:10] <resnick> OK. I thought I was losing my mind or something.
[21:40:11] <msk> yes, please feel free
[21:40:42] <msk> most of the more passionate argument has taken place in an IRC channel, not on ietf-dkim
[21:41:16] <resnick> Feel free to re-post my message to IRC if you see fit. (Writing now.)
[21:41:21] <msk> they interpret my reply so far as "great, let's just standardize on base64, take up 66% additional bandwidth, and bury our heads in the sand until 8BITMIME is universal"
[21:41:32] <msk> wilco
[21:53:11] <resnick> Sent.
[21:58:25] <msk> perfect, thank you
[21:58:42] <resnick> Here to help!
[22:01:19] <msk> i also pointed out that one could create a canonicalization that anticipates (maybe "assumes" is a better word) a downgrade
[22:01:34] <msk> but the receiving end would have to undo the downgrade perfectly to get a valid signature
[22:02:09] <msk> such a thing would be excruciatingly sensitive
[23:10:43] Tobias_ leaves the room
[23:21:13] Tobias leaves the room: Disconnected: connection closed