Re: General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)
Bron Gondwana <[email protected]> Wed, 15 Nov 2017 11:17:50 +1100
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <1510705070.1780599.1172765248.174C2DDF@webmail.messagingengine.com> |
This is a multi-part message in MIME format. --===============6747854489106562488== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151070507017805990" This is a multi-part message in MIME format. --_----------=_151070507017805990 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 15 Nov 2017, at 01:58, Cyrus Daboo wrote: > Hi Arnt, > > --On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen > <[email protected]> wrote: > >>> Anyway, I don't think the whole way this would work has been >>> well thought out yet. >> >> AOL. It would seem to serve the case where the user uses two clients,>> both of which display whether a message has an attachment and >> neither of>> which displays any other information from inside the blob. In >> particular,>> neither can display an excerpt of the text, or any information >> about the>> kind of attachment. >> > > I think a much more useful option would be for the first client to > decrypt > the blob and generate an IMAP-like BODYSTRUCTURE which it then > encrypts> to > the user's public key and uploads as metadata attached to the original> message. Then other clients which have the private key can grab the > metadata and decrypt it to get the full structure of the > encrypted blob.> That way the clients get to learn a lot more about the message > than the> mere fact it contains an attachment. > > Note, that it might also be useful to send the encrypted BODYSTRUCTURE> data > as a separate part/header in the encrypted message. That way > recipients> would also gain the benefit of being able to quickly determine > what the> message contains. Of course that additional data does potentially leak> some > information about the message, but that might be acceptable. The main value of any non-encrypted facts about the message (like a keyword about the attachment state) is to allow server-side search. I agree with Cyrus - the sender could easily attach the BODYSTRUCTURE as a separate encrypted part, though again that leaks information about the structure based on the size of the encrypted part - all sorts of side channel/metadata stuff needs to be thought through, and different people have different tradeoffs/risk profiles - but then most people don't want to think that deeply about every message they send, so if you make it too complex nobody will use it. Regardless of what gets stored encrypted or who does it however, the value of a keyword is search/sort. I still remain unconvinced that the usecase is common enough that any client would use it, particularly since the first client still needs to download the message so it can set the flag. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd [email protected] --_----------=_151070507017805990 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8" <!DOCTYPE html> <html> <head> <title></title> </head> <body><div style="font-family:Arial;">On Wed, 15 Nov 2017, at 01:58, Cyrus Daboo wrote:<br></div> <blockquote type="cite"><div>Hi Arnt,<br></div> <div><br></div> <div>--On November 14, 2017 at 2:25:06 PM +0000 Arnt Gulbrandsen<br></div> <div><<a href="mailto:[email protected]">[email protected]</a>> wrote:<br></div> <div><br></div> <blockquote><blockquote><div>Anyway, I don't think the whole way this would work has been<br></div> <div>well thought out yet.<br></div> </blockquote><div><br></div> <div>AOL. It would seem to serve the case where the user uses two clients,<br></div> <div>both of which display whether a message has an attachment and neither of<br></div> <div>which displays any other information from inside the blob. In particular,<br></div> <div>neither can display an excerpt of the text, or any information about the<br></div> <div>kind of attachment.<br></div> <div><br></div> </blockquote><div><br></div> <div>I think a much more useful option would be for the first client to<br></div> <div>decrypt<br></div> <div>the blob and generate an IMAP-like BODYSTRUCTURE which it then encrypts<br></div> <div>to<br></div> <div>the user's public key and uploads as metadata attached to the original<br></div> <div>message. Then other clients which have the private key can grab the<br></div> <div>metadata and decrypt it to get the full structure of the encrypted blob.<br></div> <div>That way the clients get to learn a lot more about the message than the<br></div> <div>mere fact it contains an attachment.<br></div> <div><br></div> <div>Note, that it might also be useful to send the encrypted BODYSTRUCTURE<br></div> <div>data<br></div> <div>as a separate part/header in the encrypted message. That way recipients<br></div> <div>would also gain the benefit of being able to quickly determine what the<br></div> <div>message contains. Of course that additional data does potentially leak<br></div> <div>some<br></div> <div>information about the message, but that might be acceptable.<br></div> </blockquote><div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">The main value of any non-encrypted facts about the message (like a keyword about the attachment state) is to allow server-side search.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">I agree with Cyrus - the sender could easily attach the BODYSTRUCTURE as a separate encrypted part, though again that leaks information about the structure based on the size of the encrypted part - all sorts of side channel/metadata stuff needs to be thought through, and different people have different tradeoffs/risk profiles - but then most people don't want to think that deeply about every message they send, so if you make it too complex nobody will use it.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">Regardless of what gets stored encrypted or who does it however, the value of a keyword is search/sort.<br></div> <div style="font-family:Arial;"><br></div> <div style="font-family:Arial;">I still remain unconvinced that the usecase is common enough that any client would use it, particularly since the first client still needs to download the message so it can set the flag.<br></div> <div style="font-family:Arial;"><br>Bron.<br></div> <div style="font-family:Arial;"><br></div> <div id="sig56629417"><div class="signature">--<br></div> <div class="signature"> Bron Gondwana, CEO, FastMail Pty Ltd<br></div> <div class="signature"> [email protected]<br></div> <div class="signature"><br></div> </div> <div style="font-family:Arial;"><br></div> </body> </html> --_----------=_151070507017805990-- --===============6747854489106562488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext --===============6747854489106562488==--