RE: Security for various IETF services

Eric Gray <> Tue, 08 April 2014 09:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CE96F1A01CE; Tue, 8 Apr 2014 02:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RbOCSpimqaZb; Tue, 8 Apr 2014 02:21:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C62C81A01E1; Tue, 8 Apr 2014 02:20:56 -0700 (PDT)
X-AuditID: c6180641-b7f638e000005a82-2a-5343bc8b6732
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3A.43.23170.B8CB3435; Tue, 8 Apr 2014 11:08:27 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 05:20:49 -0400
From: Eric Gray <>
To: "" <>, John C Klensin <>
Subject: RE: Security for various IETF services
Thread-Topic: Security for various IETF services
Date: Tue, 8 Apr 2014 09:20:48 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPgm73Hudgg7k/DCxm/JnIbPFs43wW i9ZLf9gsen/vYLY493QOo8XSP/NZHNg8pvzeyOqxZMlPJo/LK18ze0z5vJXR49LSycwBrFFc NimpOZllqUX6dglcGbM+n2Qv2CJaMf3qJPYGxg2CXYycHBICJhIt/9ayQdhiEhfurQeyuTiE BI4ySkzc1MME4SxjlGj9N5cJpIpNQEPi2J21jCC2iICrxJOvv5lBipgFWhklrsxZyt7FyMEh LKAvcbI7FqLGQGLJlp+sEHaexKJP7xlBSlgEVCQmbfIGMXkFfCU2zK4FMYUEsiWezBIBKeYU sJH4cGQ12CJGoNO+n1oDdgCzgLjErSfzmSBOFpBYsuc8M4QtKvHy8T9WCFtRYl//dHaIeh2J Bbs/sUHY2hLLFr4Gq+cVEJQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGW5i BMbZMQk2xx2MCz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj850C xV8f7ry8+iOnZua1wI5Xr2IfscluP7LX9llq0lrpKd29VVZc3ULrzjVuZNEX/KudE/tCovGM JXcQ1xux/GksPseuXi73Ozp3Af+lu8KMzLmp9kzv2H6k2/Nerg3wc1IUm5SyX4lj5+row3+e HDZeEnbULZZlr/2CNxfDK04mFs8VkKtXYinOSDTUYi4qTgQAWDr5L4ECAAA=
Cc: Stewart Bryant <>, Tim Bray <>, IETF-Discussion <>, The IESG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Apr 2014 09:21:12 -0000


	You say "_the_real_TLS_protocol_characteristics_" like they are written down

	Would you care to provide a pointer?


-----Original Message-----
From: ietf [] On Behalf Of Martin Rex
Sent: Monday, April 07, 2014 5:17 PM
To: John C Klensin
Cc: IETF-Discussion; Tim Bray; The IESG; Stewart Bryant
Subject: Re: Security for various IETF services

John C Klensin wrote:
> Ted Lemon <> wrote:
>> Stephen Farrell <> 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

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.