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 super-common.
My expect
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:
> >
> >1. A live endpoint.
> >2. A testing endpoin
bril 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;
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft-ietf-tls-tls13-24]
Of course not. I mean an attacker w
discussion list; General Area Review Team;
draft-ietf-tls-tls13@ietf.org; Dale R. Worley;
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft-ietf-tls-tls13-24]
Ion Larranaga Azcue writes:
>And for the malicious user that, knowing the server is currently in de
Ion Larranaga Azcue 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 w
t; General Area Review Team;
draft-ietf-tls-tls13@ietf.org; Dale R. Worley;
Asunto: Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of
draft-ietf-tls-tls13-24]
Eric Rescorla writes:
>In my experience, there are four major scenarios for diagnosing this kind of
>failur
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
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 test
