Re: [TLS] Should we require implementations to send alerts?

[Hubert Kario <[e-mail]>]

On Thursday 17 September 2015 15:30:12 Brian Smith wrote:
> Martin Thomson <[e-mail]> wrote:
> > We're not sure where we stand with version fallback and 1.3.  We
> > don't
> > know how much version intolerance 1.3 will generate.
> > That at least
> > might not depend on alerts, though we don't know just yet.
> 
> A conformant TLS 1.3 implementation cannot be version intolerant. If
> it were version intolerant then it would not be a conformant TLS 1.3
> implementation. So, conformance requirements for TLS .1.3 servers
> don't matter as far as version intolerance is concerned.

except that a TLS1.3 version intolerant implementation won't show its 
ugly head until TLS1.4 gets deployed

"non conformant" TLS1.2 is in same boat. Just because it can 
interoperate (the *only* thing PHBs care about) doesn't mean it is 
conformant (that's the stuff we care about because that means backwards 
and *forwards* compatibility)

> > I don't see much support for the notion that forbidding alerts is a
> > good idea.  We use alerts quite a bit for basic diagnosis.  Bad
> > configurations are pretty commonplace, the most common being one
> > where there is no common cipher suite.  Being able to isolate the
> > error that is pretty useful.
> 
> I still think it is better to recommend to never send alerts. But, at
> least there are good reasons (which I gave much earlier in the
> thread) for why a server would choose not to send alerts, e.g. out of
> an abundance of caution. So, "MUST send" is clearly too far.

Sorry, but there are no good reasons why not to send them. Not sending 
them may cause interoperability issues in the future, so an 
implementation, if at all possible, should send them. That makes them a 
MUST.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic