On Fri, Apr 17, 2015 at 01:58:34PM +0100, Stephen Farrell wrote:
> > Note that for this protocol, both the address records and the TLSA
> > records of the MX host are DNSSEC-validated, since when the address
> > records are not, we don't even ask for the TLSA RRs. So I am not
> > sure what you have in mind...
>
> Yep - this could be me being confused. If there's no way in which
> the MX and TLSA can be properly signed but where the A is not, then
> I agree my comment is moot and no change is needed.
Well, though I don't know why we'd care protecting about the address
records also (given routing layer attacks), ... There is (full
disclosure) a corner case where the address records are not secure,
but the TLSA records are.
The case in question is a CNAME alias chain whose starting point
(the "owner" name of the initial CNAME) is in a signed zone, but
whose end-point is not secure:
; CNAME from signed zone into unsigned zone
; with TLSA records at start of CNAME chain.
;
example.com. CNAME example.net.
example.com. RRSIG CNAME ...
_25._tcp.example.com. TLSA 3 1 1 ...
_25._tcp.example.com. RRSIG TLSA ...
; Address records are in an unsigned zone
;
example.net. IN A 192.0.2.1
In this case, mail to example.com is sent to the "insecure" IP
address of example.net, with "secure" TLSA RRs coming from example.com.
This case is rather rare, because most domains have MX records
(rather than just receiving email at their A/AAAA records), and MX
hostnames are supposed to not be aliases (and rarely are). Rare
violators of the MX hostname is not a CNAME are however tolerated
by most MTAs, and so Postfix will occasionally deliver mail to an
authenticated peer via unauthenticated A records.
Of course the administrator of the receiving domain willingly
aliased their signed zone's hosts into an unsigned namespace.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
