Re: Security for various IETF services

t.p. <> Fri, 04 April 2014 09:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D8A31A0442 for <>; Fri, 4 Apr 2014 02:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ver-2n8ZFjtw for <>; Fri, 4 Apr 2014 02:35:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EE2E31A0429 for <>; Fri, 4 Apr 2014 02:35:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.908.10; Fri, 4 Apr 2014 09:35:50 +0000
Message-ID: <01ec01cf4fe9$0a4e1f60$>
From: t.p. <>
To: <>, <>, Randall Gellens <>
References: <> <> <p06240601cf639cb2113b@[]>
Subject: Re: Security for various IETF services
Date: Fri, 4 Apr 2014 09:48:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Forefront-PRVS: 01713B2841
X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(189002)?= =?iso-8859-1?Q?(199002)(377454003)(77982001)(20776003)(47776003)(47446002?= =?iso-8859-1?Q?)(74502001)(31966008)(59766001)(84392001)(74366001)(237560?= =?iso-8859-1?Q?03)(85852003)(93516002)(65816001)(93136001)(44716002)(1958?= =?iso-8859-1?Q?0405001)(74662001)(63696002)(79102001)(54316002)(94946001)?= =?iso-8859-1?Q?(94316002)(92726001)(56776001)(86362001)(93916002)(1958039?= =?iso-8859-1?Q?5003)(83322001)(56816005)(47976001)(47736001)(33646001)(80?= =?iso-8859-1?Q?022001)(92566001)(89996001)(51856001)(87976001)(66066001)(?= =?iso-8859-1?Q?95416001)(4396001)(88136002)(50466002)(74706001)(61296002)?= =?iso-8859-1?Q?(53806001)(69226001)(87286001)(90146001)(85306002)(4218600?= =?iso-8859-1?Q?4)(44736004)(97336001)(62966002)(97186001)(76786001)(76482?= =?iso-8859-1?Q?001)(76796001)(80976001)(98676001)(77096001)(81542001)(509?= =?iso-8859-1?Q?86001)(87266001)(50226001)(83072002)(62236002)(95666003)(1?= =?iso-8859-1?Q?4496001)(46102001)(99396002)(49866001)(74876001)(81342001)?= =?iso-8859-1?Q?(77156001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:?= =?iso-8859-1?Q?DB4PR07MB252;; F?= =?iso-8859-1?Q?PR:DA48F255.A538D4DA.FCF32D8B.90F7E960.2036B; MLV:nov; PTR:I?= =?iso-8859-1?Q?nfoNoRecords; MX:1; A:0; LANG:en; ?=
Received-SPF: None (: does not designate permitted sender hosts)
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: Fri, 04 Apr 2014 09:36:00 -0000

----- Original Message -----
From: "Randall Gellens" <>
To: <>uk>; <>ie>; <>
Sent: Friday, April 04, 2014 12:24 AM
Subject: RE: Security for various IETF services

> My reaction is also to ask "Why?"  Security and privacy involve
> trade-offs where various costs (including operational difficulty) are
> weighed against the benefits, such as protecting information from
> unauthorized disclosure or modification.  So, I'd suggest that a
> blanket statement isn't a good idea, but rather, a service-by-service
> decision should be made.  For example, XMPP and document submission
> may justify requiring encryption while email and document retrieval
> might not.

Yes, it is a trade off, a more secure service, for some meaning of
security, but a worse service for some users or usages.

Setting up a TLS session takes time; I notice every time I access
e-mail, ever since my ISP required the use of TLS.   It is only a few
seconds, but it means that I batch my usage rather than doing it
promptly, and every so often forget and shut down without having sent a
message in reply.  And certainly with that e-mail access, it is forever
tearing down the TLS session and creating a new one, e.g. between
sending e-mail on an account and receiving it from the same account, so
one (unmet) requirement is that having gone to the cost of setting up a
session, it stays up and is reused.

And then there is CRL checking.  I would assume that that would be
recommended as part of a secure system, yet with the IETF website, that
hangs the session.  The CRL is downloaded and ......  hours later, the
web page has yet to display.  There is something weird about the IETF's
use of certificates which other websites do not share.  Surmountable no
doubt but it means that a secure service is a worse service than that
obtainable via HTTP.

And what threat is this trying to counter? a corrupted DNS directing me
to a phishing website of a foreign power?

Tom Petch

> --
> Randall Gellens