Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session

[<[e-mail]>]

>> > You say choked, I say graceful fail.
>>
>> No, I don't agree with this analysis. The server being 
>> unwilling
>> to resume a session is normal behavior. The TLS state 
>> machine
>> explicitly handles such cases. Implementations which 
>> choke
>> rather than doing a full handshake are broken.
>
> I fully agree with Eric that a client MUST deal gracefully 
> with
> a server that does not resume a proposes SSL session (ID) 
> for
> whatever reason.


Show me the text in the standard that says MUST (or even 
half hints MUST from the English wording). Tell me it MUST 
apply to EAP-TLS, too. More importantly, tell me what 
"appropriate" and "graceful" then mean, for packets on the 
wire. Tell me what the server MUST do, if the client does 
not comply. Your both making this out to be security- or 
interoperability- critical (it's a MUST, Peter!!)

Eric is clear that this is not a new concept (for novel 
discussion); but an ancient one. It must be pretty obviously 
disclosed, or have been improved (by now) due to the years 
of text review.

Now, for my part, I already pointed out text that says, I 
the implementer have 100% control over open and closing 
connections. NOTHING IN THIS STANDARD SHALL ...

Now, I will also listen to any decent appeal. I'm willing to 
be convinced (just show me some half reasonable basis from 
the standard), as the text I'm quoting was admittedly highly 
contextualized.  But, it was also an adamant, general claim. 
So, give me some SSl2, SSL3, TLS1.x text (not argument) to 
weigh against it.

Concerning the evidence:-

"The particular problem in the scenario that I listed might 
be
that the client, by retrieving a cached session from its 
cache
thought he had several parameter (including the protocol 
version)
already established and treated the response from the server
(who didn't resume as proposed) probably more like a 
renegotiation
rather than a new handshake, and therefore might have 
considered
the unavailablility of the previous higher protocol version
a rollback attack."

VERY LIKELY! This is in MY purview - as a implementer - to 
decide; Martin, you are making my point for me. My 
implementations don't support ANY of the fallback practices, 
either, by default!

Now that implementation may or may not have a good attack 
signature algorithm; perhaps its intentionally 
non-conforming in its TLS handling of protocol version 
negotiation, even. But, my only point is: its for EITHER 
PEER to decide (right or wrong) on whether it closes a 
connection abruptly. We cannot assume otherwise in any case, 
since the IDS may interdict packet flow anyways, for its own 
reasons. E.g. If you even propose NullWithNull in a non 
private-mode EAP-TLS handshake, you will be dropped by my 
IDS. Period.

Now if I'm am even half convinced that the standard 
specifies what you both assert, I will properly eat crow, 
but I will not actually change my default security policy: 
Ill simply disclose non-conforming (default) behavior. 
Gaining Interoperability in open systems OFTEN DOES demand a 
lowering of absolute thesh-holds - but at the user's 
discretion.
 


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls