Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Apr 2012 17:14:15 +0100

This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
background on AppsDir, please see
<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Although Murray Kucherawy has already reviewed this I-D on behalf of
the AppsDir, folks in the Applications Area realize that wide
deployment of the TLSA Resource Record might have a significant impact
on applications, so we are performing additional reviews. Please treat
these comments just as you would any other Last Call feedback.

Document: draft-ietf-dane-protocol
Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
for Transport Layer Security (TLS)"
Reviewer: Peter Saint-Andre
Review Date: 2012-04-24
IETF Last Call Date: 2012-04-25
IESG Telechat: not yet scheduled

Summary: This draft is almost ready for publication as an Standards
Track RFC but has a few issues that should be fixed before publication.

Major Issue: none, although a) I am agreeing with Peter Saint-Andre's 
major issue and b) I would like to see a reply to my minor issues

Minor Issues:

2.2.  TLSA RR Presentation Format

    The presentation format of the RDATA portion is as follows:

Presentation for what purpose? In management UIs? Is this a required 
presentation format for DNS tools that can retrieve and update TLSA records?

  [...]

    o  The certificate association data field MUST be represented as a
       string of hexadecimal characters.  Whitespace is allowed within
       the string of hexadecimal characters.

Please define what you mean by whitespace here? CR & LFs allowed?
Examples in the Section 2.3 seem to suggest that.

3.  Domain Names for TLS Certificate Associations

    2.  The protocol name of the transport on which a TLS-based service
        is assumed to exist is prepended with an underscore character
        ("_") to become the second left-most label in the prepared domain
        name.  The transport names defined for this protocol are "tcp",
        "udp" and "sctp".

DCCP? Should there be a registry?

4.  Use of TLSA Records in TLS

    Section 2.1 of this document defines the mandatory matching rules for
    the data from the TLSA certificate associations and the certificates
    received from the TLS server.

    The TLS session that is to be set up MUST be for the specific port
    number and transport name that was given in the TLSA query.

So this will not work for any type of DNS indirection mechanism, such as 
MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec?

Nits:

4.  Use of TLSA Records in TLS

    If a TLSA record has usage type 2 for the certifcate, the

typo: certificate

    corresponding TLS server SHOULD send the certificate that is
    referenced just like it currently sends intermediate certificates.

    If an application receives zero usable certificate associations from
    a DNS request or from its cache, it processes TLS in the normal
    fashion without any input from the TLSA records.

Just to double check: if TLS client receives some TLSA records, but none
of them are usable, is this considered to be the above case?

    If an application
    receives one or more usable certificate associations, it attempts to
    match each certificate association with the TLS server's end entity
    certificate until a successful match is found.  During the TLS
    handshake, if none of the certificate associations matches the
    certificate given by the TLS server, the TLS client MUST abort the
    handshake.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Apr 2012 17:17:30 +0100

> Reviewer: Peter Saint-Andre
And now I even pretend to be Peter ;-).

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Apr 2012 10:19:55 -0600

> And now I even pretend to be Peter ;-).

Heh. :)

Alexey, overnight I realized that this document doesn't say anything
about internationalized domain names (in fact, it doesn't cite any
documents about the definition of "DNS domain name"). So I think at the
least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125.

Peter

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Apr 2012 18:30:59 +1000

> presentation format for DNS tools that can retrieve and update TLSA records?

DNS management tools could get away with using RFC 3597.
 
> Examples in the Section 2.3 seem to suggest that.

They are allowed. See RFC 1035, Section 5.1.

( )             Parentheses are used to group data that crosses a line
                boundary.  In effect, line terminations are not
                recognized within parentheses.

> MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec?

NAPTR, SRV, MX, CNAME, DNAME all potentially change/define the
expected name.  Whether they do or not is protocol specific not
record specific.  If the record changes/defines the expected name
then the record should be signed or one is vulnerable to DNS based
attacks.

NAPTR, SRV, MX, CNAME, DNAME can be encountered when trying to
determine the TLSA's lookup name.

CNAME and DNAME can also be encountered as part of the TLSA lookup
itself.  In the case the CNAME / DNAME MUST be signed or you can't
trust the TLSA.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Apr 2012 17:09:51 -0700

On Apr 24, 2012, at 9:14 AM, Alexey Melnikov wrote:

> Major Issue: none, although a) I am agreeing with Peter Saint-Andre's major issue and b) I would like to see a reply to my minor issues

Here you go.

> Presentation for what purpose? In management UIs? Is this a required presentation format for DNS tools that can retrieve and update TLSA records?

Added a pointer to RFC 1035.

> Examples in the Section 2.3 seem to suggest that.

Should be covered by the (new) reference to RFC 1035.

> DCCP?

No.

> Should there be a registry?

Seems like overkill for how rarely new popular transports get added. Such a transport is going to need to have an RFC for this anyway.

> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

Correct.

> Or does DNS retrieval of such records also requires DNSSec?

Undefined, as the draft says.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Apr 2012 09:57:00 -0400 (EDT)

>> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

I'm a little confused here. If I have:

example.com IN MX 5 mail.example.com
mail.example.com IN TLSA [....]

That should still work right? When you do the lookup for
mail.example.com's A or AAAA record, you also lookup the TLSA/HASTLS
record for _25._tcp.mail.example.com ?

If mail.example.com is a CNAME, I understand there are some indirections
at play (though it might be technically incorrect to point an MX to a
CNAME)

Paul

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Apr 2012 23:40:59 +0100

Hi Paul,

> Should be covered by the (new) reference to RFC 1035.

We shall see ;)
>>      name.  The transport names defined for this protocol are "tcp",

Why not?
> Seems like overkill for how rarely new popular transports get added. Such a transport is going to need to have an RFC for this anyway.

I don't see a point though, unless the new transport doesn't use ports.
But anyway, I am sure that you can just piggyback on an existing registry.
>> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

How?

Best Regards,
Alexey

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Apr 2012 16:55:09 -0700

> Why not?

Because DCCP is a thinly-used protocol that nearly no one in this WG has experience with. What's the chance we will get inclusion of it correct? It would be better to have someone write a DCCP-specific update that covers the topic well.

>>> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

How will it not work? Quite well, I expect. :-)

This was discussed extensively on the list, and the WG decided that indirection mechanisms need to define the relationship between the name used in the lookup and certificate association from DANE TLS. There is text about this in the document, and more going in the next draft at the request of Peter St. Andre. The experience with RFC 6125 pretty much assures that any generic solution will not be interoperable and might cause security problems based on false matches, and we wanted to avoid that.

--Paul Hoffman

---

From: James Cloos <[email-masked]>
Date: Sat, 28 Apr 2012 20:19:22 -0400

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> Because DCCP is a thinly-used protocol that nearly no one in this WG
PH> has experience with. What's the chance we will get inclusion of it
PH> correct? It would be better to have someone write a DCCP-specific
PH> update that covers the topic well.

What is there to get wrong?  For SRV, rfc-2782 says:

   Proto
        The symbolic name of the desired protocol, with an underscore
        (_) prepended to prevent collisions with DNS labels that occur
        in nature.  _TCP and _UDP are at present the most useful values
        for this field, though any name defined by Assigned Numbers or
        locally may be used (as for Service).  The Proto is case
        insensitive.

and that is the type of language TLSA should use for the proto.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Apr 2012 11:42:15 +0100

> Because DCCP is a thinly-used protocol that nearly no one in this WG has experience with. What's the chance we will get inclusion of it correct? It would be better to have someone write a DCCP-spec…

I think this requires inserting 2 words. But Transport ADs will get on your case if they care.
> How will it not work? Quite well, I expect. :-)

Sorry, missed "not" in my own earlier email ;).

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Apr 2012 06:58:50 -0700

> I think this requires inserting 2 words. But Transport ADs will get on your case if they care.

If the Transport ADs care and are willing to say "the spec doesn't need to know anything about DCCP, just add it", I suspect the WG would be happy to add it. (We're happy to hear from them now, before we do the final draft before IESG review, of course.)

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Apr 2012 16:28:18 -0700

On Apr 29, 2012, at 4:09 PM, John Gilmore wrote:

> TLSA is expected to work with TLS-based services reached via MX
> records, as well as with services that use TLS which are reached via
> SRV records.

You may have missed the earlier discussion of this topic, and the fact that the topic was closed with a result different than what you say here. Please see <http://trac.tools.ietf.org/wg/dane/trac/ticket/28>.

If the WG chairs think that Jakob and I have not reflected the WG consensus from that issue in the document, we are happy to update the document yet again.

--Paul Hoffman

---

From: John Gilmore <[email-masked]>
Date: Sun, 29 Apr 2012 16:09:11 -0700

There has been a lot of confused and/or confusing discussion that
started from this unclear question.  ("This will not work...?" -- what
is "this"?  And why in specific do you think it will or won't work?)

I suggest that to eliminate the confusion, we start over with a
clearer question.  Give us a concrete example and ask if it will work.
If the draft doesn't already answer the question, we can fix the draft
so it will.

So, for example, to secure STARTTLS in SMTP, you'd use:

toad.com.		MX	150 new.toad.com.
_25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...
new.toad.com.		A	209.237.225.253
new.toad.com.		AAAA	2607:f3a0:17::2

	John

PS: While I think our document should be readable by people without
deep knowledge (and thus I've contributed a bunch of introductory
text), I'm dismayed to see IETF "Director" reviews that betray
ignorance of very basic concepts around the Domain Name System,
such as presentation formats of resource records, or A and AAAA records.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Apr 2012 09:58:01 +1000

> new.toad.com.		AAAA	2607:f3a0:17::2

Part of the problem is that there is at least two models "STARTTLS
in SMTP" and "HTTPS".  With "STARTTLS in SMTP" the MX record (implicit
or explicit) defines the expected certificate name.  With "HTTPS"
the user input/href defines the expected certificate name even if you
encounter a CNAME record.

Add a CNAME to your example and it become decidedly less clear which
name to expect in the certificate (mail.toad.com or new.toad.com
or either).  i.e. does the CNAME change the expected certificate
name or not?  We have don't have a clear answer to this in the
current RFCs a far as I am aware.

toad.com.		MX	150 mail.toad.com.
mail.toad.com.		CNAME	new.toad.com.
new.toad.com.		A	209.237.225.253
new.toad.com.		AAAA	2607:f3a0:17::2

Which TLSA record does the client MTA lookup?

_25._tcp.mail.toad.com.	TLSA	...(a key or certificate for mail.toad.com)...

or

Then there are CNAMEs when looking up the TLSA record itself.

_25._tcp.new.toad.com.  CNAME   cane.toad.com.
cane.toad.com		TLSA	.....

Mark

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 30 Apr 2012 03:16:41 +0200

> mail.toad.com.		CNAME	new.toad.com.

Mark, I must admit I do not remember what your personal view is on MX->CNAME chains, but I am a strong believer in that this is something that is not accepted. Yes, I know for example sendmail and possibly other implementations do handle MX->CNAME constructions, but recommendations are to not construct the namespace like this. MX target should be an address record. Just like NS targets.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Sun, 29 Apr 2012 18:33:50 -0700

>such as presentation formats of resource records, or A and AAAA records.

Application Area Directorate reviews are informal; they do not bear 
more weight than a comment submitted by an individual during a Last Call.

The reviewer who commented on draft-ietf-dane-protocol-19 on behalf 
of the Applications Area Directorate must have understood the 
concepts around the Domain Name System as STD 13 is a normative 
reference in the draft.

That does not mean that the reviews should be considered as 
flawless.  The reviews are posted to [email-masked], which is 
open to everyone, so that anyone can read and discuss about them.

Regards,
S. Moonesamy

---

From: John Gilmore <[email-masked]>
Date: Sun, 29 Apr 2012 20:16:15 -0700

[Does this discussion really need to be cc'd to apps-discuss and iesg?
 I am keeping the distribution as it was, but I suggest cutting it
 back to just "dane".  --gnu]

> You may have missed the earlier discussion of this topic, and the fact that the topic was closed with a result different than what you say here. Please see <http://trac.tools.ietf.org/wg/dane/trac/…

I looked at Ticket 28 and it is not clear to me what the resolution is.
Its resolution was:  

  "use the first name that has a TLSA record, unless there is a
  protocol specific exception"

I don't know what that means in the context of MX nor SRV.  Does that
mean that SRV will work, that SRV will fail, or does it mean something
else entirely?  If it means something else entirely, then it does not
contradict my statement that TLSA is expected to work with SRV.

It is not clear to me what is the "first name" in the above statement,
nor what other names are potentially in line behind it.  The phrase
"first name that has a TLSA record" seems to imply iteration through a
series of names until a TLSA record is found.  I could imagine that it
means, in the context of MX for example, if mail is sent to
[email-masked] and example.com has an MX to mailserver.example.com,
then you would look for TLSA records "first" at example.com and
"second" at mailserver.example.com and "third" at nowhere else (you'd
decide that there are no TLSA records).  But this is not actually
specified anywhere in the ticket.

So I looked in Draft 20, and I don't see anything that says "MX and
SRV WILL NOT work with TLSA".  Nor do I see anything that says "MX and
SRV WILL work with TLSA".  I don't even see a statement that clients
should "use the first name that has a TLSA record" as recorded in
ticket 28.  Section 4, "Use of TLSA Records in TLS" just says to look
in Section 2.1 for the "mandatory matching rules".  But Section 2.1
mentions nothing about matching NAMES; it is all about matching
certificates, hashes, and keys.  Section 3, "Domain Names for TLSA
Certificate Associations", step 3, just says "The domain name is
appended" without saying WHICH domain name is appended.  So the draft
is unclear.

In the absence of any explicit statement, I apply my experience.
First, MX and SRV appear to me to be different issues.  There seems to
be a consensus among recent discussions on the mailing list that MX
should work without trouble.  Numerous people have posted example sets
of DNS records that the posters believe would work, and there were no
counterexamples other than some byplay about CNAMEs.  There is even an
example TLSA record for SMTP email delivery in Draft 20.

There is an issue about what name should be in the TLS server's
end-user certificate when using a service that has DNS records that
provide one or more domain names of servers which handle that service.
In what follows I call the original name the "service name",
e.g. "example.com", and the names of servers who provide that service
the "server names", e.g. mailserver.example.com.  Does the TLS client
demand a certificate that includes the service's name, or the server's
name?  (Or perhaps it accepts either one, or perhaps requires that both
be included in the certificate)?

Every working TLS implmentation has already solved this issue.  It
doesn't relate to TLSA records or the DANE protocol at all.  If the
certificate provided by the server doesn't include the name(s) that
the client is expecting to validate, TLS will not work.

I do not personally know whether MX clients expect to see the
service's domain name in the certificate, or the server's.  But I know
that many mail servers currently use STARTTLS and it is widely
interoperable with many clients, so the answer is easy to come by.

DANE does introduce an additional issue about what name should be
looked up in the DNS when seeking a TLSA record.  Does the client look
for a TLSA record at _port._tcp.service.name or at
_port._tcp.server.name?  Or does it look at both of them, and if so,
in what order?

The draft does not specify this, perhaps as a result of an inability
to decide, which was codified in the inscrutable resolution of Ticket
28.  However, draft 20 does provide an illuminating example in the
last sentence of section 3:

   To request a TLSA resource record for an SMTP server running the
   STARTTLS protocol on port 25 at "mail.example.com",
   "_25._tcp.mail.example.com" is used.

This example does not match what Ticket 28 seems to say, since
it provides no iteration, nor is the name of the SMTP server likely
to come to the implementer's mind as the "first name".

If it turns out that in the absence of specifying this, there is a
diversity of client implementations, then at worst, when using a
protocol that uses SRV, a server administrator could provide TLSA
records at both the service name and the server name.

This reasoning is why I stated that TLSA is expected to work with
services that use MX and SRV records.

I'm happy for someone to clarify why this won't work, or to refute
some other part of my chain of reasoning.

> If the WG chairs think that Jakob and I have not reflected the WG
> consensus from that issue in the document, we are happy to update
> the document yet again.

I am not a chair, but I don't think Draft 20 is clear about this.

I'd alter section 3, step 3, and add a paragraph below it:

   3.   A domain name is appended to the result of step 2 to produce
	a prefixed domain name.

   When a client is making domain name queries in search of TLSA
   records, it should form a name by appending the first domain name
   provided to it, and make its first query.  If it does not find a
   TLSA record there, it should form a name from the server name which
   it is in the process of contacting (for example, the name of one of
   the servers supplied in MX or SRV records), and seek a TLSA record
   from that server name.

This seems to faithfully reproduce the clear-as-mud description in
Ticket #28.  

However, this results in some semantic confusion, because the prefixed
domain name includes a port number for a specific server, yet a suffix
that is not related to that server.  For example, we'd first look up
_25._tcp.example.com while negotiating TLS to deliver mail on port 25
to mailserver.example.com for [email-masked].  But there may be some
completely different service running on port 25 of HOST "example.com",
if example.com actually has an IP address.  (This is even more
confusing for SRV records, which can specify arbitrary port numbers,
which might be more likely to be reused for different protocols on
different machines.)

Also, if there were four MX records for a domain, the client should
not look up a TLSA record for the main domain, then look up a TLSA
record for the first MX server, then look up a TLSA record for the
second MX server.  These lookups happen only in a context of trying to
negotiate TLS with a *specific* server.  When trying to negotiate TLS
with the first server, it should not be looking for TLSA records that
relate to the second server; it should restrict itself to only looking
up the particular server's name that it is talking to (and/or the name
of the original main domain).

I would be much happier if someone who actually knew what the alleged
consensus is would write this update.

	John

---

From: Ned Freed <[email-masked]>
Date: Sun, 29 Apr 2012 22:42:47 -0700 (PDT)

> Which TLSA record does the client MTA lookup?

I'm taking no position on TLSA here, but FWIW, it actually isn't clear what
host the client should connect to in this case, or that this is not in fact a
DNS configuration error.

RFC 974 recommended that CNAMEs not be allowed as MX targets. (See the section
on "Minor Special Issues" for details.) I believe RFC 2821 was silent on the
issue, but the current specification, RFC 5321, has this to say:

   When a domain name associated with an MX RR is looked up and the
   associated data field obtained, the data field of that response MUST
   contain a domain name.  That domain name, when queried, MUST return
   at least one address record (e.g., A or AAAA RR) that gives the IP
   address of the SMTP server to which the message should be directed.
   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.
   The prohibition on labels in the data that resolve to CNAMEs is
   discussed in more detail in RFC 2181, Section 10.3 [38].

My understanding of the reasoning behind this is that we would prefer to ban
CNAMEs in the context for the reasons given in RFC 2181, but since a lot of
software uses A/AAAA record resolvers that support aliasing that cannot be
disabled, this is where things ended up.

Also FWIW, what existing software that suports STARTTLS seems do is  check the
domain in the certificate against the host name in the MX record that was
used to connect to the current host. At least that's been my experience.

				Ned

---

From: SM <[email-masked]>
Date: Mon, 30 Apr 2012 01:23:25 -0700

>Part of the problem is that there is at least two models "STARTTLS

Yes.

>current RFCs a far as I am aware.

Section 5.1 of RFC 5321 mentions that MX RRs with a CNAME in the 
R.H.S is out of scope.

It seems that the main question here is about DNS indirection.  Paul 
Hoffman clarified that ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05419.html ).

Section 2 of -20 mentions that:

   'The TLSA DNS resource record (RR) is used to associate a TLS server
    certificate or public key with the domain name where the record is
    found, thus forming a "TLS certificate association".'

Section 3 mentions that:

   'Unless there is a protocol-specific specification that is different
    than this one, TLSA resource records are stored at a prefixed DNS
    domain name.'

Given that HTTPS and STARTTLS is mentioned in the document by 
example, it looks like the specification should be applicable as-is 
for these protocols.  Using www.apple.com as an example for HTTPS:

;; QUESTION SECTION:
;www.apple.com.                 IN      A

;; ANSWER SECTION:
www.apple.com.          1800    IN      CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 60 IN     CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 18278 IN     CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 20      IN      A       184.30.253.15

I assume that the TLS-based service is at e3191.c.akamaiedge.net.  As 
there is a CN-ID (the back-compatibility clause in RFC 6125) of 
www.apple.com, it should be possible to derive a certification association.

Using universalmusic.com and microsoft.com as examples for STARTTLS:

;; QUESTION SECTION:
;universalmusic.com.            IN      MX

;; ANSWER SECTION:
universalmusic.com.     3600    IN      MX      10 mail.global.frontbridge.com.

;; QUESTION SECTION:
;microsoft.com.                 IN      MX

;; ANSWER SECTION:
microsoft.com.          3600    IN      MX      10 
mail.messaging.microsoft.com.

It is not possible to come up with a certificate association in the 
second case.  My reading of prepared DNS domain name in Section 3 of 
draft-ietf-dane-protocol-20 is that it is akin to derived domains in 
RFC 6125.  I encourage the authors of that RFC to correct me as I 
might be doing an egregious extrapolation of the intent of the text.

There is a note in Section 1.3 of the draft as follows:

   "Note that this document does not cover how to associate certificates
    with domain names for application protocols that depend on SRV, NAPTR,
    and similar DNS resource records; it is expected that later updates
    to this document might cover methods for making those associations."

I don't see much difference between SRV and MX in terms of locating a 
service through DNS.

In Section 8:

   "A DNS administrator who goes rogue and changes both the A, AAAA,
    and/or TLSA records for a domain name can cause the user to go to an
    unauthorized server that will appear authorized, unless the client
    performs PKIX certification path validation and rejects the
    certificate."

Does the above also cover a change in CNAME?

BTW, there are a few typos (certifcate).

Regards,
-sm

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 04:40:33 -0400

John's post exactly illustrates why I've been advocating always doing
TLSA lookups for the port and name for which the client is making an
A/AAAA or PTR lookup¹.  Ie, from the results of the NAPTR, SRV and/or MX.

Except only for cases which /explicitly/ specify different behaviour. :)

RFC 3923 says that XMPP -- the oft-cited counter example -- requires
certs to have subjectAltName values which look like email addresses,
rather than like host names.  XMPP, therefore, isn't actually relevant
to draft-ietf-dane-protocol, but rather to the forthcoming draft about
public key data for TLS client certs.

The exceptions should be few and far-between.  And they should require
their own rfc referencing and modifying TLSA for their own needs.

1]  If an address rather than a name is supplied, one must choose between
    doing a PTR to get a name and a TLSA on that name to get the cert
    info, or doing a TLSA on the address.  Either way, one shoudl expect
    the cert to have a CN and/or subjectAltName which matches the name
    returned by the PTR lookup.

-JimC

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Apr 2012 11:44:11 +0100

> interoperable with many clients, so the answer is easy to come by.

There is currently no certificate verification on inter-domain SMTP.
Most MXs present unverifiable certificates.

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

In order to add authenticated TLS to SMTP we need some extra signalling so
that an MX can say, "not only am I offering STARTTLS, but also I promise
to present a valid certificate!"

> _port._tcp.server.name?

I believe the consensus (at least for SMTP) is for the latter. Otherwise
it becomes really hard to support virtual domains, expecially since a
single transaction can transfer a message to recipients at
multiple domains.

