Re: [TLS] Expanded alert codes

Hubert Kario <> Tue, 22 May 2018 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B6D712EB3D for <>; Tue, 22 May 2018 06:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bWTHyWYd5vrg for <>; Tue, 22 May 2018 06:11:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9393A12EB3A for <>; Tue, 22 May 2018 06:11:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFF717D83A; Tue, 22 May 2018 13:11:53 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 2430C6B410; Tue, 22 May 2018 13:11:51 +0000 (UTC)
From: Hubert Kario <>
Cc: Ion Larranaga Azcue <>, Peter Gutmann <>, Eric Rescorla <>, "Dale R. Worley" <>
Date: Tue, 22 May 2018 15:11:43 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart15429800.jRxluuDhXp"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Tue, 22 May 2018 13:11:53 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 ( []); Tue, 22 May 2018 13:11:53 +0000 (UTC) for IP:'' DOMAIN:'' HELO:'' FROM:'' RCPT:''
Archived-At: <>
Subject: Re: [TLS] Expanded alert codes
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 May 2018 13:11:58 -0000

On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote:
> I would say it's unfair to expect other people to diagnose the problem by
> claiming "that information was all that was available" because you had
> access to:
> - traffic dumps of the failing handshakes
> - traffic dumps of working handshakes
> - the possibility to try any number of modifications of the client hello to
> go from a working handshake to a failing handshake in order to identify the
> offending option or parameter - as you are going to have to ask the server
> side to activate extended alerts, you can ask them for server logs, as well
> as traffic dumps of (at least) the failed connections on their side (if
> they receive any, which is additional information)
> Besides, I also think it's not fair to claim that when someone disagrees,
> you are being "shouted down". From what I remember, both sides expressed
> their opinion, and if you manage to gather consensus your draft will get
> published. So, I think accusing others of shouting you down is an
> unfortunate phrase on your side...

you need consensus for Informational RFCs? that's news to me...
> That being said... I encourage you to write your draft and look for
> consensus within the group.

For what it's worth, and with all the downsides it would have (it would have 
to be an extension, so not every server would implement it; what about alerts 
not allowed to be fragmented, and interaction with max_fragment_length?), I'm 
in favour of more expressive errors (and more strict/detailed guidelines which 
ones should be sent when).

> -----Mensaje original-----
> De: TLS [] En nombre de Peter Gutmann
> Enviado el: lunes, 21 de mayo de 2018 14:09
> Para: Eric Rescorla <>
> CC: Dale R. Worley <>; <> <>
> Asunto: Re: [TLS] Expanded alert codes
> Reviving this discussion, if I write up a draft for this what's going to
> happen to it?  Will it get published, or shouted down?  The reason I'm
> asking is that I've just spent the past three days debugging a TLS issue
> that's pretty much a poster child for why extended alerts are needed, it
> was something that would have been resolved in a single handshake exchange
> with extended alerts, but took three days to sort out without them.  The
> sequence was as follows:
>   Client sends standard client hello.
>   Server responds with handshake failed alert.
> The same client has been running for years, and connects fine to any number
> of servers, and openssl and some web browsers connect fine to the server. 
> The only message exchanged was the hello, so there's zero security issues
> in providing extended alerts.
> Since some people have argued that extended alerts aren't necessary or
> useful, I'll wait awhile for them to diagnose what was wrong using the
> information above, which was all that was available.
> Peter.
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic