Message-ID: <4FC1FB70.7020004@tana.it>
Date: Sun, 27 May 2012 12:01:20 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ned+ietf-smtp@mrochek.com
CC: ietf-smtp@imc.org
Subject: Re: draft-fanf-dane-smtp
References: <alpine.LSU.2.00.1205251812480.572@hermes-2.csi.cam.ac.uk>
 <4FC09B0A.5010602@tana.it> <01OFXI7YA7GS0006TF@mauve.mrochek.com>
 <4FC12663.1090105@tana.it> <01OFXYSCWQ6I0006TF@mauve.mrochek.com>
In-Reply-To: <01OFXYSCWQ6I0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk

On Sat 26/May/2012 21:49:20 +0200 ned+ietf-smtp wrote:
> 
>> I just trust your word on this.
> 
> You probably shouldn't. My understanding of DNSSEC is pretty superficial.

Mine is much less than that :-/  IMHO, with all due respect for
DNSSEC, there's much more to dig with spades before mail admins can
efficaciously fence with foils.

>>> RFC 5451 is about communicating *authentication* results. This use of DANE is
>>> about making mail transport more robust. These are very different things and
>>> mixing them is inappropriate.
> 
>> The only difference I see[*] is that the client authenticates the
>> server rather than the opposite way around.  Indeed, several
>> considerations in RFC 5451, in articular Section 7.1, assume that the
>> authentication server is on the server side of the SMTP transmission.
>> This shouldn't strike down the field format, though.
> 
> This is about securing the transmission path. Authentication is only incidental
> to that. And in any case, the only identity that's "authenticated" here is that
> of the receiving server, and that's supposed to end up in the Received: field
> the server adds anyway. 
> 
> I'm afraid I really don't see the point.

For one thing, the fact that the client took the trouble to deal with
authenticating the MX should probably increase the worthiness of the
message.  However, DNSSEC and TLSA lookups, as well as RFC 6125
validation are carried out by the client alone.  The server has no way
to know it.  In particular, it won't be able to highlight the client's
quality in the Received: field.

Unless I'm missing something, the only places where that info is going
to be relevant is if the server rejects the message, if positive DSN
was requested but the server doesn't support it, and if the sending
fails because some of the specified checks failed.  In those cases,
the client can prepare a bounce where the authentication results are
reported in detail.  For rejection, for example, the author might
consume such info and be able to attribute some value to the reason
why the message was rejected, based on the knowledge that it was
indeed done by a server entitled to do so.

Normally, the work done for securing the transmission path is not
noticeable.  Some more visibility, in return for the trouble, would
seem to be in order.