Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

Eric Rescorla <> Sun, 01 April 2018 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2273124C27 for <>; Sun, 1 Apr 2018 06:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zh73MFxfvlSl for <>; Sun, 1 Apr 2018 06:53:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91EE4124207 for <>; Sun, 1 Apr 2018 06:53:48 -0700 (PDT)
Received: by with SMTP id q71-v6so11056173oic.6 for <>; Sun, 01 Apr 2018 06:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SdRDHe6J3qwifUZVLUzDYJqgfTsjzW3vdpXHFHebr6w=; b=e1uiM3Y9XBGb7UID0NbZgN1iguuI3QRcC5+Ff2Y6mNrbSTSwpHEuInhuIiXvEEIwYD s1uQAv+kog5EOfZ/2/y1HEEv0cTP2GQSYrixqIYo591wB5o1Rx5zwaMnF5Kw7/3n2hR1 L8dQoV6U1aFzun7935MjEBBa7/f+W7EjGFt6cWA8CwxjOWRDA6n+q8K68oxlcOCg4zp5 +cMS+9jD6w+k2TlFZOwHzk9o7Oa8n0XbAD1FeDR7LDK9tOrH5rq/BEbUnROtpfTi59gG ChN7qgwo6H7OfXHmyDMP/X/I3GNKdDRM5g0+R9Mqnw3NSF5WHSIPeiYsO4ls2cQnT2jM LblQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SdRDHe6J3qwifUZVLUzDYJqgfTsjzW3vdpXHFHebr6w=; b=tO5ZBdOEQQSidFP0K4wP655UNkOMQ+asR5rOr9Lly2cGeNyTp0VGGcR/n5x+0lwj7b ArvSUihMfYdE5fLcNlTUDi66MP5ujb+DKbSAEWt47D48z/05+buDR5jVMLjn5YJnzews /CBTqNz1sWU6iW2rTy9//o2HQZymxwFmo5X/TArJ1n1TBNgHucz/zuRHw4M4GHI7Qdvc W0UNf1RLp1gJxBws+kD2DuEqbdASSCWr8QuAhlC/doLaL/76p3eBfPapX7e+Sc5xmGJH uVsQ7Zinpr+31eOCjHoNyrD7y2ULiaqeRDVr7DXzJkyjG370LEwvGokiIAsFXs+4g6uX YwOQ==
X-Gm-Message-State: ALQs6tD44fvPIWMrQkoeTfoFeIXsLkWbXHZzuAnrdRBFDgYL9Ld/OvpO N+aMStPK8ZRPswZq3uPJhkYRhePjfrtCXfqJHZT2QQ==
X-Google-Smtp-Source: AIpwx4+A+TzXM6IRd36PrVErKk/OGHFI4uyXUyHVtrlphAS7j9HHmd0Ty1fvYLsRi3NoYISD+iKeQfsrSvW4dHD6MAo=
X-Received: by 2002:aca:3114:: with SMTP id x20-v6mr3458693oix.108.1522590827839; Sun, 01 Apr 2018 06:53:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 1 Apr 2018 06:53:07 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sun, 01 Apr 2018 06:53:07 -0700
Message-ID: <>
To: Peter Gutmann <>
Cc: Kathleen Moriarty <>, Bill Frantz <>, Steve Fenter <>, "Dale R. Worley" <>, General Area Review Team <>, IETF discussion list <>, "" <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000006e97b00568c9cd3a"
Archived-At: <>
Subject: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]
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: Sun, 01 Apr 2018 13:53:51 -0000

On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann <>

> Eric Rescorla <> writes:
> >In my experience, there are four major scenarios for diagnosing this kind
> of
> >failure. Under the assumption that you control one end, the other end can
> be:
> >
> >1. A live endpoint.
> >2. A testing endpoint someone has put up.
> >3. An endpoint that someone is actively working on with you.
> >4. An endpoint you control (e.g., you're running it on your own machine).
> >
> >If this is a debug-only feature, then it won't be available in case #1,
> I have the feeling the people who have commented on this were talking from
> real-world experience,

Sure. I am also talking from real world experience.

> and in the example I gave it was exactly case #1.  This
> was a live, large-scale production environment by a major ecommerce
> organisation (details fudged somewhat to avoid identifying anyone, but
> everyone here would know the name), and the only way to get things working
> was
> to spend several weeks randomly tweaking every conceivable option on the
> client until things started working, because the only thing the server
> would
> say was "Handshake failure".  The client-side organisation still has no
> idea
> what made things work, they've narrowed it down by trial and error to about
> half a dozen things they had to change, but that's it.
> If they'd been able to get the server operators to turn on extended-alert
> for
> even just a single handshake it would have avoided several weeks' effort
> and a
> fix that even now is pure guesswork.

Maybe. I've spent a fair amount of time trying to diagnose failures where
I know precisely the line of code that generated the failure, and it can
be quite difficult.

> >For the same reason, it's not really that helpful in case #3, because you
> can
> >just ask the person you're working with to read the logs,
> Except that these people are EDI companies, not TLS experts.  They have
> neither the expertise nor the inclination to help debug TLS issues.  What
> they
> will do is enable debug on the server so the client can sort things out,
> but
> they're not going to devote any effort to sorting out the problem at their
> end.

I'm not suggesting that they ask the counterparty to diagnose the problem,
just send the relevant logs. It seems like the ask of "turn on logging and
me the results" and "turn on extended debugging" are fairly similar.