Re: [certid] Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP

[Peter Saint-Andre <[e-mail]>]

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/