Home · About · A-Z Index · Search · Contacts · Press · Register · Login

The Open Group Messaging Forum

Minutes of Meeting held in Boston, MA on July 20th-22nd 2004

Attendees

Bridging the Bridges

SMG Certification

Canning Spam

Action List

Future Meeting Schedule

Useful Links

1. Attendees

2. Bridging the Bridges

2.1 Objectives of Session

This meeting set out to examine activities in the US and Europe to establish Bridge-CAs for the purpose of cross recognition of security certificates and to identify what is needed to enable cross Atlantic cross certification of certificates.

2.2 Introduction

Mike Lambert, Director of the Messaging Forum, introduced the meeting with a brief introduction to The Open Group, the Messaging Forum and the objectives of the meeting (which arose out of a meeting in April 2004 in Brussels, Belgium, to consider activities in Europe).

2.3 The European Bridge-CA Project

Charles Blauner, from  Deutsche Bank, gave an overview of the business objectives and overall architecture of the European Bridge-CA.

The European Bridge-CA is a private partnership between a number of European companies, mostly in Germany, to address the problems associated with interoperability among PKIs and applications, without a hierarchical structure and without n:n cross certification.

Stephan Wappler, from Noventum Consulting, went into a little more technical detail about the way that the service operates and the current capabilities. He explained hoe the European Bridge-CA addressed the 4 major requirements of a bridge infrastructure:

1. Generation of trust relationships (Trsutworth exchnage of certificates)
2. Access on participants and/or user certificates (Directory service)
3. Validation of certificates (Validation service)
4. Generation of a contractual framework

2.4 The US Federal Bridge-CA

Judith Spencer from GSA, and chair of the Federal Industry Credentialing Committee, presented the current state of play with the US Federal Bridge-CA. This covered the background to the Federal Bridge-CA, the architecture and a growing list of cross certified organizations. The presentation introduced a group that is already working on Transatlantic issues, the Transatlantic Secure Collaboration Program (TSCP) - see link below, and included a list of issues that need to be addressed:

1. Compound mapping variance - Different degrees of compatibility
2. Undocumented practices - Accepted or de-facto standards within specific communities
3. Compatibility of relying parties - Technical incompatibility
4. Use of constraints - Limiting name form or path length
5. Liability
6. Incompatible governance structures 

Finally, Bill Burr, from NIST, presented his view of Bridge-to-Bridge International Cross Certification issues. He talked about the future of the Federal PKI, and some FIPS that define a common policy framework, plus the transition to stronger encryption. His list of cross-certification issues includes:

1. Legal and general certificate framework
2. How many certificates? Can we include digital signature and non-repudiation in the same certificate?
3. Strategy for 2048-bit keys and 256-bit hashes
4. Naming & name constraints
5. Directories
6. Path discovery
7. Scalable validation and status

2.5 Discussion

Time permitted only a limited discussion. In summary

• There was a willingness on all sides to address the issues raised
• In many respects, the most significant communication challenge appears to be between commercial and defense initiatives in Europe

2.6 Outputs

1. A list of potential barriers to International Cross Recognition.

2.7 Next Steps

Between July 2004 and the meeting in New Orleans meeting in October 2004, research will be carried out to determine

1. Whether the list of issues from this meeting is complete
2. The extent to which other groups are already working on issues identified

There will be a follow-up session during the October 2004 meeting to review the results of this research and plan future activities within the Forum.

3. S/MIME Gateway Certification

3.1 Objective of Meeting

1. Examine how vendors and customers can get value from the S/MIME Gateway Certification program
2. Plan the next version of the S/MIME Gateway Profile
   • Contents
   • Timing 

3.2 Summary

Luke Lucas and Joe Nakai of BT Syntegra receive their certificate from Allen Brown, President of The Open Group and Elliot Stone, Executive Director of MHDC  

Jim Normandin of Tumbleweed Communications receives his certificate

The meeting on Wednesday July 21st opened with Mike Lambert, Director of the Messaging Forum, giving a brief Introduction to the S/Mime Gateway Certification program, focusing on the value of the program to customers.

Ken Beer in Implementing the S/MIME Gateway Specification addressed the reason why gateway encryption products are needed, how they work and defined a set of "Implementation Best Practices". In explaining the testing that was needed to achieve certification, he indicated that the testing was repeatable by customers during deployment.

Discussion points:

Q (Russ Chung): Are we supporting Gateway to Desktop S/MIME. 

A: No (not yet) but included in the model for completeness. The demand for this will grow over time. Still protects users in sending domain from having to know about security.
Q (Russ Chung): Are commercial CAs currently issuing domain specifications. 

