Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

[Martin Rex <[e-mail]>]

Peter Gutmann wrote:
> 
> Martin Rex <[e-mail]> writes:
> >
> > The IETF golden rule for protocol applies here
> > "be liberal in what you accept".
> 
> What people usually omit when they quote this is the footnote in the
> appendix to the apocrypha:
> 
> "... unless it's a security protocol".


That IMHO misses the point by a significant margin.

"be liberal in what you accept" was never meant in the sense
of being sloppy in performing validation of security-critical parameters.

As previously described here
  http://www.ietf.org/mail-archive/web/tls/current/msg06356.html
SSL-Alerts during the TLS handshake are _not_ protected by the
TLS handshake message hash that is authenticated with the finished
messages, so Alerts are purely optional protocol features that are
not security relevant and therefore the golden IETF rule applies
to them without restriction.

If we want to convey security-critical parameters in the TLS handshake
protocol, then it must either be part of regular handshake messages
or otherwise get covered by the protection of the handshake message
hash and/or finished message calculations.


>
> > If there are protocol elements that convey information between to
> > communication peers, then the semantics of that piece of information
> > must be well-defined for both, sender and receipient.
> 
> ... unless the protocol is IPsec, OCSP, CMP, TSP, portions of SSH, uhh...
> what else is there... well, in any case I think I've made my point.

I do not understand what you mean.

In security protocols it is much more important to specify the exact
semantics of all security-critical parameters for both, sender and
recipient, otherwise this will result in interop problems, because
being sloppy about checking security-critical parameter values is
_not_ an option.

Did you want to assert that the mentioned protocols contain a lot of
underspecified security-critical parameters?

-Martin