Philip,
I am not speaking for anyone else, but let me clarify one or two
things.
I am _not_ objecting to doing this as a experiment if the
community thinks it likely enough to succeed and/or be useful.
My personal estimate of the consensus about that is lower than
Stephen's, but that is the IESG's problem, not mine.
Stephen's comments about "bad idea" apply to the question of
whether the experiment should be performed. While I'm among
those who thinks this mechanism is unlikely to prove broadly
useful, I agree with him, do not believe that a proposal for an
experiment should be required to demonstrate that there will be
extensive deployment, and am willing to try to keep an open mind
on those subjects.
--On Wednesday, September 16, 2015 16:35 +0200 Philip Homburg
<pch-ietf-2(_at_)u-1(_dot_)phicoh(_dot_)com> wrote:
In your letter dated Wed, 16 Sep 2015 09:51:31 -0400 you wrote:
There are other operational differences that call "about as
expensive" into question. While arrangements differ from one
provider to the next and in part because of spam and related
problems, many SMTP servers are aggressively monitored.
...
This seems to be a great way to block a lot of progress.
If you start storing more sensitive data is a server or
service, then obviously you need to upgrade the protection
and monitoring.
...
It is _not_ obvious, at leas6 judging by the number of
relatively unsecured servers and services we have floating
around the Internet. Even among those who understand its
importance, there may be technical, operational, economic, or
policy reasons for not installing the level of protection one
would like.
Again, it is for this reason and others that I have been
advocating a clearer and more complete "Security Considerations"
section of the document and a more complete description of the
experiment being performed, including identification of those
issues that we can identify today which people should watch for
and evaluate. To pick this one as an example, I do not recall
the current draft saying "if you deploy this mechanism, it would
be wise to be sure that your DNS servers are adequately hardened
against mail address harvesting attacks". I note that the I-D
stops well short of saying "DNSSEC with NSEC3 MUST be used in
any zone that deploys OPENPGPKEY records". I don't think the
spec should be blocked because of that, but do believe it
suggests a question that should be posed as part of the
experiment.
Claiming that just because when today there is no monitoring
due to the lack of sensitive data, there cannot be a proposal
to store something else sounds very circular to me.
I made no such claim. I would not have bothered to even
respond to your note had you note made the unqualified "about as
expensive" claim which I believe, from an SMTP standpoint, to be
incorrect or at least too superficial.
...
A completely random idea. But maybe worth experimenting with
is doing the same thing over SMTP:
Require a TLS connection, probably to the mail submission
port, with a DANE record (to get the same sort of security as
in this draft) with an 'OPENPGP <mail-address>' command.
The advantage is that the LHS issues are gone. The question is
if access to port 587 is generally open to mail user agents
and whether mail servers can allow anonymous access to that
port.
At least one other question is whether a requirement for TLS
connections to mail servers, and the connectivity model they
imply would be damaging to the usability of email. I hope we
don't need to resolve that question in order for this I-D to
move forward but otherwise look forward to seeing a more
complete proposal from you in the form of an I-D. Also note
that there is a proposal floating around for an SMTP extension
to allow asking the SMTP delivery server for the PGP key
associated with an address.
A variation on that idea would be to ask the delivery server,
not for the key associated with a particular address, but for
its own key. I haven't worked through a security analysis and
don't intend to, but one could imagine using that approach for
more or less opportunistic encryption between submission and
delivery servers without incurrent the problems associated with
hop-by-hop TLS and cleartext on relays.
Noting that, like all other SMTP transactions, the delivery
server would be free to impose whatever authentication or
authorization requirements it likes before accepting and
responding to such commends, I think those idea should be
explored further, but don't see them, or their exploration, as
blocking factor for this proposal --as an experiment-- either.
I gather from Stephen's note and some correspondence with Paul
that we can expect an updated, -06, draft with improvements to
at least the Security Considerations discussion. I continue to
hope for a "Experiment Description and Questions" section too,
but can't usefully speculate further on it at this point. May I
suggest that those who are not directly involved in the
production of that draft calm down and move on to (or back to)
other work, at least until that revision has cleared the WG? I,
at least, am going to follow that suggestion -- no more comments
on the IETF list until the community is asked to review -06 or
later.
best
john