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

From: =JeffH <[email-masked]>
Date: Wed, 08 Dec 2010 11:14:34 -0800

[ 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)

 > 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"

..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])

 > 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,

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 14:44:18 -0700

On 12/8/10 12:14 PM, =JeffH wrote:
> 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)..
> 
> "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.

>   "fully-qualified DNS domain name portion"

Done.

> 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..
> 
> You mean removing the parenthetical "(following the definition of
> "label" from [DNS])", yes?
> 
> 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..
> 

Done.

> 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.
> 
> 

Indeed.

Peter

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

---

From: SM <[email-masked]>
Date: Fri, 17 Dec 2010 01:28:28 -0800

Hi Jeff,
>[ adding certid@ list ]

I suggest following up on the [email-masked] mailing list and dropping ietf@.

>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)..
>

I'll go with John Klensin's argument for simplicity.

>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)

Agreed (in this context).

>..however, I disagree with your further simplification of that 
>paragraph because we feel we need to supply the more detailed context.

I'll comment on this below.

>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..
>

That sound good.

>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..
>

That's fine to me.

>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.

This brings us to the question of the DNS specific usage of "domain 
names" and when the term is used in an application context.

For example, is the left-most part in "foo*.example.com" ( 
draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label?

I'll react to some comments from Cullen Jennings.

At 23:17 15-12-10, Cullen Jennings wrote:
>So let me start with I think there is great information in here and 
>I think it should be published as a standards track RFC however I do 
>think there are some issues with the relation with this draft and 
>the realities of what would help improve security in deployment of 
>SIP, HTTP, IMAP, XMPP etc.

The information in draft-saintandre-tls-server-id-check is 
helpful.  It's been a mouthful to comment on the draft as it requires 
the reading of several referenced documents first.  This in itself 
gives us an idea of the breath this draft tries to cover.

>process review. Next this draft contradicts the procedures in 
>existing protocols and says that it does not apply to the existing 
>protocols but that it would take precedence over any future updates 
>of existing protocols that use TLS within the scope specified here. I

That begs the question about whether this draft should be a BCP.  I 
would feel more comfortable if such a document is carefully reviewed 
by people from the different application groups it touches on as it 
attempts to shape the future.  This is not to say that there hasn't 
been enough discussion about the draft or that it did not get 
adequate socialization.  If the authors are of the opinion that there 
has been that breath of review, I am fine with that.

>In section 3.2, in the imap example, you are saying that if I 
>configure my imap server to mail.example.com and it presents a 
>certificate with a DNS-ID of example.com that this is OK. That does 
>not sound OK to me but I don't know how IMAP works. In the SIP example, the

Consider an email address of "[email-masked]".  The IMAP service is 
discovered by the MUA by doing a DNS SRV lookup on _imaps.example.com 
( draft-daboo-srv-email ) and the target is mail.example.net, i.e 
that's where the IMAP server is running.  The certificate provides a 
SRV-ID of "_imaps.example.com" and a DNS-ID of "example.com".

BTW, the reference to draft-ietf-tls-rfc4366-bis could be normative 
for the reader to understand SNI and not rely on the workaround for 
multiple identifiers.

Regards,
-sm