Alexey Melnikov has entered the following ballot position for draft-ietf-dane-openpgpkey-08: No Record
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I might have more comments/questions before the telechat. Here is my initial batch: 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? In section 7: What is the difference between "an email client" and MUA? 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. 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. 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. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
