Re: [apps-discuss] draft-kucherawy-authres-vbr-00

[Alessandro Vesely <[e-mail]>]

On 08/Nov/10 19:38, Murray S. Kucherawy wrote:
>>  -----Original Message-----
>>  From: [e-mail] [mailto:[e-mail]] On Behalf Of Alessandro Vesely
>>  Sent: Monday, November 08, 2010 4:04 AM
>>  To: [e-mail]
>>  Subject: Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00
>>
>>  Nice one, Murray!
>>
>>  Section 4 (Definition) is ambiguous, though.  It says "the DNS domain
>>  name used to perform the VBR query", but a VBR query takes two domain
>>  names.  I think mentioning the tag (md, according to the example)
>>  would make it clearer.
>
> I'd be fine with changing it to "md=".  It's more consistent with the other registrations, now that you mention it.

And shorter :-)

>>  However, why not structure all the available domains?  E.g. delivering
>>  something like (modified from section A.1)
>>
>>    Authentication-Results: mail-router.example.net;
>>          dkim=pass (good signature) header.d=newyork.example.com
>>                header.b=oINEO8hg;
>>          vbr=pass (all) header.mv=voucher.example.net
>>                header.md=newyork.example.com
>>
>>  where the comment contains the actual content of the TXT record.  A
>>  machine readable voucher name could be used by clients to learn what
>>  vouchers a server trusts.
>
> I'm not sure about this part.  One of the main purposes of A-R is
> to obviate the need for MUAs to do any authentication work.  That
> all gets done at the border, and agents within the border simply
> consume the results thus reported inbound.

Yes.

> What would an internal agent do with the name of the voucher?
> Something like "this domain was certified by X"?  Would that be
> useful, or potentially confusing?

I cannot tell about what kind of presentation is worth.  The datum 
itself is interesting, because end users have no other way to infer 
it.  It characterizes a server.  I imagine a careful client may 
collect and display them as some kind of MTA's properties.

>>  Another item that may need clarification is the "positive response"
>>  given in the definitions of "pass" and "fail".  It could be expanded
>>  as, say,
>>
>>    pass:  A VBR query was completed and the vouching service queried
>>       gave a positive response.  That is to say, it returned a record
>>       consisting of strings of lowercase letters separated by spaces,
>>       as per section 5 of [VBR].
>>
>>  The added sentence is meant to dispel any question on whether the
>>  verifier should attempt to match the text in the RR with the content
>>  of the mc= tag in the VBR-Info header field, if any.
>
> I think that's redundant to the algorithm VBR's RFC defines.  The
> "mc" in the message has to match the type assertion made by the
> voucher.  So I'd actually propose the opposite, that "fail" be
> expanded to include the case where voucher did make a positive
> assertion but the message types don't match.  For that matter,
> "fail" might also cover the case where the message contained
> multiple VBR-Info header fields with different "mc" values, also in
> violation of the VBR RFC.

Isn't that overly complicated, since the "type" of a message is a 
somewhat subjective datum?  In addition, a verifier may query a 
voucher even without having been prompted by a VBR-Info field.  (For 
example, the string "VBR-Info" does not appear in 
http://www.spamhauswhitelist.com/en/techfaq.php)  In that case no "mc" 
is given.  Can positive results still be reported?

RFC 5518 section 3 does not mention matching.

Section 4 indeed says "All of the VBR-Info header fields in a single 
message MUST have identical mc= values."  (In-transit forgeries?)

Section 5 has that "Verifiers MUST then check that the TXT record 
consists of strings of lowercase letters separated by spaces".

Section 6 says "The purpose of this element is for auditing." But the 
VBR-Info field is as accessible as A-R itself, so I don't think it is 
worth repeating it.

I'm confused.  I CC to John in the hope he will shed some light on this.