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

From: Ion Larranaga Azcue <[email-masked]>
Date: Sun, 1 Apr 2018 07:58:47 +0000

> Note that temporarily enabling debug on a live endpoint isn't a big issue,
> everything will continue to operate as before except for the one client that
> requests debug-level alerts, and that knows what it's up for because it
> explicitly asked for it.

And for the malicious user that, knowing the server is currently in debug mode and returning extended errors, can more easily perform attacks on it...

________________________________________
De: TLS <[email-masked]> en nombre de Peter Gutmann <[email-masked]>
Enviado: domingo, 1 de abril de 2018 7:29
Para: Eric Rescorla
Cc: IETF discussion list; General Area Review Team; [email-masked]; Dale R. Worley; <[email-masked]>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

Eric Rescorla <[email-masked]> 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, 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.

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

Note that temporarily enabling debug on a live endpoint isn't a big issue,
everything will continue to operate as before except for the one client that
requests debug-level alerts, and that knows what it's up for because it
explicitly asked for it.

>so this leaves case #2,

Actually it leaves 1, 2, and 3.  4 is kinda pathological, so really the
problem is "all of the cases".

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 1 Apr 2018 08:14:12 +0000

Ion Larranaga Azcue <[email-masked]> writes:

>And for the malicious user that, knowing the server is currently in debug
>mode and returning extended errors, can more easily perform attacks on it...

If there's someone on the Internet who can scan every TLS server on the planet
once a minute to see a brief debug window open up, and then perform something
like a million-message-attack using a single debug message, then they're kinda
wasting their abilities in attacking TLS servers...

Peter.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Sun, 1 Apr 2018 09:55:31 +0000

Of course not. I mean an attacker who is specially interested in this server and knows that someone has requested a debug window on it.

________________________________________
De: Peter Gutmann <[email-masked]>
Enviado: domingo, 1 de abril de 2018 10:14
Para: Ion Larranaga Azcue; Eric Rescorla
Cc: IETF discussion list; General Area Review Team; [email-masked]; Dale R. Worley; <[email-masked]>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

Peter.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Sun, 1 Apr 2018 10:00:53 +0000

Anyway, I don't mean I'm against the idea of the extended errors extensions... Only that let's not take it lightly. It can be a good debugging tool but also a risky one.

________________________________________
De: TLS <[email-masked]> en nombre de Ion Larranaga Azcue <[email-masked]>
Enviado: domingo, 1 de abril de 2018 11:55
Para: Peter Gutmann; Eric Rescorla
Cc: General Area Review Team; Dale R. Worley; IETF discussion list; [email-masked]; <[email-masked]>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Apr 2018 06:53:07 -0700

On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann <[email-masked]>
wrote:

> real-world experience,

Sure. I am also talking from real world experience.

> and in the example I gave it was exactly case #1.  This

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
still
be quite difficult.

> they're not going to devote any effort to sorting out the problem at their

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
give
me the results" and "turn on extended debugging" are fairly similar.

-Ekr

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 05 Apr 2018 22:25:45 -0400

Eric Rescorla <[email-masked]> writes:
> I guess there might be some intermediate category 1.5 that's kind of in
> production so you don't want to print out complete logs, but you'd like
> more detail than you would probably want to expose in general, but my
> experience is that that's not super-common.

My expectation is that the useful case is when there *aren't* any logs,
or what logging is done does not tell the specific reasons that
particular interactions were rejected.  That's pretty common in SIP
systems.

Of course, anything like this would be an extension.  But would it be
reasonable for one endpoint to present a "debug password" in its request
which, if it matched the debug password set in the other endpoint, would
cause the other endpoint to provide fuller error information?  That
would allow a "debug window" that could be exploited only between
endpoints that had some sort of administrative coordination.

Dale