Subject: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Feb 2015 15:30:05 -0500

Dear DANE WG,

The author of draft-ietf-dane-openpgpkey has indicated that he
believes that the document is ready for Working Group Last Call.
The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

This document has been discussed a number of times, to jog your
memory, here is one slidedeck:
http://www.ietf.org/proceedings/89/slides/slides-89-dane-2.pdf
Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/
.*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed
"s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p
| gpg --import --dry-run

Please review this draft to see if you think it is ready for
publication and send comments to the list, clearly stating your view.

This WGLC ends Fri 06-Mar-2015.

In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dane-openpgpkey?  If so, has this IPR been disclosed in
compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
for more details.)

Thanks,
Warren Kumari
(as DANE WG co-chair)

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: James Cloos <[email-masked]>
Date: Fri, 20 Feb 2015 19:03:04 -0500

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/
WK> ..$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed
WK> "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p
WK> | gpg --import --dry-run

FWIW, that does not work here.

Bash adds a space after the $(), so one has to do:

  dig type61 $(printf %s._openpgpkey.fedoraproject.org. \
      $(printf pwouters | sha224sum | sed 's/..$//' )) \
      | grep TYPE61 | sed 's/^.*TYPE61.*\\\#[0-9]* //' \
      | grep -v ';' | sed 's/ //g' | xxd -r -p | gpg --import --dry-run

but gpg (2.0) does not like that binary data.

Replacing --import --dry-run with --list-packets does not do any better.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Feb 2015 00:34:39 +0000

> FWIW, that does not work here.

What works for me is:

    $ dig +short -t type61 $(
	printf "%s._openpgpkey.fedoraproject.org" $(
	    printf "%s" pwouters |
	    openssl dgst -sha224  -binary |
	    hexdump -ve '/1 "%02x"'
	    )
	) |
	perl -ane '
	    ($escape_sharp, $len) = splice(@F, 0, 2);
	    next if ($escape_sharp ne q{\#}); 
	    ($rdata = join("", @F)) =~ s/(..)/chr(hex($1))/eg;
	    next if (length($rdata) != $len);
	    print $rdata;
	    last;
	    ' |
	gpg --import --dry-run --verbose
    gpg: pub  4096R/E0FD94D2 2014-12-11  Paul Wouters <[email-masked]>
    gpg: using classic trust model
    gpg: key E0FD94D2: public key "[User ID not found]" imported
    gpg: Total number processed: 1
    gpg:               imported: 1  (RSA: 1)

Of course this ignores the DNSSEC validation status.  A better
approach is to do it all in Perl with Net::DNS and either trusted
(AD-bit) local resolver, or DNSSEC validation support in Net::DNS.

Python with the getdns api is another attractive option.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Feb 2015 16:45:52 -0800

What works for me is:

$ sudo yum | apt-get install hash-slinger
$ openpgpkey --fetch [email-masked]

:)

Sent from my iPhone

> On Feb 20, 2015, at 16:34, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Feb 2015 02:23:30 +0000

> publication and send comments to the list, clearly stating your view.

Comments:

* The below does not mention the hex encoding of the digest.  Compare with SMIMEA:

   OPENPGPKEY:

    3.  Location of the OpenPGPKEY record

       Email addresses are mapped into DNS using the following method:

       1.  The user name (the "left-hand side" of the email address, called
	   the "local-part" in the mail message format definition [RFC2822]
	   and the "local part" in the specification for internationalized
	   email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
	   algorithm to become the left-most label in the prepared domain
	   name.  This does not include the at symbol ("@") that separates
	   the left and right sides of the email address.

   SMIMEA:

	   The user name (the "left-hand side" of the email address, called
	   the "local-part" in the mail message format definition [RFC2822]
	   and the "local part" in the specification for internationalized
	   email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
	   algorithm (with the hash being represented in its hexadecimal
	   representation, to become the left-most label in the prepared
	   domain name.  This does not include the "@" character that
	   separates the left and right sides of the email address.  The
	   string that is used for the local part is a Unicode string
	   encoded in UTF-8.

* Grammar nit replace "its" with "their" or rephrase:

    5.1.  Email address information leak

       Email addresses are not secret.  Using them causes its publication.

* Forward security vouching for long-term keys

    There's a typo in the first word of the highlighted paragraph:

	5.2.  Forward security of OpenPGP versus DNSSEC

	   [...]

	   Therefor, an OpenPGP key obtained via an OPENPGPKEY
	   record can only be trusted as much as the DNS domain
	   can be trusted, and are no substitute for in-person key
	   verification of the "Web of Trust".  See [OPENPGPKEY-USAGE]
	   for more in-depth information on safe usage of OPENPGPKEY
	   based OpenPGP keys.

    An complementary approach is to not use the retrieved OpenPGP
    key beyond the signature lifetime of the OPENPGPKEY RRset RRSIG
    record.  Keys obtained from DNS should be refreshed as often
    as is practical (ideally before encrypting each message) and
    never used beyond the RRSIG lifetime.  Were the RRSIG in question
    signed by an attacker, only messages signed before the key is
    refreshed are compromised.  Of course this requires that PGP
    user agent software track the provenance and cache lifetime of
    keys obtained via DNS.

* Encoding tools:

	Appendix A.  Generating OPENPGPKEY records

	   gpg --export --export-options export-minimal \
	       [email-masked] | base64

  the "openssl base64" command is an alternative on many other platforms.
  Later the examples don't yet use the newly allocated TYPE61:

       These values can then be used to generate a generic record (line
       break has been added for formatting):

       <SHA2-224(hugh)>._openpgpkey.example.com. IN TYPE65280 \# \
	   <numOctets> <keydata in hex>

       ...

       ~> openpgpkey --output generic [email-masked]
       8d[...]b7._openpgpkey.example.com. IN TYPE65280 \# 2313 99008d03[...]

  the type should of course now be TYPE61.  May as well give a
  recipe for generating "SHA2-224(hugh)":

       printf "%s" hugh |
	   openssl dgst -sha224 -binary |
	   hexdump -ve '/1 "%.2x"' -e '/28 "\n"'

-- 
	Viktor.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Feb 2015 21:19:05 -0800

I have read the document. Modulo any other minor comments from other
reviewers, I think it is a fine document, and should be published.

Extremely minor comment:
In section 5.1, about email leaks, it may be worth additionally mentioning:
Use of distinct SALT values can further limit brute force efforts, even
where the same key is used.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Sat, 21 Feb 2015 15:44:37 -0500 (EST)

> reviewers, I think it is a fine document, and should be published.

Thanks for the review!

> where the same key is used.

How would that help? I would assume the attacker zone walks the zone and
then brute forces the names offline. Whether the actual live zone
changes salt wouldnt matter at that point?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 21 Feb 2015 15:54:22 -0500 (EST)

> * The below does not mention the hex encoding of the digest.  Compare with SMIMEA:

Thanks. Fixed for -02.

> * Grammar nit replace "its" with "their" or rephrase:

Fixed for -02.

> 	   Therefor, an OpenPGP key obtained via an OPENPGPKEY

Fixed Therefor -> Therefore.

>    user agent software track the provenance and cache lifetime of

I would like that discussion to go into the OPENPGPKEY-USAGE document.

>  the "openssl base64" command is an alternative on many other platforms.

What is more widespread? coreutils or openssl ?

>  Later the examples don't yet use the newly allocated TYPE61:

Well spotted :) Fixed.

> 	   hexdump -ve '/1 "%.2x"' -e '/28 "\n"'

Sure. But what is more common, coreutils or openssl :)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Feb 2015 21:33:55 +0000

> What is more widespread? coreutils or openssl ?

I was not suggesting a replacement.  Rather, you might mention an
alternative for platforms without "coreutils".

-- 
	Viktor.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 21 Feb 2015 14:15:31 -0800

> changes salt wouldnt matter at that point?
I should have been more clear in my comment.

Enumerating a zone when NSEC3 is used, basically only gives the attacker a
dictionary of NSEC3 owner names.
_Those_ owner names are salted hashes of the original owner names.
The effort to create a mapping from salted hashes to original owner name is
"X", for some X.

If the same NSEC3PARAMs are used, the same input -> same output, i.e. for
owner FOO, NSEC3 owner is BAR.
Changing the SALT and leaving the alg and iterations unchanged, means FOO
now hashes to BAR_PRIME.

If everyone used the same SALT, alg, and iterations, the attacker would be
able to add to her dictionary by attacking each hashed value once.

However, if everyone used random SALT, even with same alg and iterations,
the dictionary of hashed values becomes worthless, and the attacker needs
to maintain a dictionary of unhashed values, and need to hash the entire
dictionary to find matches on each subsequent zone.

It's an order(N) vs order(N) x order(M) thing, where N is the attacks
dictionary size and M is the number of zones the attacker is attempting to
harvest names for. It turns a win (space vs time) into a lose (diminishing
returns).

I think.

Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Feb 2015 22:50:23 +0000

On Sat, Feb 21, 2015 at 02:15:31PM -0800, Brian Dickson wrote:

> owner FOO, NSEC3 owner is BAR.  Changing the SALT and leaving the alg and
> iterations unchanged, means FOO now hashes to BAR_PRIME.
> 
> If everyone used the same SALT, alg, and iterations, the attacker would
> be able to add to her dictionary by attacking each hashed value once.

This is not the case.  Even with the same salt everywhere, the same
relative names yield different NSEC3 hashes in different domains.

    $ ldns-nsec3-hash -t 10 -s deadbeef  www.example.com
    posh7b8ariqtee5s9bji4jvlhmj5qtbn.

    $ ldns-nsec3-hash -t 10 -s deadbeef  www.example.net
    mj2fbsp4rqaqd2u1d1jhlr3scqeqi11i.

That's because the hash covers the full domain name, not just some
"prefix" labels.  So NSEC3 hashes are already effectively "salted"
with the zone name.  What "salts" do is allow each domain to further
impede off-line dictionary attacks (via per-domain rainbow tables)
by periodically changing the salt.

> dictionary to find matches on each subsequent zone.

No, it is OK for everyone to use the same salt, because that salt
is combined with their unique domain name.  For high value domains,
what is perhaps useful is to change the salt periodically.

For example, everyone could use the calendar YYYYMM (year + month)
as the salt.  And the attacker would need a new rainbow table for
each domain every month.  The fact that the salt is the same
everywhere would not be helpful to the attacker.  Of course knowing
future values of the salt would make it possible to start computing
the rainbow tables sooner, so the problem with YYYYMM is predictability,
rather than use by multiple domains.

-- 
	Viktor.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 21 Feb 2015 15:00:05 -0800

Thanks Viktor. Obviously, not enough coffee. :-)

Brian

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 Feb 2015 19:34:53 -0800

Having reviewed the document, I would suggest the following issues be
addressed:

1.  The introduction nicely restricts the problem to dealing with encryption
and not signatures.  I think it would be wise to have a brief paragraph
about why the signature side is not dealt with.  I think it would be as
simple as saying that the document is not doing anything about changing the
trust model, so the fact that one could obtain a signature key ring for a
sender does not give any additional security on the trust of the signature.
This might prevent a future update to the document that extended to deal
with signatures.

2.  The abstract should probably make a statement that the trust model is
not changing for keys, and this is targeted towards doing optimistic
encryption rather than secure encryption.

3.  Minor point - if you lost the public key you probably lost the
pre-signed key revocation.  Not sure that it is worth updating the paragraph
to reflect that this value can be lost as well.  s/pre-sign a key
revocation/pre-sign and retained a key revocation/

4.  In section 3, I strongly urge that the problem of case folding of user
names be acknowledged.   I don't insist that the problem be solved.  (I
believe that it is not really solvable.)  However I strongly field that the
existence of the problem needs to be stated along with the fact that there
is no intention to solve it.   The problem statement can also easily state
that this is a problem ONLY for US ASCII systems and not for UNICODE systems
as these are less likely to allow for case folding in the first place.
(Does not need to be in section 3, but that seems to be the logical place to
put it.)

5.  Did I miss someplace  a statement that this record type MUST be used
only if DNSSEC is present?  Or are you willing to use it w/o DNSSEC for
opportunistic encryption?  If so then that should probably be stated.

Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 03:52:30 +0000

> (Does not need to be in section 3, but that seems to be the logical place to

The problem *is* solvable.  Case-insensitive receiving domains,
could publish a case-folded version of the user name (hashed with
a tag that prevents collisions in other domains, I proposed a
concrete scheme some months back).  Senders could for the
unmodified lookup key, and then for the tagged case-folded
key.

The main question is whether we can reach consensus on wanting to
solve it (for OPENPGPKEY and SMIMEA alike).  Solving is the easy
part.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 Feb 2015 19:58:19 -0800

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Sunday, February 22, 2015 7:53 PM
> To: [email-masked]
> Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey -
*please*
> review.
> > believe that it is not really solvable.)  However I strongly field
> > that the existence of the problem needs to be stated along with the fact
> that there
> > that this is a problem ONLY for US ASCII systems and not for UNICODE
> > systems as these are less likely to allow for case folding in the first
place.
> > (Does not need to be in section 3, but that seems to be the logical
> > place to put it.)
> 
> The problem *is* solvable.  Case-insensitive receiving domains, could
publish
> a case-folded version of the user name (hashed with a tag that prevents
> collisions in other domains, I proposed a concrete scheme some months
> back).  Senders could for the unmodified lookup key, and then for the
tagged
> case-folded key.

And what happens in the following case:

I am on a case sensitive receiving domain.
There are two recipients - JimSch and jimsch on the domain.
jimsch has a record but JimSch does not.
I now try and send mail to JimSch but get a key for jimsch.

Jim

> 
> The main question is whether we can reach consensus on wanting to solve it
> (for OPENPGPKEY and SMIMEA alike).  Solving is the easy part.
> 
> --
> 	Viktor.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 04:08:33 +0000

> I now try and send mail to JimSch but get a key for jimsch.

You forgot to hash the tag with the case-folded name.

Speaking of which, IIRC neither the OPENPGPKEY nor the SMIMEA draft
explicitly mentions what to do about quoted localparts:

	"Sam.Jr."@example.com

The localpart is not a dot-atom, and thus requires double-quotes.
My contention is that in this case the input to SHA2-224 MUST
include the quotes:

	SHA2-224("Sam.Jr.")

not

	SHA2-224("Sam.Jr.")

In this case the simplest tagging scheme is:

	JimSch			- unfolded hash input
	jimsch@lowercase	- folded hash input

any email address of the form:

	"jimsch@lowercase"@example.com

would be hashed together with the quotes!

I don't have a pointer to my original proposal handy,
check the archives.  It is something along these lines.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Feb 2015 12:31:09 -0500

[ Meta top post ]

I'd like to also draw attention to the "companion" document
draft-ietf-dane-openpgpkey-usage (
http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ ),
which describes usage of openpgpkey records, and following CNAMES.

> check the archives.  It is something along these lines.

I *think* that the proposal is in this email:
http://www.ietf.org/mail-archive/web/dane/current/msg07163.html
(Viktor, 11 Dec 2014)

This seemed to be mostly met with acceptance (or, at least closer than
many of the other options!), but didn't address the user+tag@ or
johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does.
A potential, but icky solution to those could be synthesized records.

I'd just like to note that having a single rule for mapping ascii
addresses (e.g lowercase, s/\.//g, s/\+.*// ) sure would have been
nice. Next time someone has access to a time machine...

W

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 Feb 2015 09:45:55 -0800

Is there a reason that this is not doing last call at the same time?

Jim

> From: dane [mailto:[email-masked]] On Behalf Of Warren Kumari
> Sent: Monday, February 23, 2015 9:31 AM
> To: <[email-masked]>
*please*
> I'd like to also draw attention to the "companion" document
draft-ietf-dane-
> openpgpkey-usage ( http://datatracker.ietf.org/doc/draft-ietf-dane-
> openpgpkey-usage/ ), which describes usage of openpgpkey records, and
> following CNAMES.
> 
> On Sun, Feb 22, 2015 at 11:08 PM, Viktor Dukhovni <ietf-
> [email-masked]> wrote:
> > My contention is that in this case the input to SHA2-224 MUST include
> > the quotes:
> >
> >         SHA2-224("Sam.Jr.")
> >
> > not
> >
> >         SHA2-224("Sam.Jr.")
> >
> > I don't have a pointer to my original proposal handy, check the
> > archives.  It is something along these lines.
> 
many
> of the other options!), but didn't address the user+tag@ or
addresses (e.g
> lowercase, s/\.//g, s/\+.*// ) sure would have been nice. Next time
> someone has access to a time machine...
> 
> W
> 
> >
> > --
> >         Viktor.
> >
> I don't think the execution is relevant when it was obviously a bad idea
in the
> first place.
regret at
> having chosen those particular rabid weasels and that pair of pants.
>    ---maf
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 18:18:15 +0000

> A potential, but icky solution to those could be synthesized records.

If the goal is to go beyond case-folding, then we'd have to seriously
consider publishing the data via a DANE-authenticated HTTPS service
rather than directly in DNS.  The service would then be able to
apply whatever lookup transformations are locally applicable.

I'm not sensing much appetite for moving away from per-user records
in DNS, so case-folding can be handled, but fancier variants are
I think beyond what can be done with the logic mostly on the client
side.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 Feb 2015 12:39:24 -0800

*please*
draft-ietf-dane-
many
> A potential, but icky solution to those could be synthesized records.

If we are going to deal with these cases then there are number of other
problems that need to be addressed.  Specifically the fact that there is
going to be a problem matching of email addresses found in the PGP key ring
and those that are on the to/from line of a mail message.

MUAs have traditionally just done simple comparisons of names, they are not
going to be able to handle the type of thing where google starts removing
periods from the name. 

A person is going to say - send me that and here is my address.  If it has
funny things in it, that is going to need to be matched in the PGP key ring.
I don't know how common that is for PGP, but it was rare in the S/MIME world
when I was doing work there.

Even case folding is not a requirement for S/MIME clients on doing name
comparisons of the address in the headers as compared with the address in
the certificate.

There are two different names that needs to be dealt with:

1.  The name the owner of the mail box thinks that is being used.
2.  The name that mail system thinks is being used for the mail box.

If these names differ by more than case, then there are going to be a great
number of failures in comparisons between from and to fields and the email
address in either a certificate or a key ring.  While there are stupid
folding rules that have been implemented by different systems.  They are
going to lead to problems if they are not recognized by the owner of the
mail box.  If I think the address is [email-masked] and put that into a
key ring and the From address is [email-masked] then there is never
going to a successful match by an MUA to begin with.

Jim

addresses (e.g
in the
regret at

---

From: Brian Dickson <[email-masked]>
Date: Mon, 23 Feb 2015 14:49:19 -0800

> I think beyond what can be done with the logic mostly on the client
I think maybe this needs to be broken out as a separate mini-document.
However, I think the right time to do this is NOW.

Here's the reasoning to support "NOW" for when to address this issue:
- right now, there aren't any clients doing the DANE s/mime or pgp thing
yet (I believe)
- if everyone implementing the DANE stuff for clients has the same rules to
work from, much happiness ensues
- if, on the other hand, all the DANE stuff gets built without the extra
"case-folding++" logic, it becomes a missed opportunity that can never be
addressed successfully (shutting the barn door after the horse has left)

The thing to do, IMHO, is identify ALL of the specific things that anyone
does in MUA/MTA name-handling, beyond case folding. I think even
standardizing a signaling for case-folding of names is beneficial.

The difference between PGP keyrings and DANE, is that users are responsible
for adding any "case folding" aliases into their PGP keyrings, e.g. as
child alias for their main fingerprint (or whatever the correct terminology
is for that). On the other hand, domain-based user aliasing is, by
definition, known by and generally able to be handled by, the admin for the
domain.

My suggestion would be to have some kind of _THING defined, which is
well-known, and which is queried, that lists the specific username-folding
ruleset(s). E.g. _casefold TXT "lc" for lowercase as the canonical form, or
_casefold TXT "lc nodots" for removing any dots, and converting to
lowercase, or _casefold  TXT "lc trimplus".

Having a canonical list of these NOW, means coding for DANE S/MIME and DANE
PGP can include this, and then it is up to the zone publisher to do the
right thing.

My $0.02.

Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 22:56:30 +0000

> http://www.ietf.org/mail-archive/web/dane/current/msg07163.html

Yes, thanks that the correct, more complete description.

The difference between that and what I wrote down from memory
today is the placement of the tag:

	@lower:local-part-with-quotes-if-needed

vs.

	local-part-with-quotes-if-needed@lowercase

These are trivial variations of the same thing, perhaps today's
@lowercase suffix is more natural, but I don't really care which
if either is selected, if this general approach is chosen.

Is there rough consensus behind this proposal (for both OPENPGPKEY
and SMIMEA)?

-- 
	Viktor.

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 25 Feb 2015 12:15:45 -0500

> which describes usage of openpgpkey records, and following CNAMES.

Is this also in WGLC?  Either way, some comments:

- In section 1 (Intro), there is an incorrect XML tag (xref)

- In Section 3.3 Final paragraph about wildcards:  ...at other locations (e.g. hugh@*.com) or regular expressions in keu uids are not allowed, adn any OPENPGPKEY RR containing these should be ignored."

Should that be a SHOULD above?  It discusses implementation behavior in addition to what is already described in Sections 4.3 & 4.4.  

- In Section 3.4 spelling s/Resoruce/Resource and s/accomodate/accommodate

- In Section 4. s/twart/thwart

At least I assume that last one - my spell checker gets confused about UK vs. US english.  

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Feb 2015 12:26:30 -0500

> Is this also in WGLC?  Either way, some comments:

It is NOT currently in WGLC -- but the comments are appreciated.

Would the WG like to WGLC this at the same time? Olafur and I has a
discussion about this - he figured it should be included, I thought
better to hold off - I'm happy to start a WGLC if folk want that.

W

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Feb 2015 12:37:54 -0500

> Is there rough consensus behind this proposal (for both OPENPGPKEY

I think we were very close to rough consensus, but I'm not sure how
many people actually read the suggestion. I know not everyone loved
the idea, but I think it might be the best that we can do....

Viktor, would you mind writing up the proposal again (in a new thread)
and we'll call consensus on this approach?

W

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Feb 2015 12:42:49 -0500 (EST)

> better to hold off - I'm happy to start a WGLC if folk want that.

The document is not ready. We are before the "nits" stage and I think
it would be good to discuss it from a high overview level. It basically
moved controversial policy decisions from the record format document
into this one - I don't think we actually had the dicussions we
postponed.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Feb 2015 12:50:59 -0500 (EST)

> and we'll call consensus on this approach?

I think I explained this before, but I don't like anything that requires
putting more than one entry into the DNS. The logic should be in the
client behaviour. the SMTP protocol allows "Frank" to be a different
email from "frank" so we cannot define these two to be the same at the
protocol level. We can only provide guidance the clients trying to
consume the new RRtypes.

So I'm okay with defining client behaviour to try sha224(Frank) and then
sha224(frank) and have a note in the security section explaining that
in theory (even if not in practise) these two could be different people.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Feb 2015 18:13:22 +0000

> protocol level. We can only provide guidance the clients trying to

Note that precisely because the client is not free to define "Frank"
to be the same as "frank", and because DNS does not have anything
remotely resembling server-defined case matching rules, we either
give up on supporting case-less matching even when case insensitivity
is known to the server, or multiple lookup keys need to be published,
in such a way that "frank" is explicitly lower-case-of(Frank) rather
than just some lower-case address.

> in theory (even if not in practise) these two could be different people.

Once the client is making two queries, why accept collisions?  Are
we (after all these years) finally defining RFC-822/2822/5322 local
parts to be case-insensitive?  (Price of progress and all that?)

Is a CNAME per-user really a major burden?

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Feb 2015 14:01:38 -0500 (EST)

> Is a CNAME per-user really a major burden?

It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul
paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P

The client needs smart logic anyway, and the client at least has a user
it can interact with. It can ask "A key for [email-masked] does not
exist but there is a key for [email-masked]".

Needing to roll out between 2 and 4 different capitalizations for
different [Ff]irstname.[Ll]astname makes everything more errorprone
and the client still needs its logic and user interaction.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Feb 2015 19:15:00 +0000

> paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P

One CNAME per case-insensitive name (if the preferred form is mixed
or upper case).  Those other names you're mentioning if they all
share the same underlying keys would be CNAMEs you'd have to create
with or without my proposal for a mechanism to publish case-insensitive
names.

> exist but there is a key for [email-masked]".

Why ask the user, when the server can just publish the fact that
all upper/mixed-case veriants of "paul" are the same mailbox.

> and the client still needs its logic and user interaction.

The I don't how you get to "4".  You can publish exactly one owner
for each case-insensitive "LocalPart", no CNAMEs required if you
are willing to accept clients making two queries to find keys in
your domain (space/time trade-off):

	SHA2-224(localpart@lowercase) IN <RDATA>

Optionally, for faster queries, if the mailbox has a preferred
form:

	SHA2-224(LocalPart)		IN <RDATA>
	SHA2-224(localpart@lowercase)   IN CNAME SHA2-224(LocalPart)

If there's also a "Local.Part" and "local.part" to go with it, that
it is completely separate from my proposal which deals only with
handling case-insensitive matching.  The overhead of supporting
case-insensitive matching is at most a second (CNAME) record for
each record that would be there in the absence of the proposal.
	
-- 
	Viktor.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 25 Feb 2015 13:41:19 -0800

Top-reply to raise (IMHO) a major issue:

This is not only a "publish vs discover" issue, it also is dangerously
close to the IDNA rat-hole.

I wasn't around when the latter came up, but I think DNSEXT dodged a bullet
very wisely, by making it the applications' responsibility to handle
any/all case folding beyond ASCII.

There are also scale issues, e.g. consider use cases where #users in a
domain vary in order of magnitude. What works for O(10e3) does not work for
O(10e6), and definitely does not work for O(10e9).

There are implications to DNS resolution & caching, if you consider stub,
recursive, and authoritative actors. It may be the case that multiple
queries need to be done by the stub, regardless of approach. However, if
policy discovery involves looking up a single common record per DNS zone
(e.g. rhs of email address), then this is cacheable and reduces both the
size of the publishing zone, as well as the number of queries by the
recursive to the authoritative, per client query.

I implore everyone to please consider the design:

_casefolding RRTYPE RDATA as a way of allowing the zone owner to publish
all the case-folding rules for the zone, and require the client to use this
to discover the canonical (published) owner name for a given email address.

Brian

P.S. For those not familiar with it: The IDNA rat-hole involves
case-folding of >2:1, as well as things like Greek language where there are
lots of rules governing variant code points depending on context
(first/last letter of a word). Putting that into DNS would have been an
absolute nightmare, and pushing back on that request was IMHO the right
thing to do.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Feb 2015 00:31:39 +0000

> recursive to the authoritative, per client query.

If by RHS of email address you mean the domain part (the local part
being the LHS), then indeed designs are possible where the case
folding rules are published via a single per-domain key.

However, this does not substantively impact the scalability of DNS
caching, by which I mean that the number of cache entries is
increased by a factor of two rather than some much larger factor.

> to discover the canonical (published) owner name for a given email address.

This complicates the client code, but avoids the factor of two in
the number of cached records.  We would still however need O(10e9)
records in zones like gmail.com.  The only way to eliminate that
problem is to do per-user lookups via an online query service (whose
location is published via DNS) rather than finding users directly
in DNS.

-- 
	Viktor.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 25 Feb 2015 17:24:00 -0800

> increased by a factor of two rather than some much larger factor.

For all but the most unusual domains, I would expect the user queries to be
all long-tail, with no substantial busy user set.

So, the caching of the policy record improves client query count (1 vs 2),
times total volume to the zone.

I would even expect that individual user entries to have TTL = 0, as there
is little to no value in caching individual records.
(Stubs might briefly cache, as might MTAs, but that is at the app layer,
not the DNS resolver.)

The real problem is the number of entries required in the zone. (see below)

> the number of cached records.
>
>
To use the gmail example, I just did a test.

I was previously unaware of the "s/\.//g" behavior. But, it is real.

So, I sent mail to a never-before-used variant of my name, "br.i.an"
instead of "brian".
Lo and behold, it was delivered to my mailbox.

If the goal was to preserve this behavior, while having MUAs look up keys,
without a policy mechanism, it would be necessary to publish 2^(N-1)
records for every name of length N.

If the average length of a name were 11 characters, then 2^10 = 1024
records would be needed per user.
This takes O(10e9) and turns it into O(10e12), of thing which have to be
hashed, signed, and then NSEC/NSEC3-ified.

So, the publishing side takes a disproportionate hit.

Have the client understand a very limited set of case-folding rules, which
could be used universally, is clearly preferable, even to the client, IMHO.

Brian

---

From: Coyo <[email-masked]>
Date: Wed, 25 Feb 2015 19:48:20 -0600

On 2/25/2015 7:24 PM, Brian Dickson wrote:
> So, I sent mail to a never-before-used variant of my name, "br.i.an 
> <http://br.i.an>" instead of "brian".

Gmail also ignores everything after + so brian+dontspamme is sent to brian.
this can be helpful for writing spam filtering rules.

---

From: Petr Spacek <[email-masked]>
Date: Thu, 26 Feb 2015 16:23:41 +0100

> publication and send comments to the list, clearly stating your view.

IMHO current version *should be rejected* because further clarification to
keyring format is needed.

See previous discussion on
http://www.ietf.org/mail-archive/web/dane/current/msg07227.html

As I already said, I believe that -01 version does not define an interoperable
standard.

The main problem is that
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01#section-2.1
2.1. The OPENPGPKEY RDATA component
  The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single
  value consisting of a [RFC4880] formatted OpenPGP public keyring.

references

http://tools.ietf.org/html/rfc4880#section-3.6
3.6. Keyrings
  A keyring is a collection of one or more keys in a file or database.
  Traditionally, a keyring is simply a sequential list of keys, but may
  be any suitable database.  It is beyond the scope of this standard to
  discuss the details of keyrings or other databases.

and this definitely is not a definition you could use for implementation.
	
Current format of records can stay as is but it has to be clearly documented
so we do not rely on current GPG implementation.

'It is beyond the scope of this standard to discuss the details of keyrings or
other databases.' is simply not sufficient.

-- 
Petr Spacek  @  Red Hat