Re: [TLS] Expanded alert codes

[Hubert Kario <[e-mail]>]

On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote:
> I would say it's unfair to expect other people to diagnose the problem by
> claiming "that information was all that was available" because you had
> access to:
> 
> - traffic dumps of the failing handshakes
> - traffic dumps of working handshakes
> - the possibility to try any number of modifications of the client hello to
> go from a working handshake to a failing handshake in order to identify the
> offending option or parameter - as you are going to have to ask the server
> side to activate extended alerts, you can ask them for server logs, as well
> as traffic dumps of (at least) the failed connections on their side (if
> they receive any, which is additional information)
> 
> Besides, I also think it's not fair to claim that when someone disagrees,
> you are being "shouted down". From what I remember, both sides expressed
> their opinion, and if you manage to gather consensus your draft will get
> published. So, I think accusing others of shouting you down is an
> unfortunate phrase on your side...

you need consensus for Informational RFCs? that's news to me...
 
> That being said... I encourage you to write your draft and look for
> consensus within the group.

For what it's worth, and with all the downsides it would have (it would have 
to be an extension, so not every server would implement it; what about alerts 
not allowed to be fragmented, and interaction with max_fragment_length?), I'm 
in favour of more expressive errors (and more strict/detailed guidelines which 
ones should be sent when).

> -----Mensaje original-----
> De: TLS [mailto:[e-mail]] En nombre de Peter Gutmann
> Enviado el: lunes, 21 de mayo de 2018 14:09
> Para: Eric Rescorla <[e-mail]>
> CC: Dale R. Worley <[e-mail]>; <[e-mail]> <[e-mail]>
> Asunto: Re: [TLS] Expanded alert codes
> 
> Reviving this discussion, if I write up a draft for this what's going to
> happen to it?  Will it get published, or shouted down?  The reason I'm
> asking is that I've just spent the past three days debugging a TLS issue
> that's pretty much a poster child for why extended alerts are needed, it
> was something that would have been resolved in a single handshake exchange
> with extended alerts, but took three days to sort out without them.  The
> sequence was as follows:
> 
>   Client sends standard client hello.
>   Server responds with handshake failed alert.
> 
> The same client has been running for years, and connects fine to any number
> of servers, and openssl and some web browsers connect fine to the server. 
> The only message exchanged was the hello, so there's zero security issues
> in providing extended alerts.
> 
> Since some people have argued that extended alerts aren't necessary or
> useful, I'll wait awhile for them to diagnose what was wrong using the
> information above, which was all that was available.
> 
> Peter.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic