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

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2012 10:24:12 -0700

On Apr 30, 2012, at 7:43 PM, Peter Saint-Andre wrote:

>> 1b. The term "client-chosen port" makes it sound as if the client 
>> can choose any port it pleases when connecting to the TLS server. 
>> Yet typically the port is derived from a URI, "hardcoded" into the
>> application protocol (sometimes as a fallback), or discovered via 
>> the DNS (again, think SRV). We needn't reflect those alternatives 
>> in the text, but at the least "appropriate" is better than 
>> "client-chosen".
> 
> The change from "client-chosen port" to "client-define port" is
> mystifying to me. Even assuming that "client-defined" was meant, it's
> not clear to me what a client-defined port is, and I see no effective
> difference between the old text and the new text.

The intended difference was to say that the client gets to define which port it is using based on pre-configured settings ("POP is always done over TLS on port 995") or the way it interprets the URL or on something else we cannot guess. I didn't feel that your proposal of "appropriate" indicated to whom it needed to be appropriate, namely the client.

Better suggestions are welcome.

>> 4. In Section 2.2, the term "whitespace" is underspecified. Does 
>> that include, say, any Unicode space separator (Unicode General 
>> Category Zs) or also line separators (Unicode General Category Zl) 
>> or only certain code points in the ASCII range? Further, is the 
>> whitespace significant in the examples from Section 2.3?
> 
> I see no change in -20 to clarify this matter.

We can add ", as described in <xref target="RFC1035"/>" in the next draft, or remove the whole sentence since it is already covered by an Internet Standard. I think the former is better, but can do the latter if you think that is clearer.

>> 2. Section 1.1, uses the term "subdomain" in the sentence "This 
>> prevents an untrustworthy signer from compromising anyone's keys 
>> except those in their own subdomains." The term "subdomain" is not
>> always well understood. I suggest explicitly citing Section 3.1
>> of RFC 1034 here.
> 
> Unchanged, but it's probably OK as-is.

There are many DNS-related terms that are defined in 1034/1035; I don't think calling each out will help the reader.

> In a follow-up email message, I also noted:
> 
> ###
> 
> One more issue is nagging at me: there is no definition or citation
> for "domain name" in Section 3. In particular, there is no indication
> of whether internationalized domain names are allowed (and, if so, in
> what format). I think it would good to make this clear by saying that
> a domain name can be either a "traditional domain name" (RFC 1034) or
> an "internationalized domain name" (RFC 5890); for the latter I think
> it would be best to say that the IDN's internationalized labels are
> represented only as A-labels. IMHO a short paragraph on this matter
> would be appropriate in Section 3 or in a new section entitled
> "Internationalization Considerations".
> 
> ###
> 
> I still think that this document needs to say something about IDNs.

Please give specific wording for a specific location. I do not see any place appropriate in this document to introduce IDNs and explain A-labels in order to say "they're fine here". If you propose wording and a location, I bet they will be fine.

--Paul Hoffman

---

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

> difference between the old text and the new text.

I think the mistake is to talk about the client here. The client begins a
connection to the service's port at that IP address.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Cyclonic 5 in far north, otherwise southwesterly 5 to 7.
Moderate or rough. Occasional rain. Moderate or good, occasionally poor in
north.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 May 2012 11:56:17 -0700

> connection to the service's port at that IP address.

Usually, yes. Sometimes the client is configured to override the default
port for the given service, as Paul noted.

Could we just say "It then begins a connection to a particular port at
that address"? Perhaps the method for determining the port isn't really
relevant in this spec.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 May 2012 12:02:54 -0700

On 5/1/12 10:24 AM, Paul Hoffman wrote:
>>>  can choose any port it pleases when connecting to the TLS
>>> server. Yet typically the port is derived from a URI, "hardcoded"
>>> into the application protocol (sometimes as a fallback), or
>>> discovered via the DNS (again, think SRV). We needn't reflect
>>> those alternatives in the text, but at the least "appropriate" is
>>> better than "client-chosen".
>> 
>> mystifying to me. Even assuming that "client-defined" was meant,
>> it's not clear to me what a client-defined port is, and I see no
>> effective difference between the old text and the new text.
> 
> The intended difference was to say that the client gets to define
> which port it is using based on pre-configured settings ("POP is
> always done over TLS on port 995") or the way it interprets the URL
> or on something else we cannot guess. I didn't feel that your
> proposal of "appropriate" indicated to whom it needed to be
> appropriate, namely the client.
> 

See other message.

>>>  Category Zs) or also line separators (Unicode General Category
>>> Zl) or only certain code points in the ASCII range? Further, is
>>> the whitespace significant in the examples from Section 2.3?
>> 
> We can add ", as described in <xref target="RFC1035"/>" in the next
> draft, or remove the whole sentence since it is already covered by an
> Internet Standard. I think the former is better, but can do the
> latter if you think that is clearer.

Hmm. The text I'm referring to is:

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

How does RFC 1035 apply to the representation of the certificate
association data field?

>>>  except those in their own subdomains." The term "subdomain" is
>>> not always well understood. I suggest explicitly citing Section
>>> 3.1 of RFC 1034 here.
>> 
> There are many DNS-related terms that are defined in 1034/1035; I
> don't think calling each out will help the reader.

You're right.

>> One more issue is nagging at me: there is no definition or
>> citation for "domain name" in Section 3. In particular, there is no
>> indication of whether internationalized domain names are allowed
>> (and, if so, in what format). I think it would good to make this
>> clear by saying that a domain name can be either a "traditional
>> domain name" (RFC 1034) or an "internationalized domain name" (RFC
>> 5890); for the latter I think it would be best to say that the
>> IDN's internationalized labels are represented only as A-labels.
>> IMHO a short paragraph on this matter would be appropriate in
>> Section 3 or in a new section entitled "Internationalization
>> Considerations".
>> 
>> ###
>> 
> Please give specific wording for a specific location. I do not see
> any place appropriate in this document to introduce IDNs and explain
> A-labels in order to say "they're fine here". If you propose wording
> and a location, I bet they will be fine.

I'm tied up today, but I will try to formulate some text as soon as
possible.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2012 12:18:17 -0700

> that address"? Perhaps the method for determining the port isn't really

Works for me. What do others think?

Current:
It then begins a connection to a client-defined port at that address, and sends an initial message there.
Proposed:
It then begins a connection to a particular port at that address, and sends an initial message there.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2012 12:20:46 -0700

> How does RFC 1035 apply to the representation of the certificate

The representation is happening in a DNS zone file.

> I'm tied up today, but I will try to formulate some text as soon as

No rush: IDNs will be with us for a long time. :-)

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 May 2012 09:59:42 +0100

> port for the given service, as Paul noted.

My point is that the correct port is defined by the service's
configuration, which belongs to the server not to the client.
I didn't mean to imply the service's port is well-known - it
might come from SRV records or from URLs etc.

> that address"?

Works for me.

> Perhaps the method for determining the port isn't really
> relevant in this spec.

Right. A bit like the question of which name is authenticated :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight, Humber: Variable 3 or 4, becoming north or northeast 4 or 5.
Slight or moderate. Fair. Moderate or good, occasionally poor.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 1 May 2012 15:26:05 -0400

[ -IESG]

> It then begins a connection to a particular port at that address, and sends an initial message there.

LGTM.

W

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

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 16:35:49 +0200

>> It then begins a connection to a particular port at that address, and sends an initial message there.

+1

--
 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: SM <[email-masked]>
Date: Thu, 03 May 2012 14:26:37 -0700

Hi Peter,

> >> I still think that this document needs to say something about

Section 3 of draft-ietf-dane-protocol-20 uses "domain name".  The 
reference is likely RFC 1035.  The problem with DANE is that it 
touches application layer protocols by using host names (see the 
examples).  RFC 1123 is applicable then.  If you want to support 
internationalization, you then end up using RFC 5890.  Should the 
question about whether STD 13 supports IDN, everyone knows what the 
answer will be. :-)

The note in Section 1.3 could be extended as a separate paragraph:

   This document does not cover how to associate certificates with
   domain names for application protocols that depend on MX, SRV,
   NAPTR, and similar DNS resource records; it is expected that
   later updates to this document might cover methods for making those
   associations.  Note that legacy application specifications (e.g.,
   SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII labels
   in DNS domain names used with those protocols, i.e., only the A-label
   form of IDNs is permitted in those contexts.  Section 2.2 of RFC 6125
   discusses about DNS domain name used by an application service.

[sentence borrowed from RFC 5890]

Somewhere during the discussion of the AppsDir reviews, Alexey asked 
an interesting question: what is a "DNS domain name".  The question 
was not fully answered.  The "fix", if anyone thinks it is 
worthwhile, would be to get an answer in the context of Section 3 of 
the draft and adapt the hand-waving accordingly.

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 May 2012 17:47:23 -0400

> question about whether STD 13 supports IDN, everyone knows what the

I don't think that the examples (I presume you mean "in that section",
since the examples in Appx C aren't DNS names) are normative, and as
nearly as I can tell nothing about section 3 is restricted to the host
name syntax.  It's true that if you want to use IDNA with DANE then
you have to do it using A-labels.  I don't really get why any of that
needs to go into the protocol document, though.  This is a document
about how you do stuff in the DNS, and that means you have to do it in
a DNS-y way.  No?

A
-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Thu, 03 May 2012 15:03:58 -0700

Hi Andrew,
>since the examples in Appx C aren't DNS names) are normative, and as

I understand that.

>about how you do stuff in the DNS, and that means you have to do it in

Peter posted a message at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05577.html 
which in my opinion explains the application perspective.  If you go 
by RFC 4398, yes.  The problem with the DNS way is that it pushes 
issues to the application side and the reverse is also valid.

Regards,
-sm