I'm not proposing anything new here. My point was simply that if anti-abuse requires the sender's key is on the outside, then it rules out some schemes. Namely any scheme where the signature only exists within an encrypted segment (e.g., your E(S(m,k2),k1)). This limitation could be considered an undesirable side-effect of Paul's proposal to use the signature for anti-abuse.
--Richard On Mon, Oct 7, 2013 at 4:07 PM, Phillip Hallam-Baker <[email protected]>wrote: > > > > On Mon, Oct 7, 2013 at 3:09 PM, Richard Barnes <[email protected]> wrote: > >> >> >> >> On Mon, Oct 7, 2013 at 10:33 AM, Paul Wouters <[email protected]> wrote: >> >>> On Thu, 3 Oct 2013, Douglas Otis wrote: >>> >>> Several have expressed valid concerns regarding abuse of encrypted >>>> email. >>>> >>> >>> One can always request encrypted email is signed. Than an abuser's key >>> can simply be blacklisted. Or all encrypted but not signed email can be >>> refused or disgarded. Encryption and key verification in DNS is actually >>> a really good anti-spammer tool. >> >> >> Note that this would require Encrypt-then-Sign or >> Sign-then-Encrypt-then-Sign, either of which has some security implications. >> <http://tools.ietf.org/html/rfc5751#section-3.6> >> > > Please be specific. > > There is no consensus on the order of operations and never will be because > there are security considerations of doing it either way. > > There are more options than S(E(m,k1),k2) or E(S(m,k2),k1) as well. > > Encryption takes place under a session key and that session key can be > used to encrypt the hash or encrypt the message. > > So be precise, it is really important here. One of the things that holds > the field back is that a lot of the time repetition of lore substitutes for > thinking. > > > The scheme I am currently working with has a policy layer so at the same > time the email recipient publishes their key they tell people how to use it > to send them mail. > > This allows for constraints such as: > > 1) Always try to send me encrypted mail. > > 2) Only send encrypted mail on prior permission. > > 3) Encrypt data to my personal key > > 4) Encrypt data to the organization's key. > > 5) Encrypt data to my personal key, sign it and then super encrypt under > the enterprise key. > > > Pre-PRISM we used to argue about choice A or choice B. > > What Bruce-who-has-seen-the-docs tells me is that when the NSA has that > choice their answer is always do both. > > And we have to do the same if we are going to win this. > > -- > Website: http://hallambaker.com/ >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
