On Fri, 24 Jul 2015 12:40, phill(_at_)hallambaker(_dot_)com said:
2) If people find it does not meet OpenPGP needs, they should say so and
have no qualms about objecting. It is much more important that there be a
spec people use than that the document progress quickly.
I was a bit disappointed by the process: I learned about the I-D too late
and was surprised that it started out at the OpenPGP WG mailing list (2
years ago?) with just a few messages and then continued at the DANE list
without having notified the OpenPGP list. IIRC, I send some thoughts on
this to the GnuPG list but people told me that it is too late for
changes to the I-D - so I gave up.
Here are some thoughts, anyway:
- Why a new DNS record despite that the CERT type has PGP support for
9 years now (RFC-4398).
The argument for a new record is that this makes parsing easier
because there is no need to loop over the record's sub-types. I do
not consider it a valid argument because there is a need to loop
anyway because there may be several DANE records for the same key.
Adding an extra loop over the sub-types is a non-brainer and the
selection logic to find the best matching record will be the same.
The CERT record is more flexible because it also allows the use of an
indirect specification via fingerprint. DANE however could use the
straight PGP record and would be done.
GnuPG has support for such CERT records including a script to create
them also for about 9 years. It is not widely used because most users
have no way to add records to their zone - that is the same problem
for DANE of course.
- The use of SHA-224 (really, see below) to map addresses to valid DNS
characters is pure overkill. The shorter SHA-1 is sufficient for
this. Counter argument is that SHA-1 shall be phased out. I have not
looked up that IETF statement but I hope it states the "use of SHA-1
for cryptographic purposes". For example rsync(1) still uses MD5
which is sound for its purpose (SHA-1 would be better due to hardware
support but that is another story).
Actually it is using SHA-256 truncated to the size of SHA-224. Why
not using SHA-224 (which has a different IV)? That is surprising for
any implementer.
- The I-D says about the local-part of the mail address:
... it is turned into lowercase and hashed using the SHA2-256
[RFC5754] algorithm, with the hash truncated to 28 octets ...
Lowercasing UTF-8 characters is not easy and a likely reasons for
interoperability problems. It would be better to only require
lowercasing ASCII characters and keep characters > 127 as they are.
- There is no hint in the RFC on how to find a key to verify a
signature. This can't be done via a mail address but requires the
fingerprint (or as of today the key-id).
- How shall a key be retrieved or updated after a mail account has been
closed? It should be possible to verify signatures at all times.
Thus another non DNS service to keep the key available needs to be
setup too (e.g. a keyserver). That service is also required to allow
dissemination of revocation certificates. IPGP records could be kept
as long as the mail address has not been re-assigned.
- Implementation nit: The I-D states:
The lookup result MUST pass DNSSEC validation; if validation
reaches any state other than "Secure", the verification MUST be
treated as a failure.
As an implementer I see no way to do this without adding a full
fledged DNSSEC resolver.
People have been attempting to put email address related records into the
DNS since the first drafts of the spec and none has taken off.
That is a general problem. You need the support from the mail
providers.
I do not find the idea of relying on the DNS for my keys remotely
comforting and would not want to rely on such a record directly. The DNS
has no persistence to it. Give me the MIT keyserver any day.
When intending to send a mail the first time the DNS is pretty useful
because it creates an association between mail address and key. Thus
you can pick the right key and the recipient won't be annoyed by
encrypted mails they can't decrypt because the keyservers carry several
"faked" keys for their mail address.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp