Re: [TLS] [certid] review of draft-saintandre-tls-server-id-check-09

Martin Rex <mrex@sap.com> Thu, 23 September 2010 01:47 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F417B3A6876; Wed, 22 Sep 2010 18:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.792
X-Spam-Level:
X-Spam-Status: No, score=-9.792 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuIRTTzdRQT6; Wed, 22 Sep 2010 18:47:48 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B7B343A6827; Wed, 22 Sep 2010 18:47:47 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8N1mANw024380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Sep 2010 03:48:10 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp>
To: hotz@jpl.nasa.gov
Date: Thu, 23 Sep 2010 03:48:08 +0200
In-Reply-To: <52B5123E-208D-44B6-BB95-92D5B44D4654@jpl.nasa.gov> from "Henry B. Hotz" at Sep 22, 10 03:11:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: certid@ietf.org, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] [certid] review of draft-saintandre-tls-server-id-check-09
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Sep 2010 01:47:49 -0000

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