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

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 22 September 2010 18:13 UTC

Return-Path: <jhutz@cmu.edu>
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 ADA9028C126; Wed, 22 Sep 2010 11:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.543
X-Spam-Level:
X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 zT1SpgyfQVLa; Wed, 22 Sep 2010 11:13:40 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 2649728C121; Wed, 22 Sep 2010 11:13:40 -0700 (PDT)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8MIE1nW000952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:14:01 -0400 (EDT)
Date: Wed, 22 Sep 2010 14:14:01 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Barry Leiba <barryleiba.mailing.lists@gmail.com>, Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu>
In-Reply-To: <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com>
References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: jhutz@cmu.edu, secdir@ietf.org, IETF cert-based identity <certid@ietf.org>, IETF discussion list <ietf@ietf.org>, tls@ietf.org
Subject: Re: [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09
X-BeenThere: tls@ietf.org
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." <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: Wed, 22 Sep 2010 18:13:44 -0000

--On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba 
<barryleiba.mailing.lists@gmail.com> wrote:

> There's a distinction, here, between a protocol and a user interface
> for configuration.  My mother doesn't know whom to trust, except that
> she knows that she (at least kinda-sorta) trusts the mail program
> she's decided to use, and an entity she calls "gmail" (not
> "google.com", not "gmail.com", but just "gmail").  She's relying to
> the mail program's "easy configuration feature" to sort this out.
>
> The text I reviewed appeared to be saying normative things about what
> client software MUST and MUST NOT do with regard to this sort of
> configuration situation, which goes well beyond what the client
> software is doing on the wire.  Unless I'm mis-reading it, it's
> explicitly saying that my client software is not allowed to do
> something like this, for example:
> 1. Ask the user, "What email service do you use?"
> 2. Receive the answer "gmail" from the user.
> 3. Auto-configure itself for the known gmail servers based only on
> that user input.

I think that's reasonable behavior _if_ the mail client knows that "gmail" 
is "mail.google.com".  What's _not_ reasonable is for it to arbitrarily 
transform "gmail" into a domain by adding ".com", then look up "gmail.com" 
and see that it is an alias for "mail.google.com" and not only follow the 
(insecure) alias to mail.google.com but also use it to decide that 
"mail.google.com" is an appropriate name to find in a certificate.

If your mother's mail client does that, then all I have to do to steal her 
password is convince said client that "gmail.com" is actually an alias for 
"stealgmailpassword.attacker.org".