Subject: review of draft-saintandre-tls-server-id-check-09

From: Wes Hardaker <[email-masked]>
Date: Mon, 13 Sep 2010 20:58:49 -0700

I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
document and support it's forward progress.  I do have a few comments
though:

(*):
  Applies to many of the comments below: some parts of the document
  read like a BCP in the way it tries to rationalize things.  A number
  of these text sections really don't help the document, though, as it
  adds unneeded ambiguity.  Examples of this are marked below with (*).

Section 1.1: (*)
  I don't think you should be spelling out the popularity of TLS vs
  DTLS.  While it may be true today, this is intended to be a proposed
  standard and thus doesn't need to specify that one is potentially more
  popular than the other.  The document should be targeting the use of
  both regardless of how well DTLS is used at the moment.  Suggested:

  OLD:
                                  When a client connects to an
    application services using Transport Layer Security [TLS] (or, less
    commonly, Datagram Transport Layer Security [DTLS]), it references
    some conception of the server's identity while attempting to
    establish a secure connection (e.g., "the web site at example.com").

  New:
                                  When a client connects to an
    application services using Transport Layer Security [TLS] or
    Datagram Transport Layer Security [DTLS], it references some
    conception of the server's identity while attempting to establish a
    secure connection (e.g., "the web site at example.com").

Section 1.1 and the appendices:
  You could now, if you wanted, add SNMP over (D)TLS: RFC5953.  If
  you're going to copy into the appendix as well, the text to copy is
  from the snmpTlstmAddrTable object in that document.

Section 1.3.2: (*)
  This section is full of text that is subjective and really isn't
  needed in the first place.  Nearly every paragraph contains text that
  may be true today but might not be in the future or is subject to
  interpretation.  While I agree with most of the conclusions, I don't
  think it's worth putting the text into the document; especially when
  the text is simply defining what's out of scope.  I don't think you
  need to spend effort rationalizing what's out of scope.

  Suggestion: keep the bullets, ditch the paragraphs.

  Phrasing examples (IE, an incomplete list) that are questionable:

    "service operators have less experience with client certificates"

    "Most fundamentally, most users find DNS domain names much easier to
    work with than IP addresses, which is why the domain name system was
    designed in the first place.

    "Furthermore, application technologies have less experience with
    IPsec than with TLS, thus making it more difficult to gather
    feedback on proposed best practices."

Section 1.4, "Target Domain"
  It took me far too long into reading this document to remember what a
  "target domain" really meant.  IMHO, a better term that already
  conveys the proper meaning to most readers would be a "derived
  domain".  Think about a global search and replace for target->derived?

Section 3, bullet 5:
  Unfortunately, this is the one rule I think will be
  broken the most often.  Fortunately, checking from the client side
  says to ignore the CN-ID if it can match on other things as well.
  Because of this, the only thing this particular rule hurts is the
  software that isn't going to conform to this document because the code
  is already too old.  It's basically a "should upgrade" statement.  I
  think an extra sentence here might be helpful, though I don't have a
  suggestion at the moment.

Section 4.3, security note:
  I actually think wording these things is tricky when the future is
  unknown.  I think it's generally safer to describe the only conditions
  which are valid for checking a CN-ID instead of trying to list all the
  "MUST NOT" cases, which is more likely to change with the addition of
  future specs into the spec tree.  I didn't have time to fully think
  out replacement text, but I'd start it with "A client MUST only seek a
  match for a reference identifier of a CN-ID if it is the only
  available presented identifier."  Or something like that.

Section 5, Security Considerations:
  The interesting thing about this specification is that we're leaving a
  fairly broad range of potential "success" matches.  Not only that, but
  future specifications may lead to future reference identity matches
  that previously didn't work.  Fortunately, I can't come up with an
  example that works all that well to describe it but somehow I'm left
  feeling nervous that a server cert could have a clause the clients
  don't understand currently but might later after a software upgrade
  and an admin that expects a failure may suddenly see a success.  You
  can ignore this paragraph if you fail to grasp what I'm trying to say,
  as I'm not at all stating it well.

