Subject: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Sep 2010 14:20:22 -0600

FYI.

-------- Original Message --------
Subject: secdir review of draft-saintandre-tls-server-id-check-09
Date: Tue, 14 Sep 2010 17:39:40 -0400
From: Barry Leiba <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Please forgive the lateness of this review; I really meant to have it
done sooner.

First, I found the document to be a tough read, and I can't really pin
down why.  I started reviewing it several times, and restarted, before
I finally got through it.  I can't give any advice with this comment,
so just take it as it is.

Second, there's a mixture of "natural person" and "human user" in the
document, and my sense is that you mean the same thing by both.  If
you do, you should switch to one term (I prefer the latter; "natural
person" sounds odd).  If they're meant to be different, you should
make it clear what the difference is.

Third, I'll note the earlier discussion of issues with IDN
comparisons.  I have nothing to add to that discussion, and it may be
that the best thing is to leave things as they are.

Comments are in order of appearance, not significance:

-- Page 16, bullet 6:
       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's
a question.

-- Page 17, sec 4.2, first graf:
   Before connecting to the server, the client MUST construct a list of
   acceptable reference identifiers.

Why MUST it be done "before"?  Can anyone detect, or does it hurt
interoperability, if it's done, say, in parallel with connection, or
while the client is waiting for the server to return the certificate?

-- Page 18, sec 4.2, last bullet:
   o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
      included) MUST be constructed only from the source domain and
      never from a target domain.

I find this oddly put.  How about "The list SHOULD NOT include a
CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

I'd also like to take the security note from section 4.3 and echo it
here.  So maybe this?:

<< The list SHOULD NOT include a CN-ID.  If a CN-ID is used despite
this advice, it MUST be constructed only from the source domain and
never from a target domain.  Further, it MUST NOT be used unless there
are no other supported identifiers present in the certificate. >>

-- Page 18, sec 4.3, first graf:
   by seeking a match and aborting the search if any presented
   identifier matches one of its reference identifiers.

"Aborting" has the connotation of premature termination, before
completion, and that's not the case here; you're saying that the match
completes the process.  How about, simply, "stopping", or "ending" ?

-- Page 19, sec 4.4.3:
I think implementers might think that you're simply allowing any
leading wildcard character, so we should explicitly dissuade them.

So, in the first graf:
   the wildcard character '*', but only as the left-most label of the
   domain name,
make it "only as the complete value of the left-most label".

And in the second graf:
   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)
change to:
   baz1.example.net and baz2.example.net; also, *bozz.example.net is
   not allowed and MUST NOT be taken to match frobozz.example.net)

-- Page 19, sec 4.4.3, last graf:
   A specification that references the rules defined in this document
   can specify that the wildcard character is not allowed in
   certificates used by the relevant application protocol or community
   of interest.

How about “...can strengthen this section by ruling out wildcard
matching altogether for the relevant...” ?

-- Page 20, sec 4.4.4, second graf:
   entry types supported by the client), the client MAY as a fallback
   check for a string whose form matches that of a fully-qualified DNS
   domain name in the CN-ID.

Back in section 4.2, you say that the client SHOULD NOT include CN-ID
in the list, and here you're saying that it MAY make such a
comparison.  That seems oddly contradictory to me, though one can
certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this
worded differently.

-- Page 21, sec 4.6.2:
   client MUST verify that the presented certificate matches the cached
   certificate and (if it is an interactive client) MUST notify the user
   if the certificate has changed since the last time a secure
   connection was successfully negotiated (where causes of change
   include but are not limited to changes in the DNS domain name,
   identifiers, issuer, certification path, and expiration date).

I worry about this kind of advice.  It violates my rule that says,
"Don't ask the user a question that he's not qualified to answer."  Of
course, "notify the user" can mean a lot of things, but too many
clients will implement something like this with a popup that will be
meaningless to 99% of the people who use it.

-- Page 21, sec 4.6.3, last graf:
   Instead, the client MUST proceed as follows.

I like a colon there, instead of the full stop.

-- Page 21, sec 4.6.3.1, security note:
      caution, for example by first encouraging the user to terminate
      the connection, forcing the user to view the entire certification
      path, and allowing the user to accept the certificate only on a
      temporary basis (i.e., for this connection attempt and all
      subsequent connection attempts for the life of the application
      session).

Same comment as for 4.6.2.  Most users will not understand certificate
problems, and will have no idea what they should do about them.
Always remember the "Barry's mother problem".  My mother will *never*
want to see an "entire certification path", let alone appreciate being
"forced" to.

-- Page 22, sec 5.1:
   When the connecting application is an interactive client, the source
   domain name and service type MUST be provided by a human user (e.g.
   when specifying the server portion of the user's account name on the
   server or when explicitly configuring the client to connect to a
   particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
   the user inputs in an automated fashion (e.g., a host name or domain
   name discovered through DNS resolution of the source domain).  This
   rule is important because only a match between the user inputs (in
   the form of a reference identifier) and a presented identifier
   enables the client to be sure that the certificate can legitimately
   be used to secure the connection.

Does this mean that a client specifically designed for the "gumbo"
service can't automatically use the service type "gumbo", without the
user's involvement?  Or that a client put out by example.net can't
assume a host name of services.example.net in the absence of user
input that says otherwise?

Further, it's entirely reasonable for a program to have a user enter
something like "gmail", and have the client turn that into something
like "mail.google.com", deriving it from the user's input in an
automated fashion.  Do we really want to forbid that sort of thing?

--
Barry Leiba

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Sep 2010 16:58:03 -0700

> automated fashion.  Do we really want to forbid that sort of thing?

That strikes me as an awfully blase comment for a security review.  Whatever process translates the user input into the name that's used to verify the server's id is a critical part of the verification.  If you can subvert the translation, then you can subvert the server ID check, which is the whole point of this draft.

I'm not opposed to the idea of name canonicalization, but it has to be done in an authoritative, secure fashion, and that's probably out of scope for this draft.

For discussion's sake, how about changing the MUST NOT to SHOULD NOT and adding a big "here there be dragons" to the text?  I might prefer leaving it as-is, since we can always write a new RFC that defines how the automated translation can be done in a safe way.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Sep 2010 03:08:28 +0200 (MEST)

some personal comments on (parts of) Barry's review.

> Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's

This was supposed to be a BCP.  The current implementation practice
is that many existing clients honor/match only the "most specific" CN
(as per rfc-2818), but do _not_ abort when multiple CNs are present,
and a small number of clients match all CNs.

A "MUST NOT" would be a change to what is out there any make the
entire installed base non-compliant that does not abort on the presence
of multiple CN AVAs in a server cert.

But there is another issue.  This document is directed to a non-obviously
large and diverse target audience, and takes short cuts.

  - Server admins MUST NOT create or request server certs with multiple
    CN-IDs.
  - CAs MUST NOT sign/issue server certificates with multiple CN-IDs.
  - Servers should not use certificates with multiple CN-IDs.
  - Clients SHOULD NOT match CN-IDs if SRV-IDs or DNS-IDs are present
    in a server cert.  If client match CN-IDs anyhow, as a fallback
    for server certs without SRV-IDs and DNS-IDs, then they should
    match only the "most specific" CN as per rfc-2818.
  - architecture-wise I personally think of the CN-ID match as a
    fallback for DNS-ID matching rather than an entirely seperate
    reference identifier.

> while the client is waiting for the server to return the certificate?

This imperative MUST is underexplained.  It's likely possible to
convey the underlying idea without an rfc2119 imperative.

rfc-2119 MUST and MUST NOT always translate to code in the
implementation and to test cases for compliance in validation
test suites.  "needs to / will have to", while conveying a very similar
message at the natural language level, doesn't have such impact on the code.

The client consists of several different layers/components,
The application client (above TLS) and the TLS client implementation.

What is probably meant is that the application client needs to produce
a list of acceptable reference identifiers before asking the TLS
client implementation to start a TLS handshake.  The TLS client
implementation will need the DNS-ID for composing a TLS ClientHello
with a TLS extension "Server Name Indication" (SNI).

As a rule of thumb (netiquette/politeness), you should make up your mind
whether you want to enter before you rap on a door (dial a phone number
or connect some network service) in order not to annoy those who answer. :)

> CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

I think its fine to use the term CN-ID when describing actual components
of a certificate, but for the actual matching of the server endpoint
identity, I would always implement CN-ID matching as a fallback of DNS-ID
matching, not as matching of a conceptually distinct reference identifier.

> completes the process.  How about, simply, "stopping", or "ending" ?

maybe "succeeding the search" or "successfully stop the search"?

> make it "only as the complete value of the left-most label".

Now that you mention it:

4.4.3. Checking of Wildcard Labels

This is in clear contradiction to the wildcard matching specified
in rfc-2818 Section 3.1.  And without any rationale for this U-Turn,
that seems to be entirely inappropriate for a BCP.

In my implementation of RFC-2818 wildcard matching, I deliberately
ignore DNS names that contain more than one wildcard character,
have a wildcard character in different but the leftmost label 
or have a wildcard character and less than 3 DNS labels.
But I certainly do the substring match specified in rfc-2818
and I'm not going to remove the substring match from my
implementation without a convincing rationale...

What exactly is the benefit of allowing a full wildcard match but
prohibiting a partial/substring wildcard match of the leftmost label?

>    certificates used by the relevant application protocol or community

To me this sounds awkward.  It implies that either the CA has a flawed CPS
can not appropriately deal with wildcard reference identifiers in certs,
or is in general not trustworthy or that the wildcard-scheme too dangerous
(=too difficult to handle safely) for server admins.

> certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this

Yup, there is a disconnect.  Although at the colloquial level,
"should not" is often treated as a "may", there is a sigificant
difference for these imperatives in technical specs.

  SHOULD NOT   http://tools.ietf.org/html/rfc2119#section-4
  MAY          http://tools.ietf.org/html/rfc2119#section-5

MAY indicates something truely optional, completely at the discretion
of the target audience of this imperative, not requiring considerations
one way or the other, whereas "SHOULD NOT" is a clear recommendation, that
requires a rationale in the spec so that the target audience of
this imperative can "understand and carefully weigh the full implications"
before deciding to not follow the recommendation.

> "Don't ask the user a question that he's not qualified to answer."

SSH's traditional behaviour in a comparable situation would be to
print a warning an fail (no offering of an _easy_ leap-of-faith
override for something that shouldn't happen).

What confuses me is that 4.6.1 + 4.6.2 + 4.6.3 would allow a server,
which originally offered an inadequate server certificate which the
user manually confirmed, to unconditionally and silently bypass
the users manual confirmation with appropriately looking server cert
from any arbitrary trust anchor.  This doesn't seem right.

The option of memorizing a server certificate for future reconnects
would significantly improve the security.  Once a client caches
a server cert that is manually confirmed by the user, this could
protect a user on future reconnects to the same server from
an attacker that succeeds subverting a trusted CA.  Even from
full compromise of all CAs by that attacker.  

I wondering why PKIX designed trust in X.509 PKIs so much
different to trust relationship of human beings.

Human Trust starts with initial (leap-of-)faith and grows
stronger over time.  Memorizing server certs and first contact
would match this much better than the traditional Web Browser
model, where the millionth TLS handshake to the same peer
is just as vulnerable to the full scope of attacks as the
very first TLS handshake.  SSH got this one right from the
beginning, whereas in SSL/TLS the absence of secure re-authentication
looks like a genetic defect that has prevailed through all protocol
and browser generations (inherited from X.509 PKI).

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 15 Sep 2010 23:04:43 -0400

> from any arbitrary trust anchor.  This doesn't seem right.

I disagree.  The user's confirmation was to accept the certificate, not
to use it exclusively.  I have taken advantage of this behavior on
https://mattmccutchen.net .

> full compromise of all CAs by that attacker.  

The certificate exception mechanism serves the limited purpose of making
it possible for users to connect to servers with unverifiable
certificates, without which they would be unable to get work done in
some cases.  It looks like you're trying to replace the public-CA trust
model, which is a much more ambitious goal, and it's not clear that your
suggested change to the exception mechanism is anything near an
appropriate or comprehensive solution.  Let's have that discussion
elsewhere and let the server-id-check draft proceed with its original
scope.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 15 Sep 2010 23:47:56 -0400

On Wed, 2010-09-15 at 16:58 -0700, Henry B. Hotz wrote:
> That strikes me as an awfully blase comment for a security review.
> Whatever process translates the user input into the name that's used
> to verify the server's id is a critical part of the verification.  If
> you can subvert the translation, then you can subvert the server ID
> check, which is the whole point of this draft.
> 
> I'm not opposed to the idea of name canonicalization, but it has to be
> done in an authoritative, secure fashion

Exactly.

> and that's probably out of scope for this draft.

Is it?  We may be able to make a useful general statement.  There are
two issues here:

1. "Authoritative": different applications and even users may have
different ideas of what name canonicalization processes are
"authoritative", so all we can ask of compliant implementations is to
document which processes they use.  "Profiles" of server-id-check may
fill in more details.

2. "Secure": given that the point of TLS is to protect against network
attackers, it makes no sense to use a name canonicalization process that
is vulnerable to them.  We can say, "Any process by which the source
domain is derived from user input MUST NOT be subject to subversion by
network attackers", or some such.

Tangent: I know we want to avoid implementations that do foolish things
being claimed as compliant, but IMO, the requirement that input come
from a "human user" is goofy for a technical specification and in
practice a non-starter.  A web browser that followed a HTTP redirection
to a https: URL would violate it.  The web has evolved toward complex
applications in which all pretense that the user is mediating the
issuance of HTTP requests has been abandoned, which brings major
productivity benefits as well as major security implications; ignoring
this would be a mistake.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Sep 2010 07:27:50 +0200 (MEST)

Peter Saint-Andre wrote:
> user's involvement?

The current wording does not seem to adequately illustrate the
characteristics that are important here.

"MUST NOT be derived from the user inputs in an automated fashion"
could be very misleading.  The real problem is with using using
information from untrusted sources or performing transformations
of (originally user-supplied or user-confirmed) untrusted information
prior to matching the server endpoint.

There are situations where the implicit assertion of the
protocol "gumbo" is fully aligned with the intention of the user
and is safe to use for matching SRV-IDs. s/gumbo/xmpp/g  wash,rinse,repeat.

Clearly unsafe operations:

  - building a reference identifier from the result of a
    DNS CNAME lookup (the use of DNSSEC does not make this safe)

  - retrieving the URL to a HTTPS resource from a HTML page
    that was loaded through HTTP based on information provided by the user.

>
>                      Or that a client put out by example.net can't

It depends.
It is OK when it is sufficiently aligned with the users intention
(although some users may not be fully aware of all technical details).

> automated fashion.  Do we really want to forbid that sort of thing?

That should be fine as long at it is sufficiently aligned with the
users intention and this translation is based purely on trusted sources
of information and protected access to these information sources.

This precludes both, DNS and DNSSEC lookups.

Sufficiently protected local configuration options or protected local
mappings should be fine. (meaning protected from changes without
explicit consent and awareness of the user).

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Sep 2010 01:39:15 -0400

On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
>     DNS CNAME lookup

> (the use of DNSSEC does not make this safe)

Why not?  I'm not saying it's good practice, but I don't see an actual
vulnerability.

I agree with everything else you said; nicely put.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 10:11:36 -0400

The question in my view is what you intend to do with the certificate
information.

Let us consider some outsourcing cases:

A)  Alice writes a blog, she has her own DNS name and the Web site is hosted
as a virtual Web server on a machine with 1000 other blogs

B) Bob writes a blog, but he rents use of a whole machine, not just a
virtual partition.

C) Carol writes a blog and also sells T-shirts with witty slogans on that
people buy through a hosted checkout.

D) Doug runs a business with a large e-commerce shop and manages the credit
card data directly.

Question, which ones of these should be using SSL?
Answer, all of them.

Question, which identity should the application client be presenting to the
user.
Answer: Doug is the only party that has a corporate identity.
Alice, Bob and Carol probably don't want to reveal their personal identity
so the only identity we have that we can present is a domain name.

The reason I raise this is that I see several possible conclusions that can
result from cert processing query:

1) Organizational Validation or Extended Validation that establishes
accountability.

2) Certificate is bound to the domain name on which the resolution process
was begun

3) Certificate is bound to a domain name to which the resolution points

4) There is no particular connection between the cert and the domain name.

Which outcome is sufficient depends on whether your objective is to turn on
use of crypto or tell the user that they are safe.

Another point to bear in mind is that applications are not necessarily
applying the traditional SSL model in which the application looks at the
information provided by the Web site and determines if that meets a
particular safety threshold and the user is responsible for working out if
they are safe or not.

For the past five years or so, the model that has been emerging is one in
which the application takes data from multiple sources and fuses them to
establish a safety evaluation. For example, if a domain name is on the
Anti-Phishing Working Group suspicious URL list, the browser might well want
to block access regardless of whether the Web Site has a certificate or not.

So rather than having a spec state what is 'safe' and what is not. We really
need to look at how many potential points of vulnerability have accumulated.

Running Web servers and running DNS servers 24/7 is complex and time
consuming. There are clear economies of scale. So people are inevitably
going to outsource.

The number of potential points of vulnerability are a consequence of the
outsourcing and not the use of CNAME. The use of CNAME is merely a
consequence of the easiest way to implement outsourcing.

More points of vulnerability does not correspond to higher risk. What
matters is the vulnerability of the weakest link in a chain (or the weakest
critical path in a redundant mesh).

On Thu, Sep 16, 2010 at 1:39 AM, Matt McCutchen <[email-masked]>wrote:

> _______________________________________________
> certid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/certid
>

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Sep 2010 17:33:47 +0200 (MEST)

> Why not?  I'm not saying it's good practice, but I don't see an actual

You need two characteristics:

  (1) trustworty information source for a name transformation
  (2) protected access to this trustworthy source

DNSSEC meets (2) but not (1)

DNSSEC provides only data integrity protection and data origin
authentication for the distribution of the informtion, it has
zero impact on the quality, accuracy and trustworthyness of
the underlying information source.

If Wikipedia enables TLS on their web-servers tomorrow so
that you can access it through https://www.wikipedia.org/
what impact will this have on the trustworthyness of the
information in Wikipedia articles?

When there is not change to how others can can access wikipedia
and edit the information there, the impact of you using
TLS to access wikipedia will have exactly zero _impact_ on
the trustworthyness of the information in wikipedia.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 16 Sep 2010 09:55:34 -0700

> (=too difficult to handle safely) for server admins.

<rant>
I believe wildcards are a misfeature, because a wildcard cert doesn't identify the server well enough that it should be trusted.  I believe that "Best Practice" is to never use the feature, and for clients to raise flags if presented with it.

Of course "Current" practice is to make maximal use of the feature because:

1)  nobody understands how to make the names match in real deployments.

2)  the CA's pricing model makes it cheaper to buy a wildcard cert than the full collection of multiple-alias certs you really need.
</rant>

Getting back to the point:  I think it's perfectly appropriate for a Practice document to restrict when and how much you use a Standard feature.

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Sep 2010 20:38:52 +0200 (MEST)

Personally, I do _not_ see a problem with wildcard certs.
And neither with partial/substring wildcard matching defined in rfc-2818.

They're perfectly sensible, but should only be employed with caution
after understanding and carefully weighing the full implications of
the intended usage scenario.

I do see a huge problem with the constant bending of the details
of server name matching.  The proverb says: if you bend it too often
it'll break.

What we currently have is a mess, and applying any further changes,
such as dropping partial wildcard matches while retaining full wildcard
matches and app-specific ignore-wildcard is going to make the mess
bigger and is IMHO a bad idea.

Partial wildcard match will allow you to use one single server cert
for a server farm behind a load-balancing NAT with hostnames such as
 "www1.example.com", "www2.example.com", ... "wwwNN.,example.com"
by using the pattern "www*.example.com" that will neither match
"kdc.example.com", "ldap.example.com", nor "imap.example.com"
To me, that seems significantly more useful than only a full
wildcard match.  The current draft could be read to mean (without a single
word of rationale) that partial wildcard matching is so much more dangerous
than full wildcard matching that MUST NOT be used by anyone anymore.
If this is not removed from the draft, this will result in a completely
inconsistent behaviour within the installed based causing headaches
with no ends to end-users, admins and helpdesks--for those servers
that actively use this sensible alternative to full wildcard
certs as specified in rfc-2818.

One should be looking at the bigger picture, what does changing
the spec mean for the (consistency) accross the installed base?

Start with the history of how server-name matching developed:

1.  matching hostnames to CN-ID

2.  allowing (full) wildcards in CN-ID

3.  matching hostnames to DNS-ID in addition to CN-ID

4. (rfc-2818) recommending DNS-ID, specifying IP-ID, deprecating CN-ID,
   recommending only "most specific" CN-ID matching,
   asking to ignore CN-ID when DNS-ID or IP-ID is present
   specifying partial wildcard match, 

5. TLS server name indication (SNI) explicit non-support of IP-ID
   within SNI, but leaving IP-ID matching based on rfc-2818 perfectly valid.
   unreasonably specifying hostname in SNI with UTF8-encoding,
   instead of IA5-String punicode

6. (draft-saintandre-tls-server-id-check)
   prohibiting partial wildcard match??
   suggesting app-specific wildcard-matching enabling.

Now look at how the work of actually matching has been shared between
the calling application above TLS and the TLS client implementation.

Many TLS implementations offer a convenience/utility function to
application callers of the TLS client to perform the server endpoint
identification for them, sometimes as a default "added value".

There is an API call in the TLS client implementation where the
application caller can pass the target hostname of the server
as an argument, and the TLS client implementation does all the
rest.  Depending on the API architecture (service-API or callback)
this may be a call prior to the handshake or the call the starts
the handshake (like the target_name parameter of InitializeSecurityContext
for the Microsoft SChannel SSP).  

But there are also client apps that have been doing the server endpoint
identification all by themselves, exactly as it is has always been and
still is suggested by the TLS spec, last sentence of section 1 of
every TLS spec (2246,4346,5246):

                                the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

Where the TLS client implementation offered to perform the matching,
and the calling client application on top of TLS used that service,
passing down the target hostname, the migration from CN-ID matching
to the scheme described by rfc-2818 is easy, straigtforward and
transparent to the application.   When the client TLS implementation
wants the target hostname prior the TLS handshake or at the beginning
of the handshake (not as a callback when the servers certificate
is received), the TLS client application can conveniently provide
implementing client-side TLS session caching (Note however, that
for adequate client-side cache management the client application
should really include the Port/service behind the hostname from
the URL instead of blindly assuming that server-side TLS session
caches are unconditionally shared across all service endpoints of a host.)

>From what I can see, the most recent fine-tuning proposals are
likely difficult to add into existing deployments where the
client application conveniently relies on the convenience function
supplied by the TLS client implementation in matching the server
endpoint identity, client apps may face a lot of work (which
significantly reduces the chances that its adopted by the
installed base).  Keep in mind that often, TLS implementations
and calling client applications are independently maintained,

If your app is built on top of Microsoft Schannel and relies on
what that does about server endpoint identification based on the
target_name passed to InitializeSecurityContext() to the Schannel SSP,
then your app may have little choices.  The exact matching is
whatever Microsoft has shipped.

Special requirements, such as
  - "for this server, I want no rfc-2818 partial wildcard matching"
  - "for the other server over there, I need rfc-2818 partial wildard
     matching for in order not to break a productive usage scenario"
  - "and for that server I want no wildcard matching at all, because
    the app-spec says so (keep in mind that the TLS client implementation
    does neither know nor care what app protocol is used inside).
  - "and for the server over there I want no CN-ID fallback when there
     no DNS-IDs in the server cert"
  - "and here's yet another server where I would prefer SRV-ID matching,
    to DNS-ID matching (but I have no clue how to request this...)"

IMHO, any backwards-incompatible changes to server endpoint identification
with regards to rfc-2818 ought to come with a very convincing rationale,
or they are likely to make things worse ... much worse from what we
currently have.

-Martin

Henry B. Hotz wrote:
> I believe wildcards are a misfeature, because a wildcard cert doesn't
> identify the server well enough that it should be trusted.  I believe
> that "Best Practice" is to never use the feature, and for clients to
> raise flags if presented with it.
> 
> 2)  the CA's pricing model makes it cheaper to buy a wildcard cert
>     than the full collection of multiple-alias certs you really need.
> </rant>
> 
> Getting back to the point:  I think it's perfectly appropriate for a
> Practice document to restrict when and how much you use a Standard feature.

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Sep 2010 00:34:19 +0200 (MEST)

Cleanup of my prior message:

 
  (1) _trustworty_ information source for a name transformation
  (2) _protected_access_ to the information source

DNSSEC provides only data integrity protection and data origin
authentication for the distribution of the informtion.  The
use of DNSSEC for distribution of DNS data has zero impact on
the quality, accuracy and trustworthyness of the underlying
DNS information source.

When there is no change to how others can access wikipedia
and edit the content, your selection of accessing Wikipedia
through HTTPS instead of HTTP will have exactly _zero_ impact
on the trustworthyness of the information in wikipedia articles.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Sep 2010 23:13:09 -0400

> DNSSEC meets (2) but not (1)

Why not (1)?  It should go without saying that by DNSSEC I meant "DNSSEC
with a set of trustworthy trust anchors that will get us to the desired
signed zone".  From there, the DNS admin has full authority to say what
certificates a client trying to connect to a host in her zone should
accept.

We could have a record, CERTNAME or something, that specifies the
hostname for which the certificate should be valid (via keyassure or
PKIX + server-id-check).  I realize now that it would be dangerous to
reinterpret CNAME for this purpose, just as it is dangerous to
reinterpret CERT as making an assurance, but that is a separate issue.
I still wouldn't advise doing it unless we come up with a compelling use
case.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Sep 2010 23:37:31 -0400

On Thu, 2010-09-16 at 09:55 -0700, Henry B. Hotz wrote:
> I believe wildcards are a misfeature [...]

One important use case for wildcards is a web server that serves
untrusted content spread out over a large or infinite set of subdomains
to get increased protection from the same origin policy implemented by
modern browsers.  The server may use one subdomain per user who
publishes content, or even a fresh subdomain for every request.  A
wildcard certificate is a much cleaner solution than having to automate
the generation of a certificate per user, let alone per request.

We can absolutely blame the inflexible same origin policy for
necessitating the use of different host names (which also breaks TLS
session sharing), but realistically it isn't changing any time soon.

(Pardon me if this has already been pointed out.)

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Sep 2010 07:21:59 +0200 (MEST)

> certificates a client trying to connect to a host in her zone should

DNS needs to be available, fast, efficient and low-low-low cost.

The cost of creating and maintaining DNS records with any trustworthyness
that is measurably distinct from zero, with the necessary expertise to
set up and devotion to practise scrutiny for every change to the data
is probably going to far exceed the funding of most, if not all DNS admins.

Are there already workable procedures and APIs for software to
distinguish "normal" DNSSEC lookup results from "trustworthy" DNSSEC
lookup results with some level of portability?  How and how often
would admins/consumers have to update and reconfirm every "trustworthy"
DNSSEC key they keep?

> I still wouldn't advise doing it unless we come up with a compelling use

DNS domains is a resource that is managed pretty arbitrary on a
first-come first-served basis.  It has some loose "a domain is leased
to at most one entity at any single time" provision, that's it.
DNS is vital for the internet, so it needs to remain fast,
efficient and free, and all of that combined makes it hardly
usable to bootstrap an infrastructure of trust, with any meaningful
level of trust.

The fraction of resources that web browsers accesses through HTTPS,
where the first HTTPS link is served through a page received via
HTTP in a completely untrusted fashion is mindboggling.
Example "ebay".  What do you think: how many users that login
through the ebay sign-in page via HTTPS every day, have supplied
the URL of the signin page in a trusted&secure fashion, and
how many open http://www.ebay.<country> and click a link
on that page?

How about online banking?  An internet commerce that cares strongly
about security should serve only one single "301 Moved Permanently"
page with an HTTPS url on port 80, making it difficult to bookmark
anything else than a HTTPS urls to this site.

"Secure" electronic commerce on the internet is often
like a handful of iron rings that are quickly attached to
each other with tiny rubber bands from the kitchen drawer
in order to give the impression of a chain.  Occasionally,
some of these "chains" rip apart by their own weight alone.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Sep 2010 19:52:39 +1200

Martin Rex <[email-masked]> writes:

>Are there already workable procedures and APIs for software to distinguish
>"normal" DNSSEC lookup results from "trustworthy" DNSSEC lookup results with
>some level of portability?

If you mean "is there a way to say 'I don't care about authentication, just
gimme an address, dammit'", i.e. a getaddrinfo_unauthenticated(), then no,
this was explicitly excluded from the DNSSEC work with a let-them-eat-cake
argument that if anyone cared about this then they could just hack around at
the res_query() level themselves.  Note that this is just for basic DNS vs.
DNSSEC lookups, given that you can't even do that I doubt there's any way to
do vanilla DNSSEC vs. EV-cert-equivalent DNSSEC.

Peter.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 11:17:47 -0600

> network attackers", or some such.

Over a year ago, Alexey Melnikov suggested adding text along those lines
and somehow it got lost during the revision process. We'll add something
to that effect back to the spec. The text that Alexey suggested was
similar to text from RFC 4513, and you can see it in version -02 of
draft-saintandre-tls-server-id-check:

   4.  Before attempting to find a match in relation to a particular
       presented identity, the client MAY map the reference identity to
       a different identity type.  Such a mapping MAY be performed for
       any available subjectAltName type to which the reference identity
       can be mapped; however, the reference identity SHOULD be mapped
       only to types for which the mapping is either inherently secure
       (e.g., extracting the DNS name from a URI to compare with a
       subjectAltName of type dNSName or SRVName) or for which the
       mapping is performed in a secure manner (e.g., using [DNSSEC], or
       using a user-configured or admin-configured lookup table for
       host-to-address or address-to-host translations).

> productivity benefits as well as major security implications; ignoring

Wes Hardaker also raised this issue in his review. Jeff and I agree that
this is an open issue and are working to address it.

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Sep 2010 13:44:47 -0400

> this is an open issue and are working to address it.

Addressing that would likely satisfy my issue nicely.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 14:32:09 -0600

Interesting topic, but I see nothing in this branch of the discussion
that necessitates changes to the I-D. Do correct me if I'm wrong. :)