Re: [SPAM] Re: Secure email
Sandro Magi <[email protected]> Tue, 19 Jan 2016 01:08:21 -0500
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
--===============7327209782859670626==
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">I think your simple alternating
protocol could work. Each exchanged message then shares both
public keys, so both get stored to bootstrap the protocol. This
can also enable secure third-party introductions, ie. multiple
recipients includes the keys of those listed, as you know them.<br>
<br>
However, you could go some time before interacting with some
people, longer even than two key expiry dates. I might get back in
touch with a high school friend with whom I've had prior
exchanges, and I'd have to reauthorize both new keys, even though
having done so in the past, I could do so automatically and
securely if the whole key chain were available. Seems a shame to
be almost, but not quite there.<br>
<br>
As for key compromise, I'd think in that case you'd simply have to
simply start from scratch with a leap of faith, some shared secret
challenge/response, or some out of band verification.<br>
<br>
Sandro<br>
<br>
On 18/01/2016 6:24 PM, Alan Karp wrote:<br>
</div>
<blockquote
cite=3D"mid:CANpA1Z14Ct3AcGFNPBCPs9C_JKY-nciOYg6ScWwkgec8-YQsqw-JsoAwUIsXov1KXRcyAk9cg@public.gmane.org=
l.com"
type=3D"cite">
<div dir=3D"ltr">One way to handle key rollover is to start with tw=
o
keys with different expiration dates, k1 and k2.=A0 Before k1
expires, you generate k3 and certify it using k2.=A0 Use k2 as
your primary and k3 as secondary.=A0 Lather rinse repeat.=A0 This
approach does not cover the case of a k2 being compromised, but
its private key can be kept offline until</div>
<div class=3D"gmail_extra"><br clear=3D"all">
<div>
<div class=3D"gmail_signature"><br>
--------------<br>
Alan Karp</div>
</div>
<br>
<div class=3D"gmail_quote">On Mon, Jan 18, 2016 at 1:56 PM, Jed
Donnelley <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]" target=3D"_blank">c=
apability-iCFHVraI1K1Wk0Htik3J/[email protected]</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
1/18/2016 8:57 AM, Sandro Magi wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Certainly a marked improvement over unencrypted content,
but it doesn't handle<br>
key expiry. Once my key expires, all my subsequent e-mails
to you will not match<br>
the public key you stored, so what's a key update protocol
that's also secure?<br>
</blockquote>
<br>
Thanks for the comments.=A0 =A0When your key expires (e.g. yo=
u
reinstall your software or even a timeout), if you send "me"
an email my client will recognize the new public key from a
recognized "from" address, notify me (if I care), and save
the new key.<br>
If I care about the notification I can do whatever I wish to
reestablish trust with the sender with the new key.=A0 In the
rare but important (e.g. legal or financial) case where a
key is bound to a person or institution then a new key
binding must be done (see below for details).<br>
<br>
If your key expires and 'I' send you a message before you
send me one then your client will respond with a "key
change" message (rather than displaying the distracting
cypher text) - resulting in the situation above.<br>
<br>
Since I mentioned "key binding" above I may as well restate
a simple protocol that I believe can leverage a secure web
site login (common for financial/legal sites) to establish a
key binding for secure email.=A0 I login to my web site and
submit my email address and its associated public key to a
form.=A0 The web site binds that public key to the email
address.=A0 Thereafter any email signed by my private key can
be assumed to be from me - until my key expires, when I need
to do a rebinding.=A0 Anybody see any problem with that
protocol?<br>
<br>
For typical email use, however, I don't consider key binding
a significant issue.=A0 I'd be quite comfortable just
accepting a new key binding from anybody sending email to me
in nearly all circumstances.=A0 Even if I do so without any
check or exchange I'm better off than I am now as at least
ALL messages will be encrypted and signed - even if the
sender isn't necessarily bound to a specific person or
institution.=A0 Having been notified of and accepted a new ke=
y
binding to an email address, I might be on somewhat more
alert about a potential man in the middle attack, but how
often do I care?=A0 I certainly don't have any support for
caring now.=A0 If I did care in future I could do key binding
more generally (e.g. testing via alternative communication
such as telephone, video chat, or whatever).=A0 As I say, I
really don't see key binding as a practical problem except
for very rare cases where something like the key binding
through a secure web login (as above) seems perfectly
adequate to me.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Encrypted messages also reduces the effectiveness of
search, which is a big<br>
issue with today's e-mail volume.<br>
</blockquote>
<br>
Are you referring to searching my own email archive?=A0 In
that case why can't it just be the clear text that is saved
and searched?<br>
<br>
If you are referring to some other email being searched,
please clarify why one would need to "search" encrypted
email.<br>
<br>
--Jed<br>
_______________________________________________<br>
cap-talk mailing list<br>
<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a><br>
<a moz-do-not-send=3D"true"
href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk"
rel=3D"noreferrer" target=3D"_blank">http://www.eros-os.org=
/mailman/listinfo/cap-talk</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
cap-talk mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
s.org">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.eros-os.org/mailman=
/listinfo/cap-talk">http://www.eros-os.org/mailman/listinfo/cap-talk</a>
</pre>
</blockquote>
<br>
</body>
</html>
--===============7327209782859670626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
--===============7327209782859670626==--