Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[[e-mail] (Martin Rex)]

Benjamin Kaduk wrote:
[ Charset windows-1252 unsupported, converting... ]
> On 11/10/2016 11:13 AM, Martin Rex wrote:
> >
> > There is a concept called "provable correctness", and folks (such as
> > those from the miTLS implementation) are using this approach to check/prove
> > whether TLS provides certain security properties (rather than just
> > assuming that these properties are provided).
> >
> > If hiding of ContentType has *real* value, then this property will be
> > formally provable.  If the properties that someone asserts as value
> > can be proven to not exist (one counterexample is sufficient),
> > then the value is an illusion / obscurity, and definitely not real value.
> 
> My understanding was that our current knowledge of what capabilities
> traffic analysis makes possible and the countermeasures against them is
> quite poor, certainly not to the level where rigorous proofs are
> possible.  So, I fear we must be operating "in the dark" in this regard
> for the near future.


Proving that something is secure can be pretty difficult, that is correct.

Proving that something is insecure can be pretty trivial (one counterexample
is sufficient).

For someone who does this formal proofing stuff regularly, it may already
be possible today to formally proof that hiding the ContentType can not
possibly provide any value.


Where is the value with hiding the ContentType of SSL Alerts?

We know that at least one implementations notoriously _not_ sends any alerts
before closing connnections.  The installed base has somehow managed
to live with it.  But it's often painful to figure out the cause of
handshake failures, and to distinguish a certain kind of server
accept()ing and silently closing a connection after hitting a bug
(or policy) from an overzealous firewall (NAT or "transparent internet proxy").

So if your implementation has anything to hide, performing a dirty
socket closure (resulting in a TCP RST) will be *MUCH* more effective
in hiding information from observers than hiding the TLS Alert ContentType.

Silent connection closures are certainly much more effective for leaving
rightful communication peers (&helpdesk &support) in the dark about why
the heck communication is failing.


-Martin