Re: [secdir] [TLS] secdir review of

Martin Rex <> Fri, 24 September 2010 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CD333A6A8B; Fri, 24 Sep 2010 13:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.817
X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLtWF4w-rNkA; Fri, 24 Sep 2010 13:29:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0936E3A69EE; Fri, 24 Sep 2010 13:29:27 -0700 (PDT)
Received: from by (26) with ESMTP id o8OKTr1A002212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 22:29:53 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
Date: Fri, 24 Sep 2010 22:29:52 +0200
In-Reply-To: <> from "Peter Saint-Andre" at Sep 22, 10 11:53:16 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700
Subject: Re: [secdir] [TLS] secdir review of
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Sep 2010 20:29:29 -0000

Peter Saint-Andre wrote:
> For context, the "quoted advice" is mostly a description of current
> usage in some existing user agents. Incorporating Barry's suggestions,
> that text currently reads as follows in our working copy:
>       Security Note: Some existing interactive user agents give advanced
>       users the option of proceeding despite an identity mismatch.
>       Although this behavior can be appropriate in certain specialized
>       circumstances, in general it ought to be exposed only to advanced
>       users and even then needs to be handled with extreme caution, for
>       example by first encouraging even an advanced user to terminate
>       the connection and, if the advanced user chooses to proceed
>       anyway, by forcing the user to view the entire certification path
>       and only then allowing the user to accept the certificate on a
>       temporary basis (i.e., for this connection attempt and all
>       subsequent connection attempts for the life of the application
>       session, but not for connection attempts during future application
>       sessions).

This whole paragraph is evil and completely wrong.

It's bad enough that the web browser crowds replaced a useful option
and important security feature with an extremely evil scary page.

The IETF should definitely not put this non-sense into a
BCP or standard.

Offering to end-users, in a single-time-only leap-of-faith approach similar
to what SSH has been successfully doing since its invention to memorize
the peers certificate is magnitudes more secure than the endpoint
identification linking to one of a hundred trust anchors, provisionally
preconfigured by your software supplier.

The IETF, its standards & BCPs ought to stand clear from
recommendations that impair the usability or incur additional cost
for using the TLS technology between components of home networks.

The scary-pages presented by newer Browsers and the UI suggestions
in the quoted paragraph amounts to turning the entire TLS technology
into "nagware" for commercial pre-trusted CAs.  The most recent
browser scary-pages are worse than most nagware.

I'm not intimidated on the initial install of my DSL-router,
neither when logging in to the webadmin page for the first time,
nor when configuring my WPA2-PSK key.  Why on earth am I intimidated
so badly when I activate TLS for the webadmin UI of my home NAS
and connect to it with my browser for the first time?

Can't we do better than specifying the use of HTTP over TLS instead
of HTTP-only to access devices on my home network should not be
allowed to users that are not "advanced", and even those must be
badly intimidated when they try?

Even when servers use server certs from commercial pre-trusted CAs,
the options for end users to manually confirm the server cert to
have it cached/memorized and verified on future visits will
significantly improve the security for the user, because it
protects from later subversion of (the issuing procedures)
of any of the thousands CAs signed by any of the hundred
preconfigured trust anchors as well as bugs such as the
OID-integer wraparound and NUL-character in Hostname.