[signin] Proposal for DNS-based delegation of the support document

[Francois Marier]

As discussed in https://github.com/mozilla/browserid/issues/1523, there
is now a concrete proposal for doing DNS-based delegation of the
BrowserID support document:

https://etherpad.mozilla.org/biBsW5BjLQ

The most controversial aspect of the proposal so far seems to be that
HTTPS takes precedence over DNS.

I think there are two issues to resolve:

1. Should we allow unsigned DNS or just DNSSEC?

2. Should we look at DNS first?

The current proposal allows for unsigned DNS but gives precedence to
HTTPS. This is arguably less secure then what we have now though because
it would open up a new attack (block HTTPS connections to
realdomain.com, then poison DNS to delegate realdomain.com to attacker.com).

If we were to give precendence to DNS, then it would be even easier to
mount the attack as we would only have to do the DNS poisoning.

What do people think is the right answer to the above two questions?

Francois

[Robert Norris]

On Fri, Jun 07, 2013 at 12:15:49PM +1200, Francois Marier wrote:
> 1. Should we allow unsigned DNS or just DNSSEC?

> The current proposal allows for unsigned DNS but gives precedence to
> HTTPS. This is arguably less secure then what we have now though
> because it would open up a new attack (block HTTPS connections to
> realdomain.com, then poison DNS to delegate realdomain.com to
> attacker.com).

I acknowledge the potential for abuse. Very selfishly though, I can't
implement this if it requires DNSSEC for many months - I'm just not in a
position to do that right now.

I'm saying you shouldn't require it; its probably the right thing in the
long term. But so far BrowserID (and Persona) has done well to strike a
balance between what's right and what's practical to do right now. Don't
forget that.

Cheers,
Rob N.

--
Robert Norris <ro...@fastmail.fm>
FastMail DevOps - https://www.fastmail.fm/

[Francois Marier]

On 07/06/13 21:31, Robert Norris wrote:
> I acknowledge the potential for abuse. Very selfishly though, I can't
> implement this if it requires DNSSEC for many months - I'm just not in a
> position to do that right now.
>
> I'm saying you shouldn't require it; its probably the right thing in the
> long term. But so far BrowserID (and Persona) has done well to strike a
> balance between what's right and what's practical to do right now. Don't
> forget that.

That's the main reason why I didn't include a requirement on DNSSEC in
the proposal I linked to. I think it would be nice, but then what's the
point of adding DNS-based delegation if most people can't make use of it?

If we're going to allow unsigned DNS though, I don't feel comfortable
having DNS take precedence over HTTPS given that it would be easier to
compromise.

One issue that was raised on the bug is that some people outsource their
websites to third-parties and wouldn't want these not-so-trusted
third-parties to have the ability to divert their Persona logins. While
they outsource web hosting, they retain control of their DNS.

Of course, if such a third-party runs an HTTPS server for you (the
requirement for them to be able to issue a support document), then they
already have the private key for that HTTPS cert, so you're already
trusting them quite a bit.

Does anybody have any thoughts on this?

Francois

[q...@qmx.me]

I suppose we won't have end users implementing this, so:

1) People who fiddle with DNS records usually know what they are doing (or at least are more tech-savvy than the majority of the users) - Encouraging DNSSEC would be "good enough", as requiring it would harm adoption.

2) Looking at DNS first should be the natural step, and kinda how everything else works already ;) (XMPP comes to mind)

We already require HTTPS, so if you're delegating you're already somewhat trusting a 3rd-party provider for it.

--
qmx

[q...@qmx.me]

On Friday, June 14, 2013 12:32:07 AM UTC-3, Francois Marier wrote:
> On 07/06/13 21:31, Robert Norris wrote:
>
> > I acknowledge the potential for abuse. Very selfishly though, I can't
>
> > implement this if it requires DNSSEC for many months - I'm just not in a
>
> > position to do that right now.
>
> >
>
> > I'm saying you shouldn't require it; its probably the right thing in the
>
> > long term. But so far BrowserID (and Persona) has done well to strike a
>
> > balance between what's right and what's practical to do right now. Don't
>
> > forget that.
>
>
>
> That's the main reason why I didn't include a requirement on DNSSEC in
>
> the proposal I linked to. I think it would be nice, but then what's the
>
> point of adding DNS-based delegation if most people can't make use of it?

+1

>
>
>
> If we're going to allow unsigned DNS though, I don't feel comfortable
>
> having DNS take precedence over HTTPS given that it would be easier to
>
> compromise.

I know it's unconfortable, but it still feels awkward depending on a higher level service (HTTPS will use DNS, if we have a DNS poisoning attack in place we'll have a bigger problem already :P)

I remember seeing some comments about paralelizing both the DNS SRV query + HTTPS lookup - this feels like an implementation detail that needs to be left out of the spec.

--
qmx

[Douglas Campos]

> I think there are two issues to resolve:
>
>
>
> 1. Should we allow unsigned DNS or just DNSSEC?
>
>
>
> 2. Should we look at DNS first?
>
>
>
> The current proposal allows for unsigned DNS but gives precedence to
>
> HTTPS. This is arguably less secure then what we have now though because
>
> it would open up a new attack (block HTTPS connections to
>
> realdomain.com, then poison DNS to delegate realdomain.com to attacker.com).
>
>
>
> If we were to give precendence to DNS, then it would be even easier to
>
> mount the attack as we would only have to do the DNS poisoning.
>
>
>
> What do people think is the right answer to the above two questions?

