On 12/8/10 12:14 PM, =JeffH wrote:
[ adding certid@ list ]
Thanks for the review SM.
In Section 2.2:
'A "traditional domain name", i.e., a fully-qualified domain name
or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH
labels" as defined in [IDNA-DEFS].'
It would be better to reference RFC 1123 for LDH labels instead of
RFC 5890 unless the authors would like to adopt a terminology that is
specific to IDNA.
I looked into this in detail earlier this year -- it was discussed on
ietf@ (during the initial IETF LC for this spec), and this particular
issue resolution was summarized here (by John Klensin)..
Re: Last Call: draft-saintandre-tls-server-id-check
http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html
In brief summary, RFCs {1034,1035,1123,2181} do not define
"letter-digit-hyphen" DNS name labels in a concisely referenceable
fashion, nor particularly clearly.
The IDNA specs have done the wider DNS-community a service by doing so,
and at present the fashion in which "traditional domain name" is defined
and cited is the best we can do. Given that IDNs are a deployed reality,
every (new or updated) spec that discusses domain names going forward is
going to need to reference the IDNA specs in some fashion, and probably
should simply use the LDH-Label, A-Label, and U-Label nomenclature. (IMV)
I agree with that assessment.
In Section 3.1:
"Unless a profile of this specification allows continued support
for the wildcard character '*', the fully-qualified DNS domain
name portion of a presented identifier SHOULD NOT contain the
wildcard character, whether as the complete left-most label
within the identifier (following the definition of "label" from
[DNS], e.g., "*.example.com") or as a fragment thereof (e.g.,
*oo.example.com, f*o.example.com, or foo*.example.com)."
If the presented identifier is a fully-qualified DNS domain name (I
assume that means FQDN), the left-most label cannot be a wildcard
character according to LDH rules. I suggest rewriting that as:
Unless a profile of this specification allows continued support
for the wildcard character '*', the domain name portion of
a presented identifier SHOULD NOT contain the wildcard character
(e.g., "*.example.com") or as a fragment thereof (e.g.,
*oo.example.com, f*o.example.com, or foo*.example.com).
while I agree with your subtle substitution of..
"fully-qualified DNS domain name portion"
..with..
"domain name portion"
Done.
..however, I disagree with your further simplification of that paragraph
because we feel we need to supply the more detailed context.
In Section 4.2.1:
"The client might need to extract the source domain and 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.,
extracting the fully-qualified DNS domain name from the authority
component of a URI or extracting the service type from the scheme of
a URI) or information for which the extraction is performed in a
manner that is 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 that provides both
mutual authentication and integrity checking)."
I read part of the above as meaning that data can only be extracted
from DNS if the data has been resolved via DNSSEC. Is that the intent?
No, that is not the intent. We've further refined that paragraph as a
result of a concurrent discussion with Ben Campbell (on certid@) and
have this present working text..
The client might need to extract the source domain and 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.,
extracting the fully-qualified DNS domain name from the "authority"
component of a URI or extracting the service type from the scheme of
a URI) or information for which the extraction is performed in a
manner that is 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 that provides both
mutual authentication and integrity checking). These considerations
apply only to extraction of the source domain from the inputs;
naturally, if the inputs themselves are invalid or corrupt (e.g., a
user has clicked a link provided by a malicious entity in a phishing
attack), then the client might end up communicating with an
unexpected application service.
Section 4.3 discusses about how to seek a match against the list of
reference identifiers. I found the thread at
http://www.ietf.org/mail-archive/web/certid/current/msg00318.html
informative.
In Section 4.4.3:
"A client employing this specification's rules MAY match the reference
identifier against a presented identifier whose DNS domain name
portion contains the wildcard character '*' as part or all of a label
(following the definition of "label" from [DNS])"
According to the definition of label in RFC 1035, the wildcard
character cannot be part of a label. I suggest removing the last
part of that sentence.
You mean removing the parenthetical "(following the definition of
"label" from [DNS])", yes?
In reviewing RFC 1035 I see your concern, tho we'd like to reference a
description of "label". I note that RFC 1034 [S3.1] seems to
appropriately supply this, so I propose we keep the parenthetical but
alter it to be..
(following the description of labels and domain names in [DNS-CONCEPTS])
Done.
FWIW, RFC 4592 updates the wildcard
definition in RFC 1034 and uses the term "asterisk label".
Yes, but that definition (and term) appears to be specific to underlying
DNS internals, not to (pseudo) domain names as wielded (or "presented"
(eg in certs)) in other protocols.
Was the comment about the security note (
http://www.ietf.org/mail-archive/web/certid/current/msg00427.html )
in Section 4.6.4 addressed?
Yes, we believe so.
thanks again for your review,
Indeed.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf