Subject: [apps-discuss] FW: New Version Notification for draft-kucherawy-authres-vbr-00

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:25:40 -0800

I've introduced a draft to register the relaying of VBR results via Authentication-Results header fields.  I imagine this will be something the new APPS area working group can pick up, but it also seems appropriate to let the DKIM WG know about it.

Comments welcome, even if it's just "I read this, looks good to me" so that some support or consensus can be recorded.

-MSK

Subject: New Version Notification for draft-kucherawy-authres-vbr-00
From: IETF I-D Submission Tool <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:20:11 -0800

A new version of I-D, draft-kucherawy-authres-vbr-00.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository.

Filename:	 draft-kucherawy-authres-vbr
Revision:	 00
Title:		 Authentication-Results Registration For Vouch By Reference Results
Creation_date:	 2010-11-07
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
This memo updates the registry of properties in Authentication-
Results: message header fields to allow relaying of the results of a
Vouch By Reference query.

The IETF Secretariat.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 10:38:38 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, November 08, 2010 4:04 AM
> To: [email-masked]
> 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.

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

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?

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

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Nov 2010 20:45:25 +0100

> I'd be fine with changing it to "md=".  It's more consistent with the other registrations, now that you mention it.

And shorter :-)

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 11:49:56 -0800

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Monday, November 08, 2010 11:45 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; John L
> Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
> 

That's a good point.  One possible approach in that case: Act like there was an implicit VBR-Info field and apply the same reporting mechanism as if it were indeed there.

But otherwise, as with DKIM, I think it's sufficient to define pass/fail in terms of the algorithm RFC5518 defined, and leave it at that.  Enumerating all the ways one could get a "fail" result just makes this document needlessly big.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 13:18:12 -0800

> From: John R. Levine [mailto:[email-masked]]
> Sent: Monday, November 08, 2010 1:14 PM
> To: Murray S. Kucherawy
> Cc: Alessandro Vesely; [email-masked]
> Subject: RE: [apps-discuss] draft-kucherawy-authres-vbr-00
> 
> >> In that case no "mc" is given.  Can positive results still be reported?
> 
> Sure, in the common case that the VBR record contains "all".

That's specific to VBR implementation and not this registration, so I don't think I need to cover it here.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 8 Nov 2010 15:55:46 -0800

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

That's a UI question, so I think the answer is "sometimes."  *grin*

That said, there are already MUAs which do show messages like "this domain was certified by X," so I think it'd make sense to support that here.

---

From: "John R. Levine" <[email-masked]>
Date: 8 Nov 2010 16:13:52 -0500

>> http://www.spamhauswhitelist.com/en/techfaq.php)

Humph.  See http://www.spamhauswhitelist.com/en/usage.html
I'll put it in the FAQ, too.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Nov 2010 15:21:01 -0800

[moving this from ietf-dkim to apps-discuss]

> From: John Levine [mailto:[email-masked]]
> Sent: Friday, November 12, 2010 3:12 PM
> Cc: Murray S. Kucherawy
> >Comments welcome, even if it's just "I read this, looks good to me"
> >so that some support or consensus can be recorded.
> 
> I read it, it almost looks good to me.  A VBR-Info header can list
> multiple certifiers, so unless there's something I missed, the vbr
> clause in the A-R header should include the name of the certifier.
> I imagine that in a scoring system different certifiers would be
> weighted differently, e.g., a list of spamless signers vs. a list
> of signers that send a mix but it's not all spam.

The vision I have for A-R is that it provides results only and an expression of what was evaluated, but stops short of giving it more than that.  So in the case of VBR it would say "someone the border trusts vouched for domain example.com", meaning the "md=" is important but the "mv=" is not.

That said, I've got a new version already pending, thanks to previous feedback, that changes the tag set added from "header.vbr-info" to "header.md" and "header.mv".

Does that work for you?

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 12 Nov 2010 21:45:09 -0500

> That said, I've got a new version already pending, thanks to previous feedback, that changes the tag set added from "header.vbr-info" to "header.md" and "header.mv".

Looks good to me, those are the two interesting items.

Regards,