[147187] in cryptography@c2.net mail archive
Re: [Cryptography] End to end
daemon@ATHENA.MIT.EDU (Max Kington)
Tue Sep 17 13:19:51 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <7A59C43E-4F24-453C-91F8-B5C28BD0D2C7@guru.at>
Date: Tue, 17 Sep 2013 18:03:26 +0100
From: Max Kington <mkington@webhanger.com>
To: Christoph Gruber <grisu@guru.at>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8253047445283133286==
Content-Type: multipart/alternative; boundary=089e0153835898a09c04e6974c6c
--089e0153835898a09c04e6974c6c
Content-Type: text/plain; charset=ISO-8859-1
On 17 Sep 2013 15:47, "Christoph Gruber" <grisu@guru.at> wrote:
>
> On 2013-09-16 Phillip Hallam-Baker <hallam@gmail.com> wrote:
> [snip]
>>
>> If people are sending email through the corporate email system then in
many cases the corporation has a need/right to see what they are
sending/receiving.
>
> [snip]
>
> Even if an organisation has a need/right to look into people's email, it
is necessary to protect the communication on transport and storage. Of
course a certain way of key recovery has to be in place.
>
> Just my 2 cents
I intend to reply in more detail to the draft there's lots of very
interesting work there.
The most common approach to ILM for email in highly regulated sectors I've
seen is to divorce the storage and transport mechanism and associated
security from the long term storage. In a corporate environment the message
is captured pre encryption and transmission and stored.
Whilst key escrow mechanisms do exist the risk is that what gets escrowed
isn't what was sent if you maliciously want to tunnel data (imagine not
being able to decrypt a message at the request of the SEC or FSA because
the key you were sent is wrong by the desktop app, or conversely having to
decrypt everything first to check). You have the added issue of having to
store all the associated keys and in 7 years (the typical retention period
over here for business now regarded as complete, let alone long running
contracts still in play) still have software to decrypt it.
Hence, store in the clear, keep safe at rest using today's archival
mechanism and when that starts to get dated move onto the next one
en-masse, for all your media not just emails.
Hence for the purposes of your RFC perhaps view that as a problem that
doesn't require detailed specification.
M
>
>> --
>> Website: http://hallambaker.com/
>>
>> _______________________________________________
>> The cryptography mailing list
>> cryptography@metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
--089e0153835898a09c04e6974c6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 17 Sep 2013 15:47, "Christoph Gruber" <<a href=3D"mailto:gr=
isu@guru.at">grisu@guru.at</a>> wrote:<br>
><br>
> On 2013-09-16 Phillip Hallam-Baker <<a href=3D"mailto:hallam@gmail.=
com">hallam@gmail.com</a>> wrote:<br>
> [snip]<br>
>><br>
>> If people are sending email through the corporate email system the=
n in many cases the corporation has a need/right to see what they are sendi=
ng/receiving.<br>
><br>
> [snip]<br>
><br>
> Even if an organisation has a need/right to look into people's ema=
il, it is necessary to protect the communication on transport and storage. =
Of course a certain way of key recovery has to be in place.<br>
><br>
> Just my 2 cents</p>
<p dir=3D"ltr">I intend to reply in more detail to the draft there's lo=
ts of very interesting work there. </p>
<p dir=3D"ltr">The most common approach to ILM for email in highly regulate=
d sectors I've seen is to divorce the storage and transport mechanism a=
nd associated security from the long term storage. In a corporate environme=
nt the message is captured pre encryption and transmission and stored. </p>
<p dir=3D"ltr">Whilst key escrow mechanisms do exist the risk is that what =
gets escrowed isn't what was sent if you maliciously want to tunnel dat=
a (imagine not being able to decrypt a message at the request of the SEC or=
FSA because the key you were sent is wrong by the desktop app, or converse=
ly having to decrypt everything first to check). You have the added issue o=
f having to store all the associated keys and in 7 years (the typical reten=
tion period over here for business now regarded as complete, let alone long=
running contracts still in play) still have software to decrypt it. </p>
<p dir=3D"ltr">Hence, store in the clear, keep safe at rest using today'=
;s archival mechanism and when that starts to get dated move onto the next =
one en-masse, for all your media not just emails. </p>
<p dir=3D"ltr">Hence for the purposes of your RFC perhaps view that as a pr=
oblem that doesn't require detailed specification. </p>
<p dir=3D"ltr">M</p>
<p dir=3D"ltr">><br>
>> -- <br>
>> Website: <a href=3D"http://hallambaker.com/">http://hallambaker.co=
m/</a><br>
>><br>
>> _______________________________________________<br>
>> The cryptography mailing list<br>
>> <a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd=
.com</a><br>
>> <a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography">=
http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
><br>
><br>
> _______________________________________________<br>
> The cryptography mailing list<br>
> <a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com=
</a><br>
> <a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography">http=
://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</p>
--089e0153835898a09c04e6974c6c--
--===============8253047445283133286==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8253047445283133286==--
