Andrei Popov wrote: >>> the only popular stack I found that does not seem to send alerts is >>> the schannel from Microsoft > > To clarify, schannel does generate alerts per RFC, but the HTTP stack > (which actually owns the socket) sees no value in sending them.
"Pillows don't hit people, people do." ;-) When operating with a transport-less (i.e. opaque-PDUs-only) API, it is somewhat unusal to having an API call _fail_ *and* return output parameters & transport requests at the same time. Higher layer programmers (and the exception-style programming) often do not expect having to deal with both. I actually notice just now that Microsoft Win32 SSPI DeleteSecurityContext() (Microsoft's incarnation of GSS-API) does not have a final/context-deletion token output parameter. In the original (DEC given to IETF) GSS-API design, the "final token" was not meant to be emitted by a failing context iterator call along with a fatal error code, but by a _successful_ call to gss_delete_sec_context(). I'm actually confused--where does SChannel return that TLS alert PDU (and along with with what kind of API return code)? Admittedly, for applications on top of GSS-API (rfc2743/rfc2744) it is quite common to _not_ bother conveying the optional(!) context deletion token that may be produced by GSS-API's gss_delete_sec_context(), and the GSS-APIv2 spec acknowledged this being a common app behaviour, and deprecated the context deletion token. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
