Subject: [dane] draft-wouters-dane-openpgp-01 review

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 6 Jan 2014 13:25:24 -0500

This is an interesting draft and looks like a  good idea, 

I just reviewed the draft with an eye if it is ready to be used as reference for DNS RRYTPE template submission. 

The draft specifies that Presentation Format for the RRTYPE is Base64 (good) 
The draft specifies that the WIRE Format for the RRTYPE is Base64 (bad) 

I suggest that the draft be expanded to talk about Presentation format and Wire Format separately. 
Making this change in the draft will require that Paul needs to update his tool that he released today. 

Nits and questions: 
Section 3 says: "If an an OPENPGPKEY RR contains an expired OpenPGP
   public key, it MUST NOT be used for encryption." 

Suggest: "SHOULD" instead 

Section 3.1 I propose that this section be moved into Section 4, leaving only 
3 and 3.2 in section 3. 
Section 3 then only defines the DNS RR 
Section 4 then deals with location of the records in zones and how to convert "email address" into
DNS labels. 

Section 4.4 (KEY size and record size issues) is orthogonal to section 4. and should (it you keep it) become a new section
on usage and operational guidance. 
In addition to talk about key size it should recommend that a user SHOULD only have one Active record, i.e. the key
it wants others to use to use for encryption. 

Section 7: should become an appendix (how to generate a record) 

Question: Transitioning trust from old key to new key is not covered in this draft, should it ? 

	Olafur

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Jan 2014 20:40:56 +0000

> Suggest: "SHOULD" instead 

Why should "expired" keys not be used?  So long as the RRSIG on
the OPENPGPKEY record is not expired, the key is not "expired".
If none of the key metadata is authenticated independently from
DNSSEC, we only learn an expiration date modulo the validity of
the DNSSEC identity to key binding and if we trust that, why not
trust the key?  If the key is really expired, it should be replaced
in DNS.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jan 2014 13:11:42 +1100

Section 3.1 has lots of factually incorrect rationals for
encoding using base32.  The DNS is capable of encoding
binary data in labels up to 63 octets.  I've got no problem
with encoding, but if one intends to include rationalisations
please make them factually correct.

There is no mention of how to encode LHS which exceed 63 octets
when encoded using base32.  Pack the left most labels or the
right most labels?

There is no mention of how to normalise LHS prior to base32 encoding.
Are "Hugh" and "hugh" the same?  Should "hugh" and "hugh+xxx" be
treated the same?  It should be possible to specify normalisation
rules and store them at _openpgpkey.  Is the input UTF-8 or some
other character set.  If UTF-8 what normalisations need to be
applied?

It might be useful to suppress the padding at the end of base32
encoded strings.  We already do similar suppression with NSEC3
records.

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Jan 2014 23:30:54 -0500 (EST)

On Tue, 7 Jan 2014, Mark Andrews wrote:

Thanks for the review Mark.

> please make them factually correct.

I took those from draft-hoffman-dane-smime-01, Paul Hoffman and
Jacob Schlyter believe these to be right as well? Can you explain
what's wrong or perhaps write a replacement paragraph that would
agree with you more? It's mostly there to explain why we did not
end up using username._openpgpkey.domain.com and require base32 encoding.

> when encoded using base32.  Pack the left most labels or the

Is that really a use-case we need to cover? How many _real_ +- 50+ LHS
character email addresses do people use? I'm happy to document the
limitation, a little more reserved for specifying tricks to go beyond.
For example, http://tools.ietf.org/html/rfc6763 mentions this limit too
in context of UTF8,unicode,Kanji without defining anything to extend
this limit.

> There is no mention of how to normalise LHS prior to base32 encoding.

That was discussed offline, but you are right in that the result of
that discussion is missing. Since there seems to be great variety in
how SMTP servers normalise the LHS, we did not want to enforce our
one normalisation.

> Are "Hugh" and "hugh" the same?

That really depends on the SMTP server implementation, the OS it runs
on, the email client used by the sender, etc.

> Should "hugh" and "hugh+xxx" be treated the same?

I don't think so? The "+" sign as magic "this is the same user as"
is also not a feature supported by all SMTP servers or specified in
a standard, correct? And people might want to use different keys for
paul+personal versus paul+ietf.

> It should be possible to specify normalisation
> rules and store them at _openpgpkey.

But those rules could change if the SMTP implementation changes?

So, this document is leaving these as unclear as whether your email
will arrive at all or not based on the presence or absence of
normalisation rules of the SMTP server.

> encoded strings.  We already do similar suppression with NSEC3

Unlike NSEC3 we will see some interaction with userland tools and humans
that will use stock base32 that produces the padding. So I have a slight
preference to stick with the output generated by standard base32 code in
the hope that it will be less confusing to users and developers.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Jan 2014 23:35:17 -0500 (EST)

> I suggest that the draft be expanded to talk about Presentation format and Wire Format separately. 

That was a very good point and unclear in the document. I've addressed
these and will submit the new version soon.

> Making this change in the draft will require that Paul needs to update his tool that he released today. 

That's fine :)

> Section 7: should become an appendix (how to generate a record)

I've made these changes, and after some more talking decided to split
this document in two. One for just the technical specification of the
DNS record, and one for the recommended usage of the DNS record.

> Question: Transitioning trust from old key to new key is not covered in this draft, should it ?

I don't think so. I cannot come up with any good "rollover advise" I
would give other than "replace the DNS record once you have a new PGP
key". Whether you lost your old PGP key or not, when you are ready for
the new PGP key, you can just remove the old one.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jan 2014 16:27:24 +1100

In message <[email-masked]>, Paul Wouters wr
ites:
> Is that really a use-case we need to cover?

Yes.  Lots of mail systems use real names and some people have long names.

> How many _real_ +- 50+ LHS character email addresses do people use?

The fact that you can't answer that is the reason you need to support
them.

> I'm happy to document the

I didn't say enforce one normalisation, though you should specify
how to handle all the forms of Postmaster as that is required to
be treated as a case insensitive value.

> paul+personal versus paul+ietf.

And this is not a decision that needs to made by us.  This is a decision
that should be made by the publisher of the data.  One could even have
a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

> But those rules could change if the SMTP implementation changes?

So you update the rules.
 
> normalisation rules of the SMTP server.

This is about how to discover the pgp key stored in the DNSN for a
user given a email address.

I know that my email address is in various databases as "[email-masked]"
and "[email-masked]" despite me entering it as "[email-masked]" in
all cases.  I still want those who have stored the address as
"[email-masked]" to be able to find my PGP key.  I do not want to
have to add 31 CNAME records to the DNS to account for all the
permutations of MaRkA.

> the hope that it will be less confusing to users and developers.

s/=*//

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Jan 2014 05:44:02 +0000

> a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

Sorry, CMU-style address extensions are a local matter entirely
outside the world of email standards.  On some domains "+" is
special, on other domains "-", and others still some other convenient
character not used in real email addresses.

It is not possible to handle these without substantially complicating
the logic.  One would have to query the domain for the domain's
recipient delimiter first, and then for the address.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jan 2014 17:32:13 +1100

In message <[email-masked]>, Viktor Dukhovni write
> character not used in real email addresses.

All of which is irrelevent provided you can encode that into a policy
which can be transmitted.

> recipient delimiter first, and then for the address.

So.  One of the reasons to go with base32 and not raw binary is
that the DNS does normalisation which is potentially different to
the normalisation done by the SMTP server.

At a minimum we should be able to specifying "no normalisation" vs
"case fold" (and which direction) for ascii LHS.

Yes, it makes things more complicated but the real world is
complicated.

Remember that one is comparing this to a SRV record which points
to a key server that does all the normalisation required to return
the correct key 100% of the time.

Mark

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 7 Jan 2014 13:23:38 +0100

> "case fold" (and which direction) for ascii LHS.

Seems to me these are both the same issue, and they could either be 
resolved with one (probably nasty) policy-specification, or not at all 
(leave 'em out like smtp does). Not a big fan of either :)

> the correct key 100% of the time.

Are you suggesting this as a possible solution (which sounds more like 
using DNS(SEC) to specify personal pgp key servers to get around the 
current pgp key server problem)?

(while I type this, I wonder whether this functionality should be on 
this level in the first place; shouldn't it fit better in smtp itself, 
which is the only real place that currently know what normalization and 
other rules apply?)

One small thing on the draft itself: IMO the last part of section 2 
should not use 2119 terminology; it's not about interoperability nor 
implementation. Oh and 'sent' should be 'send' :)

Jelte

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jan 2014 10:37:20 -0500

On Jan 7, 2014, at 7:23 AM, Jelte Jansen <[email-masked]> wrote:

> 
> One small thing on the draft itself: IMO the last part of section 2 should not use 2119 terminology; it's not about interoperability nor implementation. Oh and 'sent' should be 'send' :)
> 

Second.  Also some minor nits that may not have been covered:

Section 3 second paragraph: Should the last sentence (if retrained) be moved to Sec. 4?  It discusses key considerations and feels out of place here in in the RR description.

Sec 4.3 first paragraph "This public key cannot be used..." Is that part of the OpenPGP spec (not familiar with it)?  Otherwise, should it be "This public key SHOULD(MUST?) NOT be used if it would only contain the key uid "[email-masked]"'

Sec 4.4 spelling Resoruce/Resource.  Also, "recommended" is in the last paragraph - should it be the RFC 2119 keyword RECOMMENDED?  It is a solid thing to add in order to reduce problems with large RRsets.

I think this can co-exist with the SMIMEA RR as well.  Wish there was a nice way to know which to query for when trying to discover an email cert. :)

Scott

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