Subject: Re: [dane] Last Call: <draft-ietf-dane-openpgpkey-05.txt> (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard

From: Petr Spacek <[email-masked]>
Date: Thu, 3 Sep 2015 22:33:39 +0200

Hello,

as far as I can tell people favor various LHS-hashing variants for privacy
reasons. Assuming that this observation is correct, I consider current hashing
scheme totally insufficient - it does not protect anyone's privacy against
even against moderately-funded attackers. We should do better (not only to
please Snowden :-)

I very much like the generic idea of salting described in variant a) here:
https://mailarchive.ietf.org/arch/msg/dane/LuC7BYtd6zVEWJF0s4cnmBLL1rU
(I'm not so certain about "rulez", but that is a separate discussion. Do not
conflate these two discussions.)

Personally I would store salt+iteration parameters in "_openpgpkey.<domain>"
so the whole tree can be shared/DNAMEd at will.

Yes, this requires additional lookup. Still, I can see important benefits
which in my eyes outweigh the disadvantage:

- The additional "salt" lookup works as privacy guard for domains which did
not deploy _openpgpkey at all. If the client does not find "salt" record then
no lookups for names derived from LHS should be made. This effectively
prevents leaks for domains which did not deploy _openpgpkey. (Domain name
leaks anyway because of MX lookups.)

- The "salt" record for big mail providers will be often in a nearby cache so
the additional time-overhead for big mail providers will be negligible. And of
course, TTL for this kind of record can be pretty long.

- Salt/iteration count can be increased over time so we can keep raising the
bar to make it costly to revert the hashing as computing power gets cheaper.

Really, I think that we should rethink the hashing if we are serious about
privacy.

Petr Spacek

On 28.8.2015 17:11, The IESG wrote:
> The IESG has received a request from the DNS-based Authentication of
> Named Entities WG (dane) to consider the following document:
> - 'Using DANE to Associate OpenPGP public keys with email addresses'
>   <draft-ietf-dane-openpgpkey-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-09-11. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

-- 
Petr Spacek  @  Red Hat

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 4 Sep 2015 15:27:56 +0000

> even against moderately-funded attackers. We should do better (not only to

For the record, similar observations from the WG discussion.

    https://www.ietf.org/mail-archive/web/dane/current/msg08046.html
    https://www.ietf.org/mail-archive/web/dane/current/msg08017.html
    https://www.ietf.org/mail-archive/web/dane/current/msg08065.html

[ I agree that hashing is not a substantial privacy enhancement.
  The original reason hashing was proposed was not privacy-related. ]

-- 
	Viktor.

---

From: "John R. Levine" <[email-masked]>
Date: 9 Sep 2015 16:49:40 -0400

>  <draft-ietf-dane-openpgpkey-05.txt> as Proposed Standard

This draft has several technical issues that will make it a problem to 
interoperate at Internet scale.  They've all come up in the WG mailing 
list, but they're still unresolved.

It would be great if there were a workable automated way to discover an 
encryption key for an address.  I'd like to sign up on my bank's web site 
with the tagged address [email-masked], the bank's then 
automatically looks up the key (likely the same as for [email-masked],) 
and after that the mail they send to me is encrypted to my key, and they 
can verify that the mail I send to them is signed with my key.

* Name semantics

The SMTP specs have always said that the local-part of an e-mail address 
(the part before the @) is only interpreted by the recipient MTA.  MTAs 
invariably map a lot of different local-parts to the same internal 
mailbox.  They do ASCII case folding, drop noise characters (Gmail's 
dots), trim extensions (user+ext), do LDAP lookups, and more, with great 
inconsistency among mail systems. The DNS does exact matches other than 
ASCII case folding and wild cards, neither of which seem relevant here.

Every variation that can be looked up using this scheme has to be put 
separately in the DNS, as a key record or a CNAME, so the number of 
variations that a user can look up will be only a tiny fraction of the 
total. The WG considered and rejected reversible encodings, e.g.  base32, 
that would allow a specialized DNS server to recover the local-part, pass 
it to the relevant MTA to find the mailbox and then sign and return an 
appropriate key record.  Since it appears unlikely that anyone would ever 
implement that, I agree it's not a solution.

>From discussions on the WG list, the plan appears to be that lookups will 
be made manually by human users who will pick addresses they think are 
likely to be in the DNS, e.g., lower case without extensions.  If that's 
the use model, the draft should say so explicitly and make it clear that 
most addresses that work in SMTP won't be in the DNS. We should consider 
whether such a narrow use case is worth it.

It also appears that they expect users and maybe MUAs to modify incoming 
addresses (the draft now says not to but the author recently said he wants 
to put back case folding advice, as did some last call comments), arguing 
that in practice all MUAs treat upper and lower case as equivalent. 
While that may well be true for ASCII addresses, it is a significant 
change to RFC 5321 address semantics.  If we're going to make that change, 
it should be an update to RFC 5321, not an end run.

* Scaling

Mail system sizes range from a handful of users to some with over 10^8 
users and possibly one with 10^9.  There are three mail systems in the 
U.S. with over 10^8 users that handle about half of all the mail in the 
country.

Hashed names require that all of the keys for a domain be served in one 
flat zone.  Large mail systems typically partition the users based on the 
local part, but since the hashes aren't reversible, there's no way to tell 
what partition would handle what hashed name. The server might broadcast 
queries to all the partitions, but that just pushes the problem down a 
level, since there's still no way to tell what address matches a query 
without a precomputed table of hashes.

PGP key records are about 3K so a zone with 10^8 keys, which would be 
under 1/4 of Gmail's or Yahoo's users, would be 300 gigabytes before 
signing. The largest signed zone now is probably .COM at about 10GB before 
signing; a zone 30 times as big seems rather a stretch.  In one sense it 
doesn't matter since large mail systems are unlikely to implement this (I 
asked), but at the least the draft should document the scale problems for 
large systems.

* Security and name guessing

Absent a change to RFC 5321 name semantics, this draft pretty much demands 
name guessing.  If Bobsmith@example doesn't work, try bobsmith@ or 
BOBSMITH@ or BobSmith@ or maybe just bob@.  If john-bank@example doesn't 
work, maybe john@ or JOHN@ will.  Key guessing in a security protocol 
seems oddly insecure.

R's,
John

PS: For a different approach, see draft-moore-email-addrquery-01.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Sep 2015 23:11:37 -0400 (EDT)

On Wed, 9 Sep 2015, John R. Levine wrote:

> with the tagged address [email-masked], the bank's then automatically 
> looks up the key (likely the same as for [email-masked],) and after that 
> the mail they send to me is encrypted to my key, and they can verify that the 
> mail I send to them is signed with my key.

For the internet scale domains, the local part rules are well known and
can be implemented by clients doing a lookup. They could even decide to
do based on the identity of the MX server (eg google domains). A few
people strongly objected to even hinting at common rewrite rules, so
that information was removed from the draft (not so much by consensus
but for conflict avoidance). Re-adding this advise would resolve this.

Another suggested method has been the addition of a domain-wide special
TXT record that describes the domain rewriting rules. However, the WG
was ready to start an experimental deployment and use the results of
those experiments to write a bis document, possible promoting such a
bis document from Experimental to Standards Track.

> The WG considered and rejected reversible encodings,

> I agree it's not a solution.

> be made manually by human users who will pick addresses they think are likely 
> to be in the DNS, e.g., lower case without extensions.

I am not sure what you base this on. While MUA's indeed have the luxury
of being able to fallback to asking a human for confirmation, one of
the main goals of the draft is to facilitate automatic email encryption
without human interaction.

> If that's the use model

It is not "the" use model. The introduction of the document even talks
about how the old HKP servers are unusable for automatically encrypting
email due to a lack of authentication of the openpgp keys.

> addresses (the draft now says not to but the author recently said he wants to 
> put back case folding advice, as did some last call comments), arguing that 
> in practice all MUAs treat upper and lower case as equivalent. While that may 
> well be true for ASCII addresses, it is a significant change to RFC 5321 
> address semantics.  If we're going to make that change, it should be an 
> update to RFC 5321, not an end run.