[Douglas Campos]

> If we're going to allow unsigned DNS though, I don't feel comfortable
> having DNS take precedence over HTTPS given that it would be easier to
> compromise.

[Burak Yiğit Kaya]

Hey there,

I'm ate in the game for this one but I have an idea. How about the
following precedence order: DNSSEC -> HTTPS -> DNS? Would it take too long?

--BYK

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Lloyd Hilaiel]

On Jun 13, 2013, at 5:32 PM, Francois Marier <fran...@mozilla.com> wrote:

> That's the main reason why I didn't include a requirement on DNSSEC in
> the proposal I linked to. I think it would be nice, but then what's the
> point of adding DNS-based delegation if most people can't make use of it?
>
> If we're going to allow unsigned DNS though, I don't feel comfortable
> having DNS take precedence over HTTPS given that it would be easier to
> compromise.
>
> One issue that was raised on the bug is that some people outsource their
> websites to third-parties and wouldn't want these not-so-trusted
> third-parties to have the ability to divert their Persona logins. While
> they outsource web hosting, they retain control of their DNS.
>
> Of course, if such a third-party runs an HTTPS server for you (the
> requirement for them to be able to issue a support document), then they
> already have the private key for that HTTPS cert, so you're already
> trusting them quite a bit.
>
> Does anybody have any thoughts on this?

+1 for phase 1 to be HTTPS first, and if not present DNS. -1 to including support for DNSSEC in the first phase of DNS based support (in the interest of small iterative improvements).

lloyd

[Dan Callahan]

On 7/11/13 3:14 AM, Lloyd Hilaiel wrote:
> On Jun 13, 2013, at 5:32 PM, Francois Marier <fran...@mozilla.com> wrote:
>

>> That's the main reason why I didn't include a requirement on DNSSEC in
>> the proposal I linked to. I think it would be nice, but then what's the
>> point of adding DNS-based delegation if most people can't make use of it?
>>
>> If we're going to allow unsigned DNS though, I don't feel comfortable
>> having DNS take precedence over HTTPS given that it would be easier to
>> compromise.
>>
>> One issue that was raised on the bug is that some people outsource their
>> websites to third-parties and wouldn't want these not-so-trusted
>> third-parties to have the ability to divert their Persona logins. While
>> they outsource web hosting, they retain control of their DNS.
>>
>> Of course, if such a third-party runs an HTTPS server for you (the
>> requirement for them to be able to issue a support document), then they
>> already have the private key for that HTTPS cert, so you're already
>> trusting them quite a bit.
>>
>> Does anybody have any thoughts on this?
>

> +1 for phase 1 to be HTTPS first, and if not present DNS. -1 to including support for DNSSEC in the first phase of DNS based support (in the interest of small iterative improvements).

I'm not comfortable with the security rammifications of that, yet.

Untrusted DNS could be used to misresolve a domain *and* to present a
delegation record, which would circumvent the HTTPS domain.

- DNSSEC would be a smaller change in terms of security model.

- DNS would be a smaller change in terms of implementation complexity.

Thinking out loud:

Maybe it's all moot? Chances are, you won't be able to spoof DNS on
*both* the user and the verifier ends of the pipe. So the spoofed
delegation should never yield certificate that could be seen as valid.

You can basically DoS someone by making it impossible for them to get a
valid cert, but data on RPs would still be safe.

On the other end, you could set up a phishing attack that delegates
authentication to "gmall.com" or similar. To what degree are we
concerned about that, and to what degree can we mitigate it?

Francois? Warner?

-Callahad

[Lloyd Hilaiel]

On Jul 11, 2013, at 3:56 AM, Dan Callahan <dcal...@mozilla.com> wrote:

> On 7/11/13 3:14 AM, Lloyd Hilaiel wrote:
>> On Jun 13, 2013, at 5:32 PM, Francois Marier <fran...@mozilla.com> wrote:
>>

>>> That's the main reason why I didn't include a requirement on DNSSEC in
>>> the proposal I linked to. I think it would be nice, but then what's the
>>> point of adding DNS-based delegation if most people can't make use of it?
>>>
>>> If we're going to allow unsigned DNS though, I don't feel comfortable
>>> having DNS take precedence over HTTPS given that it would be easier to
>>> compromise.
>>>
>>> One issue that was raised on the bug is that some people outsource their
>>> websites to third-parties and wouldn't want these not-so-trusted
>>> third-parties to have the ability to divert their Persona logins. While
>>> they outsource web hosting, they retain control of their DNS.
>>>
>>> Of course, if such a third-party runs an HTTPS server for you (the
>>> requirement for them to be able to issue a support document), then they
>>> already have the private key for that HTTPS cert, so you're already
>>> trusting them quite a bit.
>>>
>>> Does anybody have any thoughts on this?
>>

>> +1 for phase 1 to be HTTPS first, and if not present DNS. -1 to including support for DNSSEC in the first phase of DNS based support (in the interest of small iterative improvements).
>
> I'm not comfortable with the security rammifications of that, yet.
>
> Untrusted DNS could be used to misresolve a domain *and* to present a delegation record, which would circumvent the HTTPS domain.
>
> - DNSSEC would be a smaller change in terms of security model.
>
> - DNS would be a smaller change in terms of implementation complexity.
>
> Thinking out loud:
>
> Maybe it's all moot? Chances are, you won't be able to spoof DNS on *both* the user and the verifier ends of the pipe. So the spoofed delegation should never yield certificate that could be seen as valid.
>
> You can basically DoS someone by making it impossible for them to get a valid cert, but data on RPs would still be safe.
>
> On the other end, you could set up a phishing attack that delegates authentication to "gmall.com" or similar. To what degree are we concerned about that, and to what degree can we mitigate it?

We have an interesting pattern we could apply to this problem. Our current implementation has a "grace period" to solve a related issue: What happens when a primary IdP suddenly disappears? The implementation currently calls the IdP "Broken" and prevents login for some number of days. The thinking is that we should not step in with the fallback and vouch for users for a domain that has expressed intent to vouch for its own users and has temporarily fallen off the net.

What if we did a similar thing here? If a domain has an HTTPS support document, and suddenly delegation is expressed in DNS, we put them into a Broken grace period *unless* they update their support document in some way.

I don't like additional complexity, but I'm thinking we could use this basic idea to allow IdP's to make the risk determination about DNS poisioning. Like, they could effectively *turn off* DNS delegation by simply having a support document on HTTPS OR having "disable": "true"

could something like this alleviate security concerns and help us move forward with the deeply desired convenience win?

lloyd

> Francois? Warner?
>
> -Callahad

[Dan Callahan]

On 7/11/13 2:24 PM, Lloyd Hilaiel wrote:
> The implementation currently calls the IdP "Broken" and prevents login for some number of days.

I kind of think this is terrible, but that's a separate discussion. 30
minutes or an hour, sure. Locking someone out of an RP for *days* when
we have the ability to otherwise vouch for them and get them back on
their feet? As a user, what would you want? :)

-Callahad

[Lloyd Hilaiel]

Yeah, it is a separate discussion. BUT, as a user my email provider doesn't go down for days, and if they do, then they stop being my email provider.

lloyd

[Dan Callahan]

On 7/11/13 2:24 PM, Lloyd Hilaiel wrote:

> If a domain has an HTTPS support document, and suddenly delegation is expressed in DNS, we put them into a Broken grace period *unless* they update their support document in some way.

This feels like a decent solution so long as we're mostly-centralized.
How would it work in a decentralized world, where my browser has a
completely local and native implementation of BrowserID?

> could something like this alleviate security concerns and help us move forward with the deeply desired convenience win?

Maybe. I'd like to see us sit down and actually quantify the potential
harm from a spoofed, malicious delegation.

My brain is a bit fried right now, so I can't quite think through this
rigorously at the moment.

-Callahad

[Francois Marier]

On 11/07/13 20:24, Lloyd Hilaiel wrote:
> I don't like additional complexity, but I'm thinking we could use this basic idea to allow IdP's to make the risk determination about DNS poisioning. Like, they could effectively *turn off* DNS delegation by simply having a support document on HTTPS OR having "disable": "true"
>
> could something like this alleviate security concerns and help us move forward with the deeply desired convenience win?

That was exactly what I had in mind when I put "HTTPS, then unsigned
DNS" in the proposal. It seems like a good compromise between allowing
sites to retain the current security model (more or less) through the
use of HTTPS delegation, and enabling sites for which DNS delegation is
the only option.

Sites that can't easily do HTTPS, probably can't do DNSSEC very easily
either, so if we were to do DNS delegation via DNSSEC only, that feature
would probably not get used very much.

Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
compared to the current "HTTPS only":

1. block all traffic to https://idpexample.com
2. poison DNS and delegate idpexample.com to evilidp.com

So if that's we approach we settle on, I'll bring it up with the
security folks to see how feasible that attack is because the
desirability of DNS delegation is very high. It comes up almost every
time I talk at a conference.

Francois

[Dan Callahan]

On 7/15/13 9:05 AM, Francois Marier wrote:
> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
> compared to the current "HTTPS only":
>

> 1. block all traffic tohttps://idpexample.com

> 2. poison DNS and delegate idpexample.com to evilidp.com

You're presuming the site is serving something on HTTPS.

DNS based delegation opens up a dead simple attack on domains that are
not serving anything on HTTPS, and are currently handled by our fallback.

-Callahad

[Lloyd Hilaiel]

On Jul 15, 2013, at 9:34 AM, Dan Callahan <dcal...@mozilla.com> wrote:

> On 7/15/13 9:05 AM, Francois Marier wrote:

>> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
>> compared to the current "HTTPS only":
>>

>> 1. block all traffic tohttps://idpexample.com

>> 2. poison DNS and delegate idpexample.com to evilidp.com
>

> You're presuming the site is serving something on HTTPS.
>
> DNS based delegation opens up a dead simple attack on domains that are not serving anything on HTTPS, and are currently handled by our fallback.

tl;dr; I'm not yet convinced that DNS delegation when deferred to only in the absence of a response on port 443 adds meaningful risk to users.

Which domains are those and what percentage of our users do they represent? We could find the set of domains that represents 80% of our users and actually analyze them. From what I know, 50-70% of users are represented by hotmail.com, gmail.com, or yahoo.com. For those domains, do any of them right now not serve anything over HTTPS? Can we reason about the behavior of popular IdPs and optimize our algorithms to ensure users of popular domains are not at risk from day one?

I'm proposing the hole in this reasoning is: "The overwhelming majority of domains are in the null state, and thus handled by our fallback and vulnerable to malicious delegation."

We don't care about the raw number of domains. We care about domains prioritized by usage that users type in as part of their email addresses.

Now let's reason ourselves down the attack vector a bit. I'm a bad guy, and I want to get your Persona password so I can log into sites as you. The Persona team has implemented DNS delegation. So here's my strategy:

1. I determine you use ll...@hilaiel.com
2. I notice hilaiel.com:443 doesn't have HTTPS enabled
3. I poison DNS so that the persona data center you are routed to thinks that hilaiel.com is delegated to evil.com
4. You log into voo.st to check cycling events, and during your interaction with persona you notice things seem a little weird, but whatever, you type your persona password
5. it doesn't work, shit voo.st is broken
6. I, the attacker, now have your persona password and can log into all the sites you use.

First, why wouldn't I just take control of your email directly? If I can poison DNS such that a specific data center would see it, then I can change the MX record to restmail.net and I can read your email. Thus I can reset your passwords. *winning*.

Second, why wouldn't I just phish you more directly?

1. I send an email to ll...@hilaiel.com that contains a link to vooo.st
2. you go to it
3. you click on sign-in
4. a dialog from login.personna.org pops up
5. you type in your username and password
6. I, the attacker, now have your persona password and can log into all the sites you use.

This is nice for despicable me, because I don't need to poison DNS.

When I think about this, it goes like this:
1. Based on community feedback (mozilla IT folks included) this is a really high value feature
2. (to be vetted) we can design this in such a way that the majority of users are not at risk
3. (to be vetted) the additional risk delta to the remainder from the status quo is null
4. If we don't implement high value features with low risk, then persona won't be adopted into the main stream and it's all moot anyway.

I'm sure I've got some holes of my own, please point them out. (And dan, thanks for leading this and trying to get to the bottom of it)

lloyd

[Dan Callahan]

On 7/16/13 9:08 AM, Lloyd Hilaiel wrote:
> On Jul 15, 2013, at 9:34 AM, Dan Callahan <dcal...@mozilla.com> wrote:
>
>> On 7/15/13 9:05 AM, Francois Marier wrote:

>>> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
>>> compared to the current "HTTPS only":
>>>

>>> 1. block all traffic tohttps://idpexample.com

>>> 2. poison DNS and delegate idpexample.com to evilidp.com
>>

>> You're presuming the site is serving something on HTTPS.
>>
>> DNS based delegation opens up a dead simple attack on domains that are not serving anything on HTTPS, and are currently handled by our fallback.
>
> tl;dr; I'm not yet convinced that DNS delegation when deferred to only in the absence of a response on port 443 adds meaningful risk to users.

I think my "serve something on HTTPS" comment was a bit overly broad.
Specifically, I'm worried about distinguishing between malicious
delegation and legitimate delegation via DNS. Let's run with that a
little bit more.

(Unless you're suggesting that a response of any kind to
https://example.com/ invalidates DNS-based delegation? That seems like a
really strange dance to encode into the protocol, but it's worth
considering.)

> Which domains are those and what percentage of our users do they represent?

The set is basically every domain that doesn't server a well-known file.
Which is effectively all of them.

Regardless, many universities, business, and startups don't use SSL at
all, nor do many Google Apps for your Domain customers.

> We don't care about the raw number of domains. We care about domains prioritized by usage that users type in as part of their email addresses.

Gmail, Hotmail, and Yahoo are all in the null state, per the absence of
a /.well-known/browserid file.

Should yahoo.co.uk be allowed to delegate to yahoo.com via DNS? Our life
would've been slightly easier if mozilla.com had been allowed to
delegate to signin.mozilla.com via DNS, right?

> First, why wouldn't I just take control of your email directly? If I can poison DNS such that a specific data center would see it, then I can change the MX record to restmail.net and I can read your email.

Because that only gives you temporary access. Phishing your email
password is the gift that keeps on giving. When's the last time you
changed yours?

> Second, why wouldn't I just phish you more directly?

Because that requires known a user/site intersection, and it's a lot of
work.

With unsigned DNS delegation, I could just sit in a coffee shop with
open WiFi near a university and send everyone @example.edu to my evil
IdP, regardless of the RP they're trying to get into.

> 1. Based on community feedback (mozilla IT folks included) this is a really high value feature

Absolutely. I'd love to find a sensible way to make this work without
degrading the overall security of Persona.

> 2. (to be vetted) we can design this in such a way that the majority of users are not at risk

Disagree -- see the other thread between me and Warner:
http://thread.gmane.org/gmane.comp.mozilla.identity.devel/5317

> 3. (to be vetted) the additional risk delta to the remainder from the status quo is null

Disagree, per the same.

> 4. If we don't implement high value features with low risk, then persona won't be adopted into the main stream and it's all moot anyway.

Agree. Just not sure this constitutes "low risk" :)

I'm not sure it's high risk, either. I think it may be an acceptable
risk given the reward, but I want to make sure we agree on what risk
exists and its quantification before doing something like this.

-Dan

[Brian Warner]

> On 7/15/13 9:05 AM, Francois Marier wrote:

>> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
>> compared to the current "HTTPS only":
>>

>> 1. block all traffic tohttps://idpexample.com

>> 2. poison DNS and delegate idpexample.com to evilidp.com

In fact, the DNS lookup happens first, so if you poison DNS, we won't
even try to contact the real idpexample.com: you don't have to block
anything. You just have to answer the DNS query before the real response
arrives, which is trivial to do from a coffeeshop wifi (*you* don't have
to do the real lookup, so you'll always win the race). The response for
example.com will have an A record that points to the attacker's host
(which can then deny knowledge of /.well-known/browserid), then a
response for _browserid._tcp.example.com returns the delegation SRV
record.

On 7/15/13 8:34 AM, Dan Callahan wrote:
> You're presuming the site is serving something on HTTPS.
>
> DNS based delegation opens up a dead simple attack on domains that are
> not serving anything on HTTPS, and are currently handled by our
> fallback.

Yeah, so it doesn't matter if they're serving HTTPS or not :-(.

The victim (of the DNS poisoning) might be the Persona implementation
(either native in the browser, or in the fallback at Mozilla), or the
Verifier (either local in the RP, or the hosted one in Mozilla). I agree
that DNS-poisoning a datacenter is harder (because you don't generally
get to see the outgoing traffic).

So the most vulnerable point is a native Persona implementation in a
browser that's on a public wifi network. That coffeeshop attacker can
trivially redirect the IDP lookup to their own local server, and deliver
a page that is indistinguishable from the real one (am I correct in
believing that a native /auth page doesn't show a location bar?) and
then get the user's password.

(note that poison-the-datacenter attacks against email delivery are a
valid threat, but a lot of big IdPs actually run SMTP over TLS, so
there's more protection against that then you might think).

Accepting non-secure DNS redirects to an unrelated domain completely
loses the security that HTTPS offers. DNS is a helpful lookup service,
but is not a source of truth, especially when used from a hostile
network. Persona as currently designed survives DNS poisoning just fine
(you'll get a cert!=hostname mismatch and fail safe). It'd be a shame to
lose that.

cheers,
-Brian

[Lloyd Hilaiel]

This is exactly the crazy idea: (Unless you're suggesting that a response of any kind to

https://example.com/ invalidates DNS-based delegation? That seems like a
really strange dance to encode into the protocol, but it's worth
considering.)

Dan Callahan <dcal...@mozilla.com> wrote:

>On 7/16/13 9:08 AM, Lloyd Hilaiel wrote:
>> On Jul 15, 2013, at 9:34 AM, Dan Callahan <dcal...@mozilla.com> wrote:
>>

>>> On 7/15/13 9:05 AM, Francois Marier wrote:
>>>> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
>>>> compared to the current "HTTPS only":
>>>>
>>>> 1. block all traffic tohttps://idpexample.com
>>>> 2. poison DNS and delegate idpexample.com to evilidp.com
>>>

>>> You're presuming the site is serving something on HTTPS.
>>>
>>> DNS based delegation opens up a dead simple attack on domains that are not serving anything on HTTPS, and are currently handled by our fallback.
>>

[Dan Callahan]

On 7/17/13 2:54 PM, Lloyd Hilaiel wrote:
> This is exactly the crazy idea: (Unless you're suggesting that a response of any kind to
> https://example.com/ invalidates DNS-based delegation? That seems like a
> really strange dance to encode into the protocol, but it's worth
> considering.)

Check out Brian's response - that doesn't work.

Anyone on the same network could just return a bad A record, which would
call the HTTPS lookup to fail. Then they could return a spoofed SRV
record, which would delegate you out to the malicious site.

-Callahad

[Lloyd Hilaiel]

What if to address this we use the same technique we use to deal with temporarily broken primary IDPs. meaning there's a grace period from the point a site stopped responding on HTTPS to the point will begin deferring to DNS for them.

[Francois Marier]

On 17/07/13 06:02, Brian Warner wrote:
>> On 7/15/13 9:05 AM, Francois Marier wrote:
>>> Now, there is one new attack that "HTTPS, then unsigned DNS" opens up
>>> compared to the current "HTTPS only":
>>>
>>> 1. block all traffic tohttps://idpexample.com
>>> 2. poison DNS and delegate idpexample.com to evilidp.com
>
> In fact, the DNS lookup happens first, so if you poison DNS, we won't
> even try to contact the real idpexample.com: you don't have to block
> anything.

That's an excellent point, I hadn't thought of that: you can just
redirect the HTTPS traffic to a black hole via DNS too. So DNS poisoning
is all you need, really.

> So the most vulnerable point is a native Persona implementation in a
> browser that's on a public wifi network. That coffeeshop attacker can
> trivially redirect the IDP lookup to their own local server, and deliver
> a page that is indistinguishable from the real one (am I correct in
> believing that a native /auth page doesn't show a location bar?) and
> then get the user's password.

The worst side-effect of allowing unsigned DNS would be that while the
security risks may be low enough now (due to the difficulty of poisoning
the data center), they will increase as browsers get native support. So
basically, moving from the shim to native will mean a reduction in
security from the point of view of rogue delegations.

As much as I'd like to see DNS-based delegation, I'm starting to doubt
we can do it securely without a hard requirement on DNSSEC (which would
be very limiting, as many have pointed out).

Francois

[Lloyd Hilaiel]

I've come around folks. The key arguments that have swayed me are:

1. This is an IdP facing feature. For persona to become real, we should prioritize RP adoption.
2. My best attempt at mitigating security risks don't really work when we have native adoption. (they require centralized knowledge)
3. Being an IdP is a big deal in terms of responsibility. Expectations and complexity can be a bit higher.

If this is ok with everyone (and it sounds like we have resounding agreement from devs here), let's mark WONTFIX and move on?

lloyd

[Shane Tomlinson]

On 18/07/2013 05:23, Lloyd Hilaiel wrote:
> I've come around folks. The key arguments that have swayed me are:
>
> 1. This is an IdP facing feature. For persona to become real, we should prioritize RP adoption.
> 2. My best attempt at mitigating security risks don't really work when we have native adoption. (they require centralized knowledge)
> 3. Being an IdP is a big deal in terms of responsibility. Expectations and complexity can be a bit higher.
>
> If this is ok with everyone (and it sounds like we have resounding agreement from devs here), let's mark WONTFIX and move on?

+1.

I want to thank everybody, this has been a very informative discussion.
I had not realized the ease with which DNS poisoning could take place.

Shane

[Francois Marier]

On 18/07/13 16:23, Lloyd Hilaiel wrote:
> If this is ok with everyone (and it sounds like we have resounding agreement from devs here), let's mark WONTFIX and move on?

I agree that we should move on because there's not much point in doing
DNSSEC-based delegation now, it's not going to help with adoption.

Whether we close the bug as WONTFIX or leave it open as 1-star, I don't
know, but I think our message should be "will revisit once DNSSEC is
more widespread".

Shane is absolutely right: this was a really good discussion. Thanks to
all who contributed to it.

Francois

[Jedediah Parsons]

So true. I learned a ton from this thread.

----- Original Message -----
> From: "Shane Tomlinson" <stoml...@mozilla.com>
> To: "Lloyd Hilaiel" <ll...@mozilla.com>
> Cc: "Francois Marier" <fran...@mozilla.com>, dev-id...@lists.mozilla.org
> Sent: Thursday, July 18, 2013 1:04:33 AM
> Subject: Re: [signin] Proposal for DNS-based delegation of the support document
>
> On 18/07/2013 05:23, Lloyd Hilaiel wrote:
> > I've come around folks. The key arguments that have swayed me are:
> >
> > 1. This is an IdP facing feature. For persona to become real, we should
> > prioritize RP adoption.
> > 2. My best attempt at mitigating security risks don't really work when we
> > have native adoption. (they require centralized knowledge)
> > 3. Being an IdP is a big deal in terms of responsibility. Expectations and
> > complexity can be a bit higher.
> >

> > If this is ok with everyone (and it sounds like we have resounding
> > agreement from devs here), let's mark WONTFIX and move on?
>
>

> +1.
>
> I want to thank everybody, this has been a very informative discussion.
> I had not realized the ease with which DNS poisoning could take place.
>
> Shane

[janf...@tanso.net]

kl. 11:00:20 UTC+2 torsdag 18. juli 2013 skrev Francois Marier følgende:

>
> I agree that we should move on because there's not much point in doing
> DNSSEC-based delegation now, it's not going to help with adoption.
>

I don't believe this to be true. I work for an ISP, hosting ~30 partner email domains, with ~1 million users. I can't force https on the www.partner.domains but I can easily publish srv records, and probably also implement DNSSEC if you require that. Missing DNS delegation will block our adoption of persona.

>
> but I think our message should be "will revisit once DNSSEC is
> more widespread".

Chicken and egg problem.. We won't start using DNSSEC before we need to... :-)


-jf

[Eric Rescorla]

OTOH, requiring DNSSEC will basically break any persona installation
that requires it until all browsers support DNSSEC, and indeed support
DNSSEC-based domain delegation (which is currently none of them.)
This seems to break one of the main arguments in favor of the existing
persona design namely that it works on existing browsers.

-Ekr

P.S. http://datatracker.ietf.org/doc/draft-miller-posh/

[Lloyd Hilaiel]

On Aug 19, 2013, at 4:43 PM, Eric Rescorla <e...@rtfm.com> wrote:

> OTOH, requiring DNSSEC will basically break any persona installation
> that requires it until all browsers support DNSSEC, and indeed support
> DNSSEC-based domain delegation (which is currently none of them.)
> This seems to break one of the main arguments in favor of the existing
> persona design namely that it works on existing browsers.

I'm confused. Wouldn't allowing DNSSEC for delegation of authority only involve the persona implementation (our fallback, or a browser native implementation), on verifiers, and on those administrators who care to use it?

What did I miss?

lloyd

[Eric Rescorla]

Ah. I see you're talking about the support document. Looks like I am
the one missing something.

However, In that case, won't every RP need to accept the delegation and
hence support DNSSEC?

-Ekr

[Lloyd Hilaiel]

Currently most RPs are using a verifier hosted by us. There's an effort ongoing to build fantastic verification libraries fast, that RPs can use. To start, they would just forward to our verifier, but would be abstracted in such a way that they're upgradable to support local verification.

So RP's would need to either use our verifier, or use a good verification library. They'd be technically affected, but shielded a bit from the complexity.

To be clear, I'm not making any assessment about the value of charging toward DNSSEC for delegation right now given all the other things going on, just trying to confirm our assumptions and the proposed approach.

lloyd

> -Ekr
>
>
>
>
>
>

[Brian Warner]

On 8/19/13 5:05 AM, janf...@tanso.net wrote:

>> but I think our message should be "will revisit once DNSSEC is more
>> widespread".

FYI, I saw a presentation at USENIX Security last week that measured
DNSSEC deployment at about 1%-2%, measured as the difference between
clients who successfully fetched an image from a non-signed domain and a
badly-signed domain (e.g. % of users who actually check DNSSEC):


https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment

They also found that turning on DNSSEC actually *broke* about 0.5% of
users (measured as the difference between fetching from a non-signed
domain and a correctly-signed domain). They concluded that the larger
DNS records either exceeded misconfigured MTU sizes, or triggered a TCP
fallback (which was then filtered by over-enthusiastic firewalls).

> Chicken and egg problem.. We won't start using DNSSEC before we need
> to... :-)

Yeah, it's tough :). FWIW, Persona's concern is allowing DNS-based
delegation from a client that does not correctly check DNSSEC records.
That case is completely vulnerable to a network attacker, exposing the
user's password to the coffee-shop-wireless man-in-the-middle, or
allowing the wrong public key to be delivered to the verifier. We'd need
to have the client first determine if it could speak DNSSEC before being
willing to trust such delegation (maybe by querying some known-bad
domains and seeing if they fail).

But even if we had, say, 50% DNSSEC deployment, and could reliably sense
if it was available on any given client, the IdP would still be in an
uncomfortable position where half their customers are just plain broken,
so I can't imagine many being willing to turn it on.

DNSSEC is one of those things that improves protection of existing
patterns (yay!), and can be deployed incrementally (yay!), but is being
deployed too gently to let us turn off other protections like TLS any
time soon (boo!).


cheers,
-Brian

[janf...@tanso.net]

kl. 20:53:17 UTC+2 mandag 19. august 2013 skrev Brian Warner følgende:

> FYI, I saw a presentation at USENIX Security last week that measured
>
> DNSSEC deployment at about 1%-2%, measured as the difference between
>
> clients who successfully fetched an image from a non-signed domain and a
>
> badly-signed domain (e.g. % of users who actually check DNSSEC):
>
> https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment
>

Thanks, very interesting. The numbers seems a bit old though (1 year+).. Wikipedia refers to a study showing 8.3% validating clients as of may-2013, with half of these using google's public dns (which started validating dnssec in march-2013):

http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#DNSSEC_deployment_in_resolvers

So it seems dnssec validation has been rising sharply the last year. With google-dns doing validation, it feels much safer for ISPs to follow that lead and turn on validation for their customers too.

>
> Yeah, it's tough :). FWIW, Persona's concern is allowing DNS-based
> delegation from a client that does not correctly check DNSSEC records.
> That case is completely vulnerable to a network attacker, exposing the
> user's password to the coffee-shop-wireless man-in-the-middle,

Isn't the main communication to protect between 3. party service and identity-provider? Which should be a much harder route to attack by woman-in-the-middle.

The communication between client and identity-provider will be protected by SSL, and the user already having a relationship with the site owning the name and SSL certs.

(Sorry if I'm misunderstanding here -- it's been some time since I read the persona docs).



-jf

[Brian Warner]

On 8/19/13 1:30 PM, janf...@tanso.net wrote:

> Thanks, very interesting. The numbers seems a bit old though (1
> year+).. Wikipedia refers to a study showing 8.3% validating clients
> as of may-2013, with half of these using google's public dns (which
> started validating dnssec in march-2013):

Huh, interesting. The CircleID study[1] that gets 8.3% *does* seem to
use the same methodology (banner ads which load unique images). The UCSD
paper presented at USENIX says they ran for one week, but I can't find a
mention of which exact week it was.

8.3% is a lot better, but still not that great :).

> So it seems dnssec validation has been rising sharply the last year.
> With google-dns doing validation, it feels much safer for ISPs to
> follow that lead and turn on validation for their customers too.

Agreed! I suspect that Chrome has some code to test to see whether it
can successfully make DNSSEC-enabled queries, and turns them off it not.
I don't think they'd be willing to break 0.5% of their users. But I also
suspect they're continually monitoring that number and will/would switch
it on all the time once the number has changed, like they've done with
various SSL modes.

> Isn't the main communication to protect between 3. party service and
> identity-provider? Which should be a much harder route to attack by
> woman-in-the-middle.
>
> The communication between client and identity-provider will be
> protected by SSL, and the user already having a relationship with the
> site owning the name and SSL certs.

Both connections start by fetching the .well-known document. The RP
(specifically the verifier) wants to learn the pubkey, or a delegation
pointer: if the attacker could control that, they could force the RP to
accept false assertions (signed by an attacker-controlled key). And
yeah, this is harder to intercept because both ends are probably in
datacenters.

The browser/client uses .well-known to learn the URL of the
authentiation and provisioning pages. If the attacker controls that,
they can point the user to a different page that records and reveals
their password as they type it (perhaps passing it through to the real
IdP if they want to be stealthy about it). That's the most vulnerable
spot.

Delegation (via DNS or otherwise) affects the auth/provisioning page
lookup too. If the coffee-shop-wifi attacker injects a forged DNS record
from your IdP claiming to delegate Persona control to some other domain,
they can make your client load their own auth page, and then silently
grab your password. If your client is one of the 91.7% that doesn't
check for a valid DNSSEC signature, then the attack is pretty easy.

cheers,
-Brian


[1]:
http://www.circleid.com/posts/20130717_dns_dnssec_and_googles_public_dns_service/

[Eric Rescorla]

On Tue, Aug 20, 2013 at 11:38 AM, Brian Warner <war...@mozilla.com> wrote:

>
> On 8/19/13 1:30 PM, janf...@tanso.net wrote:
>

> > Thanks, very interesting. The numbers seems a bit old though (1
> > year+).. Wikipedia refers to a study showing 8.3% validating clients
> > as of may-2013, with half of these using google's public dns (which
> > started validating dnssec in march-2013):
>

> Huh, interesting. The CircleID study[1] that gets 8.3% *does* seem to
> use the same methodology (banner ads which load unique images). The UCSD
> paper presented at USENIX says they ran for one week, but I can't find a
> mention of which exact week it was.
>
> 8.3% is a lot better, but still not that great :).

It was about a year ago....

> > So it seems dnssec validation has been rising sharply the last year.
> > With google-dns doing validation, it feels much safer for ISPs to
> > follow that lead and turn on validation for their customers too.
>

> Agreed! I suspect that Chrome has some code to test to see whether it
> can successfully make DNSSEC-enabled queries, and turns them off it not.
> I don't think they'd be willing to break 0.5% of their users. But I also
> suspect they're continually monitoring that number and will/would switch
> it on all the time once the number has changed, like they've done with
> various SSL modes.
>

> If I'm reading this correctly this isn't Chrome but rather Google's DNS
servers.

I don't believe that Chrome does DNSSEC at all.

>
> > Isn't the main communication to protect between 3. party service and
> > identity-provider? Which should be a much harder route to attack by
> > woman-in-the-middle.
> >
> > The communication between client and identity-provider will be
> > protected by SSL, and the user already having a relationship with the
> > site owning the name and SSL certs.
>

> Both connections start by fetching the .well-known document. The RP
> (specifically the verifier) wants to learn the pubkey, or a delegation
> pointer: if the attacker could control that, they could force the RP to
> accept false assertions (signed by an attacker-controlled key). And
> yeah, this is harder to intercept because both ends are probably in
> datacenters.
>
> The browser/client uses .well-known to learn the URL of the
> authentiation and provisioning pages. If the attacker controls that,
> they can point the user to a different page that records and reveals
> their password as they type it (perhaps passing it through to the real
> IdP if they want to be stealthy about it). That's the most vulnerable
> spot.
>
> Delegation (via DNS or otherwise) affects the auth/provisioning page
> lookup too. If the coffee-shop-wifi attacker injects a forged DNS record
> from your IdP claiming to delegate Persona control to some other domain,
> they can make your client load their own auth page, and then silently
> grab your password. If your client is one of the 91.7% that doesn't
> check for a valid DNSSEC signature, then the attack is pretty easy.
>

There are really three questions here:

1. What is the impact to the server of doing DNSSEC at all (one question we
tried to answer with the UCSD study)
2. What fraction of client browsers do (or are willing to do) end-user
validation.
3. What fraction of servers do (or are willing to do) end-user validation.

Note that neither of these studies attempts to distinguish between end-user
validation and validation by the DNS server. The available data suggests
that the vast majority of validation is by the DNS server, but that doesn't
really help here because we assume that there is a network attacker
who can inject RRs in the connection between you and the DNS server.
So, the real number of people who are protected is just those who do
end-user validation, which, as I said above, is no browser to my knowledge,
and may be the occasional server. [0]

-Ekr

[0] There's a separate question of whether it's even safe to turn on
end-user
validation in the face of NATs and whatever that strip out unknown RRs.
That can't be measured with an ad network study b/c you need to actually
do DNS queries directly rather than as a side effect.

cheers,
> -Brian
>
>
> [1]: http://www.circleid.com/posts/**20130717_dns_dnssec_and_**
> googles_public_dns_service/<http://www.circleid.com/posts/20130717_dns_dnssec_and_googles_public_dns_service/>
>
> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>