Subject: Additional reviews of draft-daboo-srv-email-02.txt needed

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Aug 2009 11:42:50 +0100

Hi,
I've just initiated IETF LC for this document. The document describes 
how DNS SRV records can be used for email client autodiscovery of 
IMAP/POP servers.
I would like to solicit additional reviews of the document.

Thanks,
Alexey

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 21 Aug 2009 09:29:12 +0400

> I would like to solicit additional reviews of the document.

Just one point: The document assumes that the server for 
[email-masked] is somehost.example.com. This can be deduced 
from the Security Considerations and from TLS certificate 
requirements, but is not stated clearly and openly.

I'd object this very restriction, as I cannot see how it is 
justified. No similar requirements exist for SMTP servers or MX 
records. Of course, I would welcome a statement about 
accountability requirements for email domains as a means to 
increase security (I'll look for adoption of an SMTP extension 
on that topic) but not a sneaking introduction of such concept.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 13:57:22 +0100

Hi Alessandro,

Alessandro Vesely wrote:

> [email-masked] is somehost.example.com. This can be deduced from the 
> Security Considerations and from TLS certificate requirements, but is 
> not stated clearly and openly.

You are quite wrong about that. There is no such requirement.
However, if TLS is used, there is a requirement that the server 
advertised in the DNS SRV record shows that it supports the domain part 
(example.com above). This is needed to protect from attacks on insecure DNS.

> I'd object this very restriction, as I cannot see how it is justified. 
> No similar requirements exist for SMTP servers or MX records. Of 
> course, I would welcome a statement about accountability requirements 
> for email domains as a means to increase security (I'll look for 
> adoption of an SMTP extension on that topic) but not a sneaking 
> introduction of such concept.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 09:05:37 -0500

Alexey Melnikov wrote:
> (example.com above).

Alexey: I don't think that is quite the case.  Based on the work
we did in SIP for TLS, I believe that the pkix WG view is that
if the input to SRV process is the domain name "example.com",
then the certificate received better contain "example.com" and
not "somehost.example.com".  Of course, the certificate can
contain multiple entries in the SAN and the client can match
the specific one it used as input to SRV.

Some browsers today, most notably Firefox v3.0.11, issues a
warning if the URL is http://example.com but the certificate
received contains the name "www.example.com".

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 15:11:57 +0100

Hi Vijay,

Vijay K. Gurbani wrote:

>>> [email-masked] is somehost.example.com. This can be deduced from 
>>> the Security Considerations and from TLS certificate requirements, 
>>> but is not stated clearly and openly.
>>
>> advertised in the DNS SRV record shows that it supports the domain 
>> part (example.com above).
>
> not "somehost.example.com".

This is what I said above ("the domain part" is "example.com", not 
"somehost.example.com"). Unless I am confused, I think you are actually 
agreeing with what I said.

> Of course, the certificate can

Yes.

> received contains the name "www.example.com".

And rightly so.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 09:18:38 -0500

> agreeing with what I said.

OK, then we are in agreement.  Apparently I mis-understood
your original response; I assumed you meant that the client
should be okay if it used "example.com" as input to SRV but
received a certificate attesting only "somehost.example.com".

Clearly that is not the case, and the client should expect
"example.com" as an identity in the certificate.

Thanks,

- vijay

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 21 Aug 2009 10:33:27 -0400

Hi Vijay,

> "example.com" as an identity in the certificate.

The last paragraph of the security considerations makes these statements:

1) When no secure DNS is in place clients SHOULD check the hostname 
returned from the SRV lookup and match that to the domain used for the SRV 
lookup. If those do not match, then additional user verification is 
required.

2) If TLS is available for the host, then clients MUST use the domain used 
in the SRV lookup "for certificate verification purposes".

Now that last statement is a little bit vague. Is it saying that the SRV 
domain must be attested to in the TSL certificate, or could it imply that a 
sub-domain of the SRV domain be attested to. I would like to hear from 
security folks on this as I am not at all sure.

-- 
Cyrus Daboo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 09:41:27 -0500

Cyrus Daboo wrote:
> 2) If TLS is available for the host, then clients MUST use the domain 
> used in the SRV lookup "for certificate verification purposes".
> 
> domain must be attested to in the TSL certificate, or could it imply 
> that a sub-domain of the SRV domain be attested to. I would like to hear 
> from security folks on this as I am not at all sure.

Hello Cyrus:

My understanding is that you should stay away from domain
delegation, sub domains or wildcards in certificates.  That is,
you want to be as explicit as possible -- if the input to DNS is
"foo.com", then the returned certificate better contain exactly
"foo.com" in the Subject, or better yet, as an identity in the SAN.

Subdomains and wildcards can be be used to circumvent
security.  When we did the work for SIP certificates, we
explicitly stayed away from these.

You may also want to run this by pkix WG and the security
directorate.

Thanks,

- vijay

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Aug 2009 15:48:41 +0100

Vijay K. Gurbani wrote:

>> Now that last statement is a little bit vague. Is it saying that the 
>> SRV domain must be attested to in the TSL certificate, or could it 
>> imply that a sub-domain of the SRV domain be attested to. I would 
>> like to hear from security folks on this as I am not at all sure.
>
> Hello Cyrus:
>

I agree about subdomains, as they are under different administrative 
control. I haven't heard about problems with wildcards (in the leftmost 
host part only). Russ Housley and Tim Polk were certainly Ok with this 
kind of wildcards when discussing another document during IESG review.

I think the current text as written is quite clear that the domain 
itself should be used for TLS server identity verification, which I 
think is the correct way.

> You may also want to run this by pkix WG and the security

That would be fine too, if you want additional opinions.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 21 Aug 2009 11:08:59 -0400

Hi Alexey,

--On August 21, 2009 3:48:41 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> I think the current text as written is quite clear that the domain itself
> should be used for TLS server identity verification, which I think is the
> correct way.

The problem is you probably don't want to have "example.com" in the subject 
of the certificate for the server "imap.example.com" because clients that 
are directly configured with "imap.example.com" as the server host name 
will expect "imap.example.com" in the subject. i.e. the SRV lookup process 
should not "break" existing client behavior wrt verifying certificates.

Perhaps the requirement on the certificate could be:

1) Subject MUST match the server host name (does not break existing clients)

2) Subject Alternative Name (SAN) should include the SRV query name, i.e. 
_imap._tcp.example.com. i.e, rather than making it the domain itself 
("example.com") we explicitly indicate that the server is valid when found 
through the SRV lookup process. Clients would then be required to verify 
the SAN against the SRV query they did.

Is this reasonable? Is there any precedent for an approach like this?

-- 
Cyrus Daboo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 11:07:56 -0500

Cyrus Daboo wrote:
> The problem is you probably don't want to have "example.com" in the 
> subject of the certificate for the server "imap.example.com" because 
> clients that are directly configured with "imap.example.com" as the 
> server host name will expect "imap.example.com" in the subject. i.e. the 
> SRV lookup process should not "break" existing client behavior wrt 
> verifying certificates.
> 
> 2) Subject Alternative Name (SAN) should include the SRV query name, 
> i.e. _imap._tcp.example.com. i.e, rather than making it the domain 
> itself ("example.com") we explicitly indicate that the server is valid 
> when found through the SRV lookup process. Clients would then be 
> required to verify the SAN against the SRV query they did.
> 

Cyrus:

Isn't it easier for an additional identity of "imap.example.com"
to be present in the SAN instead of an intermediary SRV query name
like "_imap._tcp.example.com"?  This covers the case of clients who
are configured with "imap.example.com" to work just as seamlessly
as clients who start with "example.com" as their SRV query.  Plus we
don't have to ask CAs to put in an DNS intermediary identifier
like "_imap._tcp.example.com", which AFAIK does not have any
precedence.

Thanks,

- vijay

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 23 Aug 2009 10:24:30 +0400

>> should be used for TLS server identity verification, which I think is the

Since the same protocol can serve both TLS and cleartext 
connections, the requirement that the server name somehow 
matches a given domain cannot be restricted to TLS. That 
restriction implies that a compliant server should avoid to set 
up TLS and SRV at the same time: If SRV records with a different 
domain are allowed, they prevent using secure connections, 
vice-versa if TLS with certificate from a different domain is in 
use, it cannot be advertised in an SRV record. IOW, SRV and TLS 
are not fully compatible by design.

In addition, as matching the domain is a precise requirement, 
speaking about "a secure DNS option" should have the same 
precision, i.e. explicitly mention DNSSEC (or would DNS over 
SCTP suffice?) BTW, it seems to me that if attackers are able to 
poison the DNS so as to place the wrong name in an SRV record, 
they could as well place the wrong IP for the correct name 
instead. How effective is that restriction for preventing users' 
passwords from being phished?

> SRV lookup process should not "break" existing client behavior wrt 

That's correct. There are countless discussions about how to 
deduce the domain name from the HELO identity in an SMTP dialog, 
and all of them conclude that there's no way to do it. 
Therefore, your proposed Subject/SAN alternative may make sense.

> Is this reasonable? Is there any precedent for an approach like this?

SAN is not always used, some CA (e.g. CAcert.org) don't sign it, 
and it is not clear how they could verify it. I would propose a 
domain compatibility relationship as follows: if two domains 
share at least one primary MX server, then they are compatible. 
I'd expect it to be nearly an equivalence relationship, albeit 
not necessarily. This concept is as new as your requirement that 
a server has the same domain. Is it good? Useful?

At any rate, statistics about certificate settings for mail show 
there's a lot of "wrong" certificates.

If srv.example.com serves a number of virtual domains, e.g. 
example.org and example.net, *how* should they set up DNS and 
certificates? It is new ground: a full example would be appreciated.

I don't know how many servers will not be compliant with SRV, 
but SNI is relatively new, so any providers who designed their 
set up before 2006 will presumably delay adoption of SRV records 
until most clients support SNI.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 Aug 2009 23:41:53 +0200

Alessandro Vesely <[email-masked]> writes:

>> itself ("example.com") we explicitly indicate that the server is
>> valid when found through the SRV lookup process. Clients would then
>> be required to verify the SAN against the SRV query they did.
>>
> SAN is not always used, some CA (e.g. CAcert.org) don't sign it, and
> it is not clear how they could verify it.

That is wrong, CAcert.org definitely supports SANs.  All certs I've
acquired through cacert.org have had SANs in them for quite some time.

/Simon

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 Aug 2009 18:38:51 +0200

> acquired through cacert.org have had SANs in them for quite some time.

Oops, I apologize for my mistake. In their words

  nothing else except for commonNames and subjectAltNames
  will appear on your certificate, the other fields are removed

According to http://blog.cacert.org/2005/05/37.html they take SANs 
since 2005. An interesting discussion on using them appears in 
http://wiki.cacert.org/wiki/VhostTaskForce. However, it's centered 
on web usage, not mail. After examining a number of combinations, 
they apparently suggest "1 CN + multiple SAN" setups.

Using multiple SANs, an ESP hosting a reasonable number of domains 
could provide an acceptable certificate without resorting to SNI. As 
an alternative to the SRV label mentioned in (2) above, the mail 
domain name could be indicated by a reserved mailbox, e.g. 
[email-masked]. The latter may be less confusing for casual 
examiners of that certificate.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 24 Aug 2009 14:04:34 -0400

> (example.com above). This is needed to protect from attacks on insecure DNS.

Quite true, although an important question is how the domain part
is advertised in the certificate. Most likely it will be put in
the the common name or the subjectaltname's DNSname field. But
in many cases that poses a security problem, if other services
unrelated to IMAP (or POP3 and submission) are also hosted at
the domain part. If we issue an "example.com" certificate to the
IMAP service, it could use that to impersonate any TLS service at
that domain unrelated to IMAP (eg. jabber, https, etc).

I'm not sure we have a good practical solution to this problem.
today. RFC 4985 (SRVName SAN) could be used in theory to compartmentalize
certificates to specific services at a domain name. But I'm not
sure any commercial CAs today will issue certs with such extensions.

--Shumon.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 24 Aug 2009 13:33:07 -0500

> that domain unrelated to IMAP (eg. jabber, https, etc).

That is quite true (though I am not sure whether it is
"impersonation", per se; after all, it is a signed and issued
certificate.)

> I'm not sure we have a good practical solution to this problem.

The notion of tying an identity in the certificate to a specific
use is reasonable, I think.  The way we did this in our SIP
work was to have a SIP-specific extended key usage (EKU) -- see
http://tools.ietf.org/html/draft-ietf-sip-eku-05.

However, EKUs have their own set of emotional baggage,
including the fact that existing certificates will not have
the specific extension specified.

Thanks,

- vijay

---

From: Shumon Huque <[email-masked]>
Date: Mon, 24 Aug 2009 15:02:56 -0400

> "impersonation", per se; after all, it is a signed and issued

Well, it may have been signed and issued correctly. But since the 
embedded identity wasn't specified with sufficient granularity, it 
could be used for purposes other than intended. And this leads to
the impersonation threat.

In a large enough organization, different services at the same
domain name may be operated by different folks, on different
systems, with different security requirements. You normally
don't want the operator of one of those services being able
to impersonate the identity of another. Either deliberately,
or because it got compromised by an attacker.

> the specific extension specified.

Yeah, that's an interesting way to address this. But I think
it has an even bigger deployment problem than RFC 4985. You'd
need to define a new EKU for each new service. With RFC 4985,
one general purpose spec could potentially be used for all
services that use DNS SRV records.

--Shumon.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 24 Aug 2009 15:18:55 -0400

Hi Shumon,

> sure any commercial CAs today will issue certs with such extensions.

Right. This was why I suggested using the SRV query string in the 
subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that gets 
to that cert via an SRV lookup can verify that it is valid, whilst other 
clients will effectively ignore that, and the cert can't "impersonate" 
another service.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Aug 2009 21:40:59 +0100

Cyrus Daboo wrote:

> Hi Shumon,
>
> --On August 24, 2009 2:04:34 PM -0400 Shumon Huque 
> <[email-masked]> wrote:
>
> subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that 
> gets to that cert via an SRV lookup can verify that it is valid, 
> whilst other clients will effectively ignore that, and the cert can't 
> "impersonate" another service.

If you are going to do that, you need to update IMAP and POP3 specs 
properly, i.e. to define TLS server identity verification procedure for 
these protocols that requires that clients check srvName.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 24 Aug 2009 18:00:30 -0400

> these protocols that requires that clients check srvName.

Putting the SRV query name in dNSName is a somewhat novel
use. And reusing an existing widely used SAN field is probably 
more deployable than a new barely used SAN field.

Would you have to update the IMAP and POP3 documents though?
Wouldn't this I-D just update them. To support older software
as well, the server owner would just obtain a cert with 2 dnsnames,
the SRV name and the server hostname.

--Shumon.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Aug 2009 16:03:41 -0600

> more deployable than a new barely used SAN field.

Perhaps I missed something, but don't we have RFC 4985 for SRVName?

Peter

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

---

From: Shumon Huque <[email-masked]>
Date: Mon, 24 Aug 2009 18:12:50 -0400

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Yes Peter, we do. And the XMPP updates even use it, as
you know :)

The main impediment is that we can't get any commercial CAs
to issue certs with SRVName yet ..

Perhaps, this doc should recommend RFC 4985, but also
allow putting the SRV query name into dnsname.

--Shumon.

(Really, I wish we could get the "global" commercial CAs to
certify enterprise CAs with appropriate name constraint
extensions, so that we could all issue our own certs, with
whatever capabilities we needed. But that's a topic of another
diatribe ..)

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Aug 2009 13:16:05 +0200

> these protocols that requires that clients check srvName.

Will the spec be flexible about that? I mean, checking them only if 
they are present?

To recap, say mail.example.com hosts mail services for example.org and 
example.net. Assume its certificate may have SAN fields for any of the 
following:

* otherName dNSName mail.example.com
* iPAddress 192.0.2.3
* otherName srvName _imap.example.org
* otherName srvName _imap.example.net
* rfc822Name [email-masked]
* rfc822Name [email-masked]

The question is whether a suitable tradeoff among interoperability, 
compartmentalization, and other security issues may be obtained by 
tailoring those SAN fields, even without Server Name Indication. To 
complete the example, also assume the following RRs are set, and 
obtainable by regular DNS over UDP queries.

mail.example.com IN A 192.0.2.3
mail.example.net IN A 192.0.2.3
3.2.0.192.in-addr.arpa IN CNAME 3.0-24.2.0.192.in-addr.arpa
0-24.2.0.192.in-addr.arpa IN NS ns.example.com
3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.com
3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.net

_imap._tcp.example.org IN SRV 0 0 143 mail.example.com
_imap._tcp.example.net IN SRV 0 0 143 mail.example.net

example.com IN MX 0 mail.example.com
example.org IN MX 0 mail.example.com
example.net IN MX 0 mail.example.com

Note that example.org is served by an host in a different domain zone. 
However, as far as DNS queries can be trusted, the client can check 
that example.com is compatible with example.org (because they share a 
primary MX.) If [email-masked] is included in the certificate, 
the client may trust that the signing CA had verified who got mail for 
it, and consider that as corroborating the value of the SRV RR. Am I 
missing something?

IMHO, any MUST/MUST NOT in the spec should only prevent cases where 
phishing can actually be operated, so as not to standardize ill 
defined practices. I would suggest that the spec exemplifies, in an 
appendix, various cases of DNS and certificate settings, telling in 
what cases the client should trust the info, ask confirmation, or 
strongly discourage the user. The spec may also suggest that (in some 
cases) challenge/response authentication takes place even if the 
channel is crypted, to avoid phishing.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 25 Aug 2009 09:59:00 -0400

> Will the spec be flexible about that? I mean, checking them only if 

Sure, why not?

> * rfc822Name [email-masked]

For the purposes of this draft, I think you just need:

	dNSName mail.example.com
	otherName SRVName _imap.example.org
	otherName SRVName _imap.example.net

and to include Cyrus's proposal of SRV query names in dNSName:

	dNSName mail.example.com
	dNSName _imap._tcp.example.org
	dNSName _imap._tcp.example.net
	otherName SRVName _imap.example.org
	otherName SRVName _imap.example.net

Clients that don't understand this draft would presumably be
hardcoded with the server name (mail.example.com) and would look
for that identity in dNSName (or perhaps common name). Clients
that understand this draft would look for the otherName/SRVName 
corresponding to the service they are using (example.org or 
example.net) and failing that, look for the full SRV query name
string in dNSName.

There should probably be a separate draft about the non-submission 
SMTP mail delivery and MX records cases. This draft only addresses
submission which doesn't use MX records as far as I know.

--Shumon.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Aug 2009 15:19:38 +0100

>submission which doesn't use MX records as far as I know.
Can you elaborate on why you think this separate draft is needed?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Aug 2009 16:42:30 +0200

Alexey,

> Can you elaborate on why you think this separate draft is needed?

I understood Shumon's wording as a kind way to tell me that the MX 
records and related considerations that I wrote upthread have nothing 
to do with the draft at hand. I haven't object, because the view he 
has portrayed doesn't comprehend matching the host name returned in 
the SRV record and the original service domain that was queried. I 
have introduced MX considerations in an attempt to establish an 
alternative requirement than mandating obscure matching of domain 
names in the absence of DNSSEC.

Shumon will contradict me if I misunderstood him.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 25 Aug 2009 10:45:49 -0400

> Can you elaborate on why you think this separate draft is needed?

Actually I think Alessandro brought up MX records in the tail
end of his message, but I might have misunderstood what he was
saying ..

At any rate, I think there is a problem that needs to be addressed.
Say an MTA is delivering mail to [email-masked] using STARTTLS, 
and the relevant MX record is:

Which identity should it expect to see in the presented certificate?

RFC 3207 says only:

   -  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.

If that means the hostname of the server (eg. mail.example.com) then
it's the same problem: you are susceptible to a DNS spoofing attack. 
And I think the majority of SMTP servers that support STARTTLS are 
configured today with certs corresponding to their hostnames.

--Shumon.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Aug 2009 21:58:30 +0100

>	otherName SRVName _imap.example.net
Agreed.

>example.net) and failing that, look for the full SRV query name
dNSName _imap._tcp.example.org/_imap._tcp.example.net looks like a 
misuse of dNSName.
I would ask the Security Area Directors about whether this is Ok.

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Aug 2009 14:28:49 +0100

> configured today with certs corresponding to their hostnames.

That's true for submission servers, but less than 10% of MXs that support
STARTTLS have valid certificates. A very large proportion of them have the
wrong subject name.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Note there are at least four names that are configured separately and
which are relevant to MX server authentication: the mail domain; the
target name of the MX record; the server's canonical name (e.g. as in
reverse DNS); and the MTA's configured host name.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 26 Aug 2009 20:51:12 -0400

> http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Interesting data. It appears that most people are using this
effectively as an anonymous encryption channel.

> reverse DNS); and the MTA's configured host name.

So, which should be used as the certificate identity? I don't
think either the MX target or the mail domain in dNSName or
common name is good enough, for reasons already outlined in this
thread. I'd like to see the IETF specify the use of application
or service-specific identities in all protocols.

I also think a point needs to be made about DNSSEC. Many specs
are saying that a resolved DNS name is not an acceptably secure
identity because of insecure DNS. The implication to be drawn
is that the deployment of DNSSEC will take care of this problem
and allow such identities to be used. But how does an application
know that DNSSEC is being used? It would probably need to be
using a DNSSEC aware name resolution API that indicated that 
the queried data was successfully authenticated with DNSSEC.
Those things don't really exist yet (although there are some
early drafts on the topic), despite some early deployment of
DNSSEC.

--Shumon.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Aug 2009 12:13:33 +0400

> or service-specific identities in all protocols.

+1. I'd state the objective as follows:

Certificates should carry enough information to

1. confirm the identity of the host and/or accountable domain,
    thereby clearing any mistrust about DNS, and
2. confirm the service(s) that the certificate is meant to be
    valid for.

That way compartmentalization is a decision made by the 
certificate requester, and applications may act appropriately.

In order to avoid creating an ad-hoc OID, SRVNames could be used 
to indicate the service, regardless of whether they correspond 
to actual RRs. No SRVName would imply any service; otherwise, 
only services explicitly mentioned in the certificate. Some of 
these names, including _imap, _pop3, _submit, are specified in 
the draft. What about the other ones? What difference makes the 
FQDN of a service, e.g. _mail vs _mail.example.com (claim of RR 
existence?)

I guess many of the misconfiguration issues that Tony referred 
stem from lack of simple but detailed instructions and examples.