Re: [keyassure] Objective: Restrictive versus Supplementary Models

So it's a social engineering attack?  Might as well just send an email trojan.

This is the same result as
-- Hijacking the TCP session and feeding in a fake cert 
-- Spoofing the A record and sending the client to the wrong host (like ekr said)

--Richard

On Mar 31, 2011, at 3:02 PM, Martin Rex wrote:

> Eric Rescorla wrote:
>> 
>> On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex <mrex@sap.com> wrote:
>>> Martin Rex wrote:
>>>> 
>>>>> 
>>>>> I think this is an important consideration. However a relevant
>>>>> question for a 2119-level MUST seems to be whether we wish to have
>>>>> this data rejected if not DNSSEC signed.
>>>>> What's your view on that?
>>>> 
>>>> I'm much less worried about false positives resulting in DoS, which
>>>> can be more easily achieved attacking at the network layer (IP, TCP).
>>> 
>>> Actually, a DoS based on spoofing an DANE TLSA record with incorrect
>>> data and a long TTL into a DNS cache might turn out to be devastatingly
>>> effective when unsiged TLSA records are accepted.
>> 
>> How is this different from a spoofed A record with a long TTL?
> 
> In a first round of attack, the attacker inserts a fake unsigned
> TLSA record (DNS poisoning) that the victim is accessing with TLS
> frequently and where the DNS admin is not using DNSSEC.
> 
> After constantly running into validation failures although one is
> connecting to the correct server and gets presented the correct
> TLS server cert, either his help desk or the victim will disable DANE
> or switch to a browser that doesn't have it yet.  At that point
> the victim becomes vulnerable to mis-issued certs even for sites
> where the DNS admin uses DANE with DNSSEC.
> 
> -Martin
> 
> 
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure