The IAB chair confirmed to me that this document is in last call,
comments are solicited.
The existing list of comments makes it clear that publication is not
imminent and might not occur at all.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hallam-Baker,
Phillip
Sent: Wednesday, March 05, 2008 3:27 PM
To: Jim Fenton; John Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] draft-iab-dns-choices-05 and tree climbing
(fwd)
One of the authors of the draft has assured me that this is not an
attempt to override working group consensus through the back door.
While the announcement indicated that publication is imminent, it is far
from clear that this is the case. The announcement also indicates that
comments are invited till March 28th. Objections have been lodged.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Monday, March 03, 2008 12:23 AM
To: John Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] draft-iab-dns-choices-05 and tree climbing
(fwd)
John Levine wrote:
This note seems relevant to DKIM. This draft says, predictably, that
the way you add new data types to the DNS is with a new RR type, and
all other approaches are ill-advised.
It also says that DNS tree climbing is always bad. We might want to
reconsider whether the small amount of tree climbing specified in -03
is worth the hassle it will doubtless cause on the route from final
draft to RFC.
The relevant section (4) of this document points out that by querying
the parent domain, it "may lead to incorrect results and may also put
security at risk," because the parent domain maybe under different
administrative control. What we need to consider is whether the risk of
undesired inheritance of an ASP from a parent domain is greater or less
than the risk presented by other labels (hostnames, etc.) being used in
From addresses without regard for the ASP of the domain they're in.
Since the default ASP is "unknown", the risk presented by a
separately-managed parent domain is that they will publish an ASP that
is stronger than that desired by the child. This can be countered
either by the parent publishing its record with the t=s flag that
prevents its application to subdomains, or by the child domain
publishing an explicit ASP of its own.
Without the parent query, any label in the domain is potentially able to
be used to circumvent the ASP record. Labels in the domain not having
an explicit ASP record would be interpreted as "unknown", which might be
looser than the ASP for the domain.
I have spent considerable time with the DNS folks, including two of the
editors of this draft, socializing what we are doing here. I believe
that security is better served by doing the parent query. I would hate
to compromise the effectiveness of ASP just to make it more expedient to
get it to RFC.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html