Subject: dane-openpgp 2nd LC resolution

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Mar 2016 15:10:07 +0000

Hi all,

The 2nd IETF last call for this started on Feb 8th.
Thanks again for the lively discussion.

The tl;dr version is: once a revision addresses the
substantive issues raised as per below, taking into
account reactions to this summary, and we have a chance to
take a quick look at -08 (I'll extend the LC to the date
of the -08 version plus one week), then if no new
substantive issues arise, I think we have rough consensus
to go forward with this experiment (and others to come)
and let the IESG review the document.

Cheers,
S.

The substantive issues that arose in the 2nd last call
were:

1. The context of the experiment
2. Changes to the trust model
3. The local-part (lhs) issue and i18n

For each, I'll say where I conclude we've ended up and
recommend what to do for -08.

1. The context of the experiment
--------------------------------

I think part of the reason this one has been hard has been
a perception that we're developing the one true way to
retrieve key retrieval for e2e email security.  The
resolution here is to include text like that below in all
similar experiments.

"This specification is one experiment in improving access
to public keys for end-to-end email security. There are a
range of ways in which this can reasonably be done, for
OpenPGP or S/MIME, for example using the DNS, or SMTP, or
HTTP.  Proposals for each of these have been made with
various levels of support in terms of implementation and
deployment.  For each such experiment, specifications such
as this will enable experiments to be carried out that may
succeed or that may uncover technical or other impediments
to large- or small-scale deployments. The IETF encourages
those implementing and deploying such experiments to
publicly document their experiences so that future
specifications in this space can benefit."

2. Changes to trust model
-------------------------

John Levine noted a place where -07 seems to be saying a
bit too much:

" In sections 1 and 7, it claims that finding a key
through DNS lookup is not a substitute for web-of-trust
verification, which is fine.  But section 5.2 says that if
a domain publishes a key for an address that's
inconsistent with an existing key, verification of the key
is "treated as a failure."  It's unclear what the effect
is supposed to be, but considering the discussion of the
lost key problem, it appears that the intent is that the
sender would stop using the old key. "

I think the text is 5.2 is a little ambiguous so suggest
the change below, which clarifies that the failure is
in the confirmation step and that the resulting action
is dependent on local policy and is not being determined
by taking part in the experiment.

OLD:

Locally stored OpenPGP public keys are not automatically
refreshed.  If the owner of that key creates a new OpenPGP
public key, that owner is unable to securely notify all
users and applications that have its old OpenPGP public
key.  Applications and users can perform an OPENPGPKEY
lookup to confirm the locally stored OpenPGP public key is
still the correct key to use.  If the locally stored
OpenPGP public key is different from the DNSSEC validated
OpenPGP public key currently published in DNS, the
verification MUST be treated as a failure unless the
locally stored OpenPGP key signed the newly published
OpenPGP public key found in DNS.  An application that can
interact with the user MAY ask the user for guidance.  For
privacy reasons, an application MUST NOT attempt to lookup
an OpenPGP key from DNSSEC at every use of that key.

NEW:

Locally stored OpenPGP public keys are not automatically
refreshed.  If the owner of that key creates a new OpenPGP
public key, that owner is unable to securely notify all
users and applications that have its old OpenPGP public
key.  Applications and users can perform an OPENPGPKEY
lookup to confirm the locally stored OpenPGP public key is
still the correct key to use.  If the locally stored
OpenPGP public key is different from the DNSSEC validated
OpenPGP public key currently published in DNS, the
confirmation MUST be treated as a failure unless the
locally stored OpenPGP key signed the newly published
OpenPGP public key found in DNS.  An application that can
interact with the user MAY ask the user for guidance,
otherwise the application will have to apply local policy.
For privacy reasons, an application MUST NOT attempt to
lookup an OpenPGP key from DNSSEC at every use of that
key.

3. The local-part (lhs) issue and i18n
---------------------------------------

This has always been and will always be an issue for any
solution in this space. Absent changes to the mail
architecture, or major changes to email protocols and
deployment, it will always be an issue. And it's quite
related to the  "joe+ietf" kind of lhs too, which'd need
to be considered for a general solution to the problem.  I
conclude that the right thing here is to do experiments,
but for those to not try to solve the general issue, and
instead to define the limits within which the experiment
is to be done. In this case, I think the only tractable
thing is stick with the lhs handling in -07, to note that
implementations are in fact not quite doing that, and to
point to an existing well-thought out description of some
some of the issues. To that end I suggest renaming section
4 to become "Email address variants and
internationalisaion considerations." and adding the
following NEW text to the end of the section:

"Section 3 above defines how the local-part is used to
determine the location in which one looks for an
OPENPGPKEY record. Given the variety of local-parts seen
in email, designing a good experiment for this is difficult
as: a) some current implementations are known to lowercase
at least US-ASCII local-parts, b) we know from (many)
other situations that any strategy based on guessing and
making multiple DNS queries is not going to achieve
consensus for good reasons,  and c) the underlying issues
are just hard - see Section 10.1 of RFC 6530 for
discussion of just some of the issues that would need to
be tackled to fully address this problem.

However, while this specification is not the place to try
to address these issues with local-parts, doing so is also
not required to determine the outcome of this experiment.
If this experiment succeeds then further work on email
addresses with non-ASCII local-parts will be needed and
that would be better based on the findings from this
experiment, rather than doing nothing or starting this
experiment based on a speculative approach to what is a
very complex topic."

Misc comments
-------------

- There were also a bunch of nits noted in [1] that we
may as well fix in -08.

[1] https://mailarchive.ietf.org/arch/msg/ietf/7qqmoghCO_BfAt3YdRn81chn5Mc

---

From: E Taylor <[email-masked]>
Date: Tue, 08 Mar 2016 02:16:20 +0000

Hi Stephen,

> and let the IESG review the document.

Thanks for producing this summary and these suggestions, with specific
sections of text to be added, which gives a clear picture of what we're
discussing.  I was initially concerned that your additions, and the
general process of updating the drafts to reach consensus, might have
made the document become an unruly patchwork, but I took the time to
re-read it, in light of what you propose, and it actually holds together
remarkably well.

In particular, I think your judgement on the casing / i18n issue is
sound, and seeing it in the context of the whole document makes it feel
like the most technologically neutral and acceptable solution.  It puts
no undue burdens on the traditions and best practices of the DNS
community, nor on the email community.  As you say, more work in a
future Standards Track document can be done to extend the approach
specified in the draft, but "doing so is also not required to determine
the outcome of this experiment".

One thing I wanted to bring to wider attention, though, was an
observation I made in looking at RFC 4398 (which is referenced in
section 1.1 of the draft).  That RFC, Storing Certificates in the Domain
Name System (DNS), says:

>    OpenPGP signed keys (certificates) use a general character string
>    User ID.  However, it is recommended by OpenPGP that such names
>    include the RFC 2822 email address of the party, as in "Leslie
>    Example <[email-masked]>".  If such a format is used, the CERT
>    ought to be under the standard translation of the email address into
>    a domain name, which would be leslie.host.example in this case.  If
>    no RFC 2822 name can be extracted from the string name, no specific
>    domain name is recommended.

(internal references removed).  This is interesting because not only
does it not consider a non-ASCII (or even give an example of a
non-alphabetic) local-part, but it also happily lower-cases the
local-part, "under the standard translation of the email address into a
domain name".

Admittedly this RFC is from 2006, and of course it is good that the IETF
is now thinking harder about non-ASCII use cases, but I think that the
fact that this RFC was accepted onto the Standards Track, with that
approach to email addresses, reinforces your point that the experiment
of dane-openpgp can safely go ahead while leaving some questions open
until further data has been accumulated from wider deployment of this
technology.

I look forward to the closing of the extended LC, and to reading the
IESG's review of the -08 draft.

Best regards,
Edwin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Mar 2016 17:08:25 +0000

Hiya,

> and let the IESG review the document.

Paul has now posted -08 (diff at [1]) so this mail is
to extend the IETF LC until March 15th.

Thanks,
S.

[1] https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-08

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Mar 2016 04:00:55 -0500

--On Sunday, March 06, 2016 15:10 +0000 Stephen Farrell
<[email-masked]> wrote:

>...
>...
>...

Stephen,

I've been thinking about this for a few days and have concluded
that I do not agree with your "resolution" and proposed
approach.  All of what you write would be reasonable (whether we
agree or not), except for two closely-related issues:

(1) The IETF should not be encouraging experiments on the public
Internet that could be harmful to the Internet or to existing
deployed applications, especially standards-track ones.  Several
people with significant email operational experience have made
the claim that this experiment could be harmful to the
Internet's email infrastructure, if only by encouraging a
violation of a fairly explicit (and very important, IMO)
provision of SMTP.  As far as I can tell from reviewing the
discussions, there has not even been effort to refute those
claims or explain why they are not relevant.

The attitude associated with the problem -- and why I think it
is an important problem -- is perhaps best summarized in a note
from the author posted today: 

--On Friday, March 11, 2016 07:51 -0500 Paul Wouters
<[email-masked]> wrote:

>...
> I believe the chairs stated that the experiments of dane for
> openpgpkey and smime can continue without tackling every
> corner case of local-parts. Fixing the local-parts is up to th
> email community, not the dane community.

First, there is apparently disagreement with the email community
about what is and is not a corner case.  Many of the issues that
have been raised (and the text that appears in -08) appear to at
least some of us to involve relatively mainstream cases.
Equally important, a "corner case" in email addresses may
represent a few million messages a day, which I don't believe
should be so lightly dismissed.

I believe it has been said before, but the first sentence of
Section 4 is either much more informal language than it appears
to be (and somewhat misleading in the process) or it is wrong.
Most (final delivery) mail systems support aliases for mailbox
names.  The specifications make no assumptions, and systems
differ, about whether there are lexical or semantic
relationships among the set of aliases for a given mailbox, much
less what those relationships might be.  Whether those aliases
are somehow "variant forms" is in the mind of the beholder.
However, if the specification simply hashes the local part
string as given (as specified in section 3), then at least most
of that first paragraph of Section 4 is gratuitous and should be
out of scope for this document and dropped.

While I generally like the "it is just an experiment"
justification for publishing and moving on, it seems to me,
after having reviewed the discussion of Experimental status in
2026, including the specific comment about limited use in 3.3(d)
and thinking about evolution since 2026 was published, that
there are two reasons for publishing an experimental
specification from an IETF WG.   One is to encourage widespread
experimentation, an approach we have often taken when we are not
sure enough about a proposal to standardize it.  The other, I
believe much less used in recent years, is precisely the
"limited use" case that 2026 seems to anticipate: use only by a
prearranged group of people who understand what they are getting
into and a recommendation to the broader community that they
_not_ attempt to use it until after the experiment is reported
upon.  While your new paragraph in Section 1.1 and the end of
Section 4 of -08 is a considerable improvement in other ways, it
does not contain any hint of that "limited use" restriction or
other warning notice nor is there any warning in Section 8.
Given that there are unrefuted claims that this "experiment"
could cause harm in or to the deployed email infrastructure or
create additional security risks, that seems necessary.

(2) In general, we've explained the purpose of an IETF Last Call
as allowing review across area and from multiple perspectives
with the intention of resolving issues that are identified by
the process prior to publication.  When one community finds a
problem in a specification, we generally (I believe never) allow
the document's authors to say "we've made this mess, if you
think it is a problem, it is your job to clean it up".  I'm
sympathetic to the next text at the end of Section 4 and the
desire to experiment first and deal with the so-called
canonicalization problems later but:
(a) Saying "some current implementations... lowercase at least
US-ASCII local-parts" misses the point to the degree that it is
misleading.   RFC 5321 rather explicitly allows a final delivery
MTA ("MDA") to make whatever equivalence rules it likes,
certainly including applying any lower-case procedure it
considers appropriate.  However, nothing else is allowed to do
so and it is no more appropriate for me, as a sender of mail to
you, to assume that [email-masked] will work and
reach you rather than your colleague Joe Bloggs than it is for
me to assume that [email-masked] will reach you and not Steven
Bloggs.   Because at least one of the "possible harm" scenarios
is associated with that particular alternate-local-part-guessing
procedure, this example is significant rather than facetious.
(b) We've been told during the Last Call that repeated efforts
by email experts to inject these issues into the discussion and
have them properly reflected in the document have been ignored,
met with abuse, or turned into "we don't care about that
problem, you solve it if you do" comments.  I note that the last
sentence of the quotation from Paul Wouter's note above is
consistent with those claims -- it asserts that the problem is
the email community's to fix and not a DANE responsibility and
may imply that the definition of email local-parts (a definition
that is at least around 35 years old and arguably nearly a
decade older than that and supported in _very_ widely
implemented and deployed systems) is the problem and not how
DANE wants to handle them.  

The situation with this document is in danger of turning into a
"victory for attrition" pattern, in which the "victor" is the
party with the most energy for continuing the discussion for the
longest period of time.  Whichever side on is on, that is not a
good way to make decisions that are supposed to represent IETF
consensus.  Extending the Last Call in a situation like this one
encourages that pattern by wearing those with concerns based on
relevant knowledge and expertise to just give up from exhaustion
and the demands of other work.

I therefore suggest that the approach of extending the Last Call
be dropped and that either the document be returned to the WG
for careful consideration of the input from the email community
(moving the WG into ART if that review cannot occur adequately
under SEC supervision) or that the IESG as a whole take a
position on it.   If it does decide to advance it, I strongly
suggest inclusion of an applicability statement that specifies
limited use and that carries appropriate warnings.

  best,
     john

p.s.  I hope this can be resolved in a less time-consuming way
and without my having to decide on whether a next step is needed
(and would welcome comments from others on that subject), but I
trust you have noticed that the statement above is in
substantially the form that could be considered as the "contact
the relevant AD" first step in an appeal of how this document is
being handled.

---

From: Doug Barton <[email-masked]>
Date: Sat, 12 Mar 2016 12:15:51 -0800

On 03/12/2016 01:00 AM, John C Klensin wrote:
> The IETF should not be encouraging experiments on the public

Has anyone laid out the perceived dangers in an easily digestible 
format? I would be interested to see that discussion.

Given that the DNS RR in question is something the end user has to 
explicitly request, the danger is not immediately obvious to me.

Doug

---

From: Paul Wouters <[email-masked]>
Date: Sat, 12 Mar 2016 16:09:50 -0500 (EST)

On Sat, 12 Mar 2016, Doug Barton wrote:

> Has anyone laid out the perceived dangers in an easily digestible format? I 
> would be interested to see that discussion.
>
> Given that the DNS RR in question is something the end user has to explicitly 
> request, the danger is not immediately obvious to me.

That is not clear to me either, since the _delivery_ is unchanged, and
still goes to the local-part _exactly_ as specified by the user. So the
risks here are:

1 Failure to find an existing OPENPGPKEY record, email goes out in plaintext just as
   if this draft never existed.

2 In an email server has [email-masked] and [email-masked], AND these
   are different users, then instead of JUST mailing the wrong user in
   plaintext, the wrong user is emailed encrypted to that user. This is
   functionaly still better than the current deployment, since only 1
   wrong user can see the (encrypted) email instead of everyone on the
   path plus the user who can see the never-encrypted email.

However, the email community experts themselves have already stated that
finding an email server compliant to case 2 is a theoretical exercise
only.

Paul

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2016 11:10:29 -0400

Paul, Doug,

I want to respond to two issues/questions only right now and am
going to do so in two separate messages.  Perhaps someone else
will get to the other questions before I do -- I think they have
been answered and explained several times already.   This is
therefore message 1 of 2.

I don't know why we (that "email community") and you (Paul) are
having so much trouble communicating, but

--On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters
<[email-masked]> wrote:

>...
> However, the email community experts themselves have already
> stated that finding an email server compliant to case 2 is a
> theoretical exercise only.

I can't speak for others, but I certainly didn't say that.

The specs (and generally-accepted good practice) recommend using
prohibition, aliasing (of some flavor), or other mechanisms to
avoid making subtle distinctions in addresses that are likely to
be confusing to users and/or to stress expectations about human
memory and precision beyond reasonable limits.  I would
certainly recommend that a final delivery system not provide a
mailbox named [email-masked] to a different recipient than a
mailbox named [email-masked].  I am agnostic about whether
they should be the _same_ mailbox or associated with the same
key: some recipient might plausibly use an obscure form of an
address as a mail classification tool or as part of a very cheap
sender-checking model.  Such models, whether done that way or by
subaddresses or the like, are surprisingly effective against
casual bulk attacks even if much less so against focused and
determined ones.   

The same thing could be said for other distinctions.  For
example, [email-masked] is a popular form for a
local-part and has been used on some systems for years.  IIR,
there is even a standards-track spec that recommends it.  I
would certainly not suggest that a system that uses that form
for local-parts also support separate mailboxes, assigned to
separate recipients, named like "[email-masked]".
Whether is it better to not support the latter at all, to make
it an alias for the [email-masked] form, or to
algorithmically remove the special characters(s), possibly also
making [email-masked] point to the same mailbox, is a
matter of taste: the specs are (deliberately) mute on the
subject.

However, there is a huge difference between "bad idea to assign
these different mailbox names to different recipients and I'm
not aware of any contemporary system that does it" and
"theoretical exercise only".  It is really not hard to imagine
reasons for doing such things (no matter what you, or I, think
about them). They are explicitly allowed by the spec and are a
part (if only a small one) of why there are "no guessing" rules
in 5321 and elsewhere.   And that, in turn, brings me back to a
point I've tried to make several times: it is a bad idea to try
to modify the rules about interpreting mailbox names (or "email
addresses" if you prefer) via some sort of back door, even an
experimental one.    If you want to modify those rules, write
something that does it up-front and explicitly (and that
"updates" 5321), rather than trying to hide it in a
key-retrieval spec.

Now, having said all of that, I want to note that this has
little or nothing to do with the protocol requirements of
draft-ietf-dane-openpgpkey-08.   At least as I read it, that I-D
simply applies a hash function to the mailbox name as given and
does not attempt to find "equivalent" or "canonical" names.
That means that the very worse case is a false negative about
finding a key.  You want to experiment with that, fine -- I
won't lose any sleep over it.  I do believe that, if that is the
protocol spec, there is a lot of surplus and confusing text in
the I-D that should just come out.  Alternately, if you really
believe that draft-ietf-dane-openpgpkey should do aliasing or
canonicalization, take that up on the SMTP and/or DANE lists
(where you and Warren reported you've already lost the argument
once), not here.   Making the argument on the IETF list is
really just demonstration that there is no IETF consensus about
the draft of which you are the author because these issues are
unresolved and important.

    john

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2016 11:40:39 -0400

Part 2 of 2 -- see introduction to immediately prior note.

--On Saturday, March 12, 2016 12:15 PM -0800 Doug Barton
<[email-masked]> wrote:

> Given that the DNS RR in question is something the end user
> has to explicitly request, the danger is not immediately
> obvious to me.

--On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters
<[email-masked]> wrote:

> 2 In an email server has [email-masked] and [email-masked],
> AND these are different users, then instead of JUST mailing
> the wrong user in plaintext, the wrong user is emailed
> encrypted to that user. This is functionaly still better than
> the current deployment, since only 1 wrong user can see the
> (encrypted) email instead of everyone on the path plus the
> user who can see the never-encrypted email.

That depends entirely on the threat model you are concerned
about.   I (and others) have repeatedly asked that you be
explicit in the I-D about applicable threat models (aka "the
problem you are trying to solve") in more specificity then you
have now and that you see if you can get consensus.   If the
goal is to try to get more email on the Internet encrypted as an
"opportunistic" matter, then certainly your reasoning is
correct, perhaps modulo one other issue.

In our quest for more privacy, language like "everyone on the
path" implies something similar to letters being posted in shop
windows for public viewing before being delivered (or as a means
of delivery).  The reality is the most ISPs, and most operators
of mail servers and relays, take at least some measures (often
strong ones) to ensure that the collection of people who can get
to a message in transit is very restricted and a lot short of
"everyone".  Yes, those measures, and the ISPs and mail
providers themselves, can be subverted or forced to expose
message traffic, but the parties who can do that aren't
"everyone" either.  If one is interested in attacks from them
--either on you or as part of a pervasive surveillance effort--
then the threat model changes quite a bit.

In particular, if a user has a sensitive information to
transmit, information that will not be transmitted at all unless
there is high assurance that it will go encrypted and encrypted
in the key of the right party, then the choice between "one
wrong person sees it" and "everyone sees it" is a not-starter.
With the treat model implied by that sort "must go encrypted"
model for sensitive material, the alternative to "correctly
encrypted" is "don't send" and sending and delivering to the
wrong party, encrypted with that party's key, is a disaster.

In the hope of avoiding a rat hole, the above has nothing to do
with the argument that everything should be encrypted to provide
cover for the sensitive stuff or make life harder for those
involved in pervasive surveillance.  If one believes that
everything should be encrypted, then it may be ok be less
careful about how messages that are less sensitive are encrypted
(keys found, etc.) than for ones containing really sensitive
materials.

best,
    john

p.s. See last paragraph of part 1 for comments -- slightly less
applicable here -- about the relationship of this discussion to
the dane-openpgp draft.

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2016 17:11:01 -0000

>format? I would be interested to see that discussion.

See the discussion on this list in the first LC.  I tried to sum them
up in one message about a week before the end.

>explicitly request, ...

Uh, what?  The DNS is under control of the domain owner, not the end
users.  If I'm running mitmmail.com, I can publish keys for all of my
users that I can decode on the way in.  If I'm that kind of MITM I
might even re-encode the mail with the users' real keys if I know what
they are, perhaps from the traditional PGP key servers.

This points out one of the problems with this draft: there's no
security model beyond the implicit DANE model that anything that's
signed with DNSSEC must be true.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 13 Mar 2016 13:48:46 -0400

> On Mar 13, 2016, at 1:11 PM, John Levine <[email-masked]> wrote:
> 
> users. 

A misreading of the comment.  The "end-user" in question is the one
doing the lookup, not the one whose key is published.  Paul is making
no claim about how the published key got there...

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 13 Mar 2016 14:04:26 -0400 (EDT)

> up in one message about a week before the end.

You will also find my arguments against that summary there.

> they are, perhaps from the traditional PGP key servers.

So can the Registrar, the Registry and the root key owners, your OS
vendor, and many more. I don't see us blocking TLS or IPsec or PKIX
documents based on that.

Which is why the draft clearly states "not a replacement for Web Of
Trust". Why it has advise on what to do when keys in DNS conflict with
the local key ring. Why it says "still better to use to encrypt than
send in the clear".

> signed with DNSSEC must be true.

And as I replied then, the key listed can have trust signatures on them,
or you can get those trust signatures from public key servers (now you
have a key id). The draft mentions these things very clearly because
these arguments keep coming up and I've tried to accomodate things in
various rounds of LC, and you just keep rejecting with hand waving and
refusing to contribute text.

All of this has been said before, and all of this will be said again
it seems.

Paul

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2016 14:54:03 -0400

--On Sunday, March 13, 2016 1:48 PM -0400 Viktor Dukhovni
<[email-masked]> wrote:

>>> has to  explicitly request, ...
>> 
>> Uh, what?  The DNS is under control of the domain owner, not
>> the end users. 
> 
> A misreading of the comment.  The "end-user" in question is
> the one doing the lookup, not the one whose key is published.
> Paul is making no claim about how the published key got
> there...

I understood that, and I assume John L. did too.  The problem,
again, is that we are conflating several issues, including
whether the right key is going to be found to correspond to a
given address and whether and how it can be trusted.  A
problematic domain owner (and, unless the nominal domain owner
is paying a lot of attention, a problematic registrar or other
third-party domain administrator) can provide bogus,
self-serving keys.

"Making no claim about how the key got there" is almost
certainty true, but that misses the point.  The document more or
less claims that, if one finds a key in the DNS associated with
a particular mailbox string, then that key has some association
with the person who owns/controls (not necessarily the same
thing) that mailbox.  -07 was actually more clear about the
issues with that than -08 is, but neither goes far enough, IMO,
in detailing the risks that the community perfectly well knows
about.

The requirement is still that the I-D be clear about either
known risks, restricting the experiment to those who are very
familiar with those risks and accept them, or both.

    john

---

From: Paul Wouters <[email-masked]>
Date: Sun, 13 Mar 2016 19:28:46 -0400 (EDT)

On Sun, 13 Mar 2016, John C Klensin wrote:

> -07 was actually more clear about the issues with that than -08 is,

The change between 07 and 08 was by direction of the AD. So the author
and the AD have tried to write text that would resolve your issue. There
is really only one person left that can write text that you will agree
with, and that is you.

> but neither goes far enough, IMO, in detailing the risks that the
> community perfectly well knows about.

Note again that the "risks" are:

1) email being sent to the intended user in the clear like it happens now.
2) email being sent to the wrong user encrypted to the wrong user's key,
    which is not as bad as being sent in the clear like it happens now.

Paul

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Mar 2016 18:32:06 -0700

> up in one message about a week before the end.

Can you provide a URL? You have sent 98 messages to the DANE list (to 
date). I read all the ones that looked like they might apply to the 
topic and was unable to find the kind of tidy summary I was hoping for. 
Sorry if I missed it.

> Uh, what?  The DNS is under control of the domain owner, not the end

I was referring to the end user sending the mail. Sorry I wasn't more 
clear.

> If I'm running mitmmail.com, I can publish keys for all of my

That is an interesting threat model, however I don't see how that's any 
worse than the status quo. If you're the operator of evilmail.com and 
the sending user doesn't already have and/or cannot find a PGP key for 
your receiving user they will almost certainly send the message in the 
clear. Therefore still have access to it, and your receiving user is 
still none the wiser.

If your receiving user has no PGP key that you are aware of, your scheme 
fails, and your user receives an unexplained encrypted message that will 
likely cause them to investigate why it happened.

Either way, your actions have not negatively affected security for 
either party.

> signed with DNSSEC must be true.

To a rather limited extent I agree with you on this. I will elaborate in 
another message.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Mar 2016 18:47:15 -0700

Thanks for the response John, more below.

> having so much trouble communicating, but

Having read a bunch of the DANE archives today it does seem that there 
is a problem in communication, but honestly it doesn't seem all that 
one-sided. :)

> casual bulk attacks even if much less so against focused and

I'm perfectly willing to grant that some systems do this. Paul's hashing 
scheme accounts for this, and CNAMEs can be used to handle any aliases 
that are desired.

Further, I think that many of the critics of the draft are ignoring the 
fact that in the overwhelming number of cases the sending user is going 
to have an example of the receiving user's e-mail address, the most 
likely case being that they are replying to a message they already have 
in their MUA. Thus it's overwhelmingly likely that the sending user will 
already have a representation of the receiving user's local part that 
the receiving user considers to be canonical, and thus is likely to have 
placed an OPENPGPKEY RR for.

> matter of taste: the specs are (deliberately) mute on the

Agreed, see above.

[snip]

> won't lose any sleep over it.

Good to hear! :)

> I do believe that, if that is the
> the I-D that should just come out.

FWIW, I agree that the draft in its current state needs some tightening, 
as it seems to have some leftover tidbits from previous versions. I also 
think that the approach suggested is wrong, and would like to see a 
parallel approach codified (which I will comment on further in another 
message).

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Mar 2016 18:56:11 -0700

> correct, perhaps modulo one other issue.

I agree that the draft needs to spell this out in more detail.

> then the threat model changes quite a bit.

Paul has a point here. For good reasons or ill, the number of "eyes" 
(where "eyes" can also be various forms of machine tools) "on the path" 
can be non-trivial.

It's also worth reiterating one of his points ... the risk to neither 
the sending nor the receiving user is not increased, and may in fact be 
decreased, by the mechanism described in the draft. Do you believe 
differently? (Note, I'm not asking about your analysis of the relative 
"worth" of the decrease. I'm only interested in whether you see that 
there is a decrease, or more significantly, if you see an increase in 
risk, and why.)

> wrong person sees it" and "everyone sees it" is a not-starter.

I disagree quite strongly with your assessment here.

Further, your caveat of "encrypted in the key of the right party" by 
definition precludes using OPENPGPKEY as the sole point of information 
in determining said key, which renders your argument here moot.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Mar 2016 20:58:53 -0700

In general I support the idea of an *experimental* draft on this topic. 
The idea has been kicked around in both casual and serious conversation 
in both the PGP and DNSSEC communities since the earliest days of the 
latter, and having a canonical (pun intended) way to experiment with 
this concept would be a great way to move forward.

However, I have some serious concerns about the suggested approach. I 
realize that I'm late to the party on this, so I apologize in advance to 
Paul. I've subscribed to the DANE WG ML so hopefully I can make a more 
useful contribution going forward. (FWIW, the last time I checked the 
suggested approach was one I agreed with, so I diverted my attention to 
more personally critical pursuits.)

Fundamentally I think that using this RR to return the cert itself is 
the wrong approach. IMO it should return the full fingerprint of the key 
and let the sending user retrieve the key itself, with all corresponding 
material. This overcomes several problems I see with the proposal:

1. We know from vast experience with PGP that users are very lazy about 
updating keys, and everything associated with them.

2. The draft recommends that the version of the key that is published be 
stripped of any "extraneous" material such as unrelated UIDs, photos, 
various certifications, etc. Given the desire to keep the packet size as 
small as possible these recommendations are sensible, but I question 
whether the resulting certificate has sufficient utility. One could also 
argue that most users think of "my PGP key" as the entire package of the 
main key, along with the the various associated UIDs, subkeys, etc.

3. Encryption subkeys are not tied to specific UIDs. Also, it's not at 
all clear to me how the mechanism described in this draft would interact 
with a "key" that has multiple encryption subkeys.

4. The draft suggests (primarily in Section 7.1) that this mechanism be 
utilized in a side channel (my term) separate from the sending user's 
existing keyring(s). I have deep concerns about this approach, as it 
increases the risk that a message could be sent encrypted to the wrong 
key. The biggest risk in this case is that of a false positive, where 
the sending user believes that the message was correctly encrypted. 
That's arguably still better than the alternative of sending the same 
message unencrypted. However it's not better than the alternative of 
informing the user that the MTA was not able to send the message because 
it couldn't find a key that it could rely on.

5. Super large OPENPGPKEY RRs will undoubtedly be used as DDOS 
amplification fodder. For example, using Paul's software to generate the 
RR for my primary key/UID the resulting packet would be over 12k.

All 5 of these issues are resolved by having the OPENPGPKEY RR specify 
the signature of the key, and having the sending user's software deal 
with the full key instead of only a truncated version.

1. To the extent that users are likely to update anything with their 
key, they are likely to send a current version to the key servers. 
Further, in the case of a key revocation (particularly for a compromised 
key), it may not be possible to remove or modify the OPENPGPKEY RR in a 
timely manner, or at all. However the receiving user should be able to 
upload a revocation cert for the key to the key servers, which would be 
picked up by sending user's software.

2. Having the sending user's software retrieve the full key gives them 
the most up to date version, and matches better with what I believe the 
expectations of most users would be for this RR.

3. Retrieving the whole key puts the problem of multiple encryption 
subkeys into the hands of the sending user's software, where there are 
already well known solutions.

4. The way that this mechanism interacts with the user's existing key 
ring still needs more thought.

Regarding 4, I see several likely scenarios:

1. The user already has exactly 1 key that contains exactly 1 UID which 
matches the e-mail address:
	- The OPENPGPKEY result matches: The user is notified, the user's 
software MAY make note of this match and suitably increase the "validity 
score" for the key (if the software has such a concept)
	- The OPENPGPKEY result does not match: The user is notified, MTAs/MUAs 
SHOULD halt processing at this point, and let the user manually rectify 
the error. User's software MAY make note of the mismatch and suitably 
decrease the "validity score" for the key (if the software has such a 
concept)

2. The user has more than one key, and/or more than one UID which 
matches the e-mail address:
	- There is an RR which corresponds to one of the known keys: See the 
first mechanism under 1 above.
	- Otherwise see the second mechanism under 1 above. Additionally, the 
software MAY ask the user if they would like to download the key that 
matches the RR for evaluation.

3. The user has no extant keys which match the e-mail address:
	- There is an RR which corresponds: The software MAY ask the user if 
they would like to download the key that matches the RR for evaluation.
	- There is not, the user is notified, and the software MAY suggest that 
the user search the key servers.

The draft currently suggests a mechanism for using the RR data in an 
unattended manner. I believe that this is a mistake for an experimental 
draft, and should be replaced with text which makes it clear that at 
this stage of the experiment the software SHOULD NOT proceed without 
user confirmation.

Some other thoughts:

The draft needs to be even more clear about its intentions. Specifically 
it needs to spell out how the mechanism should be used. I see two 
scenarios, but that doesn't mean there are only two:

1. This mechanism can be used as a data point in the WOT
2. This mechanism can be used for opportunistic encryption

Personally I don't see anything wrong with #2, but the sending user has 
to be involved in the decision-making process. Retrieving the full key 
will make that user's decision making process easier.

I would like to see more explanation of the mechanism for representing 
the local part. I think that the explanation of "Why do we need to hash 
it?" is good, however it's not clear to me why SHA-256 was chosen, or 
why the hash value is truncated the way that it is. Obviously a full 64 
character hex encoding of a SHA-256 hash would overflow the 63 byte 
limit for a single DNS label. But why truncate the value specifically to 
28 octets? If the 63 byte limit is the concern, why not use SHA-224?

I'd also like to suggest an alternative mechanism for this problem. In 
cases where the entire local part of the address consists exclusively of 
1-63 Letter-Digit-Hyphen (LDH) characters, allow that representation to 
be used directly. That would greatly simplify provisioning in the common 
case, and also go part of the way towards addressing John Levine's 
concern about the poor DNS admin who needs to go in and clean up those 
records later. (That said, the records themselves refer to a key which 
will answer said admin's question, so while it's a bit of extra work the 
hash doesn't make answering the question impossible.)

This would also require a bit of text warning mail/DNS admins to mandate 
hashes in the event that local delivery is case sensitive, but I really 
think that this is such a corner case (again, pun intended) as to be 
nearly a non-issue.

In cases where the local part contains a non-LDH character, the hashing 
mechanism is mandatory. Obviously the system should fall back to trying 
the hash version of the RR for a "simple" local part as described above.

Given that the draft specifies a new RR with its own ID, there is no 
need for the _openpgpkey intermediate label. A query such as 'dig 
doug.barton.us openpgpkey' would do the right thing (once all the 
software catches up to the eventual RFC of course).

I would avoid using 'LHS' to refer to the local part of the e-mail 
address in order to avoid confusion with the way that acronym is 
commonly used in reference to DNS RRs.

The discussion about local part wildcards in 5.3 confuses me. How would 
the user know how to hash the wildcard to look up the RR, given a real 
e-mail address as the starting point?

The details on how the sending user's software should use the returned 
data should be moved out of Section 7 (Security Considerations) and into 
Section 5. Also, see above. :)

If we stick with sending the whole cert back in the RR the Security 
Considerations section should list use of such answers in DDOS 
amplification attacks as a risk.

Regarding 7.5, given that the hash is truncated, it's hard for me to see 
how rainbow tables would be effective for converting the results of zone 
walking into a list of valid e-mail addresses for the domain.

Minor nit, it's "GnuPG" :)

I hope that these suggestions are useful, and again, I apologize for not 
offering them sooner. If you are in agreement with them, and would like 
help with text, I'd be happy to do what I can.

best,

Doug

Some more comments below.

> 1. The context of the experiment

This is a good change, and it was adopted in the -08 version.

> 2. Changes to trust model

This text is too confusing. Also, the issue of how to associate any keys 
that already exist on the sending user's keyring for the same e-mail 
address with any information retrieved from an OPENPGPKEY query needs 
more thought. (See above)

> to be considered for a general solution to the problem.

I disagree that a solution for representing the local part of an e-mail 
address in DNS *for the purpose of looking up PGP keys* needs to take 
every possibly valid local part into account. The reason being that in 
order to be useful for encrypting e-mail the PGP key has to specify a 
UID that is an *exact* match for the receiving e-mail address. Thus it's 
trivial for the receiving user to create the precise number of canonical 
records and CNAMEs that are relevant for their key.

I think part of the communication problem here is that the mail folks 
have gotten caught up in trying to boil the ocean, and rightly conclude 
that Paul's hashing mechanism does not account for every possible 
combination. But that argument is specious *in this context*.

> I

Hooray :)

> but for those to not try to solve the general issue,

... and again! :)

> and
> is to be done.

Agreed.

[big snip of more stuff I agree with]

Doug

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2016 09:47:12 -0400

--On Sunday, March 13, 2016 18:47 -0700 Doug Barton
<[email-masked]> wrote:

>> I don't know why we (that "email community") and you (Paul)
>> are having so much trouble communicating, but
> 
> Having read a bunch of the DANE archives today it does seem
> that there is a problem in communication, but honestly it
> doesn't seem all that one-sided. :)

I didn't claim that it was.  While, IMO, it shouldn't be an
excuse for this many communication problems, the two communities
rather clearly have different priorities about what is
important.  Until and unless we can somehow rise about protocol
details to engage about those priorities and figure out how to
figure out the tradeoffs between them, we aren't going to make
much progress.

I don't speak for the rest of the "email community" but my
highest priority is "don't break things that are implemented,
widely deployed, and at least reasonable satisfactory to many
millions of users".  Some of the arguments for doing what the
draft proposes seem to me to be rather close to "encryption
whenever possible is so important that, if fewer messages get
through or other damage occurs, that is ok".  Certainly not all
of them, of course.
 
>...
> I'm perfectly willing to grant that some systems do this.
> Paul's hashing scheme accounts for this, and CNAMEs can be
> used to handle any aliases that are desired.

I don't see how the hashing scheme accounts for it without at
least some address canonicalization, which the I-D does not
specify.

> Further, I think that many of the critics of the draft are
> ignoring the fact that in the overwhelming number of cases the
> sending user is going to have an example of the receiving
> user's e-mail address, the most likely case being that they
> are replying to a message they already have in their MUA. Thus
> it's overwhelmingly likely that the sending user will already
> have a representation of the receiving user's local part that
> the receiving user considers to be canonical, and thus is
> likely to have placed an OPENPGPKEY RR for.

At one level, certainly yes although I'm not sure about
"overwhelmingly".  FWKW, we have had email systems that, because
few people could get the rather complex address formats right,
essentially required that one either have a message to reply to
or a correct directory entry in order to send a message.  It
didn't work out well; opinions differ as to how much of the
problem was the absence of a working universal email address
directory.

> FWIW, I agree that the draft in its current state needs some
> tightening, as it seems to have some leftover tidbits from
> previous versions. I also think that the approach suggested is
> wrong, and would like to see a parallel approach codified
> (which I will comment on further in another message).

Ack.  I look forward to that message with the understanding that
there are a number of parallel approaches floating around (I
don't believe Keith's promised proposal has been posted, btw)
and that Stephen's position seems to be that we should just push
them all out as experiments.

      john

---

From: "John R Levine" <[email-masked]>
Date: 14 Mar 2016 10:42:41 -0400

> Can you provide a URL? You have sent 98 messages to the DANE list (to date).

These were to IETF general.  It's two messages, since there's an issue I 
missed in the first one.

https://mailarchive.ietf.org/arch/msg/ietf/_kUe6YG6BUMlI43I65okFhqR6L8
https://mailarchive.ietf.org/arch/msg/ietf/5lW3clLKgu6NL-0atCE4i9sO2oM

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2016 11:18:45 -0400

>     which is not as bad as being sent in the clear like it

We don't quite agree about the "not as bad" part.   Let me try
once more to explain why.  I understand that you may not agree
with the analysis but I should probably add that I don't find
statements like "it isn't as bad" persuasive by themselves.   

Again, this appears to me to be about different attack and data
protection models and perhaps different priorities.  If were is
no such thing as a highly sensitive message and the only reason
for encryption was to protect against casual snooping (or
pervasively gathering up everything in case it might prove to be
of interest), I would completely agree with your risk summary
above.

However, consider a different case.  Assume I have a message,
whose content I consider sensitive, that I need to transmit to a
party I know but with whom I have not corresponded by email
before (and, therefore, Doug's "replying to message" case does
not apply).   Now I don't need to send that by email.  I may
have the post, fax, assorted courier services, reading it on the
phone (PSTN or VoIP), transmission it by IM or text message, and
other methods available to me.   I might even consider semaphore
flags, not because they are "secret" in the "out of sight" sense
but because very few people can read them these days and because
the message information is more transient and volatile than most
of the above.  

In ranking the above for preserving the secrecy of my sensitive
message and making a choice of method, it is at least as
important for me to understand just how secure a given method is
as that it be "secure" in the abstract. If one ignores my
earlier comment about protective methods imposed by
ISPs/Carriers and mail relay operators, "email sent in clear" is
a non-starter: I need to either modify the message so it isn't
sensitive, use a well-protected code rather than relying on
cryptography, or, more likely than either, make a different
choice about transmitting the message.  

Now, _in that context_, your second option is a big problem
because it implies accidental disclosure, possibly to an
attacker who has deliberately acquired a confusable address
(note similarities to phishing and confusable domain names here)
in an environment in which I had reason to believe that the
message transmission was fully secure.   If I understand the
risks, I do one of two things:

(i) I get super-careful about checking the identifier in the key
to make sure it matches an email address I want to send to
and/or check the key against a fingerprint that I've obtained in
some other way and trust [1].  Probably I do that if I prefer
email.  Typical users don't, as we know from other experiences.  

(ii) I use some other mechanism, one that I consider more
secure, to transmit the message.

So it seems to me that, at least for information perceived by
the sender as sensitive enough to deserve special treatment, the
"otherwise the message goes in the clear" case is not applicable
because the actual case is "otherwise the message doesn't get
transmitted over Internet email".   And the second case is
either a real and significant risk due to  the sender believing
that she has a level of protection that doesn't actually exist,
or is nearly impossible because the sender makes checks for
which the I-D does not spell out the necessity.

best,
     john

[1] As an aside, if I've got a trusted way to obtain that
fingerprint without using the DNS, I most likely have another
way to obtain the key so I don't need this I-D and protocol.
When that argument is reversed, some of the advantages of Doug's
suggestion (somewhat similar to that of others, earlier) to put
fingerprint (and maybe other) information in the DNS rather than
the key itself become obvious.  But, if we are really committed
to letting a thousand experiments bloom, that is not relevant.

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Mar 2016 13:18:33 -0700

On 03/14/2016 08:18 AM, John C Klensin wrote:
> other methods available to me.

In this scenario the PGP community has long (and I mean, for 20 years or 
so) advised to ring the person and confirm their key fingerprint (and by 
extension preferred e-mail address) over the phone. I don't see any 
reason why the existence of a DNS mechanism would change that advice.

> to letting a thousand experiments bloom, that is not relevant.

Thanks!

Doug

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Mar 2016 21:18:28 +0000

On Mon, Mar 14, 2016 at 01:18:33PM -0700, Doug Barton wrote:

> In this scenario the PGP community has long (and I mean, for 20 years or so)
> advised to ring the person and confirm their key fingerprint (and by
> extension preferred e-mail address) over the phone. I don't see any reason
> why the existence of a DNS mechanism would change that advice.

Because opportunistic encryption won't happen under that requirement.

While not all encryption of email will be opportunistic, it seems
to me that part of the motivation for this experiment is to enable
opportunistic encryption of email sent to people you'll never meet
in person or necessarily be able to contact by means other than
email.

The way that PGP has been used for 20 years has not resulted in
broad adoption of PGP.  This experiment may well not do much better,
(cue Phillip and mathematical mesh which could be what it takes to
make real progress, but too early to tell), but it seems to me that
it is definitely intended to facilitate encrypted first contact.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Mar 2016 19:18:22 -0400 (EDT)

On Sun, 13 Mar 2016, Doug Barton wrote:

Hi Doug,

> Date: Sun, 13 Mar 2016 23:58:53
> From: Doug Barton <[email-masked]>
> To: [email-masked]
> Subject: Re: dane-openpgp 2nd LC resolution

> In general I support the idea of an *experimental* draft on this topic.

Thanks.

> more personally critical pursuits.)

Yes, you are about 1.5 years late. And your arguments are (un)fortunately
not new arguments. Since the archive on this draft is rather huge, I can
understand that you missed part of this discussion. So for completeness
sake, I will answer your questions again.

> material.

This argument has come up a number of times, and it has been rejected each time.

> This overcomes several problems I see with the proposal:
> 

I don't see how that differs from where they need to update the key
from/to.

> whether the resulting certificate has sufficient utility.

Leaving some signatures on it to anchor it in the web of trust is fine.
What is meant is to strip away the photo, and other non-required
items. The problem is not really of "big keys", which we handle fine in
DNSSEC (see below) but there is an upper limit of 64k in DNS that you
must remain under. So having 100s of signatures and a photo is not going
to fit. It does not matter whether the key is 2k, 12k or 63k.

> One could also 

That's fine. See above.

> with a "key" that has multiple encryption subkeys.

I don't see why the draft needs to say anything about that? How is that
different from obtaining this key via another transport like HKP ?

> existing keyring(s).

I do not understand what you mean here.

> I have deep concerns about this approach, as it 

This draft on purpose provides no GUI to the user. As it states clearly,
this is not a replacement for the Web Of Trust.

> message unencrypted.

Not "arguably". There is nothing to argue about it. It _IS_ better than
sending it plaintext - if you do not mislead the sender by any
"security" claims in the GUI.

> However it's not better than the alternative of 

Hard fail is certainly possible as a local policy, and everyone is free
to implement that. It is not up to the draft to dictate either hard fail
or soft fail. This is identical to TLS soft/hard fail which is a browser
matter, and not a TLS protocol matter. Local policy might be different
based on whether there is a direct link to the enduser (MUA) or not (MTA)

> RR for my primary key/UID the resulting packet would be over 12k.

The draft is very clear about how to avoid amplification. It is not
supposed to respond on non-source verified transport, such as plain UDP.
It should be used with TCP or UDP with DNS COOKIES for this very reason.

> with the full key instead of only a truncated version.

But it introduces a complexity of third party PKI systems on top of
DNSSEC and/or direct unfiltered/uncensored communucation to this third
party service. If you point to an HTTPS server, then one needs to take
that trust model with PKIX/CAs into account. What do you do when the TLS
certificate is expired? Or from a bad CA? Or when you just don't receive
an answer to your first TCP packet because the attacker is on-path and
filtering you to attempt to lure you into sending it in the clear? Or
when it is an SMTP extension but your ISP blocks all SMTP communication
to non-ISP SMTP servers. The strength of this document lies in the fact
that it does not depend on third party services.

DNSSEC provides the Indeterminate and Bogus status, so you know when an
attack is happening. Adding third parties to that destroys this property
which is essential.

> key, they are likely to send a current version to the key servers.

The key servers are the equivalent of the Great Garbage Patch of the
internet. It is full of expired keys, lost keys, mallicious keys and
fake keys. These servers are also closely monitored and/or attacked
by nationa states, etc etc. It provides a simple central point of failure.
The strength of DNS is that it is a distributed system with intermediary
caches.

> timely manner, or at all.

A good implementation would use reasonable TTL's and provide a decent
GUI for inserting, updating and deleting the DNS record. This is not
worse then a website needing to update their A record. We are not saying
A records are bad because a website cannot update their A records in a
timely matter. So I find this argument a bit of a straw man.

> However the receiving user should be able to 

Realistically, the real problem is losing the key to be able to revoke
it. With DNS, you can just stop publishing that key. So it is in fact
much better than a third party append-only store like current pgp key
servers.

> expectations of most users would be for this RR.

Email software doing so can do that from alternative locations if
desired. It does not need to be in the core functionality of this draft.
Especially for security reasons I mentioned earlier.

> already well known solutions.

You can publish as much of the key as you need to get the equivalent.
The draft is fine with keys up to 63k.

> ring still needs more thought.

That is really local policy and we have given some guidelines on it. Anything
more specific runs into infinite discussions about what the protocol should
dictate and where people want local policy to apply.

> decrease the "validity score" for the key (if the software has such a 

It would depend. Currently we state the local key ring always trumps the
policy, so if the user manually put trust in that key it should use that
key instead. If MAY inform the user if a mismatch occurs. It MAY decide
to use the new key if it is signed by the locally stored manually
trusted key. All of this is really local policy and it will take another
10 years to get any kind of consensus on trying to write this down as a
protocol specification.

> matches the RR for evaluation.

I don't see how this draft prevents you from doing so. If you have a
local key that is manually verified, it and the user local policy
trumps and an implementation MAY decide to warn to user instead of using
either old or new key.

> the user search the key servers.

I would not want to specify that users should go to search existing key
servers. See above :P All of this is local policy and none of us should
attempt to dictate that.

> this stage of the experiment the software SHOULD NOT proceed without 

That destroys opportunistic encryption for no good reason and I'm FIRMLY
against any proposal for that. Encrypted to OPENPGPKEY without informing
the user of "additional security" is ALWAYS better than sending in the
clear, which is the situation we have today. Manual key verification has
failed and is the main reason most of our emails are not end-to-end
encrypted as it is. Your suggestion of bringing back the user before
using a key to encrypt basically adds nothing to today's failed state
of mostly unencrypted emails being sent.

> will make that user's decision making process easier.

I've answered above already why I think this is wrong.

> why the hash value is truncated the way that it is.

I don't see why that information needs to be in the draft. SHA-256 was
chosen over SHA-224 and SHA-1 because:

1) SHA1 is being removed from libraries and/or is disallowed in FIPS mode.
2) SHA2-224 is not part of the Microsoft Crypto library.
3) SHA2-256 does not suffer from 1) or 2) and we need to be < 63 octets.

> Obviously a full 64 

Microsoft :P

> be used directly.

> That would greatly simplify provisioning in the common 

That leads to maybe requiring multiple queries, and additionally it
was pointed out that it makes it easier for DNS servers to log the
usernames. yes hashing is not irreversable, especially for predictable
and published names, but people believed the additional privacy was still
worth it. And the reason for hashing the local-part and not the entire
email address is to allow users to use CNAME/DNAMEs) without needing to
create OPENPGPKEY records per zone.

> think that this is such a corner case (again, pun intended) as to be 

Yes, this non-issue has generated the majority of emails and delays,
so I am very reluctant to make any further changes and re-ignite this
discussion as people simply have different opinions that are unchanging.

> the hash version of the RR for a "simple" local part as described above.

If we cannot even decide on when we can lowercase() I really don't want
to talk about which characters are "legal" and can do without hashing,
and which cannot. But regardless, the privacy issues with DNS resolver
intermediaries also makes hashing a requirement, even for US-ASCII.

> software catches up to the eventual RFC of course).

The subzone allows a separate DNS server to act as a DNS keyserver. For
instance, when we populated the fedoraproject.org zone with a couple of
thousand keys, the size of the zonefile was big enough to cause problems,
and it is nice to be able to store and serve it as a separate zone on
possibly a separate machine.

> commonly used in reference to DNS RRs.

The draft uses local-part everywhere. The term "LHS" appears once:

 	If one of the OpenPGP key uids contains only a single wildcard as the
 	LHS of the email address, such as "[email-masked]", the OpenPGP public

And it refers to using "*" as the LHS. It is not a local-part of an
email address.

> e-mail address as the starting point?

A wildcard would match any hashed attempt. the user does not need to
know anything and can just hash its intended local-part.

> amplification attacks as a risk.

You think 7.4 in the Security Considerations is not enough?

7.4.  Response size

    To prevent amplification attacks, an Authoritative DNS server MAY
    wish to prevent returning OPENPGPKEY records over UDP unless the
    source IP address has been confirmed with [EDNS-COOKIE].  Such
    servers MUST NOT return REFUSED, but answer the query with an empty
    Answer Section and the truncation flag set ("TC=1").

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Mar 2016 19:26:18 -0400 (EDT)

On Mon, 14 Mar 2016, John C Klensin wrote:

> as that it be "secure" in the abstract.

If your information is "sensitive" then hopefully you could tell
your email client that. That email client might try various things,
including looking up an OPENPGPKEY record. When found, it could
look at signatures - maybe even trying to look those up using
OPENPGPKEY or on existing pgp keyservers. It would present you
with the data for you to make an informed decision.

> because it implies accidental disclosure

The accidental disclosure to a "wrong email address" is not worse
when encrypted than it is now if you send it unencrypted. If you
risk mistyping the username and encrypting it to the wrong user,
this draft cannot help you. It has no powers to mind read the
user.

> transmitted over Internet email".

I know of no way to codify the user to email agent interaction
based on "user considers content sensitive" other than the user
stating "send this message encrypted only", which something like
enigmail, a thunderbird email client plugin, can already do. You
mistyping the email address again is not something we can protect
against in a protocol. You could have a local policy of saying
"always confirm email address before sending to any address for
the first time" but all of this is completely out of scope for
the document.

> way to obtain the key so I don't need this I-D and protocol.

But you cannot tell if pgp.mit.edu is down, or whether an attacker
is actively blocking you from obtaining the target's public key.
With OPENPGPKEY, you can.

Paul

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Mar 2016 18:44:06 -0700

> sake, I will answer your questions again.

Thank you for your patience in explaining your reasoning, and again, I'm 
sorry for coming late to the party. And thanks as well for confirming 
that my memory is correct ... at one time I did hear that this topic was 
going in the direction of signatures rather than certs. Unfortunate that 
I didn't follow it closer.

Regarding what you said and what your goals are, I think that we are 
pretty far apart. I will send a detailed response to your message on the 
DANE list soon. In all likelihood I will also create a new I-D with my 
ideas specified in more detail. Perhaps what is needed is more than one 
experiment. :)

In regards to the current last call, while your explanations do help to 
alleviate a few of my concerns, in large part I am still not 
enthusiastic about this version of the draft proceeding.

In particular I think the concern about these RRs being used for DDOS 
amplification remains. There is no mechanism in place currently in any 
name server software that I am aware of to limit responses to queries in 
the manner you describe (only send answers if the query comes over TCP 
or with DNS-Cookies). Further, I don't see that happening any time soon.

Close behind that concern, the larger IETF community (or at least some 
very vocal segments of it) have serious concerns about this type of 
opportunistic encryption happening at all, or in my case, without user 
input. They (and to some extent I) remain unconvinced that your 
assertion that this type of opportunistic encryption is always better 
than the current state. Personally, I need to think more about that, but 
at least in the early stages of an experiment in tying PGP keys to DNS 
RRs, I'm definitely opposed.

FWIW,

Doug

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Mar 2016 22:01:22 -0400

> On Mar 14, 2016, at 9:44 PM, Doug Barton <[email-masked]> wrote:
> 
> Close behind that concern, the larger IETF community (or at least some very vocal segments of it) have serious concerns about this type of opportunistic encryption happening at all, or in my case, without user input. They (and to some extent I) remain unconvinced that your assertion that this type of opportunistic encryption is always better than the current state.

I would like to suggest that RFC7435 is a reasonable statement against the
all-or-nothing fallacy.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Mar 2016 13:39:19 +1100

> or with DNS-Cookies). Further, I don't see that happening any time soon.

You just limit response sizes in general.  BIND 9.11 has
"nocookie-udp-size <integer>;" which sets a EDNS response size limit
for queries w/o a valid server cookie.  If the response doesn't fit
you do the normal fallback to TCP.  With EDNS both sides can set
limits on what they are willing to send/receive.

Amplification controls should be independent of qname and qtype.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Mar 2016 03:28:43 +0000

> I didn't follow it closer.
I just wanted to mention that we have been working on this for a long time,
and there is a definite level of frustration (and some cultural mismatches
/ cross area chalenges), and many people are tired at this point. There
have been a large number of messages on the list related to this document
(and topic), so, following it closely is a challenge.

> ideas specified in more detail.

Yes, please do - I think it would be useful to have a better understanding
/ more detail. I should mention again that at this point many people are
tired and / or frustrated, so we will to work to overcome that.

> Perhaps what is needed is more than one
> experiment. :)
>

Aaaargh! What could possibly go wrong!? :-P

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Mar 2016 12:28:12 -0400

Oh come on.

I am sure that you can sort the problem out with some sort of rule
such as 'if case matters, use punycode for upper case'.

It won't of course because people have been trying and failing to put
account information into the DNS since the first DNS specs. The number
of people who can configure DNS that way are maybe 5% of the total
base. Big enterprises can't do it because the DNS is an infrastructure
for describing hosts and they have other infrastructures for tracking
people. Small enterprises can't do it because if you don't run your
own DNS, you are left entering RRs through Web interfaces that only
recently started supporting SRV.

Let these folk get on with their experiment so that they can learn
what others have learned before for themselves.

The only way you could do that sort of thing with DNS records is if
you were doing something like S/MIME and you had a LRA for the domain
with its own root or intermediate cert and published an authenticator
for that in the DNS. then you could put a link to your directory where
account granular lookup can be performed in the DNS next to it.

This fits S/MIME a lot better than OpenPGP because it is already
hierarchical. Of course you can do the same thing with OpenPGP but the
cost is that you are imposing the DNSSEC hierarchy on OpenPGP.

This is not a solution, it is a distraction. But the sooner they get
started on learning the problems themselves, the sooner we can get
onto the next thing.

---

From: "John Levine" <[email-masked]>
Date: 15 Mar 2016 16:38:42 -0000

>account granular lookup can be performed in the DNS next to it.

Ah, you mean like  draft-bhjl-x509-srv-00

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Mar 2016 10:39:16 -0400

No, I mean like

https://tools.ietf.org/html/rfc4386

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 19 Mar 2016 12:27:20 +0000

Hi John,

Slow response, but as I said offlist, I wanted to let it sit
for a few more days to see if anything new developed. (And
then I got busy and let it sit even more days;-) But I don't
think anything new has developed to change where we're at.

The TL;DR here is that I continue to conclude we should
go ahead with this experiment and have put this into IESG
review and on the IESG telechat agenda for April 21st.

That leaves plenty of time for folks to comment and/or
appeal if there's more to be said that hasn't already been
said, and we have IETF95 in the meantime as well so interested
folks who're there will also have that chance to discuss.

On the topic of possible appeals which you mention way down
at the end, I think appealing my decision here or whatever
decision the IESG may reach is just fine - having the possibility
to appeal is an important part of our process - and I'll be
happy to try to help anyone who wants to appeal to craft text
if that's useful. Responses to your specific points are below.

On 12/03/16 09:00, John C Klensin wrote:
> approach.  

That's fair enough. I think there's no doubt that this one
has rough consensus at best. (I wonder if that'll be true for
all similar experiments, and what that might be telling us,
but we'll see I guess.)

> All of what you write would be reasonable (whether we
> deployed applications, especially standards-track ones. 

My response here is yes and no.

Yes, we ought not do experiments that cause major harm. But
I don't think this one does. Paul has explained his and the
WG's logic about this, being that you end up no worse off
if taking part in this experiment. I do understand your point
about high-value emails, but I don't agree that someone in
such a position would be depending only on this experiment as
their means of validating email address to public key mapping.

The "no" part of my response is that every experiment in this
space will have to have the potential for some harm. Indeed
that is often the case when we introduce security mechanisms,
we almost always create new vulnerabilities by changing the
attack surface. And such changes require judgement and in this
case experimentation before we can really tell if the trade-off
is overall positive or not. Any experiment in this space will
create new potential ways for a bad actor in the right place
to provide bad mappings from email addresses to public keys,
but the hope is that this or some other experiment will more
than offset such potential harms by making it easier to find
public keys with sufficient reliability and hence improving
matters via more/better use of the technology, being OpenPGP
in this case.

I also consider that most all of the above has been a part of
the discussion already. While I may be summarising it from a
high level, I think the salient points were considered already.

And the above considers harm in terms of harm to users of PGP
which is a point you have raised. I think below you start to
consider a different form of harm (to the mail infrastructure)
but I wanted to address the above too.

> Several
> Internet's email infrastructure, 

So I think the only point here is the local-part issue as
that's the only way I think that potential harm to the mail
infrastructure has been raised. If that's not correct, please
do let me know. (Other issues about DNS were raised and also
sufficiently discussed I think but are not a form of harm to
the mail infrastructure that I can see.)

> if only by encouraging a

I think you're just wrong there. The draft says to not mess
about with local-parts and to not guess and says that that
is a part of the mail architecture. And all this has been
discussed at great length.

> from the author posted today: 

I think we're dealing with what the draft says and not with
the way folks have explained that (on any side of this debate).

> about what is and is not a corner case.

"corner case" is not a phrase that occurs in the draft and is
therefore not really relevant at this point in the process.

>  Many of the issues that
> names.  

Taking that sentence alone would be misleading too though.
I think para1 of section 4 is ok. It says:
  "Mail systems usually handle variant forms of local-parts.  The most
   common variants are upper and lower case, often automatically
   corrected when a name is recognized as such.  Other variants include
   systems that ignore "noise" characters such as dots, so that local
   parts johnsmith and John.Smith would be equivalent.  Many systems
   allow "extensions" such as john-ext or mary+ext where john or mary is
   treated as the effective local-part, and the ext is passed to the
   recipient for further handling.  This can complicate finding the
   OPENPGPKEY record associated with the dynamically created email
   address."

If someone had other text to offer that was saying the above
in a better way, and that didn't (re-)open cans of worms, then
I doubt there'd be any problem making such editorial changes.

> The specifications make no assumptions, and systems

Personally, I find it useful information. But if it is
at worst gratuitous then that's no reason to not proceed
with the experiment.

> other warning notice nor is there any warning in Section 8.

So, this particular experiment is definitely going to be
of limited scope - the number of openpgp users is tiny compared
to email users. The number of signed domains is tiny compared
to the number of DNS domains. And there will not be 100% adoption
of this experiment in any case. And I'm pretty sure that those
openpgp users who have existing key management arrangements
(e.g. sysadmins and others with funny-handshakes) will not be
part of this, or at least won't be depending on this, as doing
so would break their existing agreements for how to handle
high-value emails (e.g. with unannounced vulnerability reports).

There is IMO no need to specify any of that in the document
as it is just the current external reality in which this experiment
will be performed.

And to head of a point repeated mail and countered: no, one
cannot in this experiment mandate a precise OpenPGP trust model.
There is too much variation in uses of PGP for that to be a
realistic ask.

> create additional security risks, that seems necessary.

I do not agree there are any such "unrefuted claims."

For this draft, it could be that almost every possibly relevant
controversial statement has in fact been made and refuted and
that both happened multiple times;-)

> think it is a problem, it is your job to clean it up".  

I don't think that is a fair characterisation of the overall
discussion during the two IETF last calls. While the author
has indeed asked a number of times for text, I just don't
accept your characterisation (the text in quotes) above.

> I'm

Sorry, but the draft already says all that is required and
requires implementations to do what the mail architecture
calls for being done, that is: no messing with local-parts.
I don't see how an objection to an explanatory note like that
is a valid objection. It is just a fact that some implementations
do lowercase US-ASCII local-parts and that that has the issues
noted in section 4 (partly via reference to RFC6530). And that
fact is relevant in terms of why this experiment cannot "solve"
the variant local-part issue and is better off not trying to
"solve" that (perhaps unsolveable) issue.

And all of these issues have been discussed a lot in the two
IETF last calls.

> problem, you solve it if you do" comments.  

I'm sorry but the discussion from various folks, including
some of the "email experts" has been less than ideally phrased.
The above casts that as a one-sided problem, which is just
not correct.

> I note that the last

Again. We are considering the text of the draft and not the
latest semi-flammible email exchange;-)

*And* the draft does not have the problem you state above.

> longest period of time.  

I agree that is a potential problem here. And that there are more
than two different parties who could potentially win by attrition.
That is yet another reason to envisage that there will be more
than one experiment needed in this space. But I think we've not in
fact ended up with a win by attrition in this case.

> Whichever side on is on, that is not a

Sorry, but no. I extended the last call so that the changes in
08 could be considered by the list. Not so that people could
try to win via attrition.

> limited use and that carries appropriate warnings.

I believe that the scope of potential experiments here is
clear without an applicability statement. (See above.) I
also think there are appropriate warnings but of course it
could be that some additional (non-inflammatory) text will
improve the document. I'd be happy to consider recommending
any such text, that aims to improve the document and to
make the experiment usefully safer and more likely to be
a success. (I will not be happy to consider suggested text
that denigrates this particular experiment.)

> the relevant AD" first step in an appeal of how this document is

As I said above I'm happy to help with any appeal if one
is needed. I also consider that appealing is just a fine
thing to do if one feels that an appeal is warranted. I
don't myself see any good grounds for appealing but that's
of course also natural.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Mar 2016 10:26:24 -0400

--On Saturday, March 19, 2016 12:27 +0000 Stephen Farrell
<[email-masked]> wrote:

> decision the IESG may reach is just fine - having the
> possibility to appeal is an important part of our process -
> and I'll be happy to try to help anyone who wants to appeal to
> craft text if that's useful. Responses to your specific points
> are below.

Stephen,

In the interest of being constructive and focused, let me
suggest the following (more to those who have been participating
in this discussion than to you in particular).  

First, at least between now and 21 April, let's try to keep
discussions (at least on the IETF list) of dane-openpgp issues
narrowly focused on what the document, in its current version,
actually says or, if other discussions are necessary, very
clearly changing subject lines.  From my point of view, that
excludes discussion of using this for opportunistic encryption
with no check on key signatures or other validation (the
document appears to say "don't do that" and, if that isn't clear
enough to people, the question of clarity should be within
scope) or for heuristics or canonicalization to try to guess at
equivalencies among email addresses (the document has no
provision for doing that).  In both cases, the WG apparently
decided, however rough the consensus, that it didn't want the
spec to do such things at this point, so, if someone believes
the spec should be approved and published by the IETF, then
introducing those possibilities, or writing a message that
assumes they are in the spec or intended by it, is a distraction
and source of confusion at best.   On the other hand, if someone
believes the spec is so seriously defective without those
characteristics that it should be returned to the WG, they
should say that clearly (I haven't heard it yet).

I'm sure you have a different list of topics that should be set
aside for a while unless they take the form of "the document
should be stopped unless these changes are made" rather than
speculation on fanciful alternate documents.   From my point of
view, you (or, better, the WG Co-Chairs) posting such a summary
list would be helpful.  If we discover that we can't agree on
what the topics are, that should be a helpful discussion.

Second, I hope that those who feel strongly about this set of
issues will raise it forcefully in Buenos Aires, both in the
DANE WG (and I hope the co-Chairs will make allowances for such
a discussion, especially to raise points people feel have been
dealt with dismissively, if only because failure to do so would
be excellent grounds for an appeal) and, as needed, at the
plenary that, conveniently, immediately follows.

And then we will see what the IESG decides later in April,
presumably informed by the above.

best,
     john

---

From: [email-masked]
Date: Sun, 20 Mar 2016 09:48:42 -0700 (PDT)

(This is the first in what will hopefully be a series of review comments on the
latest version of the dane-openpgp specification. I'm breaking this up into
several different topics in hopes of keeping any resulting discussion focused
on the particular set of issues I've brought up.)

This is the first specification I'm aware that hashes the local-part of an
address to produce a corresponding identifier. Not only have we never gone this
far before, we've actually tried to stay away from operations like address
comparisons that have similar, albeit more limited, semantics.

In regards to this operation, there has been extensive discussion of the
longstanding requirement that only agents with administative authority over the
associated domain can "interpret" the local-part of an address.

Unfortunately, AFAICT this discussion has completely missed two fundamental and
vitally important points.

First, there's no way to define a mapping of local-parts to a new set of
identifiers *without* effectively interpreting the local-part! If you define
the mapping as the draft currently does, implicit in that definition is that
local-parts are case-sensitive. And similarly, if you convert the local-part to
lower (or upper) case, you're now assuming the local-part is case-insensitive.

And in the case of EAI, without some sort of normalization you're assuming that
different UTF-8 representations of the same string of characters correspond to
different recipients. (Which, as Harald Alvestrand and I both pointed out on
the IETF list, is technically untenable and needs to be addressed. My
suggestion was and is to specify that the same case-folding and normalization
algorithm used for IDNs also be employed here.)

But - and this is the second fundamental point that AFAICT has been missed -
who is doing the interpreting? In one sense it's the consumer of the OPENPGPKEY
records in the DNS, and the discussion so far has focused on how such consumers
don't have the right to do that.

But who published those records? That would be the owner of the domain - you
know, the folks who *are* entitled to interpret the local-part of addresses in
whatever fashion they choose.

So when a domain owner publishes such records in the DNS, a reasonable way to
look at it is that they are effectively saying, "Everyone is allowed to
interpret the local-parts of our addresses as specified in this document in
this one narrow context." I'm pretty confident there's nothing in any standard
that forbids such a delegation of authority.

And once you realize this is what is going on, not only does it become clear
that this draft is *not* violating the longstanding rules about local-part
interpretation, it casts the decision not to normalize the local-parts to lower
(or upper) case in an entirely different light. By choosing not to normalize
this specification is effectively restricting its own applicability to domains
with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the
overwhelming majority of domains treat the local part in a case-insensitive
fashion, and so should the mechanism specified in this draft.

Or, to put this another way, the inherent limitations of using the DNS to
provide the mapping from address to PGP key restricts the domain of
applicability of this specification to domains with particular local-part
policies, and the way in which the local-part to DNS mapping is specified
determines which policies the specification supports. And while it seems
logical to support a policy that's known to be in wide use, the specification
also needs to be very clear that domains that employ case-sensitive local-parts
MUST NOT avail themselves of this mechanism.

What needs to happen here is that the specification be revised to make it clear
that this is what is going on: That by publishing such records a domain is
granting a limited right to interpret the local parts of its addresses.

(One can of course argue that a specification that fails to offer a solution to
case-sensitive domains, or to domains that employ various forms of
subaddressing semantics, is unacceptable. But I am emphatically not making that
argument. I have a number of grave reservations about this draft that I am
going to try to explain in subsequent messages, but this isn't one of them.)

There's also - as noted by Sean Leonard - a technical glitch in the current
specification: The local-part is not the correct input to the hash function. A
canonicalization step is needed because all of these addresses are
equivalent:

(1) [email-masked]
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

(2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to
(1) because the enclosing quotes are not properly part of the address, and (4)
is equivalent to (1) because quoted-pairs are semantically equivalent to
just the quoted character.

I believe this is the entire list, so the obvious canonicalization to use
on the local-part portion of an address prior to lowercasing and hashing is:

(a) If the local-part is unquoted remove any whitespace around periods.
(b) Remove any enclosing double quotes.
(c) Remove any literal quoting.

I might be inclined to say that this rather technical matter can wait to be
resolved in a future update, but (1) Implementations once deployed are
difficult to change, and according to the draft there are already incompatible
implementations out there and (2) Normalization need to be revisited
anyhow, so why not fix this as well?

Finally, a couple of observations about terminology are in order. The current
text covering the hashing of local-parts begins with:

      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]) is encoded in UTF-8 (or its subset ASCII).  If
      the local-part is written in another encoding it MUST be converted
      to UTF-8.

First, the left hand side of an email address is not a "user name" and should
not be referred to as such. (The entire address is in some cases a "user name"
of sorts, and in some cases the local-part is identical to some kind of login
credential. But neither of these are universally true, and more to the point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be charset.

That's all for now.

				Ned