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(_at_)comcast(_dot_)net
+1-603-828-1401
On 2/21/12 6:01 PM, "Stephen Farrell"
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf