Re: [TLS] PR#625: Change alert requirements

Hubert Kario <hkario@redhat.com> Wed, 07 September 2016 17:54 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE17D12B563 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 10:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.41
X-Spam-Level:
X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 O1r21WOUkNl9 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 10:54:46 -0700 (PDT)
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 7E3A912B23C for <tls@ietf.org>; Wed, 7 Sep 2016 10:54:46 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3CE4581227; Wed, 7 Sep 2016 17:54:46 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u87HsiQI014130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2016 13:54:46 -0400
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Sep 2016 19:54:38 +0200
Message-ID: <3902031.op4bE2I96X@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.2-201.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <CABcZeBMCkSJ1nGfZDjx3CJcUsLhH4AMZ=0wOc+uNs0YKu6kW1Q@mail.gmail.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <1558569.9rZYFBiQ0G@pintsize.usersys.redhat.com> <CABcZeBMCkSJ1nGfZDjx3CJcUsLhH4AMZ=0wOc+uNs0YKu6kW1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1785953.o4YIGmg6dn"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 07 Sep 2016 17:54:46 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gQzDo--023JhKY4r7VDxdeyVbW0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#625: Change alert requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 07 Sep 2016 17:54:47 -0000

On Wednesday, 7 September 2016 10:19:02 CEST Eric Rescorla wrote:
> On Wed, Sep 7, 2016 at 10:05 AM, Hubert Kario <hkario@redhat.com>; wrote:
> > On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > > PR: https://github.com/tlswg/tls13-spec/pull/625
> > > 
> > > Currently the TLS spec requires implementations to send alerts under
> > 
> > various
> > 
> > > fatal conditions. However, many stacks actually don't send alerts
> > 
> > the only popular stack I found that does not seem to send alerts is the
> > schannel from Microsoft
> 
> Well, that's a fairly popular stack.

just pointing out that "one does not many make" :)

> > F5, FortiOS, OpenSSL, NSS, GnuTLS, Java, mbedTLS, botan, axtls, Go
> > implementation of TLS, all send alert messages
> 
> My understanding is that this is situation-dependent and that some systems
> do not send alerts all the time.

which points out that some messages (both valid and invalid) may not be 
handled as well as they should

while making a protocol definition that is precise and allows for 
interoperability is the primary objective of this work group, I think we can 
all agree that helping developers actually implement it correctly and with no 
bugs (a la heartbleed) is not something we should completely ignore

In my opinion, precise definition of error handling does that (even if 
implementation decides not to send alerts at all).
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic