IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Michael Gray <mickgray@au1.ibm.com> Thu, 03 December 2009 01:59 UTC

Return-Path: <mickgray@au1.ibm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305C93A68C6 for <tls@core3.amsl.com>; Wed, 2 Dec 2009 17:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Level:
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqNmgGfJd4Nh for <tls@core3.amsl.com>; Wed, 2 Dec 2009 17:59:17 -0800 (PST)
Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id CF3D63A6863 for <tls@ietf.org>; Wed, 2 Dec 2009 17:59:16 -0800 (PST)
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB31x1Qt017618 for <tls@ietf.org>; Thu, 3 Dec 2009 12:59:01 +1100
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB31tTQF1470654 for <tls@ietf.org>; Thu, 3 Dec 2009 12:55:29 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB31x64w032177 for <tls@ietf.org>; Thu, 3 Dec 2009 12:59:06 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB31x51f032171; Thu, 3 Dec 2009 12:59:05 +1100
In-Reply-To: <4B16FE0E.5010602@bolyard.me>
To: Nelson B Bolyard <nelson@bolyard.me>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF34697738.17919711-ON4A257681.0008007F-4A257681.000AE498@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Thu, 03 Dec 2009 11:58:58 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 03/12/2009 13:06:00
MIME-Version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: base64
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Thu, 03 Dec 2009 01:59:18 -0000

Nelson B Bolyard <nelson@bolyard.me> wrote:

> On 2009-12-02 15:26 PST, Marsh Ray wrote:
> > Nelson B Bolyard wrote:
> >>  ... for servers that have never been conformant with the standards
that
> >> require them to ignore unknown extensions, yes.  Another way to
> say this is:
> >> non-conformant servers are a known interop problem for conformant
clients.
> >> That fact is manifestly obvious now, as we see attempts to
retroactively
> >> codify the behavior of those non-conformant servers as we try to fix
this
> >> problem.
> >
> > Hold on now, is there any reasonable interpretation of
> > draft-ietf-tls-renegotiation which "codifies the behavior of those
> > non-conformant servers"?
>
> Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD
OF*
> (rather than in addition to) the RI extension is such an attempt.
> Such proposals now exist.
>

IMHO there is a possibility of some very small but regrettably non zero
number of old Servers still in existence (perhaps in an internal network
doing secure LDAP) that might not be able to tolerate data following a
Client hello.  Consider if a user were to apply this security fix and
update the client code that connects to these servers in a production
environment then there is risk that the production system will stop
working.  This would most likely be due to human error in that the Servers
were not updated in conjunction with the Clients, as the user might not
know that one product update requires another product update possibly from
a different vendor, but this is how adverse events start.  In this case the
security fix has broken the security principal of ‘availability’.  IMHO the
security fix must ensure that ‘availability’ is not adversely impacted for
any SSL/TLS user, even if that number of users who might be impacted is
tiny.   Additionally, I can not see how any SSL consumer is going to be
pleased with the idea that applying a fix against a possible risk can cause
a real failure in a production environment. This risk is due to client
behavior change as a result of applying the fix.  IMHO the proposed
CipherSuite signaling method provides an operationally safe probe of Server
capability due to no change in ClientHello protocol behavior.  I would go
so far as to recommend that this method be used exclusively unless the
Client in question is already sending extensions during ClientHello, in
which case the Client should send the RI Extension instead of the
CipherSuite as it is then clear that applying this security fix and sending
the RI Extension does not result in a client behavior change.

- Mick

> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email