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

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 09:46:52 +0100

Hi Ned,

On 05/01/2012 07:30 AM, Ned Freed wrote:
>> On 4/30/12 6:52 PM, Ned Freed wrote:
>>>
>>>>> 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.
>>>
>>>> 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."
>>>
>>> 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.
> 
>> 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.
> 
> 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.

So I don't get the sensitivity here at all. There is, afaik, no
plan for the DANE WG to be gatekeeper for anything, and nor is
there any plan for the DANE WG to have a very long lifetime.
I don't think is there a definite need e.g. for something that
says how to use DANE with XMPP or SMTP to update the TLSA RFC -
that might or might not be needed but we won't know until its
being done.

Nevertheless, how about if it said:

"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
future documents will cover methods for making those associations.
Those documents may or may not need to update this one."

As Paul said, I don't think there's any problem if you've a
better wording for that, so please do suggest some specific text
if the above doesn't work.

Cheers,
S.

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 May 2012 12:22:21 +0100

Ned Freed <[email-masked]> wrote:
>
> 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.

I don't think it's as simple as that because RFC 6125 says certificates
should match the SRV owner name not the target name. See also Dave
Cridland's comments about XMPP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: Variable 3 or 4. Moderate becoming slight. Showers, fog patches.
Moderate or good, occasionally very poor.

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 May 2012 12:12:52 -0700 (PDT)

> Cridland's comments about XMPP.

That's actualy A Good Thing, because it means that there's nobody can argue
that there's a simple addition to this document that will address the SRV
case. Now all that remains is to open the door to using TLSA without having
to update this specification.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 May 2012 19:55:56 -0700 (PDT)

> there any plan for the DANE WG to have a very long lifetime.

When why does the language say otherwise?

> that might or might not be needed but we won't know until its

But that's what it currently says is needed.

> Those documents may or may not need to update this one."

That's essentially the change I suggested making.

> if the above doesn't work.

The wording you suggest is fine with me, and addresses my concern.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 May 2012 13:38:08 +1000

In message <[email-masked]>, Tony F
> Cridland's comments about XMPP.

	Should != must.

	None of the examples in RFC 6125 deal with a store and
	forward protocol that uses trusted third parties.  SMTP is
	a example of such a protocol and if implements using SRV
	rather than MX it would be a exception.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 May 2012 10:01:22 +0100

Mark Andrews <[email-masked]> wrote:
> Tony Finch writes:

Indeed, I used the word precisely :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic 5 to 7, occasionally gale 8 at first, decreasing 4 at
times. Moderate or rough. Rain or thundery showers. Moderate or good,
occasionally poor.

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2012 15:47:39 +0200 (MEST)

> That's essentially the change I suggested making.

Writing that those apps-protocol-specific documents (defining how to
use a particular protocol with TLSA/DANE-protocol) might need to update the
TLSA/DANE-protocol document is misleading (and IMHO should be avoided).

http://tools.ietf.org/html/rfc2223#section-12

defines the "Updates:" metadata for RFCs to have a very narrow and purely
editorial meaning.  "Updates:" is meant to refer to those situations
where a paragraph or section of a new document **completely** replaces
the same paragraph or section of a previous RFC.

It is probably much more common to "extend" an existing protocol or
describe/define additional usage scenarios without changing the original
specification, simply by using the extensibility of the original protocol.

Normally, such "expected usage" should not use the editorial
rfc2223-Updates: metadata.  But the use of the Updates:&Obsoletes:
meta-data tags in RFCs is not consistent, a number of RFC seem to
ignore the rfc2223 definitions of what these headers are supposed
to indicate.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2012 15:59:31 +0200 (MEST)

Mark Andrews wrote:
>>> 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.
>> 

I think that is a misunderstanding.

The XMPP document may explicitly account for a local policy to override
the decision to continue communication because of a mismatch and chose
"should" over "must" for that, assuming that MUST is unconditional
and not subject to local policy.

Some specifications in the security area (and PKIX in particular)
use a different approach, using MUST all over the place, silently
assuming that local policy overrides MUSTS in specs all the time...
(and some of the language in DANE-protocol is the same, generously
sprinkling MUST all over the place, and causing confusion about
when a MUST is really a MUST (i.e. not subject to local policy).

Personally, I prefer shoulds to musts for situations where local
policy is supposed to apply.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 May 2012 00:12:35 +1000

> policy is supposed to apply.

This isn't a local policy issue.  It's a appropriate fit for the
protocol issue.  Most protocols where you will be using SRV you
can use the owner of the SRV record but there are some where it
does not make sense.  By forcing the security model to be too
rigid you stop SRV being used in ways it was designed to be used.

Mark

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 May 2012 15:13:44 +0100

> I think that is a misunderstanding.

No, I think Mark is right. RFC 6125 is guidance for protocol designers,
so the "should" is a recommendation about how to decide which identity is
authenticated when adding TLS to a protocol. Whether local policy can
override this decision is something else entirely.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Northwesterly 4 or 5, increasing 6 in north. Slight or moderate. Fair.
Moderate or good.

---

From: Ned Freed <[email-masked]>
Date: Wed, 02 May 2012 09:13:44 -0700 (PDT)

> the same paragraph or section of a previous RFC.

That section doesn't say or even imply that the change has to be purely
editorial in nature. (The word "editorial" appears nowhere in the section and
neither do the words "paragraph" or "section".)

And even if it did, the facts are that Updates: is routinely used by documents
that make a substantial technical change to a previous document. A particularly
relevant example of this is the EAI specification RFC 6532, which states that
it "Updates: RFC 2045" and the nature of this update is to remove a MUST NOT,
which is just about as substantial a technical change as you can make.

So if there's a bug here (and I don't think there is), the bug is in RFC 2223.
Not in this use of Updates:.

> specification, simply by using the extensibility of the original protocol.

Sure, but it is also common to make a technical change and call it an update.
You may not like that, but that's how it works.

> ignore the rfc2223 definitions of what these headers are supposed

Again, if there's any inconsistency, it's in RFC 2223.

				Ned

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2012 19:50:51 +0200 (MEST)

> neither do the words "paragraph" or "section".)

The rfc2223 document title is "Instruction to RFC Authors".  The Updates:
header has a purely editorial meaning for the *new* document, but the
result can certainly be very technical for the *old* document!

Updates: should only be used if the change is supposed to apply not only
to implementations of the *new* document, but that all new implementors of
the *old* (=updated) document should ignore certain parts of the old
document and use the new document instead.  But in order for this to
work,
  - a section in the new document is *REQUIRED* which list exactly
    which pieces of the *old* (=updated) document are completely
    replaced by which pieces of the new document
  - retaining full interop with old implementations based on only
    the full spec, and clear distinction of features that were
    added or dropped in the updated parts.

> You may not like that, but that's how it works.

That is not necessarily a contradiction.

But there is a certain mess in the meta-data of published RFCs.
Publishing a change to specification will not magically change
the behaviour of an installed base, therefore "changes" need to
account for the reality of life.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2012 20:07:44 +0200 (MEST)

> override this decision is something else entirely.

The idea behind this should is that it completely obviates the need of a
secure directory and secure lookup service and is easier to understand
and configure and therefore easier to operate securely.

The idea behind DANE is that it can be implemented and evaluated
as a module, and provides a similar service as a public CA that issues
DV-validated SSL certs.

If there are apps protocols that would like to perform fancy name
transformations on the that is passed as input to an implementation
of DANE-protocol, then this apps protocol will have to specify
(and implement) the security for any such name transformations
when they are not based on a trusted local source, because the
DANE module does not know about (and therefore does not care about)
any such transformations.

Any necessity of such name transformations is likely to also cause
problems with obtaining and using "traditional" PKIX certificates
(TLSA usage types 0&1).  Apps which currently have such a PKIX-problem
first ought to fix their architecture so that the TLSA usage 0&1 vs 2&3
becomes a true option for the consumer of the technology, rather
than focus on subverting usage type 2&3 only and leaving the problems
that preclude TLSA usages 0&1 unsolved.

-Martin

---

From: Ned Freed <[email-masked]>
Date: Wed, 02 May 2012 11:10:49 -0700 (PDT)

> result can certainly be very technical for the *old* document!

