I have read the SMIMEA -08 draft and support it being "undeterred" and put back on track. NIST also has some (old) test code that we want to host and have sponsored SMIMEA work in the past. Our previous work has used the format described in the current draft.
I have heard of two potential privacy concerns that the WG may want included in the Security Considerations section: First, if the _smimecert.<domain> is hosted by a service provider (i.e. not the domain owner), the service provider can see who may be receiving encrypted mail and may also learn the source IP address and other potential information. Of course, the hosting provider also knows the whole list of (hashed) cert holders in the domain as well. Pervasive monitoring may also discover this (source IP A is looking for a cert for person X in order to send them mail), but qname-minimization may mitigate this to a degree. Second, clients looking to validate a digital signature using SMIMEA queries may also be signaling a read receipt. If the original sender knows the recursive servers of the recipient, The sender could get an idea as to when the receiver MUA validated the digital signature by observing SMIMEA queries to their domain. This isn't a showstopper IMHO as recipients with cached digital signature certs may not send queries. To summarize as some suggested text (as a starting point at least - not happy with it, but it is the best my brain allows right now): ***** In addition to the zone walking vulnerability, SMIMEA aware senders and receivers may also leak information when querying for SMIMEA RRs for validating digital signatures and discovering a recipient's S/MIME encryption certificate. SMIMEA RR queries may leak information about who is planning to send, or has receive S/MIME protected email messages. DNS privacy techniques such as qname-minimization may mitigate some of the leakage. ***** Scott
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
