Re: Security for various IETF services

mrex@sap.com (Martin Rex) Mon, 07 April 2014 21:17 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF71A0257; Mon, 7 Apr 2014 14:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 DgELsRrSX_tE; Mon, 7 Apr 2014 14:17:31 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 40A271A01FC; Mon, 7 Apr 2014 14:17:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s37LHI2D007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 23:17:18 +0200 (MEST)
Subject: Re: Security for various IETF services
In-Reply-To: <DC23F34E807E77F8C4C095C3@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.com>
Date: Mon, 7 Apr 2014 23:17:18 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140407211718.60C021ACAA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/fkpWT__UBUDkItEpd5fZ4uyKoRo
Cc: IETF-Discussion <ietf@ietf.org>, Tim Bray <tbray@textuality.com>, The IESG <iesg@ietf.org>, Stewart Bryant <stbryant@cisco.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 21:17:37 -0000

John C Klensin wrote:
> 
> Ted Lemon <ted.lemon@nominum.com> wrote:
>>
>> Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>>
>>> Yes, we ought move away from passwords if/when we ever find an
>>> acceptably better solution, and yes, people ought manage their
>>> passwords well, but neither are today's reality more's the
>>> pity.
>> 
>> Perhaps it would be worth setting up support for client certs
>> as a way to log in to IETF services.   If we won't start, why
>> would someone else?
> 
> If we are really serious about promoting/ encouraging security,
> I'd really like to see this as an option.  Not only would it be
> responsive to Ted's question, but, if we made it available and
> almost no one used it, it would give us a lot of information
> about the course we are on.

TLS _client_ certificates are typically used in closed groups,
where a single CA is issuing all these certs.

TLS client cert authentication has a few small issues.  The TLS server
needs to explicitly request the client cert (unsolicited client certs
are not possible/not allowed), and when the server asks for them
in the initial handshake, the client certificates will travel the
network _in_the_clear_.  Requesting client certificates only in the
renegotiation handshake has it own set of problems, besides twice
the full handshake crypto overhead.  For TLS renego problems and fixes
see rfc5746 and https://secure-resumption.com/



I also think that discontinuing the _public_ services of the IETF
over traditional, insecure channels (HTTP, anon-FTP, plain SMTP, whatever)
should require a threat analysis.

Different to what a lot of folks believe, TLS is neither a panacea nor
magic pixie dust.  In order to determine whether doing X-over-TLS really
provides the desired security characteristics, it is necessary to know
what security properties one is looking for.

The reason why there was an issue with TLS renegotiation is that applications
boldly assumed properties which never existed in the first place -- and
that problem would have been obvious if anyone of those abusing
TLS renegotiation for delayed authentication would have actually cared
to check for _the_real_TLS_protocol_characteristics_ instead of
believing in TLS magic pixie dust.


-Martin