On Sun, 10 Apr 2016, Alexey Melnikov wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I might have more comments/questions before the telechat. Here is my
initial batch:
Thanks for the review and comments....
5.1. Obtaining an OpenPGP key for a specific email address
If no OpenPGP public keys are known for an email address, an
OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
that corresponds to that email address. This public key can then be
used to verify a received signed message or can be used to send out
an encrypted email message. An application whose attempt fails to
retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
that failure for some time to avoid sending out a DNS request for
each email message the application is sending out; such DNS requests
constitute a privacy leak
Should the document give a specific recommendation about "remember for
some time"?
TTL for the corresponding RR?
TTL advise for this RRTYPE is not different from other RRTYPEs. After
talking to implementors, they stated they have their own methods for
dealing with things like attacks using short TTLs or overly long TTLs.
In section 7:
What is the difference between "an email client" and MUA?
Nothing. I can pick one of the two terms and make it consistent.
In 7.1:
If the DNS request for an OPENPGPKEY record returned an Indeterminate
or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the
message and queue the plaintext message for encrypted delivery at a
later time. If the problem persists, the email should be returned
via the regular bounce methods.
Is this behaviour only specific to encrypting gateways? I want to make
sure that this is not applied uncondionally to general MTAs, which don't
need to understand this specification.
This document only refers to those MTA's and MUA's (or their plugins)
that implement/support this document. I am not sure what you mean with
"encrypting gateways", but it applies to all those that implement
encrypting using OPENPGPKEY records. If the DNS returns Indeterminate
or Bogus, it means the DNSSEC records are bad or mangled, or withheld
by a MITM. To prevent a downgrade to plaintext, the above process is
defined to ensure no unencrypted message is sent out.
In 7.2:
If the public key for a recipient obtained from the locally stored
sender’s public keyring differs from the recipient’s OPENPGPKEY RR,
the MUA MUST NOT accept the message for delivery.
Minor terminology issue: It is better to say here "accept the message for
submission", because "delivery" is a recipient side operation which is
not done my MUAs, it is performed by MDAs.
How about:
[...] the MUA MUST abort sending the message and seek user assistance.
In 7.5:
The hashing of the user name in this document is not a security
feature.
Please use "local part" instead of username here, email addresses are not
user names.
Agreed.
Paul
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