Section 5.1, Service Delegation:
  You discuss interactive clients and how the the source domain name
  MUST be provided by a human user.  But the odd case that I couldn't
  figure out what it mapped to was references from an original source.
  EG, images or javascript elements in a web page aren't "provided by
  the user", but a web-browser is certainly interactive.  This sort of
  "snow ball" domain list probably should be discussed at least in
  brief.

Section 5.1, Service Delegation:
  I read the last paragraph (which is one sentence) multiple times and I
  only barely feel that I understand what it's saying.  I'd suggest
  rewording it for clarity and splitting it into multiple sentences.
  I'd offer suggestive text, but then I'd prove that I really didn't
  understand it.

General:
  Some of the possible combinations and options that may exist could
  really use an "examples" section or something that had example info
  from a certificate combined with example list of expected reference
  indenties.  Though this would be nice, it's not at all critical.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Sep 2010 10:12:53 -0600

On 9/14/10 10:07 AM, Sean Turner wrote:
> I'd offered to review this version during the TLS session at IETF 78,
> but I think I'm going to wait for the next version ;)

Yes, the authors will work to submit a revised I-D soon, based on all
the feedback received so far.

Peter

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Sep 2010 12:07:03 -0400

spt

---

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

Wes, thank you for reviewing this document. Jeff and I provide replies
inline using the editorial "we".

>     secure connection (e.g., "the web site at example.com").

Fixed in our working copy.

>   from the snmpTlstmAddrTable object in that document.

Thanks for the pointer; we'll incorporate some of the text from RFC 5953
into our "Prior Art" appendix.

>   needed in the first place.  

The authors have lost count of how many times commenters have said "why
doesn't this spec talk about X and Y and Z?" We think it's valuable to
explain why the scope is as limited as it is, in part to motivate others
to work on specs about X and Y and Z.

> Nearly every paragraph contains text that
>   may be true today but might not be in the future 

Clearly we can't write about the future yet. However, we fully expect to
update this document once the Internet community has gained more
experience with the technologies under discussion. That "C" in BCP does
stand for "current". :)

> or is subject to

We do. See above.

>     feedback on proposed best practices."

Those statements seem to us like truisms at this point in the evolution
of the Internet.

>   domain".  Think about a global search and replace for target->derived?

We borrowed the term "target" from RFC 2782, because in DNS SRV records
the "target" is the result of an automated lookup for what we're calling
a "source domain". However, we tend to agree with you that "derived
domain" probably captures the concept better, so are looking into
changing it (we haven't yet made that change because we want to be sure
it doesn't have implications we haven't had time to consider).

> Section 3, bullet 5:

That is:

   5.  The certificate SHOULD NOT represent the server's fully-qualified
       DNS domain name in a CN-ID, even though many deployed clients
       still check for this legacy identifier configuration within
       certificate subject name.

>   suggestion at the moment.

Jeff and I are discussing what text to add here.

>   unknown. 

Is there a time when the future is not unknown? ;-)

> I think it's generally safer to describe the only conditions
>   future specs into the spec tree. 

Sure, which is why we expect to update this document when reality has
changed enough to justify the effort.

> I didn't have time to fully think

How about this?

   A client SHALL seek a match for a reference identifier of CN-ID
   only if the certificate contains no other presented identifiers.

That does seem better -- it's good to future-proof the spec where
possible, I just don't think it's always possible.

I'll ask Jeff to review that text, too, because I came up with it just
now while replying to you.

>   as I'm not at all stating it well.

I have a sense of what you're getting at, but I'm not deeply concerned
about it because I think we'll be updating this document in the future.

>   "snow ball" domain list probably should be discussed at least in

That is an excellent catch. Jeff and I are discussing how to address
this matter and will post again once we have proposed text.

>   only barely feel that I understand what it's saying. 

That is:

   There are several scenarios in which it can be legitimate for an
   interactive client to override the recommendation in the foregoing
   rule.  Examples include:

   <snip/>

   2.  A human user has explicitly agreed to trust a service that
       provides mappings of source domains to target domains, such as a
       dedicated discovery service or an identity service that securely
       redirects requests from the source domain to a target domain
       (however, such an arrangement is not encouraged and if a client
       supports such a service then it needs to disable it by default
       and carefully warn the user about the possible negative
       consequences of trusting such a service).

> I'd suggest

During an earlier review, Stefan Santesson suggested adding some text
about trusted mapping services, and the quoted text is the result.
Although there are cases when trusted mapping services are well-defined
(e.g., some SAML-based services), in general we agree with you that the
concept of a trusted mapping service is vague and difficult to grok.
We'd be open to removing that paragraph entirely, if Stefan would not
object too strongly. :)

>   indenties.  Though this would be nice, it's not at all critical.

Good suggestion. We will work to add a section of examples. See for
instance Section 13.7.1.2.2 (!) of draft-ietf-xmpp-3920bis-15 for the
kind of thing we'll include.

Thanks again for your feedback.

Peter

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

---

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

Henry B. Hotz wrote:
> 
> [...] For example the user may trust a dedicated discovery service
> or identity service that securely redirects requests from the source
> to a target domain.  

Thinking about it, I feel slightly uneasy about some redirects, such as
https://gmail.com  -> 301 ->  https://mail.google.com/mail

I think these should never go without a warning.

If my banks online-banking portal (https://www.<mybank>.de)
would suddently redirect me to https://www.<mybank>.com before
asking me for credentials and transaction authorization codes,
that would be a real security problem, because www.<mybank>.com
is not leased by my bank (it is apparently not currently leased to anyone)

A hacker that breaks into a web-site in order to do trap
victims might be less easily detected if he doesn't subvert
the entire site and tries to send collected data to external
places, but instead puts redirects into place that browsers
will blindly and silently follow, maybe additionally filtering
the clients that will be redirected based on their origin,
so that the helpdesk and security guys can not immediately
repro it with their browsers.

Should a users decision to trust a particular service with
a particular issue always imply that this particular service
is a fully trusted naming service (i.e. one that performs
secure name transformations)?

-Martin

---

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

>       consequences of trusting such a service).

Pure wordsmithing.  Make sure this still says what you want:

2.  A human user has explicitly agreed to trust a service that provides mapping of source domains to target domains.  For example the user may trust a dedicated discovery service or identity service that securely redirects requests from the source to a target domain.  

Such an arrangement is not encouraged.  If a client supports such a service then it needs to disable it by default, and it MUST carefully warn the user about the possible negative consequences of trusting such a service.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Marsh Ray <[email-masked]>
Date: Thu, 23 Sep 2010 10:57:09 -0500

> I think these should never go without a warning.

That bugs me too. Lots of sites do it though, usually with Javascript.

> is not leased by my bank (it is apparently not currently leased to anyone)

Yep. There are often ways to make that happen with just a blind 
plaintext injection capability, too.

> victims

The site is now 100% (to use the technical term) "pwned".

It's not possible for a network security protocol to survive the 
compromise of one of the endpoints. We can no longer reason about Alice 
and Bob if Bob is allowed to be under the hypnotic control of Eve.

I think it's dangerous to try. We're likely to optimize for cases of 
dubious security at the expense of some properly functioning cases.

> might be less easily detected if he doesn't subvert

There are lots of ways a site can delegate its security like that. They 
could load Javascript or HTML from external sites, for example. They can 
use headers and script to broaden the origin which the browser trusts.

http://code.google.com/p/browsersec/wiki/Part2

Not to mention that they could simply proxy the requests on the server 
side, outsource their servers to someone untrustworthy, add insecure 3rd 
party tracking cookies, redirect via non-SSL HTTP, and so on.

Once your browser trusts a server to serve some domain/origin, there's 
almost nothing that server can't do with its identity, including 
delegate it to someone else (intentionally or not).

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Sep 2010 20:15:39 +0200 (MEST)

Marsh Ray wrote:
> Martin Rex wrote:

True.   I used the wrong words in what I was trying to say.

There is definitely little that you can do about a full compromise of
the real server.

But blindly trusting browsers may easily turn seemingly small security
vulnerability (every XSS, CSRF, content upload), that enables diverting
a victim to the attackers own server seamlessly, close to equivalent to
a full compromise of the real server for the purpose of capturing
sensible or confidential information from the victim.

-Martin