Re: [dane] UKS attacks on DANE

[Martin Thomson]

The draft explains this in more detail.

To use your example, there is now confusion over the identity of the
server.  The client thinks that they have connected to google.com,
when in fact they have connected to facebook.com.

That's where the attacks start.  Requests made to facebook.com over
that connection will be treated as *same-origin* to google.com.  That
violates the SOP and could allow google.com to read confidential data
from facebook.com.

On 14 October 2016 at 11:15, John Gilmore  wrote:
> I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept.
>
> The attack scenario, presented in section 2 of
>
>   https://www.ietf.org/id/draft-barnes-dane-uks-00.txt
>
> is that a user connects to the "attacker" site (say google.com) but
> actually google.com has published Facebook.com's public key and is a
> man-in-the-middle (MITM) forwarding all the traffic to facebook.com.
>
> Now this MITM can't actually read or modify any of the traffic, they
> are just a passive conduit.  The most they can see is the timing of
> the traffic and the number of bytes involved.  The user sees
> Facebook's site, secured with Facebook's key, even though they
> connected to google.com.  (How or why the user was somehow convinced
> to connect to google.com while seeking facebook.com is unexplained.)
>
> So the threat is...  uh...  ?
>
> ... something about some cross-origin scripting firewall policy
> elsewhere in the system?
>
> Why do we care?
>
> John

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] UKS attacks on DANE

[Viktor Dukhovni]

> On Oct 11, 2016, at 8:31 PM, Martin Thomson  wrote:
> 
>> I believe your concept is much to narrow.
> 
> I tend to agree, though that hinges on your definition of
> "cross-origin".  In the web world, that has a very specific meaning.
> What you could say that "if the client doesn't care who it is talking
> to, or it has some secondary means of validating the identity of a
> server, then this isn't a concern".

No, it is not "don't care".  It is rather that it is quite sufficient
to know that mail is being delivered to whichever server the next-hop
domain designates as its mailhost.  If some domain wants to publish
(DNSSEC-signed) records:

example.com. MX 0 mail.ietf.org.
or
_xmpp-server._tcp.example.com. SRV 0 100 5222 jabber.ietf.org.

to the effect that its email or XMPP servers are running on some
outsourced host, it is free to do so.  The target host may not
offer the service, and may turn away clients trying to send email
or instant messages to u...@example.com, but there is no security
impact on either the client or ietf.org beyond any extra load.  And
of course extra load be imposed much more effectively by other means.

> In the mail case, I continue to be astonished that this isn't a
> material problem, but I guess that there really must be these
> secondary mechanisms.

No secondary mechanisms are present or needed.  The issue is
simply moot.  The attacker gains no advantage by redirecting
his own domain's SMTP, XMPP, ... traffic to an unwitting target
server.

What's odd is not that SMTP and XMPP are immune, but rather
the astonishing subtlety of the Web security model, which
makes web applications vulnerable.

-- 
Viktor.
___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] UKS attacks on DANE

[Martin Thomson]

On 12 October 2016 at 01:45, Martin Rex  wrote:
>> Well, the UKS issue is rather narrowly applicable to special TLS
>> applications in which cross-origin concerns apply.  That's
>> basically just browsers, and browsers are not doing DANE, and
>> certainly not DANE-EE(3).
>
> I believe your concept is much to narrow.

I tend to agree, though that hinges on your definition of
"cross-origin".  In the web world, that has a very specific meaning.
What you could say that "if the client doesn't care who it is talking
to, or it has some secondary means of validating the identity of a
server, then this isn't a concern".

In the mail case, I continue to be astonished that this isn't a
material problem, but I guess that there really must be these
secondary mechanisms.

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] UKS attacks on DANE

[Martin Rex]

Viktor Dukhovni wrote:
> 
> Well, the UKS issue is rather narrowly applicable to special TLS
> applications in which cross-origin concerns apply.  That's
> basically just browsers, and browsers are not doing DANE, and
> certainly not DANE-EE(3).

I believe your concept is much to narrow.

The issue affects *EVERY* TLS client that will in at least one usage
scenario perform rfc2818 section 3.1 endpoint identification for
a TLS server certificate issued from a public CA.


Every such client, when adopting an alternative TLS server certificate
validation through DANE, probably ought to check the end-entity certificate
for appearance of the Certificate Policy with the OID 2.23.140.1.2.2
and for any TLS server certificate that carries this OID, enforce
the rfc2818 section 3.1 endpoint identification for the hostname,
no matter what kind of TLSA record/usage exists for that server.


-Martin

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] UKS attacks on DANE

[Martin Thomson]

On 10 October 2016 at 20:24, Martin Rex  wrote:
> The description of the problem sounds vaguely familiar.
>
> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html

If only they had listened eh?  And they went ahead and published anyway.

I didn't do a complete search of mailing list archives when writing
this.  Unsurprisingly, your concerns turned out to be well-founded.

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

Re: [dane] UKS attacks on DANE

[Martin Rex]

Martin Thomson wrote:
> Richard, ekr and I have submitted a draft describing UKS attacks on
> certain DANE usages:
> 
>   https://datatracker.ietf.org/doc/draft-barnes-dane-uks/
> 
> The draft contains the details, but the short version is that usages 2
> and 3 are potentially vulnerable to an unknown key share attack if the
> client fails to verify the identity of the server.  Since Section 5.1
> of RFC RFC 7671 explicitly states that client's should NOT verify the
> identity of the server in these cases.

The description of the problem sounds vaguely familiar.

https://www.ietf.org/mail-archive/web/dane/current/msg03737.html

-Martin

___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane