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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 29 Jan 2009 20:19:52 +0100

Liman, DNS-DIR,

I am holding a DISCUSS on the issues related to draft-hoffman-dac-vbr.
Can you please asses whether your review comments were addressed, and
what critical items - if any - were left out in Paul's response? 

Thanks and Regards,

Dan

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, January 29, 2009 9:05 PM
To: Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: DISCUSS: draft-hoffman-dac-vbr

At 7:50 PM +0100 1/29/09, Romascanu, Dan (Dan) wrote:
>There has been quite a lot of traffic on this. Can you send again the 
>response that you consider being the 'official' answer (may be more 
>than
>one) so that we make sure the DNS-DIR has seen it?
>

To: Russ Housley <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: FW: [dns-dir] Question about draft-hoffman-dac-vbr
Cc: John Levine <[email-masked]>, Arvel Hathcock
<[email-masked]>
Bcc:
X-Attachments:

>Please generate a response to this review.

Done. This is approved by both my co-authors as well. You may pass it to
the IESG. I also spoke with Liman and we have agreed to disagree on the
TXT record issue. He did not know why the DNS-DIR review was not
requested earlier, nor why Peter Koch did not bring it to the DNS-DIR
when we spoke with him probably a year ago about the document.

=====================================================================

>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.".

The document purposely doesn't do that because different mail systems
will do the certification at different times. For example, some mail
systems would do this between the time a message is received and when it
is put in the user's mail store; others would do it when reading the
file from the mail store but before displaying it to the user. The
timing truly doesn't matter to the protocol: what matters is that it is
done using the steps given in the document.

We carefully designed VBR so it can be used in conjunction with any of
the widely used domain authentication schemes, so it can be applied at
or after the time the authentication scheme is evaluated.  Note that VBR
does not provide authentication; that is the job of the underlying
authentication scheme.  It provides certification, which is a different
thing.

>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.

These are both good catches.

The first says this:

   All
   of the VBR-Info header fields in a single message MUST have identical
   mc= values.  The semantics of a message with non-identical mc=
   categories are undefined.

We agree that this could lead to incompatible implementations. The last
sentence can be dropped.

The second says this:

   If more than one TXT record exists at a name from a VBR record, the
   results are unspecified.

We agree that this could lead to incompatible implementations. The
sentence can be changed to:

   The VBR record MUST have only one TXT record.

>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. ;-)

Vouching services will have different business models for how they
assure people that their vouching is worthwhile. That is definitely out
of scope for this document. Some models are like the ones we see today
with Return Path and Constant Contact; others will spring up, such as
trade groups vouching for their members. Another example might be that
the bank regulator in a country (such as the FDIC in the US) might
choose to vouch for the banks that it oversees. We do not expect that
every email user will want to use one or more vouching services, just
that, if they do, there should be a single interoperable protocol.

>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.)

We have been through this many times. The use case here is exactly the
same as for DKIM. The underscore used on the _vouch label prevents there
from being any possibility of collision with TXT records for actual
domain names. The paragraph near the end of section 5 ("Verifiers MUST
then check...") deals with the issue of wildcards and TXT records.

>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".

We don't understand this objection at all. As stated throughout the
document, VBR is for vouching for mail from a *domain name*. The lookups
are based on a domain name, and the responses are small single replies.
DNS seems like a perfect fit for that.

>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.

We designed VBR the way we did because we knew that similar designs had
acceptable DNS characteristics.  There is no "service locator": there's
just the domain name of the vouching service.

>4) The DNS language is pretty sloppy, and needs to go through "boot
>   camp with a DNS sergeant". ;-)

We asked for such input during the development of the document, and we
heard no comments from the sergeants who said they would review it other
than a disagreement about TXT records.

>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.

The document says that the string queried is a domain name, and that the
domain name is queried for a TXT record. If it would help, we can add
"The recipient looks up the domain name in the DNS in the exact same
manner it looks up all other domain names." The protocol is agnostic to
whether A or AAAA records are returned.

>From his comment, we think that Liman maybe supposed that there had to
be some way to auto-discover vouching services. There is deliberately no
intention that vouching services can be found automatically. VBR is
about reputation, and the mail system's management has to decide for
itself what vouching service(s) it wants to use. One uses a vouching
service that one trusts, not just "one that is there".

>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.

The protocol is agnostic to DNSSEC. There is no more reason to force a
user to use DNSSEC for this protocol than for any other protocol. DNSSEC
would indeed be of some use, just as it would be for any other protocol.

>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.

We can change "valid domain name" to "currently-valid domain name" or
"host names". _vouch is indeed a valid domain name, which is why we use
it in the DNS.

>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?

Agree; see above.

>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. ;-)

We truly meant "and".

>... 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?

It is not required, it is recommended. The exact words are:

   o  The VBR-Info header field SHOULD be added in the header
      immediately below the corresponding DKIM-Signature header field.

>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.

We hope the changes and explanations above cover all the issues.

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

We see no difference between the use in VBR and other standards-track
documents. We looked at the objections to re-use of TXT carefully and
found that none of them apply to VBR, given the way we purposely
designed the protocol.

>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.

This document was informally reviewed by a WG (DKIM), by a group of
vendors with a great deal of technical knowledge (the Domain Assurance
Council), and went through a four-week IETF Last Call that generated
review. We are not sure what more we could have asked.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Jan 2009 14:40:20 -0500

Hi,

>    The VBR record MUST have only one TXT record.

The above gets exactly to the reasons why some of us are uneasy with
TXT records: I have no idea how to enforce the above rule in any zone,
and there's nothing about TXT records that can ensure there'll be only
one such TXT record.  So what happens if there is more than one TXT
record?  The results are still unspecified; the document just doesn't
say so any more.  That said,
 
> then check...") deals with the issue of wildcards and TXT records.

we've already given in on the brain-dead approach of using TXT records
for DKIM.  So I guess we're stuck with it here.

A

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 Jan 2009 20:46:22 +0100

> for DKIM.  So I guess we're stuck with it here.

I am not happy either, as people know, with the prefix-related TXT  
records. One day you have a TXT record that by definition MUST have  
the same owner as another RR. And if that RR is also of type TXT, then  
you have a problem. Two TXT with same owner.

    Patrik

P.S. I see movement on the IAB draft on TXT records...