Re: [TLS] Deployment ... Re: This working group has failed

Andy Lutomirski <luto@amacapital.net> Wed, 27 November 2013 01:05 UTC

Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33081AE0ED for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWVozluVdoEe for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6335E1AE0EA for <tls@ietf.org>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so4659886veb.15 for <tls@ietf.org>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PnS5fW3RcfpcgReWdgsuWw2iozdD8BAuXiCZwrbhMSI=; b=ALz63EeMl8+DeCbhLXG0Kqlsf5fxrSk8jof8tgGuIA9PHDwL2CsFIloazzgs9nBpVx GazQQzw2zAdY/xRZlFHe9v9x3iKYWl4HJhoFEY2AKSPSKyIazMGZUmTcb/GpMUM5l1/E 6MjTLAuFjjwDVlft5jaXQ/SNExQ9fOWVFpRRpnVNYG7pDAAqv0WxTRM+4IUkyuJP1Bkh hdlCYR83OG8EAINFpQZKTW+WRH2lrGTrf8qo4LKDauDfIS9D+ojRjVHcOcc777ngljVj CgoucBOBr+tV35TqBHR9edfIsdfyF/85QoDoTUd7iXu6s7DV/4SD+G4av1lepweA1IJD hRbQ==
X-Gm-Message-State: ALoCoQlJqLiAPlygARXS4IhwnKLaq3ZG4RKYruaNGZ7NoKaANJUcvCsGPP7+IqHimkxl3OMLyofD
X-Received: by 10.52.230.35 with SMTP id sv3mr6614221vdc.27.1385514333976; Tue, 26 Nov 2013 17:05:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 17:05:13 -0800 (PST)
In-Reply-To: <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 17:05:13 -0800
Message-ID: <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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, 27 Nov 2013 01:05:35 -0000

On Tue, Nov 26, 2013 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Do you really think that "completely insecure against active attack"
>> is a good option?
>
> For some things, yes.  Specifically: SMTP.

Why?

My .msmtprc contains (excerpted):

tls on
tls_starttls on
tls_certcheck on
tls_min_dh_prime_bits 2048
tls_trust_file /etc/ssl/certs/ca-bundle.crt

host smtp.gmail.com

If msmtp were easier to configure, I'd pin Google's CA.  Sadly it's
not, but nonetheless this was *easy* to set up in such a way that my
SMTP is about as secure as HTTPS.

Why on earth is it considered acceptable that the defaults are
insecure?  If it's really okay to connect, *not verify the server
certificate*, and send a password without using a real PAKE algorithm,
then at least the software that does it should not pretend to offer
any form of security.

--Andy