On Sat, Oct 19, 2013 at 2:27 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Presumably you are referring to using the destination domain DKIM keys
to encrypt ...
Sort of. Here's a straw man I sent to one of the MAAWG lists last
month:
Sender fetches TXT _encrypt._domainkey.recipient.com. If it exists,
it uses the p= public key to encrypt the whole message, embeds it as a
MIME application/dkim-encrypted body in a new message to the original
address, and sends it off.
Recipient MTA receives message, and if it has an
application/dkim-encrypted body, decrypts and unwraps it and delivers
the original message. Intermediate MTAs don't have to do anything
special.
Bonus anti-traffic analysis hack: new wrapped message is always sent
to: postmaster(_at_)recipient(_dot_)com with subject: encrypted message,
real
recipient and subject recovered from Subject: and DKIM-Encrypted-To:
headers in the encapsulated message.
A single header field for the recipient(s) really doesn't cut it. There's
lots
more to message envelopes these days. I suggest you take a look at RFC 2442
instead. Batch SMTP has a long and quite successful history of being used
for
this sort of thing.
And now, I'm afraid, I'm going to have to do the IPR dance: I'm aware that
there may be intellectual property claims on this scheme. Unfortunately I
really cannot say more than that - not because of any sort of
confidentiality
restrictions, but rather because I don't know the details.
Specifically, I was contacted maybe 6 months ago by a law firm looking for
prior art on exactly this scheme. They didn't identify the patent and I
didn't
ask for any details because I'm instructed by my employer to never do that.
But apparently there's one out there.
Ned
My read of this and RFC 3979 is that possible IPR problems with an idea
such as Levine's proposal, doesn't preclude it from further discussion,
though correct me if I'm wrong. Also what you've written paints a very
broad brush. The way I see it, his proposal actually has three parts, and
does that prior art exactly cover all three parts? That is:
1) Use of DNS for public key distribution. The obvious prior art is DKIM.
2) Use of a domain wide public key (e.g. DKIM public key) Surely one can
create a new RR that isn't covered by any patent?
3) Wrap at sender MTA or MUA, and only unwrap at the recipient MTA, with
relays seeing only cipher text.
If only item 3) is encumbered, then surely there's something to work with
from 1) and 2) ?
my two cents,
-Wei
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp