Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate

"Kemp, David P." <> Tue, 30 March 2010 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74FAD3A6A6A for <>; Tue, 30 Mar 2010 08:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NIuvWLZXNNEU for <>; Tue, 30 Mar 2010 08:29:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF9AA3A68B3 for <>; Tue, 30 Mar 2010 08:29:32 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Mar 2010 11:29:58 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate
thread-index: AcrQGF9uJJ//OYkSSse91tLbzcmCUwAANbsw
References: <> <> <> <><> <> <> <>
From: "Kemp, David P." <>
To: "TLS Mailing List" <>
X-OriginalArrivalTime: 30 Mar 2010 15:31:01.0343 (UTC) FILETIME=[00BC7EF0:01CAD01E]
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Mar 2010 15:29:38 -0000

Neither AT&T nor China can authenticate themselves as
(assuming the browser trust list is properly managed, all trusted
issuers are trustworthy, the user won't confuse with, etc.).  ADH does not protect against data stealing or
session hijacking in general; authenticated TLS performs that function.
The ADH tunnel protects just one small piece of data (the certificates)
from eavesdropping during the TLS authentication handshake.

If AT&T and China and 10 other players all insert themselves between the
user and, they can all learn the identities of the user and
of facebook.  But none of them can view or modify any data sent over
mutually-authenticated TLS.

Social networking sites are not a useful example because they don't use
TLS for most pages and they don't do client authentication for the few
pages that do use TLS.  But if banking / medical sites actually used
client-authenticated TLS for all pages (instead of little
phish-prevention pictures and personal-knowledge questions and
passwords), then AT&T would be out of luck.


-----Original Message-----
From: Marsh Ray [] 
Sent: Tuesday, March 30, 2010 10:51 AM
To: Kemp, David P.
Cc: TLS Mailing List
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a
different certificate
Importance: Low

On 3/30/2010 9:24 AM, Kemp, David P. wrote:
> ADH is a pretty standard way of
> reducing ID exposure from an infinite number of attackers down to 1
> active party

It doesn't reduce it to one active party because Malloy can't know any
better than Alice or Bob if one of his connections is itself being

One could imagine amusing scenarios where AT&T and China bump into each
other on the wire and begin to argue "hey, buddy, go get your own
Facebook connection".

> and 0 passive parties.  That's a fairly significant
> reduction.

Defeating passive eavesdropping is important, but it's sufficient in

In the past, people were on shared Ethernet and would naturally be in a
position to quietly observe every packet going by.

For several common types of attacks today it's no harder to modify the
packets than it is to observe them. Think of China and Pakistan DNS- and
BGP-jacking YouTube for recent examples.

- Marsh