Subject: [saag] Scoping the HARD problem

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Nov 2010 14:24:40 -0900

The audio during the saag session wasn't great, so 
there's an excellent chance I missed a great deal,
but I'm unclear on the intended scope of the "HARD"
problem.  There's a similar problem in HTTP
redirects, or even just in HTTP handoffs from one site
to another.  These cases seem very ill-suited for the
DNS-based solution described in draft-barnes-hard-problem 
(you're probably not going to go out to get an SRV 
record for an HTTP URI).  Is the intent to focus on
the XMPP/some-other-service case, or to be more general?

Thanks,

Melinda

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 12 Nov 2010 07:47:06 +0800

Hey Melinda,

The presentation in SAAG was an attempt to generalize out from a 
conversation that started in the XMPP community, which has SRV-based 
outsourcing as a particular pain point.  But I think the idea of 
presenting to the broader community was to see if there was interest in 
a more general solution, or even if that's something that people thought 
might be feasible.

--Richard

On 11/12/10 7:24 AM, Melinda Shore wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Nov 2010 15:18:52 -0900

On Nov 11, 2010, at 2:47 PM, Richard L. Barnes wrote:
> The presentation in SAAG was an attempt to generalize out from a conversation that started in the XMPP community, which has SRV-based outsourcing as a particular pain point.  But I think the idea of presenting to the broader community was to see if there was interest in a more general solution, or even if that's something that people thought might be feasible.

I've been interested in the more general problem from a 
somewhat different perspective: Vendor A sends you off to
someone who appears to be Payment Agency B - how do you
know that they're authorized to collect funds on behalf of 
Vendor A? 

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Nov 2010 21:12:57 -0500

I think it depends on the level of assurance you require here as to which
approach approaches are going to give an acceptable cost/benefit tradeoff.

There is an option in TLS that allows a client to tell the server which
domain it is attempting to connect to. So one principled approach to this
problem would be to say that the client presents the domain name that it
used at the start of the resolution chain.

For example, client attempts to connect for [email-masked]

_service.example.com  SRV 1 1 443 host.outsource.com

Client presents example.com as the domain to host.outsource.com. This means
that there is an end-to-end security context that is independent of the DNS
redirects. So DNSSEC is not required.

I would be comfortable with this approach presenting EV type chrome to the
user if the EE cert was EV. The user is clearly being serviced by Example
Corp that owns example.com.

One disadvantage that people might see in this is that outsource.com has a
cert to pretend to be example.com. But that does not bother me much for an
application that does not offer non-repudiation.

The other approach would be to allow the client to present the cert for
host.outsource.com.

The question here is what are you going to be telling the user?

If the application is OK sending the messages plaintext, and the user is not
going to be told that the connection is 'secure' then the criteria for
accepting a certificate can be negligible. A TLS session with a completely
bogus certificate is still more secure than a plaintext session. At least if
you are using Mallet's cert, only mallet can attack you.

In an Internet where 99% of traffic is not secure, the threshold for turning
on cryptography should be really low. The question is where the threshold
should be for giving a padlock icon. And that is much harder. I don't think
that we should be giving the padlock icon interface for DV certs used in Web
browsers. Checking a domain name is not a sufficient degree of validation
for accepting credit cards.

What should be the criteria for XMPP? I don't know.

If you want to tell the user that the connection is 'secure' then you
probably want to have some sort of authentication of the referral. And then
you get into the question of how strong you need that binding to be.

A DNSSEC signature on an SRV record produces a strong cryptographic basis
for a referral. But it is only as strong as the signing key.

The ICANN chain can only give us what we expect from DV security at best.
But imagine that we have an EV cert for the DNSSSEC KSK at example.com. What
is the strength of the resulting chain?

Omitting the KSK/ZSK thing we have:

example.com DNSKEY  is signed by CA-EV
SRV -> host.outsource.com  is signed by example.com DNSKEY
host.outsource.com is signed by CA-?

Even if CA-? is an EV CA there are two different administrative zones here
and we don't know that they are necessarily in sync.

On Thu, Nov 11, 2010 at 7:18 PM, Melinda Shore <[email-masked]> wrote:

> outsourcing as a particular pain point.  But I think the idea of presenting
> to the broader community was to see if there was interest in a more general
> solution, or even if that's something that people thought might be feasible.
>

-- 
Website: http://hallambaker.com/