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:tls-boun...@ietf.org] En nombre de Peter Gutmann > Enviado el: lunes, 21 de mayo de 2018 14:09 > Para: Eric Rescorla <e...@rtfm.com> > CC: Dale R. Worley <wor...@ariadne.com>; <tls@ietf.org> <tls@ietf.org> > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