Just to clarify, the document does not expect or suggest any changes to
the SMTP protocol or RFC-5321. I assume that with "modifying incoming
addresses" you mean modifying the DNS lookup for the openpgpkey record,
not the SMTP envelope values.

There was proposed text to only perform lowercasing for the QNAME in
the DNS lookup when the LHS was in ASCII. That would prevent any issues
with internationized email names. The reason lowercasing is needed is
because it is well known that webforms and phone virtual keyboards often
auto-capitalize names that appear in built-in dictionaries. Additionally,
there are no known deployments where the case of the LHS matters. Humans
simply cannot handle that [email-masked] is a different user from
[email-masked]. Lowercasing is simply not a problem for ASCII names.

An alternative approach was also suggested where if the client detects
the LHS can be lowercased, and an unmodified lookup yields no record,
that it would be allowed to perform a second lookup lowercased.

The only argument against either of these were dogmatic and based on
illusionary mailservers that could be implementing different mailboxes
for "Paul" vs "paul" local-parts.

I still believe the draft would be greatly improved if either one of these
solutions were added back to the document. Obviously, implementors should
not ignore the auto-capitalization problem. While it would not lead to
interoperability problems, it could lead to a decrease of Opportunistic
Security.

> Mail system sizes range from a handful of users to some with over 10^8 users 
> and possibly one with 10^9.  There are three mail systems in the U.S. with 
> over 10^8 users that handle about half of all the mail in the country.
>
> Hashed names require that all of the keys for a domain be served in one flat 
> zone.

As far as I'm aware, some of these 10^8 or 10^9 actually don't use flat
zone files but use online DNSSEC signing with database backends.
Regardless, one would expect an infrastructure for 10^9 mailboxes would
be able to run an online signer on the _openpgpkey.example.com domain.

> Large mail systems typically partition the users based on the local 
> part, but since the hashes aren't reversible, there's no way to tell what 
> partition would handle what hashed name. The server might broadcast queries 
> to all the partitions, but that just pushes the problem down a level, since 
> there's still no way to tell what address matches a query without a 
> precomputed table of hashes.

I'm not sure how local part partitions for mailboxes are affected at
all. Mail is delivered either encrypted or not encrypted, to the
identical local-part. This draft does not require any modification on
the part of the SMTP server. Partitioning still works.

Partitioning DNS answers is a very well understood feature called "DNS
split view" and are often in use for localising DNS answers based on
geographic IP of the query. Various very successful companies deploy
these technologies.

> PGP key records are about 3K

Not if the recommendations of Section 2.1.2 are followed.

> so a zone with 10^8 keys, which would be under 
> 1/4 of Gmail's or Yahoo's users, would be 300 gigabytes before signing. The 
> largest signed zone now is probably .COM at about 10GB before signing; a zone 
> 30 times as big seems rather a stretch.

Clearly, online signing would be used in such a large deployment.

> In one sense it doesn't matter since 
> large mail systems are unlikely to implement this (I asked)

Obviously, the large mail systems that base their business model on
reading the emails for targeted advertising are not the main target for
deployment of this document - the other 50% of the internet is.

> name guessing.  If Bobsmith@example doesn't work, try bobsmith@ or BOBSMITH@ 
> or BobSmith@ or maybe just bob@.  If john-bank@example doesn't work, maybe 
> john@ or JOHN@ will.  Key guessing in a security protocol seems oddly 
> insecure.

The only "guessing" that the document has ever suggested in its
previous drafts were lowercasing or rewriting based on well-known
domain properties. It has never attempted to do the "guessing" you are
listing above.

The document is about attempting to encrypt email that otherwise would
go out in plaintext. It clearly states it is not a replacement for
using authenticated pre-arranged encryption. The main focus of the
document is to prevent pervasive monitoring of plaintext email in
transit and stored on intermediate email servers. So failure to encrypt
[email-masked] is not a security failure. It is merely the
failure of adding Opportunistic Security.

> PS: For a different approach, see draft-moore-email-addrquery-01.

I encourage deployment of alternative encryption authentication methods.
The method of draft-ietf-dane-openpgpkey is based on DNSSEC. One of its
features is that misbehaviour by the email server can be spotted by
the enduser. They see their OPENPGPKEY record being modified without
their consent. It seems the method of draft-moore-email-addrquery-01
relies on fully trusting the SMTP server, which is not secure
if the email provider can be coerced by a third party. Therefor,
draft-moore-email-addrquery-01 is an alternative approach, but not a
replacement of draft-ietf-dane-openpgpkey.

Paul

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2015 04:11:07 -0000

>but for conflict avoidance). Re-adding this advise would resolve this.

Well, OK.  Then put it in the draft, create a rewrite rule registry,
and see if we get consensus.

>TXT record that describes the domain rewriting rules. 

Ditto, write it up.

>However, the WG

If you're saying that this draft is experimental, please adjust its
status to say so, since it's currently proposed standard.  On the
other hand, if it really is standards track, you need to flesh out the
magic that you're assuming people will use.  If everyone invents their
own magic, that's hardly interoperating.

>zone files but use online DNSSEC signing with database backends.

These systems have 10^8 e-mail addresses, not 10^8 DNS records.  The
.COM zone has about 2.8x10^8 records, but the unsigned records average
only 35 characters. I am under the impression that they do static
signing.  10^8 records at 3K apiece really is a lot bigger.

>> partition would handle what hashed name. ...

>all.

The name space is partitioned.  As an oversimplified example, one
might divide the mail system into 26 partitions, one for addresses
that start with "A", through the 26th for addresses that start with
"Z".  So in a setup like that, when you get this hash:

401f1721a42a814961323c460dd7d2036231ddf590b5d898c9cd086a

which partition handles it?

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Sep 2015 11:22:20 +0100

On 10/09/15 05:11, John Levine wrote:
> status to say so, since it's currently proposed standard. 

My fault. The draft correctly says it's aiming for experimental, but
I forgot to twiddle the datatracker knobs before I started the LC. I
have now twiddled that knob. [1]

I don't think there's a need to re-do the IETF LC announcement for
that. But if someone feels the need for additional correctness, please
do say and I'll get that sorted.

S.

[1] https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

---

From: "John R Levine" <[email-masked]>
Date: 10 Sep 2015 08:31:39 -0400

> do say and I'll get that sorted.

No, that's fine.  I see the draft itself says experimental.

Should it be more clear about what the experiment is and what results it's 
looking for?  Just putting some records into the DNS to see what happens 
doesn't seem like it would tell us much, and it also wouldn't be 
surprising to find that small numbers of monocase records looked up 
manually would work.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Sep 2015 11:00:51 -0400 (EDT)

> and see if we get consensus.

I think the WG was fine with sticking to the currently defined
experimental now, and now delay another year before starting the
experiment. Such rewrite rules could be added later by those who
actually care and run this and write software, so they can come back
to us with a proposal.

> signing.  10^8 records at 3K apiece really is a lot bigger.

One would think a factor of 100x is something these super large
providers could deal with. That's less than say adding India or China
to their userbase. It's also unavoidable too. public keys are blobs of
a certain size that don't compress. It's fundamental to this document.
This document is not Mandatory To Implement. If a certain big provider
cannot implement this in their DNS, they should not deploy this
document. If your point is that this document should never be published
because some large providers might not be able to deploy it, please state
so clearly.

> which partition handles it?

The hash does not make it to the mail server. It is only used in DNS
to find the public key. The recipient name is NOT changed.

The SMTP server just sees the envelope address which is not hashed as
there are no modifications made to the SMTP protocol.

Paul

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2015 16:20:20 -0000

>actually care and run this and write software, so they can come back

It sounds like you want to invent a way to canonicalize address local
parts.  If you want to do that, OK, although it's been tried and
failed many times before.  (SMTP has two commands that nobody
implements, for example.)  But it'd be an update to 5321 since I don't
think anyone believes it'd be a good idea to have one set of rules
for e-mail addresses in actual e-mail and a different set here.

>> These systems have 10^8 e-mail addresses, not 10^8 DNS records. ...

>because some large providers might not be able to deploy it, please state

It seems to me that the point of creating a standard is so that
systems can interoperate.  If we know in advance that the systems
handling the majority of the world's mail are vanishingly unlikely
to implement something, what's the point?

>>>> Large mail systems typically partition the users ...

>to find the public key. The recipient name is NOT changed.

Here, I think we agree.  In a partitioned mail system (which is not
limited to the largest ones), all of the partitions would have to
export all the keys to one monolithic database.  That's what I mean by
scaling badly -- the techniques which work fine to scale up mail
systems don't work here.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Sep 2015 17:01:14 +0000

> scaling badly -- the techniques which work fine to scale up mail

Without taking a stand on the overall design, I don't agree with
the above objection.

There is no new requirement for a single database.  The hash keyspace
can be partitioned in exactly the same way as the recipient address
keyspace.  What does change is that the partitions responsible for
user addresses would need to publish hashes to the corresponding
server for the hash in question.

-- 
	Viktor.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2015 19:35:19 +0200

I believe it would be a mistake to publish this document without having
it include a discussion of its relationship to RFC 4648.  As far as I
can tell, the CERT record defined in RFC 4648 solves roughly the same
problem as OPENPGPKEY and CERT is already deployed with support in (for
example) GnuPG.  I believe the community would benefit from sorting out
the relationship before publication, not after, when we would have two
RFCs describing solutions for what appears to be the same problem.

/Simon

The IESG <[email-masked]> writes:

> Abstract
>    OpenPGP is a message format for email (and file) encryption that
>    lacks a standardized lookup mechanism to securely obtain OpenPGP
>    public keys.  This document specifies a method for publishing and
>    locating OpenPGP public keys in DNS for a specific email address
>    using a new OPENPGPKEY DNS Resource Record.  Security is provided via
>    DNSSEC.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2015 19:40:21 +0200

Sorry -- I meant RFC 4398 and not RFC 4648!

/Simon

Simon Josefsson <[email-masked]> writes:

> The IESG <[email-masked]> writes:
>
>> [email-masked] mailing lists by 2015-09-11. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
> [email-masked]

---

From: manning <[email-masked]>
Date: Thu, 10 Sep 2015 10:39:40 -0700

I’d have to agree with Simon here.  

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Sep 2015 19:05:14 -0400 (EDT)

On Thu, 10 Sep 2015, John Levine wrote:

> parts.

I'm saying any such efforts were deferred in this document precisely
for the reasons you mention. The only rewrite rule I suggested was
the obvious lowercase issue - as it addresses a real and common problem.
The vast majority of the 10^9 users does in fact not use foo+bar
addressing.

> to implement something, what's the point?

Using that argumentation we can close down XMPP work too, since google
and facebook, the 99% of chat messages, are deviating from XMPP on
purpose. What's the point of writing more XMPP documents?

> export all the keys to one monolithic database.

You know, once in a while I receive an unknown IKE vendorid, which is
usually an md5 or sha1 hash. I throw it into google and get a response
within 1 second. I think we're okay letting these people decide how to
do their large data provisioning. You can't say these email providers
have 10^9 users with hundreds of datacenters but don't know how to deal
with Big Data.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Sep 2015 19:38:49 -0400 (EDT)

> RFCs describing solutions for what appears to be the same problem.

This issue has also come up several times in the working group
discussion. While a paragraph could surely be added to the document, I
don't see much value in such historic inclusion to implementors.

The CERT record uses sub typing which is (now) considered to be bad
in DNS, including by at least one of the authors of the original CERT
record RFC-2538.

It includes dependancies on other security modules besides DNSSEC (PKIX,
CA's, generic URI's dealing with TLS security, etc.) which makes it hard
on implementors that only want to implement certain security schemes
(eg just OpenPGP and not PKIX, SPKI, X.509 blobs, etc). So that leaves
only the PGP and iPGP sub types of the CERT. That also means the DNSKEY
algorthm number of the CERT RDATA is always 0 (and really not needed)

Indirect URI schemes of CERT can also be used to trick MUA's or MTA's
into connecting to random rogue servers, which is both a security and
a privacy problem. This makes the CERT sub-type IPGP undesirable.

The OPENPGPKEY record uses no sub types, involves no other PKIs, and
supports one clear RDATA format to implement. Depending on only DNS(SEC)
means that openpgp key data can be distributed easilly and widely,
without creating single point of failures or easilly blocked HTTP
requests that are indistinguisable from outages.

With DNSSEC, tampering is visible because there will be a BOGUS DNS answer
when the data is filtered or the data is obtained. Whereas with indirect
methods there can be "unknown errors" in reaching the indirectly pointed
by resource.

The CERT record did not address the local-part lookup problem.
So regardless, a new RFC would be needed to specify the local-part
lookup. That RFC would than basically have to say "Only use IANA
certificate type is 3 (PGP) and algorithm type 0 (not a DNSKEY algorithm).

It seems much cleaner to limit the RDATA section to just the OpenPGP key
material without unused sub-typing and zero'd algorithm identifiers.

The OPENPGPKEY record early code point has already seen more deployment
than the CERT record.

The SMIME record draft also does not plan on using the CERT record.

Paul

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Sep 2015 02:43:59 -0400

Preface: I've been working on this note intermittently for a few
days.  I think I've eliminated inconsistencies that arose during
that process, but please forgive me if not.

It seems to me that there are two major clusters of issues with
this spec.  One set have to do with interactions with earlier,
standards-track, models for storing keys or certificates in the
DNS.   Simon and Bill have addressed that and I assume can be
counted upon to continue to do so if needed.  I do believe,
however, that a proposed Experimental spec should not be
proposing to do something that overlaps heavily with the goals
of a standards track spec, yet does things differently, without
commenting on, and proposing to update or depreciate the earlier
spec.  Note in a mail message that say, essentially, "we talked
about that and decided the old spec was a bad idea" do not seem
to me to be sufficient for that purpose.

The second relates to interactions with the email environment
and DNS scaling, especially the relationship between whatever is
used as a DNS lookup key and the email address.  Those seems to
be the main theme of John Levine's remarks and are the topics I
want to address.

--On Wednesday, September 09, 2015 16:49 -0400 "John R. Levine"
<[email-masked]> wrote:

>> - 'Using DANE to Associate OpenPGP public keys with email
>> addresses' <draft-ietf-dane-openpgpkey-05.txt> as Proposed
>>  Standard
> 
> This draft has several technical issues that will make it a
> problem to interoperate at Internet scale.  They've all come
> up in the WG mailing list, but they're still unresolved.
> 
> It would be great if there were a workable automated way to
> discover an encryption key for an address.  I'd like to sign
> up on my bank's web site with the tagged address
> [email-masked], the bank's then automatically looks up
> the key (likely the same as for [email-masked],) and after
> that the mail they send to me is encrypted to my key, and they
>...

In part because John L.'s comments are the only ones posted so
far in opposition to approving this draft because of email
issues, let me add a few remarks and emphasize a few points.

First, I agree with his analysis (all of it, not just the
introduction quoted above).

In particular and from my point of view (RFC 5321 editor hat
very much on), SMTP-transported email has become ubiquitous
throughout the network-connected world precisely because it was
designed, and has evolved further, to provide adequate support
of a variety of implementation and operational models.  In
particular, it works when the SMTP servers involved are
relatively small, serving only a single household or SME; it
works with very large and centralized email providers, including
those who handle many messages that never leave their own
systems (and hence might be considered equivalent to the
non-network centralized mail systems of the 70s and 80s); it
works in both single-hop and multiple relay situations,
including those that involve gateways to non-SMTP and even
non-Internet environments; it works in both message delivery
environments and "notify and pick up" ones; it works and is used
for control messages and signaling as well as human-human
communications; and so on.  Some of the provisions of RFC 5321
to which John Levine refers, including the prohibitions on
interpretation of local parts anywhere in the path before the
delivery server (the prohibition that effectively prohibits
guessing), are not merely historical artifacts but have proven
key to supporting those alternate models, including links to
alternate email systems and scenarios over which the IETF has no
control.

"This won't screw up a very large percentage of users or their
email addresses" is not an adequate story if what is being
discarded is one of those models.  Again, if mail service other
than to users of GooHooSoftMail were simply discontinued, the
percentages would not be large, but the damage to the Internet
would be considerable.  And, if an extension is not accessible
except to, e.g., YaMicOgleMail users, it is not something the
IETF should be entertaining.

In the hope of heading off a side-argument, if we were to decide
that one of those models was the only important one, we could
design protocols that would be much nicer than SMTP.  However,
at least so far and despite several proposals, the IETF and the
broader community have rejected all of those "we only need one
model" approaches.  We should not allow one of them to sneak in
through a back door in an experimental spec either.

Despite that, we've seen an increasing tendency in recent years
to come up with, and even standardize, approaches that work well
for one particular model, more or less with the assumption that
everyone can either switch to that model or that whatever bad
effects happen are the fault of the non-switchers.  That seems
undesirable to me, even with a nominally "experimental" protocol.

I don't think it has been mentioned in earlier messages, but
what is perhaps the most fundamental design characteristic of
PGP -- the Web of Trust idea -- is violated every time someone
picks up a key from a keyserver and trusts it based on where it
was found.   As far as I can tell from the Introduction to this
spec, the main objection to the use of keyservers is that they
can contain invalid or faked keys.  If so, the motivation is
very weak indeed because (i) The problem could be more easily
solved by adding provisions to keyserver protocols that would
warn or restrict retrieval of unsigned keys or even keys that
are not anchored in the retrieving user's web of trust and (ii)
to the extent to which this design depends on name- (or
address-) guessing, incorrect guesses are possible.  If the keys
are important and validated by their presence in the DNS, the
possibility of bad guesses creates an business opportunity for
bad actors abetted by unscrupulous registrars (the presence of
unscrupulous DNS registrars on the Internet has been extensively
demonstrated).  This problem is essentially confirmed in the
third paragraph of Section 7.4 of the I-D.  So the very
justification given for this protocol is dubious... and
"Security is provided via DNSSEC" comes very close to the
spreading of low-quality, or even imitation, pixie dust.

Recommendations:

(1) Particularly because it has the potential for weakening
interoperability in the installed base, if this is going to be
an experimental protocol, then the conditions for the experiment
need to be laid out, including how the experiment is going to be
evaluated and when.

(2) If the use of this approach leads to violations of 5321 (as
both John L. and I believe it does) or could have other side
effects on the use and operation of the mail system, then the
I-D should have an evaluation of those cases and bow any damage
can be mitigated both during the experiment and in any possible
production follow-up.   If the WG expects the latter to emerge
during the experimental period, that should be explicit and the
experimental evaluation should conclude the effort was a failure
if that does not occur.

(3) John's concerns about DNS scaling are clearly as important
as mine about ill-effects on email infrastructure and
operations.  I suggest that this draft be referred to DNSOps and
the IETF Last Call and its evaluation be suspended until there
is consensus in that WG that this is safe and would be safe at
scale, even as an experiment.

(4) The IETF normally requires that specifications contain
Security Considerations sections and that they be meaningful and
substantive.  The one in this document is dependent on a
reference to an Internet Draft.  That draft is listed as
Informative but, given the statement "OPENPGPKEY usage
considerations are published in [OPENPGPKEY-USAGE]." the
reference is a requirement for understanding the security issues
with the proposal and is hence normative.  Similarly, "See
[OPENPGPKEY-USAGE] for more in-depth information on safe usage
of OPENPGPKEY based OpenPGP keys" in Section 7.4 is
unquestionably a normative reference as well as indicating that
the text that is redundant with that in
draft-ietf-dane-openpgpkey-usage-01 is not a replacement for it.
Worse, the referenced I-D does not exist: that draft expired
last April and, if "expired" is to mean anything, it cannot be
cited as even active work in progress.  This issue should have
been caught and dealt with by the WG or, if not, by the relevant
Shepherd or AD.  The Last Call should be suspended or abandoned
and the document returned to the WG until the document is
revised to contain a Security Considerations section that is
either complete and self-contained or that uses normative
references to active documents that are expected to be published
as RFCs soon enough to be meaningful.

(5) The Introduction to the I-D should be rewritten to explain
why this is being done and what problem it solves, noting that
the problems associated with the ability to store a bogus
(unsigned/ unverified) key on a keyserver is merely replaced in
this proposal by the ability to store bogus keys in the DNS that
are no better linked to the user's web of trust than those
unsigned keys on keyservers (btw, "in-person" has nothing to do
with it -- the issue has to do with whether the key contains
enough information linked to the web of trust of the relying
users to be meaningful, so the I-D is also slightly misleading).

This I-D is just not ready for prime time, even as an
Experimental specification.

    john

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2015 14:27:53 -0000

>purpose. What's the point of writing more XMPP documents?

It was definitely a victory for open standads when Google and Facebook
adopted XMPP for their systems.  The people I know at both companies
are pretty reasonable, so if they're diverging from the specs it's
unlikely to be just to be gratuitously incompatible.

Given their size, I agree that there are likely more XMPP users at
Google and Facebook than everywhere else combined which means that in
the real world, they're the standard that everyone will implement and
if we disagree, we're the outliers.  If we can't come up with
standards that they can use, or at least document what the largest
systems do so everyone else can interoperate, we're not much of a
standards organization.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Sep 2015 14:44:22 +0000

> experimental evaluation should conclude the effort was a failure

Note, I am ambivalent as to whether the draft represents a sound
long-term approach to publishing user keys in DNS.  

However, I should note that I take 5321 to apply primarily once
messages enter the email transport system.  At the point of message
composition, when a user is interactively composing an email, if
the MUA allows the user to try a case invariant of the address
(particularly on devices that gratuitously capitalize the first
letter of entered text) that I think is outside the scope of 5321
which keeps relays from damaging messages already in transit.

Trying a lower-case variant is something an MUA supporting the
draft would do to help a user find the right key.  This does not
introduce damage of message envelopes for mail in transit.

So I think the main objection is not that a variant (lower-case)
might be tried, but that there's no way to find all the right
variants to try (e.g. +extensions, especially since even the "+"
is a destination-dependent character).  This means that a user who
wants to receive end-to-end encrypted email for a set of distinct
addresses that are all mapped to the same mailbox would need to
publish multiple public key bindings.

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.

Implementing MUAs would then be expected to adapt their address to
key binding logic when they implement support for obtaining keys
via DNSSEC, by creating a binding from the lookup key to the result
at the time the key is retrieved, that overrides addresses found
in the "certificate", since absent other trusted evidence in the
retrieved "certificate" any other addresses found with the key are
not trustworthy.  Therefore, "certificates" obtained from DNS cannot
simply be merged into an existing "public keyring", they have
different naming semantics.

> users to be meaningful, so the I-D is also slightly misleading).

Whether an MUA is willing to employ the PGP message format for a
different trust model (not web of trust, but DNSSEC-validating
domain operator assertions) is up to the user of the MUA.  I don't
think it is fair to accuse this draft of violating web of trust
(WoT), the PGP message format is not irrevocably tied to WoT.

If the user and MUA want to be able to employ DNSSEC to obtain keys
for correspondents well outside their social circle, it is not
reasonable to call these keys "bogus".  They are certainly less
"bogus" than most web site (DV) certificates.

We've long ago learned that scaling secure communications to the
masses means giving up absolute end-to-end assurance.  Usable
encryption for the masses will not be as strong as tailor-made
encryption for covert agents.

I don't know that this particular design (or in fact any design)
will bring secure end-to-end email to the masses.  The masses might
in practice find encrypted email much to painful to use (unlike
ephemeral communication, people often want to retain and later
search their past email communications, and end-to-end encryption
makes that substantially more difficult).

This could make scaling less of an issue, because adoption rates
are likely to be rather low, I don't expect any large provider to
enroll all but a tiny fraction of their users in the foreseeable
future.

I am not vigorously endorsing this draft (damning with faint
praise?), but I do want to clarify some of the issues as I see
them.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2015 11:09:54 -0400 (EDT)

> unlikely to be just to be gratuitously incompatible.

Could you ask your the people you know why Google Talk Service
does not support server-to-server encryption via TLS mandated by RFC
3920 in 2004?

Here are some links about how these protocol changes were not gratuitous:

http://www.disruptivetelephony.com/2015/02/google-finally-kills-off-googletalk-and-xmpp-jabber-integration.html

https://developers.facebook.com/docs/chat

http://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-google-talk/

Paul

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Sep 2015 11:53:59 -0400

Victor,

Your message contains a long chain of suppositions.  I really
don't have time to do, and write, a complete analysis, but I
think the most essential issues are covered below...

--On Friday, September 11, 2015 14:44 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> (2) If the use of this approach leads to violations of 5321
>> (as both John L. and I believe it does) or could have other
>> side effects on the use and operation of the mail system,
>> then the I-D should have an evaluation of those cases and bow
>> any damage can be mitigated both during the experiment and in
>> any possible production follow-up.   If the WG expects the
>> latter to emerge during the experimental period, that should
>> be explicit and the experimental evaluation should conclude
>> the effort was a failure if that does not occur.
> 
> Note, I am ambivalent as to whether the draft represents a
> sound long-term approach to publishing user keys in DNS.  
> 
> messages enter the email transport system.  At the point of
> message composition, when a user is interactively composing an
> email, if the MUA allows the user to try a case invariant of
> the address (particularly on devices that gratuitously
> capitalize the first letter of entered text) that I think is
> outside the scope of 5321 which keeps relays from damaging
> messages already in transit.
> 
> draft would do to help a user find the right key.  This does
> not introduce damage of message envelopes for mail in transit.

Certainly you are correct about messages in transit.  Noting
that SMTP requires that case variations in the local-part be
preserved even while it discourages taking advantage of them
(see Section 2.4 of RFC 5321), consider the following:

(1) A delivery server at smtp.example.com, for whatever reason,
associates [email-masked] and
[email-masked] 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 [email-masked] [1]. 

(2) The owner of the joesmith mailbox chooses to supply a
OPENPGPKEY DNS RR and key, the owner of the JoeSmith one chooses
to not do so.

(3) Your MUA tries to look up an OPENPGPKEY record associated
with [2] JoeSmith and gets a failure.  It then decides to
lower-case the string, looks for a key associated with joesmith,
and gets one.  This is an instance of what John Levine and I
have referred to as "name guessing" or "address guessing" and
results in a false positive for the key for JoeSmith.  If one is
lucky, the message is then sent to JoeSmith encrypted in the key
for joesmith.  Since the owner of the JoeSmith mailbox doesn't
have the joesmith private key (and absent MITM or other attacks
on intermediates), the message will arrive but not be able to be
decrypted and no important information is disclosed (I note that
the I-D warns against that case).   On the other hand, if the
MUA, having decided that the two addresses are equivalent, sends
the encrypted message to the joesmith mailbox, then information
the sender believes is being transmitted encrypted is disclosed
to the wrong party.

I believe that whole scenario is a bad idea and is one of
several reasons why originating MUAs should not start
algorithmically guessing at names --and IETF specs, even
experimental ones, should not encourage doing so-- even though
5321 does not (and cannot) explicitly prohibit it.  If the
advocates of this spec believe the level of risk is acceptable,
I believe they _MUST_ carefully describe that risk and the
tradeoffs in their Security Considerations section.  Either way,
the draft is not ready for publication; sufficiently unready
that I believe it should never have been posted for IETF Last
Call.

> So I think the main objection is not that a variant
> (lower-case) might be tried, but that there's no way to find
> all the right variants to try (e.g. +extensions, especially
> since even the "+" is a destination-dependent character).
> This means that a user who wants to receive end-to-end
> encrypted email for a set of distinct addresses that are all
> mapped to the same mailbox would need to publish multiple
> public key bindings.

Because this is a security protocol, I'm even more concerned
about false positives because the sending MUA has no way to know
whether [email-masked] and [email-masked]
represent the same or different mailboxes and, if different,
whether they represent the same or different users.  That raises
a separate issue which is that, while we often use mailbox
identifiers to identify keys, users are not, and never have
been, uniquely bound to mailboxes.

> 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.

While some PGP traditionalists would, I believe, object to the
use of the term "certificate", what they include is a mailbox
address that is more or less "certified" as belonging to the
user.  Whether or not it is "the user's address",  is another
matter.  In the PGP case in particular, it is not an accident
that the key format contains provisions for several addresses
associated with a given user, addresses that are individually
signed/ certified/ validated.

>... 
> If the user and MUA want to be able to employ DNSSEC to obtain
> keys for correspondents well outside their social circle, it
> is not reasonable to call these keys "bogus".  They are
> certainly less "bogus" than most web site (DV) certificates.

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.

> We've long ago learned that scaling secure communications to
> the masses means giving up absolute end-to-end assurance.
> Usable encryption for the masses will not be as strong as
> tailor-made encryption for covert agents.

I'm not sure what that means, but you have, IMO, just
strengthened my argument that the Security Considerations
section of the draft is completely inadequate as a discussion of
the vunerability and risks associated with this approach.

>...
> This could make scaling less of an issue, because adoption
> rates are likely to be rather low, I don't expect any large
> provider to enroll all but a tiny fraction of their users in
> the foreseeable future.

However, as illustrated by the example above, if a given domain
"enrolls" some of its mailboxes but not others, and MUAs start
guessing at mailbox name variations in the way you suggest (or
otherwise), the vunerability to false positives increases.
Again, I expect that to be discussed in the Security
Considerations section and believe that normal IETF rules for
those sections requires such a discussion.

    john

[1] Upon skimming back through the draft, if example.net. owns
an MX record that points to smtp.example.com, it is not
completely clear whether the lookup for an OPENPGPKEY record
should be performed at subdomains of example.net,
smtp.example.com, or example.com.  The question becomes more
complex if example.net is associated with multiple MX RRs whose
data identifies different domains.  The I-D should be explicit
about this unless name guessing is expected for those cases too,
in which case even more is needed in Security Considerations.

[2] I say "associated" because of concerns about the proposed
hashing mechanisms (which John Levine identified as well)
including the possibility of false positives there as well.    I
note in that regard that the first sentence of Section 3 of the
I-D is simply false.  The authors and advocates of this draft
might find it helpful to read RFC 2181, 1034, and 1123 (not
necessarily in that order).

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2015 13:38:15 -0400 (EDT)

> the sender believes is being transmitted encrypted is disclosed

Luckilly, "[email-masked]" and "Joesmith@example".com are
already really good hypothetical friends. They have been regularly
receiving each others unencrypted email for the last 20 years.

> I believe that whole scenario is a bad idea and is one of

While others believe that webforms and phone virtual keyboard auto-correct
functions that changes "[email-masked]" to "[email-masked]"
is an _actual_ problem to address, happening to actual people every day
and not some theological and hypothetical deployment.

In the real world, the local-part is not case sensitive.

> algorithmically guessing at names

It is not guessing. It is a defined transformation. Leaving lowercasing
out of the spec will result in most implementations querying the
unmodified and the lowercased versions to support webforms and virtual
keyboard auto-capitalization. And some implementations will forget to
implement this because it wouldn't be mentioned in the spec, and it will
cause some people's email to go out unencrypted where it could have gone
out encrypted. But we would have saved the imaginary Joe Smith and joe
Smith from receiving each others unreadable email. At least they will
still have each others unencrypted email to read.

> --and IETF specs, even
> tradeoffs in their Security Considerations section.

I am totally willing to do that, once we can find one instance out of
the 10^9 email addresses where two different people have identical email
addresses apart from the case of the local-part. I suspect the change
of finding that is going to be smaller than that of a hash collision
in DNSSEC or OpenPGP.

> whether [email-masked] and [email-masked]

The document has never in any of its iterations stated that the "+" or
"." symbol should be removed before hashing, let alone that they should
be juxtaposed in the way you are describing, so your concern is unfounded.

> users are not, and never have been, uniquely bound to mailboxes.

The OPENPGPKEY record is not about users, it is bound to email addresses.
(or as you can call them, mailboxes)

> In the PGP case in particular, it is not an accident

And OPENPGPKEY records can be deployed on any of these indepedantly,
and the draft even suggests removing those IDs in the key that are
not referring to the mailbox for which the OPENPGPKEY is being created.

> DNS and a particular external user identity.

It seems we have already established a nice family of pixie dust
with the SSHFP, CERT, TLSA, IPSECKEY and CAA records. And of
course other records also publish data on the assumption that
the consumer can trust it due to DNSSEC, such as SPF/TXT records.

DNSSEC is used as a PKI. Half the people who built DNSSEC,
set out to build it as a PKI from the start.

> the vunerability and risks associated with this approach.

You mean, the risk of an MTA receiving a plaintext email and
sending it on as a plaintext email because it did not find an
OPENPGPKEY record? Or an enduser sending an unencrypted email
and not being told by their mail client it could have been
encrypted, and so they send the email in plaintext as they
had planned to originally do anyway?

> MUAs start
> otherwise),

There is no guessing. See above. See WGLC. See dane archive.

> smtp.example.com, or example.com.

It is perfectly clear, and does not involve the MX record whatsoever.
The document states:

    o  The user name (the "left-hand side" of the email address, called
       the "local-part" in the mail message format definition [RFC5322]
       and the local-part in the specification for internationalized
       email [RFC6530]) should already be encoded in UTF-8 (or its subset
       ASCII).  If it is written in another encoding it should be
       converted to UTF-8 and then hashed using the SHA2-256 [RFC5754]
       algorithm, with the hash truncated to 28 octets and represented in
       its hexadecimal representation, to become the left-most label in
       the prepared domain name.  Truncation comes from the right-most
       octets.  This does not include the at symbol ("@") that separates
       the left and right sides of the email address.

    o  The string "_openpgpkey" becomes the second left-most label in the
       prepared domain name.

    o  The domain name (the "right-hand side" of the email address,
       called the "domain" in RFC 5322) is appended to the result of step
       2 to complete the prepared domain name.

Nowhere does it tell you to look at MX records.

> I note in that regard that the first sentence of Section 3 of the
> I-D is simply false.

The first sentence reads:

    The DNS does not allow the use of all characters that are supported
    in the "local-part" of email addresses as defined in [RFC5322] and
    [RFC6530].

RFC 6530 Section 7.1:

 	Permits the use of UTF-8 strings in email addresses, both local
 	parts and domain names.

So you are claiming that DNS can take any UTF-8 character? I guess you
should file an errata for IDNA RFC-3492.

Paul

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2015 17:43:33 -0000

>does not support server-to-server encryption via TLS mandated by RFC

Sure, when I see them which probably won't be for a while.  I'd think
that things being as they are, they would want to encrypt where
possible.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Sep 2015 17:55:26 +0000

> example.net, i.e., the address [email-masked] [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.

> 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.

> the vulnerability and risks associated with this approach.

All I'm saying is that deployments of cryptography for the masses
(e.g. iMessage which is under the microscope lately) have been
successful largely by focusing on usability first at some tradeoff
against absolute security assurance, but the tradeoffs can be quite
sensible.

In the case of this draft, we have a metadata leakage problem (sans
DPRIV).  We also have a directory harvesting problem because queries
are typically intermediated by caching resolvers are difficult to
rate limit.  Finally, we have resolver cache pressure, because
now instead of just the hosts for each domain, resolvers will have
(mostly negative) cache entries for the users of various domains.

And of course "+extension" and other variants are out of scope.
So I have my concerns, they are just mostly different from the ones
you emphasized.

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.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Sep 2015 14:45:22 -0400

Paul,

I am trying very hard, as I believe John Levine is trying, to
identify some substantive and significant issues that we see
with this draft.  I don't think the discussion is moved forward
by the your apparently taking sufficient offense at those
comments and explanations to respond in the tone that you have
adopted.  In the hope of keeping temperatures down, I won't
quote or respond further on those points.

However, because I'm fairly well acquainted with the authors of
RFC 5890/5891 and 6530, I do feel a need to try to correct
misunderstandings that your reading of those documents and their
predecessors seem to have produced.

--On Friday, September 11, 2015 13:38 -0400 Paul Wouters
<[email-masked]> wrote:

>> I note in that regard that the first sentence of Section 3 of
>> the I-D is simply false.
> 

SMTP has a syntax rule -- going back at least to RFC 821 and
transposed into RFC 822 or vice versa (I don't remember and it
makes no difference at this point) -- that prohibits non-ASCII
characters in local parts and imposes that and additional
restrictions on the domain part of mailboxes.  Those
restrictions are specific to email although the SMTP domain
rules became the basis for the "preferred syntax" in RFC
1034/1035.  Those mailbox syntax rules are fairly widely
enforced in email applications.  What RFC 6530 "permits" is the
use of non-ASCII strings in mailbox names as an extension to
SMTP that eliminates that strict ASCII-only syntax rule.  It has
almost nothing to do with the DNS.

RFC 6055 essentially argues that applications should do the
encodings required by IDNA as late (and close to actual DNS
lookups) as possible.  RFC 6530ff are consistent with that
recommendation.

> So you are claiming that DNS can take any UTF-8 character? I
> guess you  should file an errata for IDNA RFC-3492.

RFC 3492 ("Punycode") simply specifies an ASCII-compatible
encoding ("ACE") that can be used when non-ASCII characters are
problematic.  RFC 3490 and its successors 5890, 5801, and the
explanations in 5894 provide, I thought very clearly,
explanations of why such an encoding was (and is) desirable for
IDN use in applications.  Key issues included maintaining a
reasonable level of compatibility with already-deployed
applications that had ASCII-only restrictions and working around
some canonicalization and encoding issues that the installed
base of DNS servers did not handle well.  But there was never a
claim that the DNS couldn't store characters coded in UTF-8 or,
for that matter, any bit sequence in octets.   The latter
capability is made quite clear in the DNS base documents
(1034/1035) and RFC 2181.

Now, for your application, you are defining a new RR Type.
There are no deployed applications that are likely to look that
RR Type up that have ASCII (or "preferred syntax") restrictions
so the IDNA arguments for sticking with an ACE form (whether
using the Punycode algorithm or something you invent) do not
apply.  It may well be that simply using UTF-8 strings is
inappropriate.  However, especially if you are trying to
establish linkages to email mailbox addresses that _must_ be in
UTF-8 or its ASCII subset (not coincidentally, largely because
of the same "no one but the delivery server interprets" rules
that John and I have cited several times), using it directly is
the most obvious solution, obvious to the point that, IMO, you
need to justify anything else.  Whatever that justification
might be, it cannot be that the DNS cannot represent non-ASCII
characters (UTF-8 or otherwise), or even arbitrary octets,
because it definitely can handle such strings in labels and has
been able do so since its inception.

best regards,
    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Sep 2015 15:34:26 -0400

--On Friday, September 11, 2015 17:55 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> (1) A delivery server at smtp.example.com, for whatever
>> reason, associates [email-masked] and
>> [email-masked] 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
>> [email-masked] [1]. 
> 
> example.  Sometimes with extreme consequences.  I recall one
> example where a confidential message intended for a lawyer was
> sent his brother the journalist...
> 
> 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).

> 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).

> 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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2015 15:57:36 -0400 (EDT)

On Fri, 11 Sep 2015, John C Klensin wrote:

>> So you are claiming that DNS can take any UTF-8 character?

> (1034/1035) and RFC 2181.

We are not talking about the RDATA part - we are talking about the DNS
label (aka hostname or qname). A primer from the dns terminology draft:

    Host name:  This term and its equivalent, "hostname", have been
       widely used but are not defined in [RFC1034], [RFC1035],
       [RFC1123], or [RFC2181].  The DNS was originally deployed into the
       Host Tables environment as outlined in [RFC0952], and it is likely
       that the term followed informally from the definition there.  Over
       time, the definition seems to have shifted.  "Host name" is often
       meant to be a domain name that follows the rules in Section 3.5 of
       [RFC1034], the "preferred name syntax".  Note that any label in a
       domain name can contain any octet value; hostnames are generally
       considered to be domain names where every label follows the rules
       in the "preferred name syntax", with the amendment that labels can
       start with ASCII digits (this amendment comes from Section 2.1 of
       [RFC1123]).

And RFC-1123 states:

2.1  Host Names and Numbers

       The syntax of a legal Internet host name was specified in RFC-952
       [DNS:4].  One aspect of host name syntax is hereby changed: the
       restriction on the first character is relaxed to allow either a
       letter or a digit.  Host software MUST support this more liberal
       syntax.

       Host software MUST handle host names of up to 63 characters and
       SHOULD handle host names of up to 255 characters.

RFC-1101 Section-3.1 states:

    The current syntax for network names, as defined by [RFC 952] is an
    alphanumeric string of up to 24 characters, which begins with an
    alpha, and may include "." and "-" except as first and last
    characters.  This is the format which was also used for host names
    before the DNS.

So based on these references, do you believe the following are legal
DNS entries:

münchen._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
jon..smiths._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
jon\.smiths._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
jon\\smiths._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
jon*smiths._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
42._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
-paul-._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
1111111111222222222233333333334444444444555555555566666666661234._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa._openpgpkey.nohats.ca.  IN OPENPGPKEY MAo=
lines---lines._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=
😱 ._openpgpkey.nohats.ca. IN OPENPGPKEY MAo=

Let's see what the tools say:

$ named-checkzone nohats.ca nohats.ca 
nohats.ca:22: using RFC1035 TTL semantics
dns_master_load: nohats.ca:210: empty label
dns_master_load: nohats.ca:213: label too long
dns_master_load: nohats.ca:214: label too long
nohats.ca:216: unknown RR type '._openpgpkey.nohats.ca.'
zone nohats.ca/IN: loading from master file nohats.ca failed: empty
label
zone nohats.ca/IN: not loaded due to errors.

$ ldns-read-zone nohats.ca
Syntax error, could not parse the RR's rdata at 203

$ validns nohats.ca 
nohats.ca:170: record name is not valid
nohats.ca:205: record name is not valid
nohats.ca:206: invalid or unsupported rdtype openpgpkey
nohats.ca:207: record name is not valid
nohats.ca:208: invalid or unsupported rdtype openpgpkey
nohats.ca:209: invalid or unsupported rdtype openpgpkey
nohats.ca:210: invalid or unsupported rdtype openpgpkey
nohats.ca:211: invalid or unsupported rdtype openpgpkey
nohats.ca:212: record name expected

Furthermore, as DNS is case sensitive you would have the problem of

jonsmiths._openpgpkey.nohats.ca.  IN OPENPGPKEY <blob1>
JonSmiths._openpgpkey.nohats.ca.  IN OPENPGPKEY <blob2>

which would be the same DNS label in DNS.

Therefor, I stand by the first line in section 3.1 of the draft
that you believe is false:

And in fact, I'd say email addresses with local-parts of > 63
characters are in fact more likely that case-sensitive local-part
delivery to different users.

> largely because
> need to justify anything else.

Note that as document author, I stated my preference was for hashed
lowercse lookup but I would be okay with the base32 split solution. The
consensus the chair posted to the list was to use hashes without
lowercasing.

My own IETF LC comment was that I think the document should address the
issue of different case by either adding a lowercase or a second lookup
(neither of which is 'guessing')

Paul

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 11 Sep 2015 16:11:41 -0400

On Friday, September 11, 2015 03:34:26 PM John C Klensin wrote:
...
...

To pull out this one point...

I tried to discuss this in the WG, but didn't get very far [1].  I agree the 
experiment in the experimental draft is underspecified.

Scott K

[1] https://mailarchive.ietf.org/arch/msg/dane/4gMgt2MiYLWYTmP-mOgcxuOqqxg

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2015 21:25:49 -0000

In article <[email-masked]> you write:
>label (aka hostname or qname). ...

Hold it.  Every hostname is a DNS name, but most possible DNS names
are not hostnames.  To take an obvious example, none of the names that
this draft specifies for the names of PGP keys are hostnames, because
hostnames are limited to ASCII letters, digits, and hyphens, and the
key names all contain underscores.

Since they're not hostnames, I agree with John K that there is no
reason to limit the representation of a local-part to hostname
characters.  Names in the DNS really can be arbitrary octets, up to 63
octets per component, and the DNS handles them completely
transparently (other than the rule to fold ASCII upper and lower case
letters.)  If you put UTF-8 names directly into the DNS, your master
file would be kind of ugly but it would work fine.  I've done it.

R's,
John

PS: It's dismaying to see confusion about basic DNS concepts at such a
late point.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Sep 2015 08:18:49 +1000

> file would be kind of ugly but it would work fine.  I've done it.

And the DNS is supposed to preserve the case of entered labels.

RFC 1034

"By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit.  This means that you are free to create a node with
label "A" or a node with label "a", but not both as brothers; you could
refer to either using "a" or "A".  When you receive a domain name or
label, you should preserve its case.  The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed."

Later versions of BIND 9 do that to the RRset level and it would
be possible to do it to the RR level if needed.  It is theoretically
possible to distingish between JoeSmith and joesmith if preservation
to the RR level is done for arbitary DNS data.  You would get back
all data and the client would need to check the case of the owner
names if the owner name is supposed to be case sensitive and only
use those that match.

However for OpenPGP you don't need case preservation in the DNS at
all as the key blob contains the original case.  If the MUA is not
checking this in the key blob it is broken.

Most but not all clients correctly cope with a different casing
being returned to that of the question in the answer section.  It
is up to the client to know if what they lookup is case sensitive
or not.  Some of them don't treat hostnames case insensitively when
looking for responses hence the acl below.

4079.   [func]          Preserve the case of the owner name of records to
                        the RRset level. [RT #37442]

3731.   [func]          Added a "no-case-compress" ACL, which causes
                        named to use case-insensitive compression
                        (disabling change #3645) for specified
                        clients. (This is useful when dealing
                        with broken client implementations that
                        use case-sensitive name comparisons,
                        rejecting responses that fail to match the
                        capitalization of the query that was sent.)
                        [RT #35300]

3645.   [protocol]      Use case sensitive compression when responding to
                        queries. [RT #34737]

3007.   [bug]           Named failed to preserve the case of domain names in
                        rdata which is not compressible when writing master
                        files.  [RT #22863]

2855.   [func]          nsupdate will now preserve the entered case of domain
                        names in update requests it sends. [RT #20928]

2236.   [bug]           dnssec-signzone failed to preserve the case of
                        of wildcard owner names. [RT #17085]

1811.   [func]          Preserve the case of domain names in rdata during
                        zone transfers. [RT #13547]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Sep 2015 09:25:49 -0400

--On Friday, September 11, 2015 16:11 -0400 Scott Kitterman
<[email-masked]> wrote:

>>         * 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).
> ...
> 
> I tried to discuss this in the WG, but didn't get very far
> [1].  I agree the  experiment in the experimental draft is
> underspecified.
> 
> Scott K
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/dane/4gMgt2MiYLWYTmP-mOg
> cxuOqqxg

While I continue to believe that there are substantive issues
with this proposal and that the document would need work even if
those substantive issues were dismissed or overcome, it seems to
me that there may also be a procedural one in that there have
been several claims about attempts to raise issues in the WG
that, to quote the above, "didn't get very far".   I just looked
at the shepherd's report
(https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup/).
It, interestingly, still indicates that the WG wants Proposed
Standard, and that "The working group consensus is strong about
advancing this document.".   It does not mention what one can
infer from the IETF was lively, and still unresolved, discussion
about a number of issues, including requested status.

It also indicates that this particular hashing mechanism was
adopted because the email community was asked for reviews and
that more review from them would be welcome.   I don't know what
was tried; I do know that some of the comments to the effect of
"tried and didn't get very far" came from people who are
considered members of the "email community" and that there were
no requests for specific comments addressed to, e.g., the
standing SMTP mailing list.

The shepherd's report also asks for 'More review from email
community will not hurt, but unless they have an sudden insight
as how to "cannonize" email address this is the best we can do'.
As has been noted in several comments during Last Call,
canonicalization of email addresses (much less efforts to
'cannonize' them) is prohibited by RFC 5321 (and 821 and 2821),
so this is not going to be a matter of insight, at least until
or unless the IETF produces a standards-track protocol that
updates and replaces those SMTP provisions with specific
required local-part formats and rules.  The comments in the
shepherd's report imply that the WG was not aware of those
restrictions.  Independent of the substance of the matter, that
is a serious procedural problem.  If people tried to raise it in
the WG and were ignored or dismissed (even in the shepherd's
report) that is even more serious.

I believe that, even if there were no other problems, those
procedural issues should cause the IESG to return the document
to the WG, request the document more consistently reflect its
proposed status, and get a shepherd's report that more
comprehensively reflects issues that have been raised (either in
the WG or in LC) and how they were resolved, rather than
claiming "strong consensus" about issues that apparently remain
controversial or expecting the community to come up with a
canonicalization approach without commenting on the relationship
of such an approach to SMTP requirements.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 12 Sep 2015 16:29:20 +0100

On 12/09/15 14:25, John C Klensin wrote:
> to the WG,

I don't agree. We see outdated and less informative shepherd reports
all the time and I've never seen one of those that was by itself a
sufficient reason to send a draft back to the WG. Many are worth
correcting, but the idea that shepherd reports must be perfect isn't
one we ought adopt.

The other procedural issue mentioned was folks who commented in the
WG to the effect that there was one or other problem with this draft.
I also don't think any of those, nor the accumulation of them, raise
to the level where they are a procedural reason to send this back to
the WG. As far as I've seen, the WG did fully debate this draft. (If
someone thinks I'm missing something there feel free to send me mail
pointing out what was raised but not considered by the WG.)

Note: the above is only commenting on whether or not we have purely
bureaucratic reasons to send this back or not. I conclude that we
do not. I have still re-read the technical comments from the LC to
figure out what I think of those.

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Sep 2015 16:28:58 -0400

> And the DNS is supposed to preserve the case of entered labels.

[…]

> be possible to do it to the RR level if needed.

I am not confident that doing it to the RR level would be a good idea
in the DNS, and I'm not sure that the DNS protocol is sufficiently
carefully described that making the distinction between RRs and the
RRset in this way would be successfully interoperable.  Certainly,
this is an area that's underspecified, so there's no way anyone should
be building hopes (never mind a protocol) on top of distinctions
between the RRset's and constituent RR's owner names.

> to the RR level is done for arbitary DNS data.

But we know perfectly well that the "case preserving but
case-independent matching" has been interpreted in all sorts of
different ways (some obviously wrong, but others different yet
consistent with the RFCs).  So let's again please not depend on
anything like this as part of any specification.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Sep 2015 17:14:04 -0400

--On Thursday, September 24, 2015 16:28 -0400 Andrew Sullivan
<[email-masked]> wrote:

>> Later versions of BIND 9 do that to the RRset level and it
>> would be possible to do it to the RR level if needed.
> 
> I am not confident that doing it to the RR level would be a
> good idea in the DNS, and I'm not sure that the DNS protocol
> is sufficiently carefully described that making the
> distinction between RRs and the RRset in this way would be
> successfully interoperable.  Certainly, this is an area that's
> underspecified,
>...

Speaking as someone who, in this area, is far more qualified to
be a victim than an expert, can we please get things that
affects what people can and cannot reasonably expect written
down somewhere, perhaps as an update to RFC 2181?  It seems to
me that differences in expectations, inconsistent
implementations, and inconsistent interpretations of what the
standards actually require, turn rather quickly into fundamental
interoperability issues (and those often turn into security
vulnerabilities), rather than mere issues of different choices. 

Expectations about case preservation under different scenarios,
with comments about how strong those expectations should be
given various implementations (including but not limited to
earlier versions of BIND) would seem to be candidates.  I don't
know how many DNS implementations are now taking U-labels or
even UTR-46-conformant strings, and input for zone files, but
some comments about expectations there, especially when a label
is mostly, but not entirely, ASCII characters, may be in order
too [1].  I assume that you, Mark, the leadership of DNSOP, and
others have much longer list [2].

best,
   john

[1] It is very clear in the IDNA documents, but IDNA was written
so that DNS implementations didn't need to pay attention to it
and apparently, some haven't.

[2] I observe that one recent document got all the way through a
DNS-related WG and into IETF Last Call with an included
assumption that it was not possible to put a non-ASCII character
in a DNS label, something that I think is very clear in 1034 but
that 2181 makes even more explicit.  The DNS expert community
clearly has got some education to do, both inside and outside
the IETF.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Sep 2015 17:30:54 -0400

Hi,

On Thu, Sep 24, 2015 at 05:14:04PM -0400, John C Klensin wrote:
> down somewhere, perhaps as an update to RFC 2181?

On this general issue, note that there was a recent IETF LC (and IESG
approval) of a terminology document that is only a _start_ on this.
But it is a start.  We need more help.

Not to put too fine a point on it, the DNS is everywhere, and it has
evolved quite a bit.  There's no question that there are gaps in the
specifications.  But the last time we attempted to do document updates
without a lot of sponsorship (which is how I got to be the lucky
winner of the second chair in DNSEXT), the effort foundered for lack
of humans to review, test, and so on.

If this effort is needed, the community needs to do it.  I am not
(happily) in a position to force that to happen.

> given various implementations

In my opinion, all you can rely upon is that case-insensitive matching
happens for any octet that happens to match the ASCII range of
letters.  Preservation will happen _somewhere_ in the DNS message
(maybe in the question section only) for any conforming
implementation, but that's about it.  In a distributed-management and
distributed-cache database like the DNS, I confess that I find
expectations much beyond that to be poor candidates for probable
satisfaction.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 Sep 2015 17:34:47 -0400

Is RFC 4343 adequate?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Sep 2015 09:04:24 +1000

> between the RRset's and constituent RR's owner names.

Almost all nameservers are not compliant with RFC 1034 in this area.
The recent changes we made to named were to bring it more into line
with RFC 1034.  Full compliance would be preservation to the RR
level.  It would roughly be a extra bit per octet in the ownername
per additional RR storage as the information needs to be stored
somewhere.

RFC 1034
				      When you receive a domain name or
label, you should preserve its case.  The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed.

This is at the RR level as the concept of RRset didn't exist when
RFC 1034 was written.

Preserving the case is a matter of engineering the databases and
the data paths to support it (don't discard the case information)
and doing case sensitive compression when sending responses.  The
wire format supports both lossy and lossless compression.  It's
just a matter of picking the appropriate sequence of octets when
looking for compression pointer targets as you construct the DNS
message.  Fixing a nameserver to do this is not a overly big task
to someone familiar with the internals.  You get to the 90+% level
just by doing case sensitive compression and not using the question
name unless it is appropriate as a compression targt as most RRsets
consist of a single RR.

EDNS(1) could specify lossless compression required for all names
and is allowed for type A, B, C, D rdata where compression is
currently banned.  This wouldn't break DNSSEC.

Fixing this now would mean we could use it in 10 years time as the
non-compliant servers would almost all be gone.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Sep 2015 22:22:03 -0400

Hi Mark,

On Fri, Sep 25, 2015 at 09:04:24AM +1000, Mark Andrews wrote:
> label, you should preserve its case.

> This is at the RR level as the concept of RRset didn't exist when

While I certainly resepect your interpretation and agree it's a strong
and plausible one, it is not the only possible one.  Moreover, since
RFC 2181 updates 1034 it doesn't matter for the protocol (as a whole)
that 1034 doesn't talk about RRsets; indeed, it makes the problem
worse.  I also respect and agree with your remarks about the relative
cost of implementation, but we don't have documents that say all that
and therefore we have a gap.  I'd be extremely happy if such documents
showed up.  Still, the history of such clarifications about the DNS
does not make me optimistic.  Moreover, as Don Eastlake indirectly
points out, RFC 4343 observes that the preservation is not as complete
as one wants.

> non-compliant servers would almost all be gone.

Perhaps, but the bigger hurdle is getting consensus and ensuring that
naïve implementers don't just read STD13 and maybe some other stuff.
DNSEXT had one go at a clearer document set (along the lines of the
updates of RFC 821/822) but didn't deliver.  Since I was co-chair
during the failure I will shoulder the blame.  But if you know a way
to make such an update successful the next time, I believe people
would value it.

I think this is a hard social problem, not a hard technical problem.
Maybe a few people interested in solving these problems could find a
way to get together in Yokohama or elsewhere, and try again at
incremental steps?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]