A: No, but you can get an INDIVIDUAL certificate for address domain-authority. The program may generate a market for domain certificates.
Q (Dean Sepstrup): We may have made the overall problem worse, by introducing a solution that is not interoperable with desktop-to-desktop encryption mechanisms.

There then followed an inconclusive discussion about domain signatures, that was continued at various points in subsequent sessions.

Luke Lucas in SMG Implementation presented a case study of deployment of a SMG for a very large US manufacturer, and also presented a set of Best Practices.

Discussion points:

Q (Ben Littauer): Was testing rigorous enough, if it only took 1 day?
A (Ken Beer): Yes it was sufficiently comprehensive, but there will be cases that were not tested.

Q (Russ Chung): Should we include deliberately bad data in the tests.

Building on these presentations, Ben Littauer led a discussion to initiate work on the next version of the S/Mime Gateway specification.

Maintenance Release

Mike Lambert: We probably will need a maintenance release in mid 2005 to address experiences from v1 of the program.

Certificate Revocation

Ken Beer: Certificate revocation.

Russ Chung: This is not as important as for user certificates. Domains don't change as often as users.

Ben Littauer: Urgency not great because of simplicity of key management in version 1.

Automated Key Exchange

Ben Littauer: We need improved key exchange for scaleability. (e.g. Ability to access keys from directories). 200 customers is about the limit of sustainable maintenance without automation, if for example cert expires annually. (Current best practice)

Ken Beer: Dual keys. (Signature and Encryption)

Ben Littauer: What are the semantics of a domain signature key.

Claudia Boldmann: Does this allow the organisation to authenticate itself?

Stephan Wappler: Legally all it means is that the message passed through the gateway.

Ben Littaue: This may be valuable in an anti-Spam context.

John Thielens: Why would people add a signature in the first place.

Initially to aid traceability, buy later could add additional semantics.

The technical question relates to the whole architecture of the e-mail system rather than simply the signature. One technical feature could be to define a way to define the policy.

Michael Burdeos: You want a way to advertise the behavior of the domain gateway has passed through.

John Thielens: Liability for sending PHI in the clear lies with sender, so it does not matter whether the receiver trusts the sender.

Stephan Wappler: We need to solve the issue relating to mail relaying. Stuff must go through the mail gateway to get encrypted. Means SSL or VPN link for mobile.

SMG to Desktop/Desktop to SMG

Dean Fleury: Capability to do SMG to desktop/individual.

Dean Sepstrup I agree that this is important.

Ken Beer: Would Sa gateway that re-encrypts for internal transmission work?

Ben: This introduces key discovery/PKI issues.

Jon Callas: Two issues. How do we find the certificate/how do we know that it is valid. There are solutions built into existing products that may meet this objective, but are not SMTP based.

Stephan Wappler: This needs to be based on standards. We need to work out how to do this with existing standards for interoperability.

 Dean Sepstrup: (Clarifying). We need to identify the problem and work out how to address it with the appropriate standards.

Two issues:

(1) Clients can probably already handle domain encrypted e-mail. (But would generate an error message because e-mail address on cert would not match originator).

(2) Clients cannot currently encrypt mail to send to domain gateway.

Agreed that this is a priority item.

Testing

Earlier in the session Jon Callas asked a question about the availability of a third party testing service (possibly based on a reference implementation). Mike Lambert had explain the original rationale to use per-to-peer testing for version1, but recognizing that the willingness to participate will diminish over time.

Agreed that we should investigate the practicality of The Open Group establishing a standing testing service. 

Issues

1. Selection of the reference implementation

2. Resources

Suggestion: Raise the price of certification to cover the costs.

Suggestion: Investigate partnership with sendmail.

Encryption algorithms

Should we revisit list of mandated encryption algorithms. Not yet.

SMG Capability Protocol

Michael Burdeos: It would be useful to have an SMG - SMG automated handshake to advertise capabilities. (Extensible). 

Five work items were identified which need to be addressed in version 2 of the program:

1. Automated Key exchange
2. Signatures
3. SMG to Desktop
4. SMG capabilities protocol
5. Testing service

In each case, the process to be followed is

1. Define the problem
2. Solicit proposals
3. Select the approach we would like to take

3.3 Outputs

1. List of work items for version 2 of the S/Mime Gateway Profile & certification program

3.4 Next Steps

1. Each of the potential work items will be investigated and short problem statements produced.
2. These problem statements will be reviewed at the next meeting (In new Orleans in October 2004

4. Canning Spam

4.1 Objective of Meeting

1. Better understand the industry view of the problem caused by Spam
2. Examine various techniques that are being used to manage Spam
3. Find out what other groups are doing
4. In depth examination of the Sender-ID proposal 
5. Plan future work on Spam within the Messaging Forum

4.2 Summary

4.2.1 The Open Group Spam Survey

Mike Lambert introduced the meeting and presented the results of The Open Group Spam Survey, carried out to establish a baseline for decisions on future work. The major findings were:

1. Spam is a major problem to most organizations
2. Most organizations believe that managing Spam is their responsibility, but want ISPs to do more
3. False positives are a concern to most organizations
4. There is little expectation that legislation will have a significant impact
5. Reliable authentication of the sender or sending organization of e-mail is the highest priority capability
6. The ability to segment e-mail by content type is also seen as important

4.2.2 Key Distribution in DNS

Dale Johnson, from Johnson Consulting, acted as moderator for the remainder of the meeting.

In a presentation that bridges between the earlier session on S/MIME Gateway Certification and managing Spam, John Thielens, of Tumbleweed, addressed the topic of Key Distribution in DNS, describing a proposal that is currently under consideration by the IETF MARID working group. This stimulated a lengthy discussion about the role of domain signatures later in the meeting.  The MARID group is currently focusing on SPF quickly;  key distribution will be addressed later.

Discussion Points:

Q: There is a validity time for DNS .. how does this impact expiry date for a domain key.

Q: Is there a single signature key for all purposes?

Q: Is DNS too much of a target for hacking.
A: DNS security is probably good enough. MARID thinks that is the case.

Q (Ben Littauer): Raw key material is easy. Automated distribution system required some form of PKI to distribute trust. The existing SMG process introduces security through the intervening manual step.
A: Domain keys/Identified mail is deliberately weak. Encryption is deliberately not precluded.
Suggestion: Consider extent to which manual intervention is required. Policy for which certificates to install automatically.

Q: Ben Littauer: Way to overcome restriction is for DNS to contain a certificate rather than simply key material.
A: It needs to be small enough (<512 bytes) so that it is not a performance bottleneck.
Suggestion: It could be the URL of the certificate.

Relevant IETF specifications can be found at: 

• RFC 1035 How to use the .TXT record
• RFC 2782 How to use the .SRV record

Q (Dale Johnson): How long before the spammer gets this information.
A: Even if the keys proposal is no good for addressing Spam, if it helps us with key distribution then it is good.

4.2.3 Existing Spam Protection Mechanisms

Dean Richardson from MessageGate described the range of techniques currently being used in products to assess whether an incoming message is likely to be Spam and announced an initiative to work on mechanisms for real-time abuse reporting between ISPs (to be done in collaboration with the IRTF).

Discussion points: 

Q: Should ISPs block port 25. i.e. Inhibit SMTP.
A: For many ISPs this is perfectly acceptable. For others, this may be troublesome (marketing problem).

Q: Should ISPs turn off machines that have a zombie?
A: This would be a significant marketing cost for ISPs.

4.2.4 Client SMTP Validation

In a presentation entitled The value of RBLs/Client SMTP Validation, Doug Otis from MAPS described the evolution of Real-Time Block Lists and introduced the Client SMTP Validation (CSV) and Bounce Address Tag Validation proposals which have been submitted to the IETF MARID working group. 

John Leslie from John Leslie Consulting, provided more technical detail about the benefits of Client Server Validation and how it would work.

4.2.5 Keynote: So Many Good Ideas, So Little Co-operation

Nathaniel Borenstein, from IBM/Lotus, opened the second day of the meeting with a provocative keynote entitled So Many Good Ideas. So Little Co-operation. Describing the broad range of measures under consideration, the key message was there is no simple solution to Spam; addressing Spam will require a long term commitment, a willingness to co-operate and agreement on standards. 

Discussion point:

Q: The presentation called for international harmonization of legislative approached to Spam. Is that practical?
A: At a recent ITU meeting, there was general agreement on this topic. Only Russia failed to participate.

4.2.6 Microsoft Position

Craig Spiezle, from Microsoft in a presentation entitled Canning Spam, the Good, the Bad and the Ugly outlined the work of the Safety Technology and Strategy Group in Microsoft in addressing Spam. He discussed the 3Ps of Spam control: Proof, Prevention  and Protection and briefly introduced the concept of Sender-ID. He identified some of the groups that Microsoft is working with, including the Anti-Spam Technology Alliance (ASTA).

4.2.7 The work of Other Groups

There then followed a number of short presentation describing the work of other groups in addressing Spam.

• Ken Beer, from Tumbleweed, spoke about the Anti-Phishing Working Group, and industry association focused on the elimination of identity theft and fraud arising from email spoofing.
  
• John Levine, from Taughannock Networks, and chair of the IRTF/ASWG described the IRTF's Anti-Spam Working Group. In the presentation he called for more experimentation to test the likely effectiveness of proposals such as CSV and Sender-ID and identified a potential joint activity with The Open Group to "help stamp out broken mail software". The active sub-groups of ASRG are addressing:

1. Abuse reporting
2. Filtering standards
3. Best current practices
4. Identity, Authentication, Reputation (IAR)

• Peter Soltez, from PAS-COM in a presentation entitled Managing Spam and Related Policies introduced a position paper on Spam produced by the IEEE_USA Committee on Communications and Information Policy. His conclusions were

1. The “cocktail” solution appears to be the most effective in fighting spam.
2. Start in the USA and then work w/Int’l groups and individual countries to aid in reducing spam
3. Set up legislation to allow monetary damages and disconnection of domestic & international spammers and their cohorts.
4. Define new standards for e-mail on the internet
5. Work on newer and better e-mail clients that enforce a “standard” for opt-out, keys, verification and other required formats.
   

4.2.8 Reputational Services

Des Cahill, from Habeas talked about The Role of eMail Reputational Services building on the experience of Habeas in introducing such a service. In closing he declared a willingness to talk to others about the right solution and summarized his presentation: 

1. Email reputation services are necessary
2. War on spam is a cold war
3. Authentication standards are not enough
4. The right ERS system has yet to be offered to the industry yet

4.2.9 Domain Signatures

At this point, Nathaniel Borenstein led a discussion on the use of digital signatures at the domain and provided information about a BOF he is planning at the upcoming IETF meeting in August 2004. The objective is the creation of a charter for a working group to develop extensions to SMTP/SMIME to:

1. Convey the existence of signature
2. Identity and provide the public key of the orginator
3. Define what in the message is signed
4. Define how to deliver signature with message

Definitely not in scope are

1. Address based authentication --> left to MARID
2. Rating and reputation services

The timescale is aggressive and the process needs to be automated.

Discussion Points:

Will this be based on S/MIME?

Nathaniel Borenstein: There is no presumption either way. S/MIME may be too heavyweight. S/MIME is likely to be the starting point, but it will be necessary to remove functionality until it looks like what we want.

Jon Thielens: If S/MIME is not used, we may end up re-inventing lots of the mechanisms.

Nathaniel Borenstein: There may need to be a signature algorithm that copes with changes introduced by the mail infrastructure (e.g. added white space).

Ben Littauer: Creating a parallel track is probably not the right way to go. Preference would be to fix S/MIME not develop a different version.

Jon Callas: The goals of domain keys and S/MIME are different. S/MIME was not designed to protect the headers, focuses on the body content. New proposals are designed to protect the headers. I would prefer to implement a new protocol, rather than having to modify an existing complex protocol. It is not digital signature for guarantee of content, it is like a tamper-proof seal.

George Webb: Can anything from S/MIME be leveraged?

Jon Callas: Not sure I understand the question. We certainly don't need ASN.1. The proposal specifically excludes a trust hierarchy.

Russ Chung: How do we prevent spoofing (of keys at DNS)?
Nathanial Borenstein: This will be as trustworthy as DNS. To go further, means a reputation service.

John Thielens: Is this a point of attack?
Nathaniel Borenstein: DNS is known to be fairly insecure. Hopefully this is being addressed by DNS-sec. DNS security needs to be addressed independently of the domain keys.

John Thielens: We will need to define what parts of the headers actually become part of the e-mail "transaction. 

Nathaniel Borenbstein: This must be linked to the category of things that the user is interested in. Better and more standard trace headers would help traceability of e-mail.

Jon Callas: Introduced concept of body count to define exactly what is signed.
Domainkeys introduces a signature that survives intervening hops and provides for sending domain to recipient validation.

Jon Callas: Remember there is no one thing that is going to solve the problem, so it doesn't matter if the approach is not perfect. 

Nathaniel Borenstein: We are not looking at a mechanism that would protect high value transactions. If we make a signature that costs 5c to break, it would deter spammers. 
Compute signature including SMTP recipient would address replay attacks.

Jon Callas: Sender-ID plus keys has more value than either proposal alone. They are complementary, not competition.  Sender-ID makes zombie networks less useful. It stops them forging well known domains.

Ben Littauer: There are at least three different groups architecting solutions.

One issue that did come out of the discussion was the plethora of overlapping activities and the need for an "Association of Associations" to provide some co-ordination and avoid the need for all companies to be members of all associations.

4.2.10 Sender-ID/SPF

The final part of the meeting was devoted to the subject of Sender-ID. Meng Weng Wong of Pobox.com with Craig Spielze and George Webb of Microsoft, jointly presented an analysis of the Sender-ID proposal, which represents the merging of 2 different approaches (SPF and Caller-ID). The slides from this session are not available. There are links below to additional information.

Sender ID is:

• A way for senders to protect their brand and domain names from spoofing and phishing
• A way for receivers to validate the origin of mail messages
• More input into spam filtering decision
• A foundation for the reliable use of domain names in accreditation and reputation systems and safelists
• The first major step industry can take together to stem the abuse of email

Sender ID is not:

• A silver bullet for eliminating spam (Spammers will register their own domains)

Sender-ID is a framework of three technical specifications

1. Sender Policy Framework (SPF)  .. a TXT record added to the DNS that defines which IP addresses are permitted to originate e-mail for a domain
2. Purported Responsible Address (PRA) .. which describes how a conforming Mail Transfer Agent (MTA) must respond when processing an e-mail message in the presence or absence of an SPF record. Drives the domain name from the message headers.
3. Submitter Optimisation (SO) .. which defines a mechanism to validate the sender information in the SMTP envelope to allow rejection of e-mail before transmission of the message.

These three specifications will all be submitted to the IETF MARID group for approval in August and are being deployed in products now.

Examples of useful SPF records

The immediate tasks are

• Get people to publish SPF records
• Ensure that all e-mail use cases are covered (e.g. transactional systems)

The presentation continued with illustrations of how different use cases should take advantage of Sender-ID, including

• Ordinary mail submission
• Mailing list servers
• Mail forwarders
• Mobile users
• Guest eMail services

Since this material is under development, the contents of the presentation are not available. The latest information may be found on the two WEB sites listed below.

• Meng Wong's SPF Information
• Microsoft Sender-ID Information

Any questions of clarification should go to Craig Spiezle craigspi@microsoft.com 

Microsoft holds a patent for at least parts of "Sender-ID". This does not cover the SPF-record.

A royalty-free license is available for inclusion of PRA checking in commercial MTA products.

Discussion Points:

There is currently a potential problem for organizations with a large number of mail servers (> 32).

Doug Otis: There is a risk of network melt-down, with frequent time-outs while searching DNS.
Meng Wong: It is possible to create wierd SPF record that would cost 1000 accesses (hackers?). sendmail.net currently doing experiments with SPF to examine performance implications.

Mike Lambert: Does the licensing model allow inclusion of PRA checking in open source products (e.g. sendmail).
This is not believed to be a problem.
Meng Wong: It is not necessary for all products to implement SPF checking in the same way. Some approaches may not require a license.

Margaret Olsen: SPF records were designed for SPF semantics. Now Sender-ID is different.
Meng Wong: This was experimental, it is probably not a real problem. We need to educate many people and in doing so we will hit most of the people who have already created SPF records.

4.2.11 SPF/Sender-ID Certification

Mike Lambert proposed a certification program to help with the deployment of Sender-ID. Possible areas for certification include

1. SPF records (potentially with a link to a Reputation Service)
2. MTA software
3. Services that use MTA software

Discussion Points:

Craig Spiezle: Companies must not have to go to several places for certification.

Additional idea: Certification of consultants able to support the creation of SPF records.

Added value of SPF record validation: Prevents an accidentally broken SPF record from impacting the behavior of the network.

4.3 Next Steps

All participants were invited to provide feedback to Craig Spiezle at Microsoft regarding the Sender-ID materials on the Microsoft WEB site.

Mike Lambert and Meng Wong will develop proposals for SPF/Sender-ID certification.

The Managers Guide to Coping with Spam to be revised to include references to Sender-ID.

5. Consolidated Action List

6. Future Meeting Schedule

7. Links

• US Federal Bridge Certification Authority
• US Federal PKI Policy Authority
• US Government E-Authentication Initiative
• Transatlantic Secure Collaboration Program (TSCP)  How-to Guide
• S/Mime Gateway Certification
• Certified products list
• Anti Spam Technology Alliance
• Microsoft and Spam
• IETF MARID Working Group
• Anti-Phishing Working Group
• IRTF Anti-Spam Working Group
• IEEE Position Paper on Spam

Additional information about Sender-ID

• Meng Wong's SPF Information
• Microsoft Sender-ID Information