Re: [TLS] Allow NamedGroups from the server?

Robert Relyea <rrelyea@redhat.com> Thu, 19 November 2015 21:52 UTC

Return-Path: <rrelyea@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 943F21B360C for <tls@ietfa.amsl.com>; Thu, 19 Nov 2015 13:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.485
X-Spam-Level:
X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_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 aNt22TWexzI3 for <tls@ietfa.amsl.com>; Thu, 19 Nov 2015 13:52:37 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95911B3603 for <tls@ietf.org>; Thu, 19 Nov 2015 13:52:36 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6AAFE42E5A8 for <tls@ietf.org>; Thu, 19 Nov 2015 21:52:36 +0000 (UTC)
Received: from rrelyea-laptop.usersys.redhat.com (dhcp-16-202.sjc.redhat.com [10.14.16.202]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAJLqZZ1013987 for <tls@ietf.org>; Thu, 19 Nov 2015 16:52:35 -0500
To: tls@ietf.org
References: <CABcZeBP-xz0UAyizac9ScxFjEbBkRYZ0CnY8xabEdtFONJf_sg@mail.gmail.com> <20151022125557.9B1651A31C@ld9781.wdf.sap.corp> <CABcZeBNikLAxO45+zryRjXD1f3jbKKjqbwtYWsVLqOjKAC9kHA@mail.gmail.com>
From: Robert Relyea <rrelyea@redhat.com>
Message-ID: <564E44A3.8020004@REDHAT.COM>
Date: Thu, 19 Nov 2015 13:52:35 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBNikLAxO45+zryRjXD1f3jbKKjqbwtYWsVLqOjKAC9kHA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050509080205030301040902"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/emALDLe74dr474C_pSZmJMovdWg>
Subject: Re: [TLS] Allow NamedGroups from the server?
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Nov 2015 21:52:38 -0000

On 10/22/2015 06:29 AM, Eric Rescorla wrote:
>
>
> From an implementation perspective, I wouldn't be surprised if client
> implementations choked on the server sending this. I had to check
> to see if NSS would do so. It doesn't, but given the way the code
> is written, it wouldn't have surprised me if it checked that all 
> extensions
> were handled and choked otherwise.

Yeah, NSS was implemented under the old 'be graceful in what you accept' 
with the 'be a bit paranoid when security is on the line'.

That being said, in the early days of SSL3, unknown extensions were 
explicitly allowed, mostly so you could handle new protocols against old 
servers.

In practice this failed miserably because many server implementations 
followed the standard security paranoia of 'it's there and I don't 
undertand it, fail'. This is why we have/had TLS intolerance issues.

Anyway NSS is purposefully tolerant of well formed unknown extensions, 
as well as typically accepting new extensions on older versions of the 
protocol (like accepting ECC operations even though you negotiated SSL3).

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