Hi, Having been involved in adding security after-the-fact to SNMP, and to Syslog, and adding authorization after-the-fact to netconf, I know it is extremely difficult to add security "later". I strongly believe that if http is going to be redesigned enough to justify a 2.0 label, then security should be part of its design from the start. Therefore I think that security should be addressed as part of the http 2.0 effort, not after the fact. I can understand the concerns about doing both at the same time increasing the risk to both, and that serializing the work might reduce the risk. So I suggest you COULD design the web security standard first, and then design HTTP 2.0 to take the updated web security standards into consideration. Web security will be easier if it doesn't need to somehow fit into an HTTP 2.0 that didn't consider a viable security approach up-front. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@xxxxxxxxxxx +1-603-828-1401 On 2/21/12 6:01 PM, "Stephen Farrell" <stephen.farrell@xxxxxxxxx> wrote: > > >On 02/21/2012 10:55 PM, Mark Nottingham wrote: >> Stephen, >> >> The approach we're advocating for this WG is to solicit well-formed >>proposals, select one and develop it. >> >> If there isn't one for HTTP authentication, how are you advocating we >>proceed? > >I'm not thinking now in terms of advocating a specific >proposal for how to proceed. > >Right now, I'm interested in what others reviewing the >draft charter think about this topic. That's the point >of having this discussion in the open like this. > >(So maybe I should shut up for a while:-) > >S > >> >> Regards, >> >> >> >> On 22/02/2012, at 9:53 AM, Stephen Farrell wrote: >> >>> >>> >>> On 02/21/2012 10:40 PM, Mark Nottingham wrote: >>>> >>>> On 22/02/2012, at 9:19 AM, Stephen Farrell wrote: >>>> >>> >>>>> So as in my initial mail the 1st question here is, what >>>>> does "modern" mean in this draft charter? E.g. does it >>>>> mean "same as the current framework with different >>>>> bits" or something else? If so, what? >>>> >>>> As discussed off-list, I'd be happy to drop this phrase from *this* >>>>charter, in anticipation of it being worked out in discussions about >>>>the *next* one. >>> >>> Well, I think the phrase does need to be replaced >>> by something else all right. >>> >>> I'm reluctant to omit mention of security entirely >>> of course and do want to know what's gonna be done >>> for authentication in a putative HTTP/2.0. >>> >>> Like I said, I'm pretty skeptical that any significant >>> change to security properties will be achievable at >>> that next charter stage. >>> >>>>> And then should it include adding some new options >>>>> or MTI auth schemes as part of HTTP/2.0 or even looking >>>>> at that? (I think it ought to include trying for that >>>>> personally, even if there is a higher-than-usual risk >>>>> of failure.) >>>> >>>> >>>> Based on past experience, I think the risk is very high, and we don't >>>>need to pile any more risk onto this particular project. >>> >>> Based on past experience the milestones for this will be >>> wildly optimistic and it'll really take five years so at >>> the end of 2017 we'll be right where we are in terms of >>> HTTP authentication for all of which time HTTP authentication >>> will be the "next thing" to do. (Ok, I'm exaggerating a >>> bit there.) >>> >>> I think both experiences are valid. >>> >>>> Also, most of the discussions about authentication and associated >>>>problems on the Web are *not* exclusive to HTTP or even protocol >>>>artefacts; they include concerns like UI and human factors, >>>>integration into hypertext, etc. As such, what we really need is a >>>>"whole of stack" focus on Web authentication; shoving it into this >>>>particular WG will, IMO, lead to a predictable failure. >>> >>> It is true that many sites don't use HTTP authentication >>> for UI reasons. I don't think it follows that doing nothing >>> is the right approach. (Well, one could argue to remove all >>> user authentication from HTTP I guess - is that one of the >>> proposals?) >>> >>> Cheers, >>> S. >>> >>> >> >> -- >> Mark Nottingham >> http://www.mnot.net/ >> >> >> >> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf