Subject: [dns-dir] FW: Question about draft-hoffman-dac-vbr

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 18 Jan 2009 12:58:19 +0100

Anybody in DNS-DIR looking at this I-D? 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Friday, January 16, 2009 3:36 PM
To: IESG IESG
Subject: Question about draft-hoffman-dac-vbr

Is there a DNS and Sec Review of draft-hoffman-dac-vbr draft somewhere?

_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Jan 2009 09:29:50 -0500

>  Anybody in DNS-DIR looking at this I-D? 

I haven't done.  When do you need it?  I can try to schedule some time
for it this week.  I haven't been doing my share, so it's my turn, I think.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 21 Jan 2009 15:17:53 +0100

>  Anybody in DNS-DIR looking at this I-D? 

I got a ping from Ólafur to look att it, and I did so yesterday. I
sent a bunch of comments off to the side for sanity check, but I
haven't heard back, so here are my comments unchecked by any
functional brain:

I took myself through this document, and I must say that without
fundamental knowledge in modern mailology, more specifically sender
authentication, it seems like "dancing around the issue but never
getting there". There is lots of talk of "certify the owner" and
"valitdation of the identity" and stuff, but little explanation of the
overall process going from A to B. I would like to see something that
starts with "mail going out here" and ends with "and by validating
that signature, the authenticity can be established. QED.".

I saw two cases of "X MUST/SHOULD be Y; and if X _isn't_ Y, the result
is undefined.". To me, that is a recipe for misunderstanding,
incompatible implementations, and quarrel about interpretation of the
spec.

I also cannot wrap my brain around the concept that some third party
could "vouch" for e-mail coming out of someones laptop - if it's of a
certain type - and what if it isn't? It me took all through to the
"Changes" section before I fully realized that sender domain
authentication is a strict prerequisite for this, and I still don't
fully comprehend the value it would add (although I saw in the IETF
tools document tracker that Chris Newman really likes it, so it can't
be all bad ... ;-), but never mind, that's not the task at hand. ;-)

Looking at the DNS parts of this, a few things caught my eye, and I
would at least like to make sure they are lifted up for closer
inspection.

1) TXT record. Again! Needs to be fixed, unless they can provide a
   _REALLY_ good explanation why TXT creates a better overall
   architecture compared to defining a new record type. (Speed of
   deployment has very little to do with good architecture in my
   world, and usually means the opposite.)

2) It seems to make use of DNS "because it's there", rather than
   because it's the optimal database mechanism for this, but that
   said, it does fit ... for some not too negative value of "fit".

3) It combines 3 semantically different entities in the lookup domain
   name. You seem to have

   a) The sender domain,
   b) The separator "_vouch", and
   c) The service locator.

   While that strikes me as kind of "not how DNS was originally
   intended to be used", at least the service locator is "to the
   right" (closer to the root), which means that the client can
   actually make good use of DNS caching, and they avoid hitting the
   higher DNS echelons (root, TLD, ...) with subsequent queries. The
   servers that will be hammered, will be the servers of the "vouching
   service", which is as it should be. Basically, it's not worse than
   any DNS based RBL list alreay in use.

4) The DNS language is pretty sloppy, and needs to go through "boot
   camp with a DNS sergeant". ;-) I note that there is no information
   about how one goes from "the service locator" to the actual IP
   address of the vouching service DNS server. It's "a list of domain
   names of certification providers that the sender asserts will vouch
   for this particular message." (sect 4.) Aha? And how do I use these
   "domain names"? Is the service locator to be interpreted as a
   lookup key for an A record? An AAAA record?  An SRV record? (If the
   latter, what are the other parameters?) Or, do I pass it through a
   NAPTR to obtain ... what? I would like to see that process
   described in a more formal way.

5) I notice that the document doesn't mention DNSSEC at all, which may
   be intentional. It could be that they don't want to force people
   into using DNSSEC (I can fully respect that), of that this is
   intended to be an alternative to using DNSSEC, but this really
   seems like an application where DNSSEC could actually be of some
   use, and I would at least like to see a discussion section on that.

6) In sec 5, par 9, the authors assert that the choice of the
   separator label "_vouch" leads to "There will never be any
   accidental overlap with a valid domain name."  That is not only
   incorrect from a DNS perspective, it is bad terminology, and also a
   questionable statement, even if you take the language aside. "will
   never" are strong words, and however unlikely, it is _possible_
   that the underscore will be made koscher in host names (which is
   what they mean) in a distant future.

7) At the end of section 5. we have one of the two "unspeifieds"
   mentioned above: "If more than one TXT record exists at a name from
   a VBR record, the reults are unspecified."  Why is that? Why not
   specify "considered it to be an error - ignore it!" or "concatenate
   them and treat them as one record", or at least something well
   defined?

On the non-DNS side, there are also questions in section 7: "Senders
SHOULD use DKIM (and MAY use DomainKeys, SPF, or SenderID)...". That
little "and" in the parenthesis - is that "DKIM _and_ any of the
following" or is it really "DKIM _or_ any of the following"? (It may
be obvious to a native English speaker, but it's not to me. ;-)

... and in 7.1, where it's required that the VBR header lines be put
"immediately below the corresponding DKIM-Signature header
field". What if you have competing such requirements from other mail
sub-protocols?

To be frank, since this is a Standards Track document, my view is that
it needs some "shaping up". I don't necessarily disapprove of the
basic idea, but I want more information to be able to judge better,
and I want better DNS language.

... and a different record type than TXT. :-)

My assessment is that this exact document isn't ready for publication,
but may become so in a future revision, given more and wider review.

All text above is subject to the caveat that I may have missed som
vital point, due to limited understanding of the e-mail related side
of the document. ;-)

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# There are 10 kinds of people in the world. Those who understand
# binary numbers, and those who don't.
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.   ! E-mail/SIP/Jabber: [email-masked]
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Autonomica AB, Stockholm  ! http://www.autonomica.se/
#----------------------------------------------------------------------
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 22 Jan 2009 13:16:01 +0100

Lesson learned: people forward your messages outside the intended
audience without asking you. I'll be more careful with my formulations
in the future.

More importantly (and in this case I don't know what to blame: stress,
fatigue, the headache I had at the time, or that someone might have
added som unsuitable substance to my evening tea?): in my piece about
the above draft I wrote:

[email-masked]:
>    camp with a DNS sergeant". ;-) I note that there is no
>    information about how one goes from "the service locator" to the
>    actual IP address of the vouching service DNS server. It's "a
>    list of domain names of certification providers that the sender
>    asserts will vouch for this particular message." (sect 4.) Aha?
>    And how do I use these "domain names"? Is the service locator to
>    be interpreted as a lookup key for an A record? An AAAA record?
>    An SRV record? (If the latter, what are the other parameters?)
>    Or, do I pass it through a NAPTR to obtain ... what? I would like
>    to see that process described in a more formal way.

03.00 AM this morning ("sleepless in Stockholm?") it suddenly struck
me: This comment from me is just plain wrong and totally out of place!
The domain name in question is part of the normal lookup string, and
is treated like any other domain name, for which finding the name
servers is a well defined process. I don't know how I managed to even
_find_ such a totally wrong end of the stick, but obviously I did and
got a sturdy hold of it.

Would you all please disregard the comment above. The text in the
draft is actually quite OK, for any normal brain which is not as
derailed as mine.

Paul, my deepest and most sincere apologies for the text above. It is
just plain wrong, and just proves your point that I should have
contacted you in the process. You would have put me on a better track.

With the above insight, my most important remaining technical
objection is the use of the TXT record, and there Paul and I have
reached the point where we agree do disagree.

				Cheers,
				  /Liman

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 22 Jan 2009 13:25:46 +0100

... and someone should have told me that the document already _had_
been looked at by dns-dir people.

I need to take it slower and be more careful when I do this type of
work. Remind me if I forget that in the future.

Too much stress, too much fatigue ... :-(

				  /Liman

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2009 14:35:45 +0100

Do not take it too tough. People make sometimes errors in good faith and
if caught in time no harm happened and we just learn something new. 

Expect such comments to be forwarded - in most of the cases filtered by
one or other of the Area Directors. In this case I had forwarded your
comments almost as is, because the document is on the agenda of the IESG
telechat one week from today and I wanted the author to have the time to
assess your comments and respond back. 

Regards,

Dan

> From: Lars-Johan Liman [mailto:[email-masked]] 
> Sent: Thursday, January 22, 2009 2:16 PM
> To: Romascanu, Dan (Dan)
> Cc: Cullen Jennings; [email-masked] IETF 
> DNS Directorate
> Subject: Re: [dns-dir] Question about draft-hoffman-dac-vbr
> 
> Hmmm.
> 
> Lesson learned: people forward your messages outside the 
> intended audience without asking you. I'll be more careful 
> with my formulations in the future.
> 
> More importantly (and in this case I don't know what to 
> blame: stress, fatigue, the headache I had at the time, or 
> that someone might have added som unsuitable substance to my 
> evening tea?): in my piece about the above draft I wrote:
> 
> [email-masked]:
> The domain name in question is part of the normal lookup 
> string, and is treated like any other domain name, for which 
> finding the name servers is a well defined process. I don't 
> know how I managed to even _find_ such a totally wrong end of 
> the stick, but obviously I did and got a sturdy hold of it.
> 
> Would you all please disregard the comment above. The text in 
> the draft is actually quite OK, for any normal brain which is 
> not as derailed as mine.
> 
> Paul, my deepest and most sincere apologies for the text 
> above. It is just plain wrong, and just proves your point 
> that I should have contacted you in the process. You would 
> have put me on a better track.
> 
> objection is the use of the TXT record, and there Paul and I 
> have reached the point where we agree do disagree.
> 
> 				Cheers,
> 				  /Liman
>

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 22 Jan 2009 19:08:08 +0100

[email-masked]:
>  Hi Liman, 

> if caught in time no harm happened and we just learn something new.

It is also a depressing lesson on how my perception is affected by
factors like lack of sleep and stress.

Maybe the impact wasn't disastrous from a process standpoint, but I've
created a lot of extra work - especially for Paul and friends, but
also for others (you included) - and also a lot of emotional distress.
It's nothing to be proud of. It amazingly hard to adhere to the old
rule that the old "postmaster" at the Royal Institute of Technology
tried to teach me: Never write e-mail when you're in a state of
affect ... (or whatever the appropriate translation is).

> assess your comments and respond back.

Yes, I understand that, and I believe the time pressure was one of the
key factors. I should have realized that ... :-(

Well, well ...

				Regards,
				  /Liman