--On Friday, September 11, 2015 17:55 +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:
> On Fri, Sep 11, 2015 at 11:53:59AM -0400, John C Klensin wrote:
>
>> (1) A delivery server at smtp.example.com, for whatever
>> reason, associates joesmith@xxxxxxxxxxxxxxxx and
>> JoeSmith@xxxxxxxxxxxxxxxx with different mailboxes. That
>> policy might be thoroughly hidden from users, e.g., by the
>> latter address never being advertised but reached via an MX
>> record for example.net, i.e., the address
>> JoeSmith@xxxxxxxxxxx [1].
>
> End-to-end encryption aside, messages are often misaddressed by
> users even for addresses a lot less similar than the proposed
> example. Sometimes with extreme consequences. I recall one
> example where a confidential message intended for a lawyer was
> sent his brother the journalist...
>
> I don't think that this draft materially changes the landscape.
> Messages in transit should not be modified by relays. Sites
> that implement publication of keys should avoid overly similar
> names, and would be wise to avoid names that differ only in
> their case.
>
> In short, I think this objection is not a particularly strong
> one. My concerns with the draft are elsewhere.
Whether I agree with your conclusion or not, I just want to be
clear that the objection is to a combination of things, not a
single decision. I believe that either things should not work
as they appear to be specified to need to work (the case you
conclude is "not particularly strong" above) _or_ that the
Security Considerations section be expanded to clearly identify
the risks and consequences (as you more or less do above). One
or the other. The objection is to "neither".
I believe that there are elements of this proposal that are "bad
protocol" (the use of hashes is a candidate for one of them) and
far more that are (just) "bad document". The "bad document"
situation includes, but is not limited to, a Security
Considerations section that does not adequately analyze and
discuss important risk cases and normative references to expired
documents that are disguised as non-normative. I don't feel a
need to make that distinction any more clearly than I have
already: I believe the Last Call comments that have been made so
far (including the things to which you do object) provide more
than enough justification to return this draft to the WG with
instructions to:
* Sort out the difference between "inadequate document"
and "problems with the protocol" and generate a document
that solves the former problem
* Sort out the protocol issues that directly interact
with email system and DNS design and operations with the
relevant communities of experts.
* And, while it is separate from the above, describe the
experiment to be performed, how it will be evaluated,
and any issues that might arise in performing the
experiment in a "live" Internet environment (including
any measures needed to back away from it if it is not
successful).
>> > One might note that with both PGP and S/MIME, the public key
>> > binding is via a "certificate" that also includes the user's
>> > address.
>>
>> One of us misunderstands DNSSEC. It doesn't obtain anything.
>> It merely provides validation of one thing and one thing only,
>> which is an integrity check that a response to a DNS query
>> reflects what is actually in the DNS. It is not, as the draft
>> can be read to assume or imply, a magical form of pixie dust
>> that, e.g., attests to the binding between a key found in the
>> DNS and a particular external user identity.
>
> The DNS is a mechanism for publishing data. That data can
> include name to key bindings as appropriate. The security of
> such bindings is not unreasonably weak by comparison with
> other plausible large scale approaches.
Probably someone else may be able to explain this better than I
can. I believe we have a large-scale, worked, attack example of
people using strings that might appear similar until some (human
or machine) algorithm to lead users to misleading data and/or
into traps. We often call the set of cases "phishing" and most
instances of it are completely immune to any protections offered
by DNSSEC because the data have been correctly paid for and
entered into the DNS -- there is, e.g., no spoofing of
responses. If this particular RR TYPE, set of label formation
rules, and associated procedures provides adequate protection
against faked, similar-looking, mailbox names, I haven't been
able to find that out from reading the text (again, that may be
just a need for more discussion or strengthened Security
Considerations).
> I was initially optimistic about Keith Moore's addrquery draft,
> and still hold some hope for that, be he seems to think that
> security for the masses needs to be as strong as covert agent
> security, and we've had rather a long debate on the UTA list
> that stands unresolved. In the mean time he may have run out
> of cycles to push another draft revision. So we'll see how
> that evolves.
Whether in the form of "addrquery" or some other form of "ask
the delivery server for a key, or pointer to a key,
corresponding to a particular address"l, I see much more
potential there than getting into a situation in which the
information in the DNS (and how it is asked) have to parallel
what only the delivery server knows. The observation that "do
you have a key for <string>", when sent to a delivery MTA,
discloses much less information than probing the DNS or trying
to canonicalize or guess, is an added attraction whether the
answer is "no", "here is the key", or "here is an FQDN from
which an appropriate query will get the key", adds to the
attraction. In addition, there are well-understood and fairly
widely deployed mechanisms for authenticating an interaction
with an MTA and most MTAs that are designed for high performance
today almost have configurable rate-limiting mechanisms.
However, you may not want to pay any attention to that because
I'm a known fan of VRFY and some of the uses to which it could
be put... and we don't have a real/complete proposal along any
of the lines above that can be evaluated and scrutinized as
closely as the Openpgpkey one has been.
john