Eric Rescorla 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
On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann
wrote:
> 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:
> >
>
21sec.com>
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;
draft-ietf-tls-tls13@ietf.org; <tls@ietf.org>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft
Azcue; Eric Rescorla
Cc: IETF discussion list; General Area Review Team;
draft-ietf-tls-tls13@ietf.org; Dale R. Worley; <tls@ietf.org>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft-ietf-tls-tls13-24]
Ion Larranaga Azcue <ila...@s21
de 2018 7:29
Para: Eric Rescorla
Cc: IETF discussion list; General Area Review Team;
draft-ietf-tls-tls13@ietf.org; Dale R. Worley; <tls@ietf.org>
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft-ietf-tls-tls13-24]
Eric Rescorla <e...@rtfm.com> writes
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
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