- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Thu, 13 Nov 2014 19:18:26 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Top of my To-Not-Do list, is chiming in on 9.2.2; but oh, well... Greg Wilkins <gregw@intalio.com> wrote: > > Roy T. Fielding <fielding@gbiv.com> wrote: > > > I don't think there is any scenario in which INADEQUATE_SECURITY > > needs to be sent. A server that wanted to send it would have > > refused the TLS handshake (i.e., no good ciphers offered). A > > server that doesn't want to send it isn't going to. A client that > > does want to send it doesn't need to -- just drop the connection. > > A client that doesn't want to send it is just going to make use of > > the completed connection, either to send an HTTP/1 request or to > > ignore 9.2.2 and send h2. > > > I have to agree with Roy on this one. Inadequate vs. Inappropriate is a moot point; I'd never send either, vs. closing the connection. > > I think there are still a few scenarios that INADEQUATE_SECURITY can > be sent - but thankfully not many. > I can't think of one, despite your examples. I've done enough httpd work since 1994 that I don't see why I'd bother to tell any client *why* I'm dropping a connection, rather than just dropping it. My httpd code just doesn't include such subroutines, and I can't see changing that for any reason. > > In both cases, if the connection is failed, sure it can just be > closed... but I think it is more informative to send the > INADEQUATE_SECURITY code. > Sorry Greg, but I'd say "more stupid" rather than "more informative". My security knowledge lags behind plenty of others on this list, let alone the black hats, and I don't see that changing. So my perspective is, why give anyone clues? I'd rather give a long-winded response, but, you either get that or you don't. Not everyone who implements HTTP has Eric's or Roy's knowledge, all we can do is not be stupid. Like by telling clients why our servers won't talk to them. You either get why that would be stupid, or you don't. I, for one, will never get why it wouldn't be. I'm far too set in my ways on that. > > It is still a hack, but at least now the hack is for the old ciphers > and old protocol and in 10 years time implementations will probably > be able to drop support for it and function perfectly ok. > Mmmm hmmm. I'm too conservative about unprovable notions of the future, to implement hacks (security holes) today. Yeah, yeah, I support Roy too much, I don't have a horse in this race as my current project is building a dude ranch, etc... But, quitting HTTP is proving as difficult as quitting smoking. And I know a bad idea when I see one. Believe me, I'd rather be all rah- rah about h2 than I am. This is just yet another reason for my bad attitude, and continued posting here despite having left the industry. Re-lurking now, and having a smoke, despite knowing it's bad for me. ;-) -Eric
Received on Friday, 14 November 2014 02:19:29 UTC