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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
