Re: [TLS] Inter-protocol attacks

[[e-mail] (Martin Rex)]

Antoine Delignat-Lavaud wrote:
> 
> This is the TLS mailing list, and the relevant problem here is the 
> complete lack of any restriction in RFC 5246 and 5077 on when a session 
> can be resumed.

This lack is intentional.  The only prerequisite is that both peers
have the session in their cache and are willing to use it for a session
instead of a full handshake.


>
> Thus, we end up in a situation where resumption is up to 
> implementations to decide; because of the lack of any specification,
> TLS libraries simply hand off the decision to the application;


You seem to be seriously misinterpreting the specifications.
The TLS libraries are not "simply handing off the decision to the
application", they are EXPLICITLY REQUIRED to leave any such decision
to the application.

Last sentence of Section 1. Introduction of every TLS spec:

  https://tools.ietf.org/html/rfc2246#page-4

                             the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.


In the abstract definition, the TLS client implementation has _absolutely_
_no_idea_ who it is talking to, working purely on a memory buffer interface
to the client application.


What is probably dangerous and unreasonable is when a TLS implementation
lets an application interfere with the PKIX path validation of a peer cert
chain.

The application level "interpretation of authentication certificates
exchanged" ought to be independent from whether the TLS stack performs
a full or an abbreviated TLS handshake, and the calling application
ought to retrieve and check/map the peer certificates after completion
of the TLS handshake and independent of whether the handshake was
full or abbreviated (and independent from the PKIX path validation).



>
> the application won't know what to do (this kind of question is typically 
> considered out of the scope of application protocol definitions),

Nope, that can not possibly happen.  Per specification, the application
*KNOWS* what to do.

There might be clueless programmers that don't know what to do, but
that is a different issue.


> 
> SPDY is an interesting case, as it does specify a clear resumption 
> policy (even though, I must against stress out again, this policy 
> technically allows resumption between any two HTTP origins as long as 
> they appear in the same certificate; thus, CVE-2014-3166 does not 
> violate any TLS or HTTP specification and cannot be considered an 
> implementation bug). This policy should be interpreted as an 
> authorization function for TLS authentication. In a full handshake, 
> there is a well-specified and widely-adopted authorization function 
> defined in RFC 5280. The problem I am pointing out is that the SPDY and 
> PKIX authorization functions are incompatible. Thus, TLS features that 
> assume PKIX authorization, such as SNI or ChannelID, may not guarantee 
> the same security properties under SPDY authorization. Similarly, 
> certain PKIX extensions will also fail under SPDY authorization, most 
> notably certificate pinning.

PKIX authorization does not exist within TLS.  Whether it exists in
the function of the application that "decisions how to interpret the
authentication certificates" is purely an application matter an
none of TLS business.

Certificate pinning would be an application decision, not a TLS decision.

But with your description I somehow still fail to see a problem.
If the server certificate of such resumptions will *pass* the
"server endpoint identification", then why would re-doing the
server endpoint identification make a difference?


-Martin