Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check

From: "James Schaad" <[email-masked]>
Date: Mon, 6 Sep 2010 22:14:33 -0700

1.  There are those who say that the DNS system is dead for dealing with
identification of items.  That the main way that people find items these
days is by doing  searches.  This should perhaps be acknowledged in section
1.3 under the DNS domain names section.  I.e. we use DNS names still for
some things (such as SMTP servers), but for many things the name that the
user knows is obtained in a very indirect manner. (search, URL click,
address book entry)  In a similar manner today people don't remember
telephone numbers as they are all indirectly obtained, but they do write
them down to give to other people.

2.  Do you consider an HTTP redirect to still be a direct name or is this
now an indirect name?  The simplest method would be to go from an http: to
an https: but other types of redirects are also interesting - not the least
is just clicking w/o actually looking at where you are going.

3.  You might want to also give a domain-component (dc=) version of the
common name for doing identifiers - and then say it is out of scope.  i.e.
"dc=com, dc=example, dc=www"

4.  You might want to add to the implementation note on page 15 that there
is not always agreement about the order that the strings should be displayed
in.  Thus for some the root RDN is displayed first but for others it is
displayed last.  (Thus the CERT_NAME_STR_REVERSE_FLAG for the CertStrToName
function from Microsoft.)

5.  In section 3, what about URI-ID and SVN-ID - are multiple of these name
forms allowed or not?  Since 5 is explicit on CN-ID and DNS-ID I think that
the other two name forms should be covered as well.

6.  I am not really happy with the choice of wording for 'and aborting the
search' - in my mind you abort for bad conditions and not for good
conditions.  Stop the search, exit the search are all reasonable and don't
imply an error state.

7.  I got confused and started to say that you needed to do wildcards in
section 4.4.1 because that is not referenced in the text of section 4.4.  It
is not clear how the wildcard label matching should be done dependent on the
tradition vs. internationalized domain name difference.

The client MUST match the source domain of a reference identifier
according to the following rules.  The rules used depends on whether the
source
domain is a "traditional domain name" or an "internationalized domain
name" as previously defined, and if wildcard labels are permitted.

8.  Does the following statement apply in section 4.4.2?  What does it mean
for 4.4.1 if a wildcard is present? 

        Each label MUST match in order for the names to be considered to
match.

                I think that it is confusing and should potentially be
removed.

9.  In section 4.6.2 - I can understand that a certificate "change" by
having the certification path change.  However if one were to change the DNS
domain name, identifiers, issuer or expiration date, I don't understand how
one would say that it is the same cached certificate?  Do you expect clients
to cache the certificate based one something other than the actual bytes of
the certificate?  i.e. the public key and subject name?   Or are you trying
to address the case where for the specific reference identifier there exists
a cached certificate and the certificate that was presented is a different
certificate from the one that was cached?  (In which case one should
potentially say that one needs to fall into the 4.6.3 logic after informing
the user of the fact.)

From: Joe Salowey [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2010 8:14 PM
To: [email-masked]; Sean Turner; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Review of draft-saintandre-tls-server-id-check

At IETF-78 you accepted the task of reviewing
draft-saintandre-tls-server-id-check.   We'd like to get this draft moving
and we think it needs wide review.  Please let me know when you think you
will be able to complete a review of the draft. 

Thanks,

Joe

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 12:41:15 -0600

Thanks for your careful review. Comments inline.

On 9/6/10 11:14 PM, James Schaad wrote:
> days is by doing  searches.  This should perhaps be acknowledged in
> section 1.3 under the DNS domain names section.  I.e. we use DNS names
> still for some things (such as SMTP servers), but for many things the
> name that the user knows is obtained in a very indirect manner. (search,
> URL click, address book entry)  In a similar manner today people don’t
> remember telephone numbers as they are all indirectly obtained, but they
> do write them down to give to other people.

Yes, that is a good point. Complicated, but good. We somewhat address it
in this paragraph:

      Finally, we do not discuss attributes unrelated to DNS domain
      names, such as those defined in [X.520] and other such
      specifications (e.g., organizational attributes, geographical
      attributes, company logos, and the like).

It seems to me that this relates to the expectations of human users more
than our relatively clear-cut discussion of DNS domain names. For
example, supposedly some large percentage of the searches on Yahoo! are
for "Google" (and vice-versa); clearly the folks who are doing such
searches are from our perspective rather unsophisticated users of the
Internet, and they might know that they're on "Google" when they see the
company logo (which changes on special days!) not when they see
"http://www.google.com/" in the address bar of their browser. The
authors of this I-D have not completed any research into the
expectations of such users (although Jeff has better knowledge of the
literature than I do), so it seems inappropriate for us to say much
about the matter. However, I agree that this would be a good topic for
further research and discussion (e.g., perhaps "petnames" might make
sense here).

> 2.  Do you consider an HTTP redirect to still be a direct name or is
> this now an indirect name?  The simplest method would be to go from an
> http: to an https: but other types of redirects are also interesting –
> not the least is just clicking w/o actually looking at where you are going.

IMHO the name received via an HTTP redirect is an indirect name (e.g., I
typed "exmaple.com" but my browser is redirected to "example.com").
Naturally that applies only to domain redirects -- a redirect from one
URL to another URL within the same domain would preserve the same DNS
domain name for identity checking purposes.

> common name for doing identifiers – and then say it is out of scope. 
> i.e.  “dc=com, dc=example, dc=www”

Earlier versions of this I-D (up through -06) talked about domain
components as something not to do, but that seems to have caused more
confusion than clarity so we removed the text.

> 4.  You might want to add to the implementation note on page 15 that
> there is not always agreement about the order that the strings should be
> displayed in.  Thus for some the root RDN is displayed first but for
> others it is displayed last.  (Thus the CERT_NAME_STR_REVERSE_FLAG for
> the CertStrToName function from Microsoft.)

Yes, there was much discussion about that topic on the [email-masked] list.

We currently have this sentence:

      However, because
      a Relative Distinguished Name (RDN) is an unordered group of
      attribute-type-and-value pairs, the string representation of an
      RDN can differ from the canonical DER encoding.

Does adding the parenthetical clause at the end of the following text
address your concern?

      However, because
      a Relative Distinguished Name (RDN) is an unordered group of
      attribute-type-and-value pairs, the string representation of an
      RDN can differ from the canonical DER encoding (and the order of
      attribute-type-and-value pairs can differ in the string
      representations or display orders provided by various
      implementations).

> 5.  In section 3, what about URI-ID and SVN-ID – are multiple of these
> name forms allowed or not?  Since 5 is explicit on CN-ID and DNS-ID I
> think that the other two name forms should be covered as well.

I agree that we need to be clear about that, and I think that it is
acceptable to include multiple instances of those identifier types.

> 6.  I am not really happy with the choice of wording for ‘and aborting
> the search’ – in my mind you abort for bad conditions and not for good
> conditions.  Stop the search, exit the search are all reasonable and
> don’t imply an error state.

In the working copy I've changed "aborting" to "stopping".

> section 4.4.1 because that is not referenced in the text of section
> 4.4.  

Yes, adding a forward pointer from 4.4 to 4.4.3 makes sense.

> It is not clear how the wildcard label matching should be done
> dependent on the tradition vs. internationalized domain name difference.
>
>    source domain is a "traditional domain name" or an "internationalized
>    domain name" as previously defined, and if wildcard labels are permitted.

I see your point. In our working copy I've adjusted Section 4.4 to read
as follows (thus pointing to the sections that follow):

###

4.4.  Verifying a Domain Name

   The client MUST match the source domain of a reference identifier
   according to the following rules.  The rules differ depending on
   whether the source domain is a "traditional domain name" or an
   "internationalized domain name" (as previously defined).
   Furthermore, the source domain (whether a traditional domain name or
   an internationalized domain name) might contain the wildcard
   character '*' as the left-most label, so we define a supplemental
   rule for so-called "wildcard domains".  Finally, we specify the
   circumstances under which it is acceptable to check the "CN-ID"
   identifier type.

###

> 8.  Does the following statement apply in section 4.4.2?  What does it
> mean for 4.4.1 if a wildcard is present?
> 
>         Each label MUST match in order for the names to be considered to match.
> 

Yes, that applies to both traditional domain names and internationalized
domain names. I have added the sentence to the paragraph in Section 4.4.2.

However, I have slightly modified the text to address your point about
wildcard labels, as follows:

###

4.4.1.  Checking of Traditional Domain Names

   If the source domain of a reference identifier is a "traditional
   domain name", then matching of the reference identifier against the
   presented identifier is performed by comparing the set of domain name
   components using a case-insensitive ASCII comparison, as clarified by
   [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to
   "www.example.com" for comparison purposes).  Each label MUST match in
   order for the names to be considered to match, except as supplemented
   by the rule about checking of wildcard labels (Section 4.4.3).

4.4.2.  Checking of Internationalized Domain Names

   If the source domain of a reference identifier is an
   internationalized domain name, then an implementation MUST convert
   every label in the domain name to an A-label before checking the
   domain name.  Each label MUST match in order for the names to be
   considered to match, except as supplemented by the rule about
   checking of wildcard labels (Section 4.4.3).

4.4.3.  Checking of Wildcard Labels

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   contains one instance of the wildcard character '*', but only if that
   character is the complete left-most label of the domain name, e.g.
   *.example.com (following the definition of "label" from [DNS]).

   If the wildcard character '*' is the complete left-most label of a
   traditional domain name or internationalized domain name, the
   wildcard MUST be used to match only the one position-wise
   corresponding label (thus *.example.com matches foo.example.com but
   not bar.foo.example.com or example.com).  The client MUST fail to
   match a presented identifier in which the wildcard character is
   contained within a label fragment (e.g., baz*.example.net is not
   allowed and MUST NOT be taken to match baz1.example.net and
   baz2.example.net), or in which the wildcard character does not
   comprise the left-most label in the presented identifier (e.g.,
   neither bar.*.example.net nor bar.f*o.example.net are allowed).

   [...]

###

> 9.  In section 4.6.2 – I can understand that a certificate “change” by
> having the certification path change.  However if one were to change the
> DNS domain name, identifiers, issuer or expiration date, I don’t
> understand how one would say that it is the same cached certificate?  Do
> you expect clients to cache the certificate based one something other
> than the actual bytes of the certificate?  i.e. the public key and
> subject name?   Or are you trying to address the case where for the
> specific reference identifier there exists a cached certificate and the
> certificate that was presented is a different certificate from the one
> that was cached?  (In which case one should potentially say that one
> needs to fall into the 4.6.3 logic after informing the user of the fact.)

We care about the latter case, which means we can simplify the text in
Section 4.6.2, as follows:

###

4.6.2.  Case #2: No Match Found, Cached Certificate

   If the client finds no presented identifier that matches any of the
   reference identifiers but a natural person has permanently accepted
   the certificate during a previous connection attempt or via
   configured preferences, the certificate is cached.  In this case, the
   client MUST verify that the presented certificate matches the cached
   certificate; if the presented certificate does not match the cached
   certificate then the client MUST proceed as described under Case #3
   below.

###

Thanks again for the review.

Peter

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

---

From: "James Schaad" <[email-masked]>
Date: Mon, 13 Sep 2010 23:01:45 -0700

Here are some additional comments inline.

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Monday, September 13, 2010 11:41 AM
> To: James Schaad
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check
> 
> > URL click, address book entry)  In a similar manner today people don�t

I agree that there is an issue.  I disagree that this is discussed in any way.  I read the paragraph above as addressing the question of additional attributes that might appear in a certificate (such as logotypes) and not as dealing with additional attributes that are displayed on the screen or indirectly inferred by the user.  I still think that a (short) discussion to the fact that in some cases where the user did not explicitly enter the reference identifier, there may be cases that even though all of the details match -- the user will be at an unexpected location.  (This is after all what a phishing attack is all about.)

> > http: to an https: but other types of redirects are also interesting �

I agree that this is a case of an indirect name.  I think therefore that you need to look at the table in section 2.1 and change the URI-ID to be "Either" rather than "Yes" in the Direct column.  And yes I agree that if the URL that you are redirected to has the same Domain Name, then it is a moot point.

> > common name for doing identifiers � and then say it is out of scope.
> > i.e.  �dc=com, dc=example, dc=www�
> 

I understand.

>       representations or display orders provided by various

Sorry - I  did not make myself sufficiently clear.  There are cases where the RDNSequence (a SEQUENCE and therefore ordered) is displayed in reverse order.  This is what the flag does.  Inside of the RDNSequence is a RelativeDistinguishedName which is a SET an therefore does not have order.

The order of the RDNSequence is ordered since it is in fact a sequence.  What is not ordered is the attribute value pairs that make up a RelativeDistinguishedName.

Generally an RDN is the same as the RDNSequence.

Going back and re-reading the text.  It is clear that there is going to be some confusion about what names are and what the fields of names are.  Certificates use the type RDNSequence as the "Name" field of a certificate.  This corresponds to the DN that you are talking about in the text.  They use the longer RelativeDistinguishedName type as the RDN that you are talking  about in the text.  Without some clarification someplace, there is bound to be some confusing popping up. 

> 
> > 5.  In section 3, what about URI-ID and SVN-ID � are multiple of these

I would think that having multiple SVN-IDs make sense - esp since you can get multiple values from the DNS on the indirect.  I am not so sure that it makes any more sense to allow for multiple URI-ID values unless they are in the same DNS space - for the same reasons that it does not make sense to allow for multiple DNS-ID records to be presented.

> 
> > 6.  I am not really happy with the choice of wording for �and aborting
> > the search� � in my mind you abort for bad conditions and not for good
> > don�t imply an error state.
> 

Yes this addresses my issue.

>    circumstances under which it is acceptable to check the "CN-ID"

Looks good

>    neither bar.*.example.net nor bar.f*o.example.net are allowed).

Looks good

> 
> > 9.  In section 4.6.2 � I can understand that a certificate �change� by
> > DNS domain name, identifiers, issuer or expiration date, I don�t

Did you mean to lose the case where the certification chain has been modified from the time where the natural person accepted the certificate?  I can see this as being one case where a different processing might need to occur.

Jim