Stephen,
--On Tuesday, September 15, 2015 20:42 +0100 Stephen Farrell
<stephen.farrell@xxxxxxxxx> wrote:
>...
> On 15/09/15 20:33, Dave Crocker wrote:
>> On 9/15/2015 12:26 PM, Stephen Farrell wrote:
>>> Note that I am not addressing what I think is an underlying
>>> objection which I interpret as "this won't work and is hence
>>> a bad idea." I do think folks can validly propose an
>>> experiment like this for a feature (e2e email security)
>>> we've never managed to get deployed at scale. (By "like
>>> this" I mean something with lots of associated and non-crazy
>>> concerns.) Were it the case that running this experiment
>>> would break a bunch of things I would feel differently but I
>>> don't think that is the case.
>>
>> Arguably, a failure of this mechanism could be quite serious.
>
> One can make that argument that seriously bad things could
> happen, as one can make many arguments. Making an argument
> does not in itself change the probabilities though.
>
> It seems very unlikely to me at least that this experiment
> would do significant harm.
In that sense, I agree. It will either work or it won't, there
will either be significant uptake or there won't, etc. My own
guess is that either a significant fraction of email users who
might be interested in installing public keys keys for
themselves this way will find that they have trouble getting the
relevant DNS records created and/or a significant number of
users who want to use it to pull public keys so they can send
encrypted messages will either discover that the key records are
not in the DNS or that they can't find them / match addresses to
them.
With two qualifications, I don't see any of those scenarios as
causing or risking significant harm. Those two qualifications
are:
(1) Unless the sender manages to verify the recipient key, e.g.,
by determining that the key has been signed by herself or
someone she explicitly trusts, rather than just "found it in the
DNS", there is a risk of spoofed keys. Whether that is a big
deal or not depends on why one wants encryption and what one's
threat model is. The I-D more or less says that, but it is not
obvious (especially in the light of the last sentence of the
abstract). I think it needs to be called out and explained as
part of the Security Considerations section (more on that
below). However, should such spoofing occur, compromise
something important, and draw publicity to the compromised
elements, that could significantly inhibit the deployment of
either this approach or alternatives to it. I would count that
as significant harm, even though one could argue that we have
seen so little deployment of PGP-based e2e encryption that our
aspirations should be in the range of "even a little would be an
improvement" and "better than nothing".
(2) I do see a failure here, should there be such a failure, as
having negative effects on other things we might try. That is
a "harm" issue, one that would be considerably mitigate by
describing the experiment and evaluation conditions to the
degree possible.
In addition, as Christian more or less pointed out, if the IETF
is really making a very strong commitment to privacy, creating
an easily-harvestable source of verified email addresses doesn't
seem to be a good idea. Perhaps the tradeoffs justify it, but
the document would be a lot better if that particular analysis
and set of considerations were explained.
That said, as an experiment and especially after a very
productive off-list discussion with the author, I have much
larger problems with the presentation in the document than I do
with the idea of doing the experiment. I think the decision
to do another draft is correct. I also think that the Security
Considerations section of the I-D needs to be complete and
self-contained, not dependent on references to an expired I-D.
It also seems to me that a number of objections can be
eliminated by being clear about objectives and explanations.
For example, while I've very sympathetic with John Levine's
position that all possible addresses for a user should be
accommodated, if that really isn't a goal -- if the goal is just
to be able to deal with whatever addresses can be found -- than
I think that can be said clearly and we can move on, leaving
questions of whether or not that is a good idea to the
experiment or later. All of that seems to be consistent with
your analysis, so perhaps we are close to being on the same page.
I do have one additional issue that I hope the revised draft can
address. Apparently, the core motivation for the hashing
procedure was a belief that the DNS could not accommodate
non-ASCII (or, more specifically, non-"preferred syntax")
characters in labels. I think I understand the source of the
confusion. RFC 1034 is reasonably clear and 1123 and 2181 are
very clear on the matter: while applications may impose other
restrictions, labels are just strings of octets containing
arbitrary bit patterns. Fixing it is probably a matter for
DNSOP --perhaps draft-ietf-dnsop-dns-terminology which is
conveniently in IESG evaluation anyway-- but, whether the
hashing is reconsidered on that basis or not, this I-D should
not make assertions about DNS restrictions that actually do not
exist.
best,
john