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

[Eric Rescorla <[e-mail]>]

Thinking through this some more, I'm skeptical that this is going to be
that useful as a debugging-only feature.

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, and
it's not that helpful in case 4, because you can read the logs, errors,
etc. yourself. 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, so this leaves case #2, which I agree can be annoying. However, what
we've started doing with QUIC is just to have the endpoints dump their logs
so that they're available on a co-located Web site. That gives you a lot
more information than you'd probably want to fit in an alert message (e.g.,
you can print out the keying material, etc.)

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.

-Ekr



On Fri, Mar 30, 2018 at 7:16 PM, Peter Gutmann <[e-mail]>
wrote:

> Kathleen Moriarty <[e-mail]> writes:
>
> >I agree with Eric’s assessment, this could be in a new draft as an
> extension.
>
> Anyone want to work on this?  I can contribute a bit by recycling the EtM
> text, which sets out how to communicate a boolean flag (for "I speak
> extended
> alerts") as an extension, apart from that you just need to define the alert
> format, which I assume just means adding a free-form text field to the
> existing alerts.
>
> Peter.
>