On Tue, 2005-02-01 at 10:43 -0800, Jim Fenton wrote:
Since I haven't seen it mentioned on this list yet, I thought I'd point
out "Security Review of Two MASS Proposals",
http://www.ietf.org/internet-drafts/draft-housley-mass-sec-review-00.txt
This looks like an excellent review. I would like to respond to a few
points and examine some areas where cooperation could be benefitical.
- 4.2 Denial of Service attacks
No signature scheme is able to protect resources. A MASS solution must
work in conjunction with a lightweight means to rapidly authenticate the
source of the message to check for negative reputations. Currently,
this is done using the remote IP address. One advantage MASS affords is
name as a basis for reputation. This name basis for reputation is also
made possible by CSV, thus sustaining these benefits, and yet CSV offers
the needed protection at the network level.
- 5.2. DomainKeys Signature
With the exception of the signature itself, having the settings within
the signature header included within the content being signed, would
allow a means to securely modify related mechanisms.
The use of fingerprints rather than public-keys seems to represent a
more conservative approach with respect to flexibility and impact upon
the network.
- 2.3. Public Key Infrastructure
- 4.1. Replay Attacks
- 6. Open Email Issues
- 7. Deployment Concerns
Although adding revocation is seen as a breaking point in terms of
complexity, for larger domains, replay attacks will be an issue. There
is a substantial difference between the typical duration for
certificates versus the period expected for this mechanism. The
duration only needs to cover the time required to ensure delivery of the
signed message, which means revocation information will be much smaller
in comparison, as well as easier to manage.
For large domains with a high turnover of customers, providing a means
to rapidly respond to replay attacks represents a potential for sizeable
reductions in associated overall expenditures responding to such abuse.
This saving can be obtained without universal deployment. Such a
mechanism would also allow large domains a means to guard their
signature-authenticated reputation.
Adding a simple identifier, perhaps obtained internally from an access
server, to the signature header could allow for a query option against
the domain to determine whether there was a specific revocation of
authorization. Per-user keys would not be as responsive and a large
domain may need to publish millions of such per-user keys which could
tax recipient infrastructures.
Without a record found, there was no revocation, and based upon the DK
style, the query could be for an A record at the location:
<internal_identifier>._rl.example.com
It is likely most domains would not need such a mechanism, and by
selectively including an identifier, this would allow such queries on a
optional basis. This type of mechanism could be introduced at any time
and, even when used, the records could be maintained manually in most
cases.
While the IIM KRS allows a means to scale to levels associated with the
use of per-user keys for larger domains, a simple revocation mechanism
should be easier to implement when based on existing blackhole listing
practices. (Plenty of existing code.)
- additional note
In an upcoming draft for CSV, domain wide policy has been considered.
Either the same approach could be followed, or an accommodation could be
made within the record. It is likely the HELO and signature share a
common domain, where this could eliminate some overhead.
-Doug