2.10.3 Interim Meeting - MTA Authorization Records in DNS (marid)




IETF-60 Meeting MTA Authorization Records in DNS (marid)

Interim Meeting Report

Minutes of the MARID Interim Meeting - May 19 & 20, 2004


Chairs:
Andy Newton
Marshall Rose


Scribe:
Marshall Rose


Jabber Logs:
http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-05-19.html
http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-05-20.html


Room Hums:
From item 4: support for being able separately express legitimate, illegitimate, and unknown IP addresses.
From item 5: support for a hint regarding a reputation/accreditation service.
From item 9: positive feedback on the merged SPF/Caller-ID plan.
From item 11: support for a "wildcard-like" function.



Item 1: Agenda Bashing
Andy put forward the following draft agenda: agenda bashing, notes from the chair, semantics with subitems of bounce address tag validation and the 30% solution, DNS record type discussion, and syntax. The expectation was that the first day was to cover up to the semantics, and the second day would lead off with a DNS discussion. Andy also noted that the agenda would be fluid and would probably change as the meeting progressed.


Dave Crocker asked for time for a discussion on regarding the problems being solved by the each proposal by decomposing the mechanisms used in the proposals. Based on the sense of the room, Andy asked for that topic to be covered after the DNS topic.


Item 2: Chair notes
Andy simply asked the room to be courteous and professional and remember that all participants should be in the room for the purpose of working toward consensus.


Item 3: Bounce Address Tag Validation - Dave Crocker presenting
The main concept on this item is that the bounce address (2821.MAILFROM) is to be signed. The syntax would be:
as = <local-part> "/" <sig-type> "/" <sig-value>
The local part is opaque to the Internet, and is only meaningful to the domain specified by the domain part. This concept has two modes based on the sig-type: the first mode uses a secret symmetric key so validation is only done by the domain in the domain-part of the address, and the second mode uses a public key so that receivers may verify the address with public key management being done via domain keys.


Many participants questioned the need for standardization since it could be done unilaterally (without coordination of the rest of the Internet). Dave noted that even in the first mode, there may be multiple software components using this validation. He also noted that the first mode stops joe-jobs at the destination while the second mode stops joe-jobs at the source (of injection).


Concerns about replay attacks were mentioned. Dave suggested that a timestamp or some other data in the hash may solve the problem.


Many comparisons with other bounce prevention/protection schemes were raised. One participant mentioned that Dave's proposal sounded similar to an old version of the SES proposal. It was also suggested that this could best be handled via a BCP rather than a standard.


Item 4: 30% Solution Semantics - Pete Resnick presenting
Pete presented the "30% Solution": receiving server takes "claimed" domain name to lookup MARID records describing IP addresses and flags containing the source (mail-from, ehlo, etc...), flags for legitimacy, resolution type. Jim Lyon compared this solution to SPF and Caller-ID, and noted the similarities.


The group discussed sets of IP addresses as either legitimate, illegitimate, or unknown. Subtopics covered deriving the set of unknown and/or illegitimate from the set of legitimate using set subtraction, explicit definition of the sets, etc... Andy asked for a hum on the need for independently expressing the three sets; there was a loud hum for it.


Item 5: 40% Solution Semantics - Pete Resnick presenting
Pete presented his interpretation of the "40% Solution": receiving server queries type for legitimate, illegitimate, and unknown status with "claimed" domain, with subsequent lookups on other types if no data is found. Many of the participants expressed concern over the multiple lookups and perceived serial chaining of lookups with respect to latency. Many participants did not understand the nature of the second query with respect to the first.


The group then undertook a discussion on reputation services. There was debate about these services being about reputation or accreditation. Concern was expressed that the group did not possess the needed understanding of either reputation or accreditation services to adequately define either. The group then discussed the necessity to provide a hint to the reputation service. It was noted that a receiver would not outright trust any reputation hint from a sender, with the counter argument being that it allows receivers to only make a single reputation/accreditation inquiry if the hinted service is in the list of used services by the receiver (thus eliminating queries to multiple services).


A hum was called on the ability to specify a hint which gives a domain that gives further information with respect to accreditation (and could be a second record). A loud hum was heard.


Item 6: CAA Semantics - Douglas Otis presenting
Doug presented his CAA proposal using SRV records, with follow-on discussion by the group. In summary, the input to the process is EHLO, with outputs being IP addresses, and a bridge mechanism for 2821.MAILFROM if EHLO does not match.


Item 7: CSV Semantics - Dave Crocker presenting
Dave presented the CSV proposals. The group discussed his assertion that HELO/EHLO is "channel-based" while MAIL FROM is "content-based" (in that it is tied to the sender). He also briefly discussed "vouching services".


Item 8: Tagged Addressing - Sam Silberman presenting
Sam presented issues around tagged addressing. The group discussed replay attacks and the affects of a MARID/LMAP solution on forwarding.
Sam suggested that all forwarding be based on an opt-in relationship.
The group then discussed problems with forwarding and LMAP/MARID solutions. The presentation ended with Ted Hardie noting that this working group does not have a charter allowing the breakage of core email functionality, and that the working group needs to produce an applicability statement on the problems being solved.


Item 9: Caller-ID and SPF Converged - Jim Lyon presenting
Jim presented a plan for convergence of SPF and Caller-ID. This convergence would merge the differences between 2821 and 2822 identity checking by using the 2822 header selection algorithm in Caller-ID and by promoting it back to a 2821 identity through a proposed SMTP extension called "RFROM" (responsible from). It was noted that 2821.MAILFROM is currently overloaded and RFROM would provide clarity while allowing the check to occur before the SMTP DATA command. There was some discussion over spammers adapting to RFROM, but Jim dismissed the concern.


The new proposal would encompass the SPF semantics while using the XML encoding of Caller-ID. Jim gave several examples of how this would work. There was then some discussion on extension mechanisms and the necessity to get the semantics for it right. There was also concern that the proposal may be too complex and may contain features that are interesting but not necessary. Finally, a concern was raised regarding the number of recursive queries.


Andy asked the room if they found the converged plan valuable and wise use of time and received a loud hum. During revision of the minutes, two participants expressed confusion regarding this hum. The confusion centers around the chairs asking the room if the merged SPF/Caller-ID proposal was a move in the right direction vs. asking the room the merged SPF/Caller-ID proposal was to be the direction of the working group. The chairs note that it was not their intention to ask at that time for committal to this merged proposal being the sole proposal to move forward in the working group. Additionally , during the revision of the minutes a participant (one of the two above) also recalls a failed hum for concurrent work on this merged proposal and other 2821 proposals and passed hum for to revisit other 2821 proposals at a later time (no such hums were recorded in the raw minutes of either the chairs or the Jabber sessions).


Item 10: CSV Semantics Continued - Dave Crocker presenting
Link - http://brandenburg.com/presentations/CSV-Summary.ppt //TODO: update
Dave Crocker continued his presentation from the previous day on CSV, and explained the cut between the various CSV drafts. Dave's main point is that CSV is orthogonal to the SPF and Caller-ID solutions, and that CSV is inherently transitive unlike checks of MAIL FROM. A concerned was raised about multiple independent mechanisms. The group finished up the discussion with a comparison of the semantics of CSV with TLS and dial-back schemes.


Item 11: DNS Considerations - Ed Lewis presenting
Link - http://homepage.mac.com/resnick/copy_MARID-DNS.ppt //TODO: update
Ed presented various issues with extending DNS based on past attempts.
The group compared the advice to not use naming conventions with the popular use of SRV records. Many concluded that if SRV were to be defined today using this advice, it would not be feasible. Discussion also centered around adding a new RR type to DNS. Ed noted that the DNS community had previously been very uneasy in defining new record types for fear of depleting the namespace, but that fear no longer existed and new record types were considered the appropriate device for extending DNS. Many in the room were convince that adding a new record type to DNS would take 5 years or longer.


The group undertook a long discussion regarding client DNS support.
Some in the room felt that the issue should not sway the adoption of a new record type because it was relatively simple to write and deploy UDP DNS clients (one participant pointed out that most malware has its own simple code for this function). However, most of the participants in the room felt that current DNS library client support was lacking.
One participant pointed to a vendor solution that used RPC instead of DNS in certain situations.


Ted proposed a dual record type approach, whereby TXT records would be used in environments where a new record type could not be defined.


The participants then discussed wildcards. It was noted that the "name hack" excluded the use of wildcards without new DNS server code. Using SOA records to determine zone cuts for the purposes of tree-walking was also discussed. Ed questioned the viability of such an algorithm.


Andy asked for a hum of the room regarding the desire for a "wildcard-like" function and received a hum in favor of it.



Item 12: Utility of Bounce Addresses - Pete Resnick presenting
Pete started a discussion on bounces being tossed on the Internet by convention. This brought back many points for earlier discussions such as comparison of proposals using the EHLO banner for checking and the themes around tagged bounce address validation.


Item 13: Action Items - Marshall Rose presiding
Action 1 - Harry Katz, Jim Lyon and Meng Wong are to develop a schedule for the output of the SPF/Caller-ID converged drafts and send it to the list.
Action 2 - All parties are to review IPR disclosures with respect to their proposal.
Action 3 - Dave Crocker and Doug Otis are to develop a schedule for the output of CSV/CAA/SRV related drafts.
Action 4 - Daniel Quinlan to write a draft to standardize the Received header format, and mention RFROM.

Slides

Assess Peer MTA
DNS Consider