IETF Logo Mail Archive

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

Andy Lutomirski <luto@amacapital.net> Wed, 27 November 2013 02:28 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 E7B841AE0DB for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:28:45 -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 dvmTP0r12_Gc for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:28:44 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2EE1A1F08 for <tls@ietf.org>; Tue, 26 Nov 2013 18:28:44 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so4374246vcb.38 for <tls@ietf.org>; Tue, 26 Nov 2013 18:28:43 -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=nZ7vt5Tvn78pOBLlUM7DTeqWRnItpCFc875ufrcgN3g=; b=MPuof2HFiGoeznQKEa6wTRhKbwqCOK5rmLmQY5UZKUJDm0IPp1iqAm+DXw2swEeoLj 6DeHIOXRucEifxXJMN6CqLk7VqlF0BMzBaJDIRqmqnLk283+Md01ZHiJwI/14zrlW1Rz RtUVCTpKJWJffEK5AB3nKKhiXeD0rP1TrcSaswnSeFWx04OzwrpYmWRxGUtBR1puePs4 inF0+o7Dd2DU1fLsYgLE7uop2vWTzG+uqpcP3+VuJ4kJ1mmoGGB0Dokn+AcrFHarKX3x /Varweh3bP51cMQqyzVqWd4GbaowqteQ7QwRFZa2CEV7ra1FpjfEB/Xj5xMxPNfThUkV JTfg==
X-Gm-Message-State: ALoCoQlZr5btdAbGfoqE+0ii6IBBswUHHvAtwUJQtfS6Q/QlXhbLwN7gb8zXd+cDqhXVBLxbXN8M
X-Received: by 10.52.98.99 with SMTP id eh3mr6292597vdb.29.1385519323832; Tue, 26 Nov 2013 18:28:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 18:28:23 -0800 (PST)
In-Reply-To: <20131127020116.GO21240@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com> <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com> <20131127020116.GO21240@localhost>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 18:28:23 -0800
Message-ID: <CALCETrVdgQUz1mVG=o7mu9Lz1wTxOKtMJGNniOitP9CkMjpktA@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 02:28:46 -0000

On Tue, Nov 26, 2013 at 6:01 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 05:51:14PM -0800, Andy Lutomirski wrote:
>> On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
>> > I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
>> > and MSAs).  With that clarification:
>> >
>> > Because it's more important that e-mail flow and be delivered than
>> > that it be hop-by-hop secure.
>>
>> Then let those programs use some kind of hack to turn off
>> authentication if they really know what they're doing.  (SMTP isn't
>> hop-by-hop secure, regardless of TLS.)
>
> Exactly.  It has to be possible to turn off what you said must not be
> possible to turn off.

Then I'll propose a rephrased straw-man version:

When in client mode, implementations MUST refuse to connect to a
server unless an explicitly chosen set of trust roots (or other
mechanism such as DANE) authenticates that server (hello, everything).
 As an exception, an implementation may support an explicit "insecure
mode" in which it is possible to disable peer authentication.

In any case, this is moot unless people think it's actually a good
idea to publish something like this.

--Andy

v2.23.0 | Report a Bug | By Email