Hi,
I've done a bit of back and forth with Stephen elsewhere, and I have a
few comments about the draft.
Opportunistic encryption really means different things to different
people. It is actually NOT well defined in RFC 4322, and in that case
they're referring to encryption between L3 endpoints where you retrieve
keying information from the DNS using the KEY record and DNSSEC. That
is not what is implied by the following paragraph:
> While existing principles call for strong security, it is important
> to note that strong security only in cases where the other party can
> be authenticated does not by itself solve all privacy problems. To
> guard against dangers of large-scale privacy attacks, some protection
> is needed also for other situations. As a consequence, at minimum,
> opportunistic encryption needs to be well-defined for almost all new
> IETF standards track protocols. In most cases it will be better to
> (also) specify how to do mutually authenticated encryption.
> Encryption provides one aspect of privacy protection, namely
> confidentiality.
That is to say, the concepts of opportunistic and authenticated or
unauthenticated encryption are orthogonal. It is worth noting that by
the use of the term, one could reasonably argue that TLS is
opportunistic encryption because the encryption is not prearranged in
advance by two parties. If that is the bare minimum, then IMHO that is
largely what is intended by RFC 3365 already. I more than suspect
that's not what the intent of this draft is.
And so this raises three questions:
1. First, what is really meant by opportunistic encryption in this case?
2. What are the appropriate approaches for opportunistic encryption? and
3. What are the best practices (i.e., "Do"s and "Don'ts"; after all,
this is meant to be a BCP)?
Also, some protocols have evolved to allow for sharing of private
information, for better and worse. There are tradeoffs associated with
privacy versus security (such as the benefit of a transparent malware
scanner). These tradeoffs should be discussed in security considerations.
Eliot
_______________________________________________
ietf-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