More generally, RFC 6125 describes the framework for what identity should
be authenticated by a certificate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Northeast 5 or 6, becoming variable 4.
Moderate. Occasional rain then fair. Moderate or good.

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Apr 2012 15:53:37 +0200 (MEST)

> >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

In many protocols, those indirections create a security problem.
So each and every such protocol should be forced to resolve that
security problem itself.

> new.toad.com.		AAAA	2607:f3a0:17::2

When trying to deliver mail to @toad.com, the only secure
question to ask is whether the server is authorized to process
Email for @toad.com.  For certificates issued from the traditional
PKIX world, that would require a "toad.com" DNSName SAN.

The only reasonable TLSA lookup would be

_25._tcp.toad.com    TLSA   ....

and DANE only checks the DNSSEC properties of that TLSA lookup.

The security properties of any MX, CNAME, A or AAAA lookups during
connection establishment with that server are irrelevant for DANE
(and invisible to PKIX).

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Apr 2012 07:22:53 -0700

On 4/30/12 1:40 AM, James Cloos wrote:
> John's post exactly illustrates why I've been advocating always
> doing TLSA lookups for the port and name for which the client is
> making an A/AAAA or PTR lookup¹.  Ie, from the results of the
> NAPTR, SRV and/or MX.
> 
> RFC 3923 says that XMPP -- the oft-cited counter example --
> requires certs to have subjectAltName values which look like email
> addresses, rather than like host names.  XMPP, therefore, isn't
> actually relevant to draft-ietf-dane-protocol, but rather to the
> forthcoming draft about public key data for TLS client certs.

That's because RFC 3923 is about client-to-client (end-to-end)
encryption, so the certificates used in that context contain
subjectAltName values of the form user@host. See Section 13.7.1.2.1 of
RFC 6120 for the most up-to-date XMPP-specific rules about server
certificates (where the subjectAltName values are domain names).

Peter

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Apr 2012 15:32:20 +0100

> PKIX world, that would require a "toad.com" DNSName SAN.

That is not the only answer if the MX lookup is secured with DNSSEC.

> connection establishment with that server are irrelevant for DANE

RFC 6125 allows for secure name indirections.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Southwesterly 4 or 5, increasing 6 or 7 for a time.
Moderate or rough. Occasional rain. Moderate or good.

---

From: Matt Miller <[email-masked]>
Date: Mon, 30 Apr 2012 08:36:22 -0600

> public key data for TLS client certs.

You are correct that RFC 3923 not relevant to the current discussion; it only covers end-to-end object encryption (read: between clients), not TLS.

However, 6120 does talk about server certificate expectations with regards to TLS; the xmppAddr looks like a host name then. See RFC 6120, sections 13.7.1.2 and 13.7.2.1 more details.

>    returned by the PTR lookup.

For XMPP, this is not true, and why Peter and I are working on an XMPP-specific proposal.

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

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Apr 2012 16:46:17 +0200 (MEST)

> That is not the only answer if the MX lookup is secured with DNSSEC.

Think of DANE as something that works (or is supposed to work) similar
to PKIX.  How and whether other parts of the software perform fancy
indirections through DNS or otherwise, and how and whether those are
secure, is not visible to the DANE module (neither to PKIX) and
should therefore not be relevant for either.  Doing otherwise is
calling for _real_ trouble.

DNS allows for some pretty fancy indirections, and trying to ensure
that *ALL* of those are secure (in particular since they happen in
software modules completely distinct from DANE) and trying to
describe the resulting implications (and dangers) to DNS admins
is IMHO bound to fail badly.

> RFC 6125 allows for secure name indirections.

Which _secure_ name indirections are you thinking of?

-Martin

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Apr 2012 15:52:42 +0100

> Which _secure_ name indirections are you thinking of?

RFC 6125 says:

   The client might need to extract the source domain and application
   service type from the input(s) it has received.  The extracted data
   MUST include only information that can be securely parsed out of the
   inputs (e.g., parsing the fully qualified DNS domain name out of the
   "host" component (or its equivalent) of a URI or deriving the
   application service type from the scheme of a URI) or information
   that is derived in a manner not subject to subversion by network
   attackers (e.g., pulling the data from a delegated domain that is
   explicitly established via client or system configuration, resolving
   the data via [DNSSEC], or obtaining the data from a third-party
   domain mapping service in which a human user has explicitly placed
   trust and with which the client communicates over a connection or
   association that provides both mutual authentication and integrity
   checking).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Bailey, Fair Isle, Faeroes: Variable 3 or 4, becoming southwesterly 5
later in north Bailey and Faeroes. Slight or moderate. Occasional rain.
Moderate or good.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Apr 2012 10:15:39 -0400

On Apr 29, 2012, at 7:28 PM, Paul Hoffman wrote:

> If the WG chairs think that Jakob and I have not reflected the WG consensus from that issue in the document,

Nope -- the chairs believe that WG consensus has been captured and reflected in the document…

The XMPP people have already agreed to do the initial work for the XMPP protocol, and others can leverage their work after it is finished.
Different protocols have different expectations / requirements, and so we will need differnt means of dealing with them ("How to do DANE with protocol foo" type documents…)

W

> we are happy to update the document yet again.
> 
> --Paul Hoffman
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Apr 2012 17:37:19 +0200 (MEST)

>    association that provides both mutual authentication and integrity

One should not confuse DNSSEC protection of DNS records (which provide
only data integrity and data origin authentication) with the concept
of a secure directory service providing name translations.

Sprinkling security equally across all DNS records also seems like
a bad idea.  I think it would be much more sensible to limit the
security-relevant DNS records (and indirections allowed for them)
to _very_ few records, and preferably all _new_ records, because
DNSSEC-less zones will be with us for many years to come, and

I believe it would be a really bad idea to change the sensitivity
of existing DNS records underneath DNS registrar's feet.

For TLSA records it would be OK if DNS software (and DNS servers)
performed some plausibility checks, e.g. warn prominently if TLSA
records are present in a Zone but no DNSSEC is active for the zone.
Something which does not make sense for any of the traditional
DNS records.

