[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]
From:       worley () ariadne ! com (Dale R !  Worley)
Date:       2018-04-06 2:25:45
Message-ID: 877epl136e.fsf () hobgoblin ! ariadne ! com
[Download RAW message or body]

Eric Rescorla <ekr@rtfm.com> 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


[prev in list] [next in list] [prev in thread] [next in thread]