IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 16 October 2014 14:04 UTC

Return-Path: <nmav@redhat.com>
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 D9A751A1A25 for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level:
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JnHTFY0KiYMd for <tls@ietfa.amsl.com>; Thu, 16 Oct 2014 07:04:13 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3F1A1A24 for <tls@ietf.org>; Thu, 16 Oct 2014 07:04:13 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GE4BEq029743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 10:04:12 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GE48eZ006989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 10:04:10 -0400
Message-ID: <1413468247.17221.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
Date: Thu, 16 Oct 2014 16:04:07 +0200
In-Reply-To: <543FCC90.7020408@polarssl.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <543E9435.8000905@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9C9@USMBX1.msg.corp.akamai.com> <543E9C9F.5050104@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECE9D5@USMBX1.msg.corp.akamai.com> <543E9FFA.5030102@redhat.com> <CADMpkcLnOh3HGD+urWuo6fPfkX4WfGhwckE0jg5jS2KqD2RuMQ@mail.gmail.com> <CABkgnnWuCwOGBXG2RdetwPFn4KtVPygSBWG5qkme1mvNst6n+A@mail.gmail.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <543FCC90.7020408@polarssl.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zNMThGs4YcXh96NlRxX7rf5Mpic
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
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: Thu, 16 Oct 2014 14:04:15 -0000

On Thu, 2014-10-16 at 15:48 +0200, Manuel Pégourié-Gonnard wrote:

> > A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
> > unconditionally.  This client would break once servers start supporting 
> > TLS 1.3.  That's just one example of what could go wrong which could not 
> > go wrong before.
> > 
> I'm sorry, but wouldn't that be very stupid of the client? Maybe the draft could
> include wording that clients MUST NOT do that, to be extra clear, but IMHO it's
> already quite clear.

Of course, but isn't this issue that SCSV is trying to fix in the first
place? Isn't the SCSV's reason of existance the fact that there are some
buggy servers that cannot handle TLS protocol version negotiation? Why
should we assume that buggy clients are impossible to happen?

regards,
Nikos

v2.23.0 | Report a Bug | By Email