Subject: [dane] DANE for MUAs

From: Tony Finch <[email-masked]>
Date: Fri, 1 Jun 2012 17:47:50 +0100

I've started a draft for using DANE with IMAP, POP3, and message
submission, but I've got a bit stuck deciding how to fit in with
RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs).

RFC 6125 has the following example:

   A mail user agent that is connecting via IMAPS to the email service
   at "example.net" (resolved as "mail.example.net") might have five
   reference identifiers: an SRV-ID of "_imaps.example.net" (see
   [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and,
   as a fallback, CN-IDs of "example.net" and "mail.example.net".  (A
   legacy email user agent would not support [EMAIL-SRV] and therefore
   would probably be explicitly configured to connect to
   "mail.example.net", whereas an SRV-aware user agent would derive
   "example.net" from an email address of the form "[email-masked]"
   but might also accept "mail.example.net" as the DNS domain name
   portion of reference identifiers for the service.)

I presume that the client would not actually use mail.example.net as a
reference identifier unless DNSSEC is in use, otherwise that would not be
secure and is therefore forbidden according to the rules a few paragraphs
earlier in RFC 6125.

There's also a question about how SNI fits in. RFC 6066 says that it only
supports DNS host names, which I take to mean SRV targets not SRV names.
RFC 6186 encourages the use of SNI but says nothing about which identity
should be used.

So I'm inclined to state that the server should have a certificate
containing both the SRV name and target as DNS-IDs and offer that
certificate if it is given either identity in an SNI. This is so that the
server can support new-style clients (supporing DANE and SRV and using the
SRV name as the identity) as well as old-style clients (using address
records directly and the server host name for the TLS identity). I'll
mention the SRV-ID for form's sake but as far as I can tell it's a fantasy
that doesn't exist in the real world.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger: Northwesterly 4 or 5, occasionally 6 in east. Moderate. Showers later.
Good.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 1 Jun 2012 13:03:06 -0400

> secure and is therefore forbidden according to the rules a few paragraphs

That sounds correct to me.

> RFC 6186 encourages the use of SNI but says nothing about which identity

SNI really needs to be extended to support other name types
(especially SRVName and URI).

> that doesn't exist in the real world.

This doesn't achieve compartmentalization of security against other 
services sharing the domain name at the DNS-ID. It might however
be necessary until software evolves.

I agree that SRV-ID is for the time being a fantasy. Although if
DANE usage types 2 and 3 take off, it might not be in the future.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Ned Freed <[email-masked]>
Date: Fri, 01 Jun 2012 12:15:15 -0700 (PDT)

> Hi Tony,

> --On June 1, 2012 5:47:50 PM +0100 Tony Finch <[email-masked]> wrote:

> Shouldn't 6125 be updated to account for DANE, rather than doing this per
> protocol (or set of protocols)? That way anything that references 6125bis
> would inherit the correct DANE behavior.

I've been thinking about this as well, and due to the different ways the DNS is
used in these cases, I think it it at least makes sense to do them separately.
But we should do all the email SRV ones at once.

I'm willing to help on a DANE spec built on top of RFC 6186. (Since Tony has
apparently taken some of my prose, I feel no qualms about swiping a bunch of
his ;-)

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 01 Jun 2012 13:34:56 -0700 (PDT)

Sorry, didn't notice that Tony has already started. Anyway, I'm willing to
help.

				Ned

> 				Ned
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 14:36:34 -0600

> But we should do all the email SRV ones at once.

Ned, I tend to agree. Let's define them separately for now (Matt Miller
and I are working on an XMPP+DANE spec) and then see what the
commonalities are before we try to define a more generic approach.

Now, it's *also* possible that we might want to update RFC 6125 to
address the existence of DANE, and I'm happy to work on that as well,
but I see it as a parallel work item.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 14:41:02 -0600

> That sounds correct to me.

Agreed. That's the approach Matt Miller and I are taking for secure
delegation in XMPP (we'll submit an I-D soonish).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 01 Jun 2012 12:55:21 -0400

Hi Tony,

-- 
Cyrus Daboo

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2012 14:51:32 +0100

Peter Saint-Andre <[email-masked]> wrote:
> Ned Freed <[email-masked]> wrote:
> >
> > I've been thinking about this as well, and due to the different ways
> > the DNS is used in these cases, I think it it at least makes sense to
> > do them separately. But we should do all the email SRV ones at once.
>

Yes, that was what I had in mind. It's possible that we might find
commonalities before the separate-protocol drafts get to RFC stage, but we
clearly need to bash out some details. It will be particularly useful to
compare XMPP and email.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames: South 4 or 5, backing southeast 5 or 6. Slight or moderate.
Showers then rain. Good, becoming moderate or poor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jun 2012 15:48:19 +0100

> delegation in XMPP (we'll submit an I-D soonish).

I have a review in the works :-)

While I was investigating this yesterday I had a look at gmail.com's
RFC 6186 email SRV setup since I thought I might use it as an example.
Sadly their servers have the wrong certificates - they can only
authenticate {imap,pop,smtp}.gmail.com not gmail.com. I've written this up
in more detail at http://fanf.livejournal.com/120855.html and notified
[email-masked]. I don't entirely blame them for this error since
RFC 6125's abstractions are a bit confusing and the email example doesn't
mention the "derived domain" caveat.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: West veering northwest 5 or 6. Moderate or rough. Occasional rain.
Moderate or good.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 09:42:25 -0600

> I have a review in the works :-)

Thanks.

> mention the "derived domain" caveat.

The more I think about it, the more I realize that RFC 6125 will need to
be updated to reflect the use of derived domains under secure
delegation. But let's work on our separate email and XMPP I-Ds first. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/