> universalmusic.com.  3600 IN  MX   10 mail.global.frontbridge.com.

For regular DANE, it is sufficient if (but also necessary that)
the DNS-Domain "universalmusic.com" has DNSSEC active in order to
securely provide a TLSA record for

_25._tcp.universalmusic.com.

and simultaneously independent from the DNSSEC status of frontbridge.com.

If you want to allow DNS-based indirection, and in particular on existing
DNS records, then you would have to enforce that *ALL* domains that
are traversed during all possible DNS indirections have DNSSEC active
and that all lookups are verified, and require that the SMTP-software
aborts if DNSSEC verification of one of the indirections fails or
is not possible, and it may be difficult to impossible for the DNS-Software
(maintenance tools and DNS-Server) to help you maintaining consistency
across all those possible indirections, and close to impossible for the
DNS admins to understand the implications.

-Martin

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 11:51:26 -0400

>>>>> "PF" == Patrik Fältström <[email-masked]> writes:

>> mail.toad.com.		CNAME	new.toad.com.

PF> Mark, I must admit I do not remember what your personal view is on
PF> MX -> CNAME chains, but I am a strong believer in that this is
PF> something that is not accepted.

There is no technical reason to avoid it.  The SMTP app does an MX
lookup and receives a name.  It then does an A and/or AAAA lookup
on that name to get an address.  If that name is handled by way of
a CNAME RR, the resolving DNS server transparently follows it; the
SMTP app doesn't see the CNAME RR, and therefor cannot be harmed
by its existance.

-JimC

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Apr 2012 17:27:43 +0100

Martin Rex <[email-masked]> wrote:
> and that all lookups are verified,

Right.

> and require that the SMTP-software aborts if DNSSEC verification of one
> of the indirections fails or is not possible,

Yes if you get a "bogus" result; if it's just insecure then it should fall
back to insecure SMTP (perhaps with unauthenticated TLS) as at present.

> and it may be difficult to impossible for the DNS-Software (maintenance
> tools and DNS-Server) to help you maintaining consistency across all
> those possible indirections, and close to impossible for the DNS admins
> to understand the implications.

That's an argument for putting the TLSA record alongside the server host
name, so that a certificate update only needs to be reflected in the DNS
in one place rather than at all the innumerable virtual domains hosted by
that server.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: Cyclonic, becoming easterly or northeasterly for a time,
6 to gale 8, decreasing 4 or 5 later in east Sole. Moderate or rough,
occasionally very rough in Sole. Rain or showers. Moderate or good.

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 09:27:38 -0700 (PDT)

> SMTP app doesn't see the CNAME RR, and therefor cannot be harmed

That's incorrect. See my previous post on this topic for specifics.

				Ned

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 12:21:22 -0400

>>>>> "TF" == Tony Finch <[email-masked]> writes:

TF> There is currently no certificate verification on inter-domain SMTP.
TF> Most MXs present unverifiable certificates.

Some MTAs can be configured for it.  I currently get valid certs on
incoming mail from a number of sites, including debian, python,
gnumonks, google, ozlabs, cisco, cacert, several universites and a
few others.

But it is certainly true that most MXs do not bother to verify, even
when the same org's outgoing MTA's certs are verifiable.

-JimC

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 13:02:13 -0400

>>>>> "NF" == Ned Freed <[email-masked]> writes:

NF> That's incorrect. See my previous post on this topic for specifics.

I don't see any previous post from you???

To which list was it posted?

-JimC

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 13:15:12 -0400

Thanks to Peter and Matt for the references to rfc 6120.

My prior presumptions about how XMPP uses TLS were based solely on posts
here.  Having now read through 6210, though, I see nothing which
contraindicates doing TLSA lookups based on the serv*er* name.

The XMPP app receives a URI.  From that it extracts a name to use in a
SRV lookup.  From the SRV RRs it gets a set of hostname+port tuples.
It then does an A/AAAA lookup on each of the hostnames.

When it does echo A/AAAA lookup it also can do a TLSA lookup using the
hostname+port and the protocol name which it previously used to
construct the SRV lookup.

It doesn't matter that it will look in the cert for the name in the
original URI and not for the resulting hostname.  It still is reasonable
to expect the cert association to be found parallel to the ip address.

Each dns lookup needs to dnsec-verify, of course, but the association
is provable (to the extent that *anything* crypto can be /proven/).

Everything just works.

Some might argue that having to add TLSA RRs for each server is a
hassle, but they already have to add the certs to each server, and
automation to keep everything in sync is not hard.

XMPP doesn't even need its own rfc for DANE, TLSA and 6120 already
cover everything it needs.

-JimC

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Apr 2012 19:43:13 +0200 (MEST)

> back to insecure SMTP (perhaps with unauthenticated TLS) as at present.

Current security with SMTP is completely fubar (.. beyond repair).

First, the SMTP server endpoint identification should be fixed so that
it can be used with both/either (1) PKIX names or (2) DANE.

I believe that it would be a very bad idea to continue ignoring
the lack of authentication in SMTP with STARTTLS or by embracing
a scheme that is much more complex than what is used for HTTPS
by adding all conceivable DNS transformations into the picture,
because neither users nor admins will understand it anymore.

When writing a program for Unix that needs to be setuid for a privileged
operation, then it is extremely sensible to limit the euid to that one
privileged operation only, and carefully check the inputs to that privileged
operation, rather than running with elevated privileges all the time and use
all sorts of fancy features from various complex application libraries.

> in one place rather than at all the innumerable virtual domains hosted by

DNSSEC seems to create a lot of confusion.  The existance of DNS signatures
does not make data any more trustworthy above plain DNS.  It is still the
_same_ data, and usually maintained with the _same_ admin procedures and
the same amount of errors in it.

A goole search result is _not_ any more trustworthy when done through
https:// instead of http://, just less susceptible to third parties
modifying the results when it is transfered between google and your
browser.  The links to which google is pointing are going to be
the exact same (I assume... :).

-Martin

---

From: Matt Miller <[email-masked]>
Date: Mon, 30 Apr 2012 11:46:30 -0600

> cover everything it needs.

I think there might still need to be some explicitness on what name to expect to match on regardless of where the certificate is found, especially with multi-domain XMPP servers (e.g. a server "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and "denmark.shakespeare.lit").

Maybe that doesn't need to be its own document.  I am working on a proposal for improving XMPP federation, and a section in that document might be sufficient...Probably (-:

- m&m

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Apr 2012 11:37:16 -0700

Yes.

> Maybe that doesn't need to be its own document.  

Are you serious!?!?! After the amount of confusing and disagreement we have seen in the past few months on this topic, a stand-alone document that can be referred to easily is exactly what we need.

> I am working on a proposal for improving XMPP federation, and a section in that document might be sufficient...Probably (-:

I'm skeptical, to say the least.

--Paul Hoffman

---

From: Matt Miller <[email-masked]>
Date: Mon, 30 Apr 2012 12:52:59 -0600

> Are you serious!?!?! After the amount of confusing and disagreement we have seen in the past few months on this topic, a stand-alone document that can be referred to easily is exactly what we need.

The preference of having a single document came from the XMPP WG.  I personally am not sure it's the best idea, but I also don't have anything written up yet.  I'm more than willing to fight hard to separate, but I also need to see what it looks like with the rest of XMPP federation stuff.

> I'm skeptical, to say the least.

I did say "might" and "probably" (-:

- m&m

---

From: Dave Cridland <[email-masked]>
Date: Mon, 30 Apr 2012 20:56:19 +0100

> is provable (to the extent that *anything* crypto can be /proven/).

One of the rather jolly things posited by those in the XMPP community  
looking at DANE and similar was that one might solve what's quite a  
tricky problem for larger XMPP services - that of maintaining a cert  
for every domain they host.

For some services (Google is oft-cited here) this is vast numbers,  
and I recall one XSF meeting (in San Diego) where the problems of TLS  
in such an environment where discussed at length.

DANE/TLSA currently makes this more complex by requiring secure name  
redirections throughout the chain; unfortunately, whilst this does  
indeed work in theory, it also provides limited benefit.

In particular, it adds little more than using a perfectly ordinary  
certificate with the server's hostname in does - plus you need to  
ensure that the certificate either contains the right domain/XMPP  
SANs, or else you've used Usage 2/3 TLSA (AKA "Please ignore your PKI  
policy").

Unfortunately, this only works to authenticate the called server -  
the caller cannot use DANE/TLSA to authenticate itself, instead it  
still must present a certificate which identifies itself as the  
domain.

Now one could, I suppose, present a certificate which matched a host,  
and then the callee could perform SRV on the asserted domain, and try  
each record in turn until it found a combination where the hostname  
of the SRV matched a hostname present in the certificate.

This is, as far as I can tell, secure, although exhaustively  
searching just fills me with horror, and this doesn't use TLSA yet -  
including *that* in the mix is even more fun, since it requires a  
TLSA record fetch per SRV record returned - and all the time we're  
effectively ignoring the port. I feel sure there's something nasty  
lurking there, although I can't think what.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Apr 2012 21:28:04 +0100

Dave Cridland <[email-masked]> wrote:
> redirections throughout the chain; unfortunately, whilst this does indeed work
> in theory, it also provides limited benefit.
>
> In particular, it adds little more than using a perfectly ordinary certificate
> with the server's hostname in does - plus you need to ensure that the
> certificate either contains the right domain/XMPP SANs, or else you've used
> Usage 2/3 TLSA (AKA "Please ignore your PKI policy").

Would it make sense to define an alternative virtual-hosting-friendly
authentication scheme that relies on DNSSEC and matches the cert against
the hostname instead of the server domain?

I think something along those lines will be required for SMTP so that
clients know they can expect a valid server certificate.

> Unfortunately, this only works to authenticate the called server - the caller
> cannot use DANE/TLSA to authenticate itself, instead it still must present a
> certificate which identifies itself as the domain.
>
> Now one could, I suppose, present a certificate which matched a host, and then
> the callee could perform SRV on the asserted domain, and try each record in
> turn until it found a combination where the hostname of the SRV matched a
> hostname present in the certificate.
>
> This is, as far as I can tell, secure, although exhaustively searching just
> fills me with horror, and this doesn't use TLSA yet - including *that* in the
> mix is even more fun, since it requires a TLSA record fetch per SRV record
> returned - and all the time we're effectively ignoring the port. I feel sure
> there's something nasty lurking there, although I can't think what.

Surely it isn't that bad: client presents certificate and asserts a
domain; server concurrently looks up SRV of domain and TLSA of all the
host names in the certificate; server checks that at least one SRV target
host name appears in the certificate and has a TLSA that matches. The
"exhausive" search is not much of a search and is not at all taxing, and
you can recommend that deployments arrange that there is one name in the
certificate to minimize the TLSA lookup cost.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Variable 3 or 4, becoming northerly 5
later in North Utsire. Slight, occasionally moderate. Fog patches developing.
Moderate or good, occasionally very poor.

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 13:41:32 -0700 (PDT)

> To which list was it posted?

apps-discuss. Id:  <[email-masked]>

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Apr 2012 21:50:03 +0100

Folks,

I think we may be wandering from the appsdir review of the
DANE draft. If we are, please reduce the cc list to one list,
either apps-discuss (with a different subject probably), or
DANE, or if this is still relevant to the concluded IETF LC
for DANE, then DANE+IESG or [email-masked] is in fact fine.

I intend checking -20 of the DANE draft vs. IETF LC comments
received now and putting it on an IESG telechat if all's well,
so if there remain substantive concerns about progressing
*that document*, you need to make those clear. (For example,
how XMPP uses DANE is not a substantive concern for the DANE
draft IMO, but if you want to, you can make that argument.)
If your mail is about some other thing then please reduce
the cc list and set the subject appropriately.

Thanks,
Stephen.

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 15:07:16 -0700 (PDT)

> for DANE, then DANE+IESG or [email-masked] is in fact fine.

I strongly disagree. This is all in response to the apps area review of a DANE
WG document and in that context it is entirely appropriate to be cc'ing both
the apps area list and the dane list. Indeed, if you fail to do so, your
comments will fail to be read by one constituency or another. It is not
reasonable to expect everyone on the apps area list to subscribe to the DANE
list for this or vice versa.

And yes, this means that some folks will get multiple copies. Life is hard
someitmes; deal with it.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Apr 2012 23:20:41 +0100

> list for this or vice versa.

Fair enough. However, I don't see what potential changes to the
DANE document are being discussed in a bunch of this mail. I do
see people talking about tricky issues with CNAMEs and XMPP
etc. (Changing the subject when appropriate would also be
good.) If people seriously want that kind of text in the DANE
document then they'd presumably start proposing something specific
or else be yelling that DANE needs to be held up for a bit, and
I'm not seeing any of that (in most of the thread).

> And yes, this means that some folks will get multiple copies. Life is hard

Dealing with lots of mail is fine - even I've gotten used to
it:-) Finding the relevant bits of the thread when its wandered
off into how to do XMPP's DNA thing better is harder, hence
my mail.

S.

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 15:41:57 -0700 (PDT)

> I'm not seeing any of that (in most of the thread).

Again, I'm not taking any position on the interaction of TLSA records and
services that use SRV or SRV-like mechanisms. That said, I think most of the
comments are essentially saying that not discussing how TLSA records would
interact with such services at all - even if that discussion is simply to say
that those services need to specify how they are going to use TLSA records - 
is a mistake. And I have to say that is a pretty compelling argument.

> off into how to do XMPP's DNA thing better is harder, hence

Don't you think it might be appropriate to discuss how specific services
actually do this sort of stuff in reaching a decision as to how TLSA records
should work in these contexts?

				Ned

---

From: James Cloos <[email-masked]>
Date: Mon, 30 Apr 2012 18:36:01 -0400

>>>>> "NF" == Ned Freed <[email-masked]> writes:

NF> apps-discuss. Id:  <[email-masked]>

Thanks.  I found it in my backup and remember reading (most of) it.

You reference rfc 2181 §10.3 which explains that:

  [MX lookups cause] "additional section processing" in
  which address records associated with the value of the
  record sought are appended to the answer....

And that:

  Additional section processing does not include CNAME records,

That indeed makes pointing an MX RR at a CNAME RR a poor choice.

Thanks.  I'd forgotten to consider additional processing in my
earlier note.

-JimC

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 00:11:45 +0100

> is a mistake. And I have to say that is a pretty compelling argument.

Could well be. What changes to the text in 1.3 of -20 do you think
are needed if any?

  "            Note that this document does not cover how to associate
   certificates with domain names for application protocols that depend
   on SRV, NAPTR, and similar DNS resource records; it is expected that
   later updates to this document might cover methods for making those
   associations."

The authors and a WG chair figure they've handled the IETF LC
comments already. I need to figure out if they have and this thread
is not helping me at least. (Given that I already know this is a
tricky area.)

> should work in these contexts?

I do. I'm suggesting that the discussion, while useful in
general, has perhaps wandered and is no longer necessarily
useful for figuring out what this draft needs to say.

S.

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 May 2012 00:47:20 +0100

> That indeed makes pointing an MX RR at a CNAME RR a poor choice.

However an MTA cannot rely on additional section processing because
additional RRsets can be silently omitted - see RFC 1034 section 4.3.2
point 6 and RFC 2181 section 9. So an MTA has to look up any address
records that are missing from the MX answer, which means CNAMEs don't
cause problems unless the MTA makes a special effort to forbid them.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: Northeast 5 to 7, becoming variable 3 or 4. Moderate,
occasionally rough. Thundery rain or showers, fog patches. Moderate or good,
occasionally very poor.

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 18:52:50 -0700 (PDT)

>    later updates to this document might cover methods for making those

Well, to be blunt, I think that by trying to avoid solving the problem now
while not giving up control over future solutions this ends up being
unacceptable to everyone. 

What if a service comes along that uses SRV records and wants to specify how
TLSA records are used to secure them? According to this text, it can't - the
clear implication here is that this has to be done by revising the DANE
specification itself.

And what about existing services like email where it is arguably the case that
simply using TLSA records to secure the A/AAAA targets MX records is
sufficient? A very short "secure email transport" specification could
be writte that refers to the DANE specification, but this would also seem
to forbid that.

I would much rather see a note that simply refers to future specification work
being needed, not specifically to a DANE revision being needed.

But even this may not be acceptable for all I know. It may turn out that using
DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an
acceptable default for SRV/MX/NATPR-based services. I could easily be wrong,
but it seems to me that this is what all this additional discussion is about.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Apr 2012 19:16:58 -0700

> being needed, not specifically to a DANE revision being needed.

I had the same concern but then I realized that "later updates to this
document might cover methods for making those associations" could be
construed as referring to add-on documents that would officially update
the DANE-RFC-to-be, not as saying that such changes would need to be
made in the single DANEbis document that would cover all possible uses
of the TLSA RR.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Apr 2012 19:30:50 -0700

> made in the single DANEbis document that would cover all possible uses

Peter's interpretation is certainly the one we intended: that is why I used "updates" not "replacements" in the sentence quoted above.

Ned: if you have a better wording for the sentence, I strongly suspect the WG would be happy with such a clarification.

--Paul Hoffman

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Apr 2012 23:30:42 -0700 (PDT)

> made in the single DANEbis document that would cover all possible uses

That doesn't fix the problem. Anything that says "updates RFC FOO" is
effectively the same as a DANEbis spec. What I want is for other specification
to be able define how to use TLSA records to secure protocols that use more
elaborate DNS record mechanisms *without* having to update DANE.

				Ned