And that's quite simply nonsense. It has a technical meaning in both cases. In
the new document it's informing the reader that this document changes or adds
to a previous specification.

> document and use the new document instead.

Which is exactly the sense in which it is being used here. Although I think it
unlikely given how limited DANE is, it is nevertheless possible that some
subsequent use of TLSA will require tweaking of something in the DANE
specification. We're not omnipotent and we don't always get every detail right.

Of course this brings up the question as to when the level of change rises to
the point where an revision that obsoletes the original is required. This is  a
judgement call that needs to be made on a case-by-case basis.

>     But in order for this to work,

I rather suspect I can find any number of examples where that wasn't done, but
yes, I agree that it is best done this way. RFC 6532 certainly used this
approach.

But this actually supports the notion that we use be using the term "updates"
here, to make it clear that if changes are made they need to be done this way.

>     added or dropped in the updated parts.

This, OTOH, is unduly constraining. The RFC 6532 is again on point - it made a
change (allowing nested encodings) that could conceivably cause
interoperability problems, although that is believed to be unlikely. Such cases
should be rare, and when they do come up full consideration needs to be given
to the consequences, but saying it should never be allowed under any
circumstances is excessive.

> account for the reality of life.

On this, at least, we agree. But the bigger problem is how to clean it up.
On that score I'm a bit sort on helpful suggestions.

				Ned

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2012 20:53:17 +0200 (MEST)

Ned Freed wrote:
> Which is exactly the sense in which it is being used here. Although
> I think it unlikely given how limited DANE is, it is nevertheless
> possible that some subsequent use of TLSA will require tweaking of
> something in the DANE specification. We're not omnipotent and we
> don't always get every detail right.

Just the opposite.

Quite similar to rfc6125, DANE-protocol assumes that you already have a
trustworthy hostname for which to retrieve the certificate association.
This way, DANE-protocol can be put into a black block module for the
caller and does not need to be updated or changed depending on the
usage scenario.  It would even be possible to tunnel the TLSA+DNSSEC
records for performing DANE-protocol through a TLS extension instead
of looking it up in a combined TLS+DANE module in a fashion that is
completely opaque to the application caller.

What some of the app specs (other than HTTPS) may have to specify _and_
implement, in order to be able to use DANE, is how to securely obtain
a hostname&port which can be used as input to an implementation of
DANE-protocol or input to rfc6125 matching for PKIX-based matching
to DV-validated server certificates.

But such an apps-specific spec is _not_ an update to DANE itself,
in spite of refering to DANE.  It is irrelevant to the DANE software module.

New TLS cipher suites usually do not update or change TLS, new crypto
algorithms usually do not update or change PKIX, new mime-types ususally
do not update HTTP or the internet message format.

> This, OTOH, is unduly constraining.

Not at all.  Maybe you're misreading this.  It says that anything that
claims to update an earlier document must explain where and how it does
that, an in particular outline omissions and mark additions as such,
so that it will be clear to the reader of the document.

Example:  http://tools.ietf.org/html/rfc5321#section-1.2

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 May 2012 09:25:05 +1000

> and configure and therefore easier to operate securely.

Indeed, but it is not the only model of usage.  Pushing the RFC
6125 model onto MX would just be wrong.  Sometimes you do need the
secure directory and secure lookup.  Having each protcol specify
the security model it is using is a good thing.

For MX and STARTTLS, DANE can stop downgrade attacks on the MX
targets.  You can't just intercept port 25 traffic and get away
with it in a world where DANE exists like you can with plain PKIX.

You have to manipulate the DNS and hope that the client MTA is
not checking by using DNSSEC.

MTA's can now know whether that should be expecting to see STARTTLS
on not in the EHOL response.  If they don't they see it then they
should abort the connection even if the MX records themselves were
not secure.

> as a module, and provides a similar service as a public CA that issues

That is part of what DANE provides.  It also provides protection
from downgrade attacks by indicating that TLS is available.  It
also provides protection from rogue CA's and rogue states that get
global wildcard certs.  These are adjucts to PKIX.

> that preclude TLSA usages 0&1 unsolved.

Just because you don't like the alternate security model that doesn't
make it wrong or require that protocol to be fixed.

Mark

---

From: Ned Freed <[email-masked]>
Date: Wed, 02 May 2012 19:10:44 -0700 (PDT)

> Just the opposite.

So you're saying that it is flatly impossible that DANE contains some assertion
or restriction or whatever that will interfere with some future protocol use
of TLSA? Please cite your proof of this, because I'm a wee bit skeptical.

Remember, just because we're allowing something to be done doesn't mean it ever
will be done. This is known as "covering our bases".

Morever, as Mark Andrews has pointed out in another thread, it is also entirely
possible that DANE may be used to implement different security models than the
one the specification currently describes.

> completely opaque to the application caller.

I fail to see the slightest relevance.

> in spite of refering to DANE.  It is irrelevant to the DANE software module.

In other words, by giving a single example where you claim it won't be
necessary to update DANE, you have shown that it any possible protocol,
including future ones we haven't even thought of, developed in the future won't
need to either?

> do not update HTTP or the internet message format.

And by giving examples of things where extensibility was specifically planned
into the underlying protocols, you have now proved that a protocol that
contains no similar provisions will ... at this point I don't even know
how to finish the sentence. This makes no sense whatsoever.

> so that it will be clear to the reader of the document.

Misreading? More like miswriting, if it was you intention to say that.

You said "retaining full interop with old implementations based on only the
full spec", which is what I objected to. Your new paraphrase mentions none of
that.

> Example:  http://tools.ietf.org/html/rfc5321#section-1.2

Both RFC 5321 and RFC 5322 and their predecessors went to considerable trouble
to maintain compatibility with RFC 821 and RFC 822, preferring to mark a large
number of features as deprecated rather than remove them. But this is not
always possible, as was the case when the nested encoding restriction was
removed so that message/global could be defined. 

Anyway, this has now gone well past the point of absurdity. I apologize to
everyone who has read all of this for wasting their time on such a silly
argument. This will be my final message on the topic.

				Ned

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:03:33 +0200

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

Hear, hear!  (Just remembers how many RFCs which states "Updates: RFCNNNN" we have...)

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:08:27 +0200

> The wording you suggest is fine with me, and addresses my concern.

I am fine with "may or may not".

O.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:12:24 +0200

Martin and all other,

> policy is supposed to apply.

<chair hat on>
Is this still related to review of DANE protocol?  It seems to me it's not.
Please change the subject, if you want to discuss this further, and cut down
the Cc list (I don't mind discussing this in the DANE WG list, if it's clear
it's not related to the review, but you talk about XMPP/SRV/etc.)
</chair hat on>

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:27:58 +0200

On 24. 4. 2012, at 18:19, Peter Saint-Andre wrote:
> 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,

I still don't understand why DANE should be different from any other
new DNS RR type out there and specifically reference to IDN.  RFC 6125
applies to DANE, as it applies to any other new RRtype which was and
will be created.  I hope you don't suggest we add a reference to RFC
6125 to every document creating a new RRtype?

What value it would add to say: "Standard DNS rules applies including
the IDN" in the document?  I would say that it's implicit and doesn't
need an explicit sentence.

Chairs (and authors) share the opinion that the document doesn't need
an update for IDN.

Ondrej

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 May 2012 13:52:18 -0600

> Chairs (and authors) share the opinion that the document doesn't need

Ahoj Ondřej,

Perhaps this is simply a difference between folks who look at things
from the DNS perspective and folks who look at things from the apps
perspective (as users of DNS). All sorts of application protocols are
being updated to support IDNs. Those applications will need to know how
to translate their IDNs (which might consist of U-labels) into a form
that can be placed into the DNS. To make things perfectly clear, I'm
just suggesting that we add a sentence or two warning those who write
code for application protocols using DANE that they might need to
convert U-labels into A-labels. I'll work to propose specific text today
or tomorrow.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2012 13:34:29 -0700

> convert U-labels into A-labels. I'll work to propose specific text today

I'll be interested to see that. I cannot see how anyone reading Section 3 of RFC 5891 could think that they would *not* need to convert to A-labels before looking up something in the DNS. If you are saying that every post-5891 protocol that defines a new RRtype must say "and if you are going to look up the domain name in the DNS, convert to A-labels first", that's fine, but it seems kinda late to start saying that.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 May 2012 15:41:40 -0600

On 5/3/12 2:34 PM, Paul Hoffman wrote:
>> Perhaps this is simply a difference between folks who look at
>> things from the DNS perspective and folks who look at things from
>> the apps perspective (as users of DNS). All sorts of application
>> protocols are being updated to support IDNs. Those applications
>> will need to know how to translate their IDNs (which might consist
>> of U-labels) into a form that can be placed into the DNS. To make
>> things perfectly clear, I'm just suggesting that we add a sentence
>> or two warning those who write code for application protocols using
>> DANE that they might need to convert U-labels into A-labels. I'll
>> work to propose specific text today or tomorrow.
> 
> 
> I'll be interested to see that. I cannot see how anyone reading
> Section 3 of RFC 5891 could think that they would *not* need to
> convert to A-labels before looking up something in the DNS. If you
> are saying that every post-5891 protocol that defines a new RRtype
> must say "and if you are going to look up the domain name in the DNS,
> convert to A-labels first", that's fine, but it seems kinda late to
> start saying that.

Not everyone is as smart as you are.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2012 14:59:26 -0700

> Not everyone is as smart as you are.

If you believe that developers who are using IDNs are not following the easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I propose that is not a DANE issue at all.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 May 2012 16:33:38 -0600

On 5/3/12 3:59 PM, Paul Hoffman wrote:
>>>> things from the DNS perspective and folks who look at things
>>>> from the apps perspective (as users of DNS). All sorts of
>>>> application protocols are being updated to support IDNs. Those
>>>> applications will need to know how to translate their IDNs
>>>> (which might consist of U-labels) into a form that can be
>>>> placed into the DNS. To make things perfectly clear, I'm just
>>>> suggesting that we add a sentence or two warning those who
>>>> write code for application protocols using DANE that they might
>>>> need to convert U-labels into A-labels. I'll work to propose
>>>> specific text today or tomorrow.
>>> 
>>> 
>>> convert to A-labels before looking up something in the DNS. If
>>> you are saying that every post-5891 protocol that defines a new
>>> RRtype must say "and if you are going to look up the domain name
>>> in the DNS, convert to A-labels first", that's fine, but it seems
>>> kinda late to start saying that.
>> 
> If you believe that developers who are using IDNs are not following
> the easiest-to-read section of RFC 5891, the issue is much larger
> than just DANE. I propose that is not a DANE issue at all.

I believe nothing -- I'm just saying that I am no longer surprised by
what folks do or do not know. I see no harm in including a sentence or
two sending folks in the right direction.

Peter

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

---

From: Ned Freed <[email-masked]>
Date: Thu, 03 May 2012 18:16:39 -0700 (PDT)

> If you believe that developers who are using IDNs are not following the
> easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I
> propose that is not a DANE issue at all.

I completely agree, but additionally, the model of trying to cover all the
possible ancillary material that some developer might possibly be unaware of is
simply unsustainable. Were we to attempt it, we'd end up with every
specification stuff with huge amounts of "see also" material irrelevant to the
specification itself. And it will cause more problems than it solves.

No, the question isn't whether someone without clue is going to read this
specification and miss something important. That's going to happen no matter
what. Rather, the question is whether or not it is at all likely that adding a
particular pointer will actually make a significant difference.
                                                                        
I don't think this suggestion rises to that level. Consider: TLSA records
appear next to A, AAAA, or CNAME records, and have to have the same names as
those records (modulo wildcards). Therefore an IDN name in a TLSA record means
the A/AAAA/CNAME record also has, and more likely already had, an IDN name.
That in turn means that the IDN issue has already been faced/addressed. So
there doesn't seem to be much value here.

Of course you can come up with scenarios where different people provision the
different records, or the provisioning interface has different behavior for
different kinds of records, and so on and so forth. But are these scenarios
likely? I don't think so. Indeed, I suspect the bigger problem will be the lack
of builtin support for TLSA records in deployed nameserver software. So if you
want to address the more likely deployment problem for the less than clueful,
you should be arguing for a reference to something that explains how to use the
arbitrary record support in the more popular nameservers. (Or alternately, we
could actually look at, you know, solving the problem. See John Levine's
draft.)

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 May 2012 14:58:53 -0600

> If you believe that developers who are using IDNs are not following the easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I propose that is not a DANE issue at all.

Maybe, maybe not. I leave that up to the working group.

Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), I
suggest that we could add the following parenthetical statement to point
3 in Section 3...

OLD
   3.  The domain name is appended to the result of step 2 to complete
       the prepared domain name.

NEW

   3.  The domain name is appended to the result of step 2 to complete
       the prepared domain name.  (The domain name is the fully
       qualified DNS domain name [RFC1035] of the TLS server and is
       represented as a byte string using ASCII encoding without a
       trailing dot; this enables support for internationalized
       domain names through the use of A-labels as defined in
       [RFC5890].)

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2012 14:10:55 -0700

>       domain names through the use of A-labels as defined in

Thank you for finally suggesting text. :-)

This seems fine to me, doesn't change anything technically, appears in the right place, and doesn't feel gratuitous.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 18:07:17 -0400

Hi,

>        domain names through the use of A-labels as defined in

I don't understand that definition of "the domain name".  What we
appear to be discussing here is how you prepare the presentation
format for the domain name; "represented as a byte string using ASCII
encoding" doesn't make a lot of sense to me in this context.  

In particular, you don't need any of the text starting with
"represented" and ending with the semicolon, because what you're
describing there isn't properly speaking a domain name at all.  It's a
relative domain name, which happens to be relative to the root.  It's
also in presentation format, which is irrelevant for DNS query
purposes, because we don't send queries in presentation format.

It sounds like the key point you want to make is that IDNA2008 labels
MUST be in A-label format before transformation.  Is that it?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 00:24:50 +0200 (MEST)

> MUST be in A-label format before transformation.  Is that it?

We added similar text like the above to rfc6066 (TLS extensions)
for the description of the extension "Server name indication" here:

  http://tools.ietf.org/html/rfc6066#page-7

3rd paragraph on page 7

Could you point to an existing document that contains a suitable
1-paragraph desciption that you believe fits better here?
I don't think that we should be inventing a new description
for ever new document, but preferably re-use what is already there.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 18:33:19 -0400

[resending from an actually subscribed address.  Apologies]

Hi,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 00:37:45 +0200 (MEST)

> for ever new document, but preferably re-use what is already there.

That "we added to rfc6066" refers to this disussion in the TLS WG:

  https://www.ietf.org/mail-archive/web/tls/current/msg07233.html

Re-reading that paragraph, I realize that the description
"fully qualified DNS hostname of the server" is factually incorrect
for rfc6066 (I don't know about DANE, though).

When used by HTTP-over-TLS, it ought to be the name as used by the
client for performing server endpoint identification (rfc2818 or rf6125),
and that _can_ be a hostname without domain from a URL!!

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 18:38:20 -0400

> for the description of the extension "Server name indication" here:

The problem in this case, however, is that what the TLSA document is
doing is building a QNAME for use in the DNS.  None of the description
from RFC 6066 is a domain name.

Remember, the dot-separated labels are the presentation form, but
_not_ what you send on the wire.  Dots aren't part of the DNS on the
wire.  

What we want to do for this case is get the QNAME for the DNS.  So we
take the two labels that come out of steps 1 and 2 in the draft, and
put them on the front of the DNS name that we're trying to look up,
creating an absolute, fully qualified name that gets sent in the QNAME
of the DNS operation.  

At least I think that's what the section is trying to do.

I'm also uncomfortable with the "ASCII" stuff, because DNS labels
aren't in ASCII.  They're octets.  However, ASCII is treated specially
in the DNS.  (This is one of the sharp edges about the DNS that we'd
all like to go back and fix if we could.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Fri, 04 May 2012 15:50:49 -0700

Hi Martin,
>1-paragraph desciption that you believe fits better here?

I'll skip the tricky question. :-)

>for ever new document, but preferably re-use what is already there.

The text from that section of RFC 6066 is about FQDNs.

RFC 6394 mentions that 'the process of obtaining this "source" domain 
is application specific [RFC6125]'.   It seems like the better choice 
to keep things easy.  It also matches what's in Section 4 of the draft.

Regards,
-sm

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 06:38:12 +0200 (MEST)

> all like to go back and fix if we could.)

Thanks for pointing out the details.  I have been an occasional caller of
gethostbyname(), and not used libresolv function() like res_query().

Do we expect the target audience (folks implementing DANE protocol)
to use an API like that of libresolv's res_query(), where the representation
appears to be still a single string rather than individual DNS labels,
or that they're caller of even lower APIs?

The name that gets prefixed by protocol and port should probably
represent an absolute, fully qualified name as is, and be used with
res_query?  The default behaviour of gethostbyname(), trying completion
of a name that doesn't end with a dot/period with (default) domain or
entries from a (domain) searchlist (res_search?) would likely
risk unpleasant consequences.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 07:21:51 -0700

> At least I think that's what the section is trying to do.

It is indeed what the section is trying to do.

> all like to go back and fix if we could.)

Note that the document explicitly states in the last paragraph of section 1.2 that "This document only relates to securely associating certificates for TLS and DTLS with host names". We are not talking just "domain names" (which are made up of labels of octets) but "host names" which are made up of labels of ASCII. We were told (wisely) not to try to reopen this can of worms, so we didn't.

As you pointed out, Peter's proposed wording had an issue by mentioning the "dots". That can easily be fixed. I now propose:

OLD

NEW

  3.  The domain name is appended to the result of step 2 to complete
      the prepared domain name.  (The domain name is the fully
      qualified DNS domain name [RFC1035] of the TLS server and is
      represented as a byte string where each label is encoded
      using ASCII; this enables support for internationalized
      domain names through the use of A-labels as defined in
      [RFC5890].)

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 06 May 2012 19:07:31 -0600

>       domain names through the use of A-labels as defined in

Works for me.

Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 11:13:01 -0400

On Sat, May 05, 2012 at 07:21:51AM -0700, Paul Hoffman wrote:
> 
> Note that the document explicitly states in the last paragraph of
> section 1.2 that "This document only relates to securely associating
> certificates for TLS and DTLS with host names".  We are not talking
> just "domain names" (which are made up of labels of octets) but
> "host names" which are made up of labels of ASCII. We were told
> (wisely) not to try to reopen this can of worms, so we didn't.

Aha, good point.  I guess this needs a normative reference to RFC 952,
then?  That's actually the most recent RFC that establishes the host
rules.

>       domain names through the use of A-labels as defined in

I'm still uncomfortable with this, because it's not technically
accurate.  When you send the QNAME, it's not a "byte string" and the
labels aren't encoded.  They're octets, not strings.

How about 

    3.  The base domain name is appended to the result of step 2 to
        complete the prepared domain name.  The base domain name is the 
        fully-qualified DNS domain name [RFC1035] of the TLS server,
        with the additional restriction that every label must meet the
        rules of [RFC952].  The latter restriction means that, if the
        query is for an internationalized domain name, it must use the
        A-label form as defined in [RFC5890].

?  I added the modifier "base" to this to make it clear that we're not
defining what domain names are, although I don't myself feel too
strongly about that addition.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 11:14:37 -0400

> or that they're caller of even lower APIs?

They'll certainly need to call something other than getaddrinfo(),
because they need to know whether validation succeeded and you can't
find it out that way.

> risk unpleasant consequences.

Indeed.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2012 12:51:13 +0100

>         A-label form as defined in [RFC5890].

I like this.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: Variable 4 in east at first, otherwise northeasterly 5 to 7. Moderate or
rough. Occasional rain. Moderate or good.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 May 2012 06:38:58 -0600

>>         A-label form as defined in [RFC5890].

WFM.

Peter

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

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 13:47:48 +0200

> This seems fine to me, doesn't change anything technically, appears in the right place, and doesn't feel gratuitous.

ACK

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

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 13:52:27 +0200

>        A-label form as defined in [RFC5890].

This also works for me.  Unless I hear any objections from WG, I think we
can use this text and close the issue.

O.