Subject: Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Jul 2010 16:29:07 -0700

At 4:08 PM -0700 7/15/10, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Representation and Verification of Domain-Based Application Service
>   Identity in Certificates Used with Transport Layer Security '
>   <draft-saintandre-tls-server-id-check-08.txt> as a Proposed Standard

The middle of Section 4.2 says:
   The client then orders the list in accordance with the following
   rules:
Then, in 4.3, it checks each reference in this ordered list until it (hopefully) finds a match. Given that it is going to do an exhaustive search, what is the purpose of ordering?

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Jul 2010 05:22:14 -0400

--On Thursday, July 15, 2010 16:08 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from an individual submitter
> to consider  the following document:
> 
> - 'Representation and Verification of Domain-Based Application
> Service     Identity in Certificates Used with Transport Layer
> Security '    <draft-saintandre-tls-server-id-check-08.txt> as
> a Proposed Standard

Hi.

These are sort of nits, but they do identify areas where the
document is substantively incorrect and subject to
misinterpretation:

(1) In Section 4.4.1, the reference should be to the IDNA2008
discussion.  The explanations are a little better vis-a-vis the
DNS specs and it is a bad idea to reference an obsolete spec.

(2) In Section 4.4.2, note that there are definitional and
procedural problems if one tries to talk about a single rule for
full domain names.  It is possible, and has been the only option
until very recently, for a fully-qualified IDN to contain both
"traditional" and "internationalized" labels.  IDNA2008 avoided
a number of definitional problems by being defined strictly in
terms of labels for just that reason.   In particular,
conversion of an all-ASCII label to an A-label is undefined and
meaningless: such a label is not a U-label and hence cannot be
converted.  One needs to parse the string into labels, determine
for each label whether it is "traditional" or
"internationalized", and then apply the appropriate rule. I'd
recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not
FQDNs.

(3) Note that anything that requires that an application program
parse a FQDN that might be an IDN into labels should probably
have a Security Considerations note about the risks if various
dotoids leak into the relevant environment.

best,
    john

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Jul 2010 08:42:27 -0700

>DNS specs and it is a bad idea to reference an obsolete spec.

+1. I accept blame on this one, since I was tasked on an earlier version to bring the IDNA discussion up to date.

>recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not

Here we (may) disagree. 4.4.2 is already in terms of labels:
   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 anme.
Are you saying that the correct wording should elide "If the source domain of a reference identifier is an internationalized domain name, then" and just start at "An implementation MUST"? That would work for me.

>dotoids leak into the relevant environment.

Errrr, why should this document be forced to have such a warning when the IDNA2008 documents don't?

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Jul 2010 20:57:21 -0400

--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman
<[email-masked]> wrote:

>...
>> procedural problems if one tries to talk about a single rule
>> for full domain names.  It is possible, and has been the only
>> option until very recently, for a fully-qualified IDN to
>> contain both "traditional" and "internationalized" labels.
>> IDNA2008 avoided a number of definitional problems by being
>> defined strictly in terms of labels for just that reason.
>> In particular, conversion of an all-ASCII label to an A-label
>> is undefined and meaningless: such a label is not a U-label
>> and hence cannot be converted.  One needs to parse the string
>> into labels, determine for each label whether it is
>> "traditional" or
>    internationalized domain name, then an implementation MUST
> convert    every label in the domain name to an A-label before
> checking the    domain name.

> Are you saying that the correct wording should elide "If the
> source domain of a reference identifier is an
> internationalized domain name, then" and just start at "An
> implementation MUST"? That would work for me.

That would probably be an improvement.  But my problem was with
"every label" and a sticky detail of IDNA2008: the only things
that can be converted to A-labels are U-labels.  One cannot
convert an LDH label to an A-label, nor can one convert
something that was already an A-label into an A-label.  Those
operations are just not defined.  So I think this should be
"every internationalized label" or (probably better) "every
non-traditional label" or something to that effect.

>> (3) Note that anything that requires that an application
>> program parse a FQDN that might be an IDN into labels should
>> probably have a Security Considerations note about the risks
>> if various dotoids leak into the relevant environment.
> 
> Errrr, why should this document be forced to have such a
> warning when the IDNA2008 documents don't?

The IDNA2008 base document sort of dodge the problem by dealing
with labels, not FQDNs.  If I recall, you have some "beware of
leaks" language in Mapping, but I might be wrong.  In any event,
the reason it occurred to me as something that might be useful
to say here is that the functions of this document would be,
IMO, particularly sensitive to having someone want to store a
name with the local label separator convention and that would be
a problem.  Possibly not more serious than other places, but
still possibly worth mentioning.  

In any event, I consider the topic worth mentioning but
definitely not a showstopper.

    john

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Jul 2010 19:05:27 -0700

>non-traditional label" or something to that effect.

Sounds good to me. Suggested edit for Paul and John to sing kumbaya:

4.4.2.  Checking of Internationalized Domain Names

   The term "internationalized domain name" refers to a DNS domain name
   that conforms to the overall form of a domain name (dot-separated
   labels) but that can include Unicode code points outside the
   traditional US-ASCII range, as explained by and [IDNA2008].

   An implementation MUST convert every non-traditional label in the
   domain name to an A-label before checking the domain name.

>with labels, not FQDNs. 

... fully dodge...

>If I recall, you have some "beware of
>leaks" language in Mapping, but I might be wrong. 

We talk a bit about leaking into the app; this document is about certs and identities, and those identities don't necessarily come from the apps.

>In any event,

But this would cause a false negative, not a false positive. It seems to me to be the same as many false negatives such as the app storing U+00B2 instead of U+0032.

>definitely not a showstopper.

Agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Jul 2010 23:05:20 -0400

--On Saturday, July 17, 2010 19:05 -0700 Paul Hoffman
<[email-masked]> wrote:

>> name with the local label separator convention and that would
>> be a problem.  Possibly not more serious than other places,
>> but still possibly worth mentioning.
> 
> But this would cause a false negative, not a false positive.
> It seems to me to be the same as many false negatives such as
> the app storing U+00B2 instead of U+0032.

Yes, absolutely.   And, again, if we disagree, it is about
whether the issue is worth mentioning, not whether avoiding
mentioning it would be some sort of showstopper.  I think it is
marginally worth mentioning.  You may think it marginally not
worth the bits.  But I can't imagine either of us losing a lot
of sleep about either outcome.

>> definitely not a showstopper.

Yes.  See above.
    john

---

From: Shumon Huque <[email-masked]>
Date: Sat, 17 Jul 2010 23:29:12 -0400

On Thu, Jul 15, 2010 at 04:29:07PM -0700, Paul Hoffman wrote:
> Then, in 4.3, it checks each reference in this ordered list until
> it (hopefully) finds a match. Given that it is going to do an
> exhaustive search, what is the purpose of ordering?

Not sure I'm following your question, but the purpose of ordering
is to look for the subject identities in preference order (SRV/URI,
before dNSName, before Common Name etc). Once a match is found,
the search is aborted; an exhaustive search is only performed if
the matched identity is the last one or there is no match. Section
4.3 has:

   It does so by seeking a match in preference order
   and aborting the search if any presented identifier matches one of
   its reference identifiers.  The search fails if the client exhausts
   its list of reference identifiers without finding a match.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 18 Jul 2010 08:17:22 -0700

>   its list of reference identifiers without finding a match.

I understand that, but what is the advantage of searching in the preferred order over, say, searching in random order of the pile? I don't see an advantage of getting a result from the more-preferred identity if you are eventually going to accept anything.

If there is no advantage, the "sort the pile before searching" step adds complexity without benefit, and thus should be dropped. If there is some advantage, I'm fine with it being there.

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Sun, 18 Jul 2010 13:59:59 -0400

> If there is no advantage, the "sort the pile before searching" step adds complexity without benefit, and thus should be dropped. If there is some advantage, I'm fine with it being there.

Well, one reason would be to reduce the number of verification
steps imposed on a client by a certificate with a more preferred
or more specific identity type.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 18 Jul 2010 15:04:55 -0700

>or more specific identity type.

Is there something more than just a non-mandatory optimization? The three bullet points in the list all have MUSTs, and it sounds like these MUSTs, and the statement that "The client then orders the list in accordance with the following rules" passes muster with RFC 2119.

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Mon, 19 Jul 2010 19:16:40 -0400

On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote:
> Is there something more than just a non-mandatory optimization? The
> three bullet points in the list all have MUSTs, and it sounds like
> these MUSTs, and the statement that "The client then orders the list
> in accordance with the following rules" passes muster with RFC 2119.
> --Paul Hoffman, Director
> --VPN Consortium

Right, I agree with that.

I'm not clear on whether you're objecting to an ordering rule. Or
saying that the additional text in 4.3 about ordering is unnecessary.

I'm not sure I really have a strong opinion on ordering per-se, 
but ..

There are multiple possible identity types. Clients will presumably 
search for them in some order. Should we just tell them to try in whatever 
order they want, including random? Or should we tell them to try in 
the order of identities that we preferred application services to use, 
and move the deprecated ones (CN-ID) to the bottom of that list? 
Optimizing for the preferred use cases sounds to me like a reasonable 
thing to do.

I do have a stronger opinion on the following point: I think there is
a longer term security goal here, of nudging application protocols to
use application specific identity types -- so that we avoid situations
where a certificate with a generic domain name identity, if compromised 
for a particular service, can be used to impersonate other unrelated 
services at that domain name. As a general rule, different application 
services running at the same domain name should not be using the same 
certificates, unless by conscious choice of the deployer.

Having a preferred ordering consistent with that goal is probably
a good thing.

I might be wandering too far away from your specific question now,
so I'll stop.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Jul 2010 17:50:39 -0700

>saying that the additional text in 4.3 about ordering is unnecessary.

I am objecting to a MUST- or SHOULD-level ordering rule where it does not affect interoperability or security. I am still open to someone showing why this particular rule might affect those, but after many rounds, none has come forth, so I am suggesting dropping the rule altogether or making it MAY-level (with some reasoning as to why it is even worth the effort).

>Optimizing for the preferred use cases sounds to me like a reasonable

Why is it reasonable? It is *we* who are preferring the order, not them, even though we admit that any value returned from the order is secure enough.

>certificates, unless by conscious choice of the deployer.

Fully agree, and that is correctly addressed, repeatedly, in the rest of the document.

>Having a preferred ordering consistent with that goal is probably

Arrrgh. Why?

>I might be wandering too far away from your specific question now,

No, please continue. I truly would be happy if you could show why forcing them to order their search would help even though any match would do. I just am not seeing it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Tue, 20 Jul 2010 00:00:43 -0400

> I am objecting to a MUST- or SHOULD-level ordering rule where it does not affect interoperability or security. I am still open to someone showing why this particular rule might affect those, but af…

Fair enough. I don't have a reason to offer beyond the already
mentioned optimization. And as a possible hint to folks about
what the preferred types are. And as I mentioned earlier, I don't
have a strong opinion on this.

This draft is all about matching identities. It should sketch out
the explicit details of some matching algorithm. Is your proposal
to match identities in the order of their appearance in the certificate?
Something else? Or leave this unspecified?

[...]

> Fully agree, and that is correctly addressed, repeatedly, in the rest of the document.

Oh, good. I was beginning to feel after several revisions of text, that 
the draft was not making this point (and the rationale behind it)
strongly enough!

[...]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Jul 2010 09:25:43 -0600

Sorry, I haven't yet had a chance to review the feedback that's been
provided during this Last Call. I'll do that en route to Maastricht
today. Next week Jeff and I will discuss in person the points that have
been raised, and then we'll post further regarding our proposed changes
to the spec.

Peter

On 7/15/10 5:08 PM, The IESG wrote:
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-08-12. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Shumon Huque <[email-masked]>
Date: Thu, 29 Jul 2010 23:44:16 -0400

Peter,

I'm not sure if this one is already on your list or not, but I
didn't see it addressed in -08:

I don't think the characterization of SRV-ID as an "indirect"
(ie. DNS resolved) identifier is correct.

Whether a subject name is indirect or not, depends on the content
of the identifier field and how that content was obtained, rather 
than on the identifier type itself.

In most cases, indirect identifiers will be found in DNS-ID or CN-ID, 
as a result of DNS resolution of SRV, CNAME, or other records. If an 
application is trying to authenticate such identities, then the 
document needs to clearly state under what conditions it is safe to 
do so (DNSSEC, or a static mapping rule in the client). The document
does touch on safe derivation rules later (currently in 4.2). But the
direct/indirect classification of identity types needs to be 
corrected (or just eliminated).

I said some more here:

    http://www.ietf.org/mail-archive/web/certid/current/msg00220.html

On Fri, Jul 23, 2010 at 09:25:43AM -0600, Peter Saint-Andre wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf