Re: [TLS] Expanded alert codes

Ion Larranaga Azcue <> Mon, 21 May 2018 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A57E6127076 for <>; Mon, 21 May 2018 06:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YYX2oY5OLsYG for <>; Mon, 21 May 2018 06:47:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00CD01270AE for <>; Mon, 21 May 2018 06:47:40 -0700 (PDT)
From: Ion Larranaga Azcue <>
To: Peter Gutmann <>, Eric Rescorla <>
CC: "Dale R. Worley" <>, "<>" <>
Thread-Topic: Expanded alert codes
Thread-Index: AQHT8Py8qEYy0pHq3E+0uC3v1ZC86qQ6LlwQ
Date: Mon, 21 May 2018 13:47:37 +0000
Message-ID: <>
References: <>, <> <>
In-Reply-To: <>
Accept-Language: es-ES, pt-PT, en-US
Content-Language: es-ES
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 21 May 2018 13:47:46 -0000

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...

That being said... I encourage you to write your draft and look for consensus within the group.



-----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.


TLS mailing list