Re: [dane] Delivery of email if MX is not signed

[[e-mail]]

Zitat von Patrik Fältström <[e-mail]>:

> On 23 Aug 2015, at 20:18, Paul Wouters wrote:
>
>>> Unsigned RRSET contain:
>>>
>>> example.net. IN MX 0 mail.example.com.
>>>
>>> Signed (and properly validated) RRSETs that contains these two  
>>> records and a few more:
>>>
>>> mail.example.com. IN A 192.168.1.1
>>> _426._tcp.mail.example.om. IN TLSA ....
>>
>> so anyone can spoof:
>>
>> example.net. IN MX 0 mail.example.com.
>
> Yes, just like today.
>
>> pretending "mail.example.com." does not give you more security. What
>> would you do if you saw:
>>
>> example.net. IN MX 0 evil.nohats.ca
>>
>> with proper TLSA records for evil.nohats.ca?
>
> This is what we have today.
>
> I would deliver over the TLS secured connection.
>
> The only way to secure that is to DNSSEC sign mail.example.net.
>
>>> I.e. if only looking at mail.example.com. and  
>>> _426._tcp.mail.example.com. that is a 100% properly setup DANE  
>>> "thing".
>>
>> But nothing in that statement securely tells you anything about example.net.
>
> Correct.
>
>>> I think that behaviour is wrong, and am unsure whether it is a bug  
>>> in postfix or whether it is a bug in the spec.
>>
>> That would be a bug in postfix? The spec states:
>>
>> All
>> "insecure" RRSets MUST be handled identically: in either case
>> unvalidated data for the query domain is all that is and can be
>> available, and authentication using the data is impossible.
>>
>> It does not state to not deliver email, it just states there is no
>> authentication possible, so deliver without dane authentication.
>
> Ok, I think what I have issues with is that I think "dane  
> authentication" is not black or white.
>
> We have at least:
>
> 1. Signed and validated MX, signed and validated TLSA
>
> 2. Unsigned MX, signed and validated TLSA
>
> 3. Unsigned MX, no TLSA, unsigned A/AAAA
>
> Then we have all of the failed situations, which include:
>
> 4. Signed, but broken signatures, on MX, signed and validated TLSA
>
> 5. Signed, but broken signatures, on MX, signed but broken signatures on TLSA
>
> 6. Unsigned MX, signed but broken signatures on TLSA
>
> Etc
>
> So if you look at 1, 2 and 3, if I understand you correctly, [2] is  
> not "DANE authenticated" even if the TLS connection has properly  
> signed and validated TLSA record?
>
> This is a bit confusing to me. I.e. the terminology is confusing. To  
> me, [2] has proper DANE validated TLS available for the SMTP  
> connection.
>
> But I completely agree there is an MiM possible for the unsigned MX.  
> Just like we have today. And why we want DNSSEC deployed.

You are https biased i guess. With an unsigned MX your secure chain is  
broken because the target you try to reach by an E-Mail address is  
directed to a target by an "unsecure" link. If the unsecure resolved  
target is then secured doesn't matter because you might be already on  
the wrong track.

Security is only as strong as the weakest point in the chain.

Regards

Andreas